A lot of information is available via anonymous logon which is called a
"null" session. This is one reason, among many others, that a firewall is
needed to protect your computer/network from untrusted networks. While such
information can be valuable to an attacker you can minimize risk by making
sure that strong passwords are enabled, that the guest account is disabled
[it is by default], and that you monitor audit logs for failed logons.

You can restrict or eliminate what a null session finds by tweaking the
security options for network access:  in the appropriate security policy
[secpol.msc for instance] and restricting anonymous. You also could disable
file and print sharing if the computer does not need it, use the Windows
Firewall to block access to file and print sharing, or enable a ipsec
require policy that does not respond to any non ipsec ESP/AH traffic and
restrict what computers have a compatible ipsec policy. Ipsec should be
implemented with care and fully tested. Domain controllers also can not
engage in ipsec ESP/AH with domain members.

Disabling null sessions all together can have some consequences particularly
with downlevel clients, external domain trusts, and the browse list that is
used to populate My Network Places. See the link below for more details.

http://support.microsoft.com/?kbid=246261

Just a comment in that if you really are having a problem with compromising
your test systems by doing Google searches and using the web then you really
need to lock down your computers. By default Windows 2003 has enhanced
security for Internet Explorer enabled which disabled such things as install
on demand and sets security for the internet Web Content Zone to high. I
suggest you read the free Windows 2003 Server Security Guide and the Threats
and Countermeasures Guide both which discuss anonymous access among a lot of
other security info.   --- Steve

http://www.microsoft.com/technet/security/default.mspx   --- TechNet
Security Center where you can download security guides and a whole lot more.

I do not want to seem as discounting Steve's good, Windows specific
information and advise.  However, I also feel you are asking a general
question in your post about how this is possible.

In general it is a service (of some type) that has bound to the network
interface (some protocol, some port, etc.) that is responsible for what
can be done when some client connects to the listener on that interface.

This has a couple of immediate implications, and is valid for all OSs.
First, it is the code that binds the listener that determines what will
happen - will it require authentication, some special handshake;
- what message formats will it expect, recognize; - what will it do
in response to accepted messages.  Here control is expressed in
the configuration of the service.

Second, the network stack is usually between the service and the
raw network traffic, and this imposes a layer with which other parts
of the OS may impose blocking of the external network traffice so
that it is or is not delivered to the listener. At this level are things
like IPsec, the wrapper code (if any) that is hosting the service,
tcpwrapper, etc..

Third, of course if the traffic cannot get to / from the host where the
listener is running then the whole thing can not / does not happen.
This is such as an external (from the host with the service) firewall.

Fourth and finally, if all of the above allow the service to attempt to
do something (like look up a piece of information for return, or to
execute something, etc.) then the OS and its subsystems might impose
restrictions on what may be done for the context that is running the
service, causing the service to succeed or fail in that attempt.