Watch for top Linux/Unix threats
Published: 22 Oct 2002 08:29 BST
Ports to block
Of special interest to those who must make quick and dirty fixes, this is the list of ports to block at your firewall that can dramatically reduce your problems. The list is taken directly from the SANS/FBI report:
Login services
Telnet (23/tcp), SSH (22/tcp), FTP (21/tcp), NetBIOS (139/tcp), rlogin et al (512/tcp through 514/tcp)
RPC and NFS
Portmap/rpcbind (111/tcp and 111/udp), NFS (2049/tcp and 2049/udp), lockd (4045/tcp and 4045/udp)
NetBIOS in Windows NT
NetBIOS 135 (tcp and udp), 137 (udp), 138 (udp), 139 (tcp) For Windows 2000, you also have to include 445 (tcp and udp)
X Windows
6000/tcp through 6255/tcp
Naming services
Block DNS (53/udp) to all machines that are not DNS servers, DNS zone transfers (53/tcp) except from external secondaries, LDAP (389/tcp and 389/udp)
Mail
SMTP (25/tcp) to all machines, which are not external mail relays, POP (109/tcp and 110/tcp), IMAP (143/tcp)
Web
HTTP (80/tcp) and SSL (443/tcp) except to external Web servers -- may also want to block common high-order HTTP port choices (8000/tcp, 8080/tcp, 8888/tcp, etc.)
"Small Services"
Ports below 20/tcp and 20/udp, time (37/tcp and 37/udp)
Miscellaneous
TFTP (69/udp), finger (79/tcp), NNTP (119/tcp), NTP (123/udp), LPD (515/tcp), syslog (514/udp), SNMP (161/tcp and 161/udp, 162/tcp and 162/udp), BGP (179/tcp), SOCKS (1080/tcp)
ICMP
Block incoming echo requests (ping and Windows traceroute). Block outgoing echo replies, time exceeded, and destination unreachable messages except "packet too big" messages (type 3, code 4). This assumes that you are willing to forego the legitimate uses of ICMP echo requests in order to block some known malicious uses.
A useful defense, if not a solution
Blocking the ports on this list won't actually fix any vulnerabilities, so blocking these ports is really a stopgap measure. Nevertheless, in concert with the top 20 list itself, the port block list can be a valuable tool for those who are swamped with the shear volume of threats they must address.
Final word
Many of the vulnerabilities found in Unix (and therefore in Linux) stem from the days when a modem ran at 0-300 baud and was a rare piece of hardware. Hackers were the good guys, and you had to have physical access to a computer to do any damage. I wouldn't want to go back to those days, but security was definitely a different game back then. Unfortunately, many of the legacy features of Unix, which were designed for that era, now make it vulnerable. And apparently, not enough systems have been updated or had unnecessary features disabled to circumvent the problems. The SANS/FBI report can help you make the proper adjustments for today's connected environment.
Have your say instantly in the
Tech Update forum.
Find out what's where in the new Tech Update with our
Guided Tour.
Let the editors know what you think in the
Mailroom.





