By Kurt Seifried Rev 0.1
Network basics - Basic IPFWADM rules. (S01.C02)
IPFWADM is a great firewalling tool, it's performance/cost ratio is infinite (anything divided by zero..) and it's just generally pretty easy to use. Suggested reading is "Building Internet Firewalls" by O'Reilly (not sure of the title, my sister stole with my copy). Also suggested reading is "Practical UNIX and Internet Security" also by O'Reilly. I will go through each service by port number, specifying the rule(s) needed to allow it to work properly. I have always gone for pessimistic security polices (allow certain things, deny everything else by default) as they are more secure and in the long run less work.
A few general notes on IPFWADM, never set the default policy for Incoming or Outgoing to deny. Why? You're working on a machine remotely and you accidently flush the ruleset. You're locked out. Have a nice service call. Use rules to set a default deny (i.e. deny all ports as your last rules), thus when you flush the rules you can get back. Also pessimistic firewalling tends to severly break passive ftp, tell them to use a real ftp client like ftp or ncftp and not Netscape or MSIE (which do horrid things to ftp servers anyways). When you build any rules that allows remote machines to access your server from a specific port (say ftp/dns/etc) restrict them to incoming to 1025 and above if at all possible, otherwise they could say scan 1:1024 from there port 53 say and avoid some of your firewalling rules.
Common services you will want to use/provide:Service Name Port/Proto TCPWrappers Other Controls ftp-data 20/tcp yes ftp 21/tcp yes ssh 22/tcp no (daemon) /etc/ssh/sshd_config telnet 23/tcp yes /etc/passwd, /etc/login.defs smtp 25/tcp no (daemon) /etc/mail/* domain 53/tcp no (daemon) /etc/named.conf domain 53/udp no (daemon) /etc/named.conf dhcpd 67/udp no (daemon) /etc/dhcpd.conf finger 79/tcp yes www 80/tcp no (daemon) htpasswd/firewall pop-2 109/tcp yes pop-3 110/tcp yes auth 113/tcp yes nntp 119/tcp no (daemon) config/firewall (I like DNEWS) imap 143/tcp yes https 443/tcp no (daemon) htpasswd/firewall/require certificates nfs 2049/udp no (daemon) /etc/exports proxy 3128/tcp no (daemon) config/firewall (I like SQUID)
Common services you should block at all costs. These are the 'bad' ones:
Service Name Port/Proto TCPWrappers Other Controls icmp NA NA netstat 15/tcp yes netbios 137,138,139/tcp/udp snmp 161 snmp-trap 162 exec 512/tcp yes biff 512/udp login 513/tcp who 513/udp shell 514/tcp yes syslog 514/udp
There are more services of course but these are very common ones, most either support tcp_wrappers (being called out of inetd) or have their own set of controls (ssh is a great example). A good security policy is multi-layered, use firewalling, tcp_wrappers, controls, chroot, tripwire, etc, etc, the more layers the harder it is for an attacker, and the sooner they are likely to set off an alarm, giving you time to react.
FTP
By far the most troublesome service to firewall properly. It does extremely strange things, clients connecting to port 21, the ftp server connecting out to the client from port 20, etc, etc. It's also one of the top 5 services, so simply turning it off often isn't an option. If you wish to allow passive FTP to work you basically cannot do any incoming firewalling above port 1024. I like to block as much as possible, pessimistic policies, etc. For ftp to work you will need the following rules:
A rule to let people use ftp clients on the server (like the admin...) so that people can access remote ftp sites, very useful.
Rules to allow the FTP Server to work:
SSH
One of the easier services to restrict, simply allow incoming to port 22/tcp from wherever you want, and in addition to that use /etc/ssh/sshd_config to lock it down nice and tight.
TELNET
Another one of the easier services to restrict, simply allow incoming to port 23/tcp from wherever you want, and in addition to that use /etc/hosts.allow and hosts.deny to lock it down nice and tight. Also using /etc/login.defs helps, set password aging/etc, remember users must have a valid shell (listed in /etc/shells) before they'll be let in.
SMTP
Another one of the easier services to restrict, simply allow incoming to port 25/tcp from wherever you want, and in addition to that use /etc/mail/* to lock it down nice and tight (primarily relaying/anti spam concerns). Also keep sendmail up to date. 8.8.8 and 8.9.0 are good.
DNS
One of the more interesting protocols, it uses UDP and TCP, UDP for normal queries (it's small and fast, if the query gets lost it'll resend) and TCP for zone transfers (moving a 2 meg file via udp while ok with nfs would stink in dns =). Hence you must allow both protocols in to your dns server for full functionality, OTOH if it's just a caching nameserver you can leave out tcp. Bind 8.X supports a very comprehensive set of access controls in named.conf, allowing you to secure zone transfers easily. It's also a good idea to allow incoming conenctions from dns servers, since they use UDP and sometimes do strange things.
For running a DNS Server:
For DNS clients:
DHCPD
An extremely interesting service, it uses UDP to answer broadcast requests for information, and assigns computers their IP, subnet mask, default gateway, etc. Firewalling it is a bit tricky considering that the inital dhcp discover packets are from, well, no IP technically speaking. However if your DHCPD server were accessible from the outside world (say it's also your gateway server like mine is) then several nasty attacks come to mind, the simplest being somone grabbing all the IP's up (which NT RAS server does, either turn RAS off, or make static entries for all the hosts).
FINGER
Another one of the easier services to restrict, simply allow incoming to port 79/tcp from wherever you want, and in addition to that use /etc/hosts.allow and hosts.deny to lock it down nice and tight. Finger is IMHO a DANGEROUS service. It's uses are rather arguable, seeing if/when someone is/was logged in, if they have mail or not, etc. Disable it if you are at all concerned about security.
HTTP
Another one of the easier services to restrict, simply allow incoming to port 80/tcp from wherever you want. It's a relatively safe service to run, although running it chrooted can help quite a bit. For info on that please see: chrooting Apache.
POP 2/3
Another one of the easier services to restrict, simply allow incoming to port 109/tcp (POP-2) and 110/tcp (POP / POP-3) from wherever you want, and in addition to that use /etc/hosts.allow and hosts.deny to lock it down nice and tight. POP is safe and semi intelligent, people can hammer away guessing usernames/passwords and it will simply reply username accepted, password please no matter what you put for a username. This is good since POP pretty much has to be available to the outside, traveling customers/clients/etc.
IDENT
Another one of the easier services to restrict, simply allow incoming to port 113/tcp from wherever you want, and in addition to that use /etc/hosts.allow and hosts.deny to lock it down nice and tight. Identd is a somewhat useless system, you can really only trust the output if you know the machine is locked down/etc/etc. Never ever use identd for authentication purposes. Disable it if possible.
NNTP
A relatively simple service to restrict, most NNTP servers have built in mechanisms for who is allowed to connect, read, post, etc news. I personally prefer DNEWS, easier to config and setup the INN, by default dnews keeps it's config files in /usr/local/dnews, access.conf, etc, and the format of the files is simple. Use them to lock down DNEWS somewhat more legantly then blanket firewall rules. Leaving a NEWS server open for public use will result in huge amounts of bandwidth getting used, generally a bad idea.
IMAP
Another one of the easier services to restrict, simply allow incoming to port 143/tcp from wherever you want, and in addition to that use /etc/hosts.allow and hosts.deny to lock it down nice and tight. IMAP has had several nasty bugs, due to the nature of what it is and does with the system restrict access as much ass possible. The problem is it is incredibly useful and makes POP look downright pathetic when you compare what the two can do. I plan to write a chrooting Sendmail/POP/IMAP article, look out for it if you are interested.
HTTPS
Another one of the easier services to restrict, simply allow incoming to port 443/tcp from wherever you want. It's a relatively safe service to run, and with Apache-SSL/etc you can typically specify that clients connecting must have a valid certificate, providing a strong level of authentication and security in general.
NFS
Good old NFS. It's incredibly useful, and incredibly dangerous. Allow incoming only from hosts that need to access it. I mean it. Also use /etc/exports, and do not specify names, use IP's, harder to fiddle with. If you give out any RW mounts only do so on an internal trusted network, intercepting/piggy backing an nfs session is far to easy. Use SSH / IPSec or some other encryption scheme to tunnel it if you need to run it across a public network (i.e. the Internet). NFS uses udp, and is slower then ftp for large file transfers, using an ftp server and ftp mirroring software can be a better option for some situations.
SQUID
Another one of the easier services to restrict, simply allow incoming to port 3128/tcp (the 'normal' proxy port) from wherever you want, and in addition to that use /etc/squid/squid.conf to lock down access, it has an extremely rich set of ACL's (Access Control Lists). Allowing external users to use your SQUID server put additional load on the server and is typically less effecient then going straight to the site (the data goes down your pipe then back out to whoever is using your server from externally).
Returned Connections (Client Software)
Allowing tcp packets with the ACK bit set (ie data using an established connection) is relatively safe, and allows useful things like smtp, ftp, etc to work properly =)
Blocking everything else
Instead of using a default deny policy, do it explicity in the rules. Why? when you flush the rules you don't lock yourself out.
Trusted networks
Often times you have a 'trusted' network, for example my lan consists of 3 machines attached to the internet, and to my internal network, and on my internal network are another 6 machines (Win95, NT, Linux, etc). I trust them explicitly since they are in a physically secure environment (my house). Add this rule at the top of your list, remember that IPFWADM checks rules sesquentially, so typically you put your allow rules first, and then your deny rules. It's also a good idea to specify the adapter, in my case eth0 is attached to the internet and eth1 is always the 'internal' adaptor.
Now for the "bad" ones
If you're using an optimistic security policy for firewalling, at least block the following services, or you will get hurt
ICMP
ICMP, Internet Control Message Protocol, is a neccesary part of Internet infrastructure, however it is typically not needed at the 'end' of the pipes, ie workstations on a LAN, or basically anything that isn't acting as a router/etc. There are also many ICMP based attacks, 99% of which are spoofed, making any sort of logging quite useless. Block incoming and outgoing, this will break ping and traceroute, which are useful tools granted, but since you can't source route packets/etc anymore knowing that a link is slow isn't gonna help much.
netstat
The equiv of 'nbtstat some_target' on an NT box. Tells people far to much. By default it no longer exists in RedHat 5.1 (wonder why.....).
netbios
Windows file and print sharing, aka SMB/samba. Windows 95/NT tcp-ip stack is incredibly broken out of the box, and at all costs you should prevent people ont he internet from even coming close to your windows machines. So far there are about 10-20 remote attacks that will crash/reboot/hang MS products...
snmp and snmp-trap
9 time out of ten your SNMP community name is public, knowing that someone can do a lot of damage to you. Hence blocking it is a 'good' idea, especially considering what could be done by a malicious person with access to your SNMP enabled hardware/software.
Remote services, syslog, etc
R* services are notorious security holes and a favourite avenue of attack for crackers, and syslog suffers from being a bit to trusting. If you need to do remote administration I cannot stress SSH to hard.
Contact Kurt Seifried, All rights reserved Kurt Seifried 1998, content and information may not be reposted physically or electronically without the express permission of the author, this includes but is not limited to www mirror sites, email, usenet news, etc.