This article applies in the main to PCs connected directly to the cable modem, and to a PC configured as the DMZ machine on a NAT Router. Other PCs connected to a NAT Router are much safer from external network attack, because the router blocks incoming calls that it does not know how to handle.
The golden rule of security on public TCP/IP networks is: Keep unwanted ports closed. A hacker can only penetrate your PC (a) if you leave a port open for him to attack on; and (b) if that port exposes a vulnerability which can be exploited. Having a vulnerable port open to the public network is like leaving your front door open while you are away from home: you should not be too surprised if you get burgled.
In principle, if a port does not expose a vulnerability, then there is no need to worry about it being open. The idea that a hacker can slip a trojan in through any open port is a paranoid urban myth.
Some distributions of the Linux operating system are problematic in respect of unwanted open ports. From a fresh installation, such distributions come with almost all network services enabled by default, leaving many ports open to the world for services that a normal end-user would never need to offer to a network. Many of these services have, in their first installed form, known security vulnerabilities (until extra patches have been applied), and these leave the machine vulnerable to hackers the world over that scan for these specific vulnerabilities. No Linux machine should ever be connected to a network until (a) all relevant patches have been applied, and (b) all services have been turned off, except those which are explicitly required (such as a DHCP client).
In Windows you can get a list of open ports by opening a command prompt window and giving the command netstat -a, with results looking like this:
C:\WINDOWS>netstat -a Active Connections Proto Local Address Foreign Address State TCP rdhw-a:137 RDHW-B:0 LISTENING TCP rdhw-a:138 RDHW-B:0 LISTENING TCP rdhw-a:nbsession RDHW-B:0 LISTENING UDP rdhw-a:nbname *:* UDP rdhw-a:nbdatagram *:*
Each of the UDP lines, and each of the TCP lines in state LISTENING is a port open to the world. In the Local Address column, the port number appears after the colon. In some cases, the port number has been translated to a service name: the table of translations is in the text file C:\WINDOWS\SERVICES for Win 9x/ME, or in C:\WINNT\system32\drivers\etc\services for Win NT/2000. Note the absence of a .txt extension in both cases. You can view the connection list without the text translations by using netstat -an.
Ports 137 (nbname), 138 (nbdatagram) and 139 (nbsession) belong to the NetBIOS transport protocol upon which Microsoft networking is based. Windows 2000/XP also use port 445 (microsoft-ds) for Microsoft networking without NetBIOS. These open ports are therefore to be expected on a Windows system. Any others need to be checked out to see whether they are legitimate or not. For instance, it is characteristic of infection with trojan horses such as Back Orifice or SubSeven that they open a port, waiting for some script kiddie to come by, detect the open port, and use the port to perform some malevolent act on your PC. However, it does take some experience to tell the difference between a legitimately open port and one which is the result of a hostile resident trojan horse. For this reason, it is advisable to have a good virus-checking program scan your entire system from time to time, checking for trojan horse infections. It is essential that you keep your virus-scanner up to date, with virus definition updates being applied at monthly intervals or more frequently. You need an anti-virus system more than you need a firewall.
In the meantime, ports 137-139 and 445 themselves are a security vulnerability if the user has file-sharing or printer-sharing turned on, and many users are unaware whether they have these services turned on or not. Assuming that you do not actually want to share your hard disk or printers with other PCs on the global internet, a Windows 9x/ME user can turn these services off as follows:
A Windows 2000/XP user can turn these services off as follows:
The above will lock out hackers trying to access your hard disk, by eliminating the exploitable vulnerabilities on ports 137-139 and 445. It will not close ports 137-139 and 445, which remain held open by Client for Microsoft Networks, the component that allows you to use files and printers on other Windows computers. In this state, hackers will still be able to deduce something about the identity and configuration of your PC, but they will not be able to break in. If you are so paranoid that you want to close ports 137-139 and 445 completely, then see the excellent discussion at http://cable-dsl.home.att.net/#Security and then http://cable-dsl.home.att.net/netbios.htm for a demolition of NetBIOS hysteria and FUD.
With Windows NT/2000, if you choose to leave File and Printer Sharing for Microsoft Networks enabled, then be aware that, out of the box, Windows NT/2000 share your entire hard disk(s) with the world, with no protection at all, unless you define passwords for Administrator accounts. It is absolutely essential that you define hard-to-guess passwords for all Administrator and User accounts. However convenient it may be to operate locally with null passwords, your PC is wide open to attack on the network unless all accounts have hard-to-guess passwords.
With Windows NT/2000, also be aware that, when sharing an object with File and Printer Sharing for Microsoft Networks, the default Permission is Full Control by Everyone, and Everyone includes Guest. For this reason, you should keep the Guest account disabled (or give it hard-to-guess password like any other account).
If you have good reason to offer the file-sharing service to the internet, ensure that you follow these guidelines to keep your PC secure:
If you want a DMZ machine, or an ICS/router machine, to offer file-sharing to other PCs on your home LAN, you should consider transferring the transport of Microsoft Networking from TCP/IP to NetBEUI, a protocol designed for LAN use, which is blocked by the cable modem, and thus secure from external probing. See http://cable-dsl.home.att.net/#Security for how to do this.
For further reading:
Apple Macintoshes by default keep all their TCP/IP ports closed unless a user application explicitly opens them, so they tend to be naturally more secure than other platforms. Traditional AppleTalk networking is filtered out by the cable modem, so even old-style File Sharing does not represent a security risk. However, Mac OS 9 and higher have, in the Start/Stop tab of the File Sharing control panel, a check box entitled Enable File Sharing clients to connect over TCP/IP. If both (a) this check box is checked, and (b) File Sharing is on, then ports 427 (Service Location Protocol) and 548 (Apple Filing Protocol) will be open to the internet. You should do this only if you wish other internet users to have access to your shared folders or disks. In this case, you should first define the Owner Name, Owner Password, and Computer Name fields on the Start/Stop tab, then use the Users & Groups tab to define userids and passwords for those users to whom you wish to grant access. Then apply the following guidelines:
Apple Mac users can check open ports (and more besides) with utilities such as Interarchy or IPNetMonitor.
A personal firewall is a program which you can add to your PC or Mac which monitors incoming network connection attempts, and takes action according to a set of rules which you help to supply. It might permit the connection, log the attempt, or just not respond to the attempt.
A list of freely downloadable personal firewalls for Windows is at http://www.webattack.com/freeware/security/fwfirewall.shtml.
There are some downsides to personal firewalls:
For information on what you might see in firewall logs, see http://www.robertgraham.com/pubs/firewall-seen.html. There is a particularly useful section on understanding NetBIOS probes, and how most of them are harmless parts of network life.
Some firewalls have a hiding mechanism they call stealth. For instance, the High Security setting in ZoneAlarm is an example of stealth mode. In stealth mode, the firewall causes the PC just to ignore incoming connection attempts, rather than rejecting them, as would be normal for incoming connection attempts to closed ports. The result is that the PC appears to be switched off and absent from the network.
This hyper-paranoid approach to security causes some difficulties. For a start, Internet standard RFC 1122 states categorically about ICMP Echoes (ping):
3.2.2.6 Echo Request/Reply: RFC-792
Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies.
Note the MUST rather than SHOULD. This means that any internet user, or ISP server, has a right to expect that all live PCs connected to the internet will respond to ICMP ping requests with an ICMP reply. If a firewall user chooses to stealth ICMP requests so that no response is sent, they have only themselves to blame if they start experiencing problems, because they are in breach of RFC 1122.
The problems that might arise if you kill ICMP responses with stealth are:
So you are strongly advised not to apply stealth techniques to the ICMP protocol. In the freeware version of ZoneAlarm, this means you should run it in Medium Security, not High Security, for the Internet Zone. In ZoneAlarm Pro, you can configure ICMP behaviour to permit ICMP Echo packets in and out even in High Security, using the Customize button of the Security Settings panel.
Windows XP has a built-in firewall that by default blocks ICMP Echo. You should uncheck this feature.
Similar problems arise with certain NAT routers, such as the Linksys. By default, the Linksys does not reply to incoming ICMP requests, equivalent to a stealth firewall. To configure the Linksys to reply properly to all incoming requests, send your web browser to the Linksys configuration page at http://192.168.1.1/ and then:
A commonly heard objection to allowing ICMP Echo Replies is that it gives away information to hackers that there is a live connection on this IP address. Such objections are not well-founded, and can be safely ignored. There is no evidence in practice that any hacker has been aided by the presence of an ICMP Echo Reply. Hackers do not typically write code that tests an address with ICMP Echo before launching a hostile probe: they always send the hostile probe directly: either it works or it doesn't, and information from ICMP adds nothing to the analysis.
With cable modem connections, most firewalls do not work correctly using their default configuration. Some extra configuration is always required from the user. There are many possible combinations of operating system and firewall, so this article will cover first an all-inclusive specification of what might need to be achieved to minimise firewall-related problems: how you achieve this specification will depend upon your specific operating system and firewall. Some firewalls are host-based, and require addresses of trusted hosts to be configured, regardless of protocol. Some firewalls are protocol based, and require port numbers to be configured as open, regardless of calling host. Some advanced firewalls allow you to specify rules combining both host addresses and protocols. Some tips for specific common combinations of operating system and firewall follow below.
The specification: to minimise firewall-related problems on a cable connection, you might need to configure the following combinations of hosts and protocols to be trusted with access to the appropriate client applications or processes on your PC or LAN:
Of the above list, the UBR's private IP address (see Finding the UBR Address above) seems to be the most important (and the one which causes difficulties unique to cable connections): the UBR acts as a DHCP Relay Agent (see RFC 2131). Several users have reported that they had difficulties acquiring or renewing their DHCP lease (symptom: disconnection every few hours) until they included their UBR as a trusted host (or permitted DHCP protocol from any host). Some firewalls are smart enough to recognise a normal DHCP transaction, but few are smart enough to recognise the validity of the DHCP broadcasts emanating from an apparently off-subnet address such as the UBR's private IP address. See more below.
To discover the cable modem address, see Finding the cable modem's address. Note: This recommendation to trust the cable modem itself is made in order to avoid false alarms from the firewall caused by the normal operation of the cable modem: some models of cable modem originate IP traffic themselves. For instance, the Surfboards multicast IGMP probes, which should not be treated as a cause for alarm. It should not be necessary to trust the cable modem address merely in order to browse its diagnostic pages, for instance, so you might be able to omit configuring the cable modem address.
To discover the DNS server addresses, see Finding the DNS server address(es). These will not necessarily be your ISP's standard published DNS servers: the ones you need to trust are the ones actually being used, for instance, as notified in the DHCP lease. Note: This recommendation to trust the DNS servers is made not to enable the proper operation of the DNS system, but to avoid false alarms from the firewall when the DNS system does not work properly. Firewalls ought to be smart enough to recognise that replies from DNS servers are valid, but in practice DNS replies can be very slow to arrive, and can trigger false alarms in firewalls when they are late. These false alarms can be avoided by configuring the DNS servers as trusted hosts. Also, there were problems in some versions of DNS server software that caused a different DNS server to reply than the one to which the query was sent: in this case, a firewall will always raise an alarm to the reply - if this happens to you, just add the replying DNS server address to the list of trusted hosts.
To discover the DHCP server address, see Finding the DHCP server address. Pace digital TV STB users in ex-C&W regions of NTL should note that they have two DHCP servers, 10.0.xxx.70 and 10.0.xxx.71, and both need adding as trusted hosts to the firewall. Blueyonder users should note that they have two DHCP servers, and both need adding as trusted hosts to the firewall.
If your firewall can distinguish the internet usage of individual applications or processes in your system, then the above configurations for UBR private IP address, DHCP server(s), and DNS server(s) need be applied only to the applications or processes running the local DHCP or DNS clients, rather than the entire system.
If your firewall is on a home LAN behind a NAT router, then you may omit both the UBR and the DHCP server(s) from the trusted host list, as the NAT router will provide DHCP service to the LAN.
Configure the hosts listed above (UBR, DHCP, DNS servers) as trusted by adding them to the Local Zone (ignore the protocol and port information above). Click Security Settings, click Advanced, [in ZoneAlarm Pro click tab Local Zone Contents], click Add >> IP Address. The Local Zone must then be set to Low security (or maybe Medium will work?).
Click the Programs tab. Ensure that the entry for Services and Controller app (services.exe) shows a tick for Allow connect in the Internet Zone, and a tick for Allow server in the Internet Zone. Click the Options button, and check Allow the program to pass through the lock. This removes all firewalling from services.exe and allows it to function as DHCP and DNS client without needing to configure specific servers as trusted. To prevent late DNS responses creating false alarms, you should also configure your DNS servers into the Local Zone as described above for 95/98/ME.
If your PC is connected directly to the cable modem, without any intervening router, then you should configure your firewall to not trust the local sub-net (by default, many firewalls trust the local sub-net), as you do not want other users on the same CATV distribution sub-net to have access to your PC:
- In ZoneAlarm: click Security Settings, click button Advanced, and uncheck all entries under Adapter Subnets.
- In ZoneAlarm Pro 2.6: click Security Settings, click button Advanced, click tab Local Zone Contents, and uncheck all entries under Networks.
If your PC is part of a home LAN, then you will want to trust the local sub-net, so do the opposite of the last paragraph, and check the Subnet or Network entries.
For more on ZoneAlarm 2.6 configuration on cable connections, see http://www.zonealarm.com/store/content/support/znalmNetworkFAQ.jsp. References on that site to gateway should be taken to mean UBR.
Configure the hosts listed above (UBR, DHCP, DNS servers) as trusted by adding them to the Trusted Zone (ignore the protocol and port information above):
For more see: http://www.mcafeehelp.com/faq.asp?docid=60827.
For advice on ipchains firewall configuration under Linux 2.2.x, see the TrinityOS HOWTO at http://www.ecst.csuchico.edu/~dranch/LINUX/TrinityOS/cHTML/TrinityOS-c-10.html.
Certain applications do not work correctly if you run a firewall (or a NAT router), unless you configure the firewall (or the NAT router) especially for them. Examples include:
The underlying problem is that such applications expect to be able to receive incoming connections, which a firewall or NAT router normally blocks. See http://www.practicallynetworked.com/sharing/app_ports.htm for instructions and a list of ports which might need to be opened.
Some DOCSIS-compliant cable modem send IGMP multicasts (destination 224.0.0.1, meaning any system on this sub-net) to the connected PCs once every 5 minutes or so. These are intended to reach your PCs. These multicasts should be allowed through a firewall, if only to avoid clogging your firewall log with useless entries.
Do not be concerned about broadcasts (e.g. DHCP) from your UBR: you need to allow these through the firewall, see next section.
Do not get over-concerned about ICMP pings from random internet hosts, particularly if you are browsing those hosts. Sending a maximally sized ICMP ping is part of one algorithm for determining the path-MTU for the connection back to you from the remote server. Just allow your PC to reply to them in the normal way: it will marginally speed up the setup of the connection. For the freeware ZoneAlarm, this means setting the Internet Zone to Medium Security, not High Security.
In the early stages of a DHCP exchange, a PC has to discover a DHCP server to talk to. When it starts, the PC does not know the address of the DHCP server, nor the address of the gateway out of the sub-net. Also, since the PC does not yet have an IP address, it is impossible to address IP packets back to the PC uniquely. So the early stages of DHCP discovery take place by broadcast in both directions. The PC transmits a broadcast calling for a DHCP server to respond. This is picked up by the gateway-UBR, which is a DHCP Relay Agent (see RFC 2131), and passed to the real DHCP server elsewhere in the ISP's network. The reply from the DHCP server also has to be broadcast back into the sub-net of the calling PC. The gateway-UBR therefore has to broadcast DHCP responses into the CATV network in the hope that the calling PC will recognise the reply intended for it. As a side-effect, every customer PC on the CATV network will also receive these DHCP broadcast replies, all of which will appear to emanate from the UBR's private IP address 10.xxx.xxx.1 or 172.xx.xxx.254 (see Finding the UBR address), directed to the PC's DHCP client port. So it is an entirely normal part of network life for the UBR to appear to be attempting to access your PC's DHCP client port, and it should not be treated as an attempted intrusion. Moreover, your own PC needs to hear those broadcast replies itself when it undertakes a DHCP discovery: therefore you must configure your firewall to permit the UBR to access your PC.
Return to Index.