Re: Checklist (was Re: OS Hardening)
On Wed, Dec 13, 2000 at 10:36:44AM -0800, Michael Smith wrote:
> What I do:
I do something similar:
> 1-Custom package selection, try to weed out talkd, telnetd, and some others that
> are installed by default.
If rebuilding a box, I make sure that I have a dpkg --get-selections in a
file that can be uploaded. If not, select packages individually based on
the purpose for the machine.
> 2-netstat -a | grep LIST or netstat -l to find out who is listening for
> 3-kill all the packages that are running that I don't want and that slipped past
> me earlier.
> 4-add ALL:ALL or ALL:PARANOID and specific services by name that I want to
> restrict to /etc/hosts.deny, depending on what the box is going to be used for.
You can also add a spawn that emails you when a rule gets busted. Add the
following to /etc/hosts.deny:
ALL: ALL: spawn ( \
echo -e "\n\
TCP Wrappers\: Connection refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
" | /bin/mail -s "Connection to %d blocked" root)
> 5-allow access to my local network or to specific services with /etc/hosts.allow.
> 6-edit /etc/inetd.conf to remove unwanted services.
Generally, I write a blank file to inetd.conf and disable inetd. Generally
speaking, nothing I use needs inetd.conf. ftp is generally started from
/etc/init.d, telnet is completely off, etc.
> 7-nmap localhost to see what ports are open.
I use nessus, which gives you a more complete report...And uses nmap for
portscanning. This will catch things like vulnerable versions etc.
> 8-start ipchains, kill all chains with ipchains -F.
> 9-block off ports that I don't want the world to see but should be open to the box
> itself with:
> ipchains -A input -p TCP -s 0.0.0.0/0 -d 0.0.0.0/0 portname -j REJECT
> Alternatively, set the ipchains policy to REJECT and then open up specific
> ports with ALLOW
Best set of ipchains scripts are Peter W's, which were included in Bastille
Linux but are available separately at http://www.tux.org/~peterw. You have
to edit the script, but it is nice because it has 12 sections that have
user modifiable information, things like setting up how you want to handle
DNS, which interfaces are trusted, untrusted and semi-trusted (which means
you can set up a DMZ). They are very well done.
> 10-nmap localhost again to see that everything's good.
> 11-install logcheck and ippl. Possibly portsentry (in the non-free section)
> and/or snort for a "bastion host".
Or you don't want to deal with non-free, my package, scandetd is similar to
portsentry, though it doesn't have the response features of portsentry.
> 12-configure portsentry if I have it installed to block out attackers with
Personally I believe that automated response is a two-edged sword. If you
are paying attention to the application and who it is blockin, then
you should be ok. But if you are using it for automated protection, you are
asking for trouble. Of course, if you are watching closely, you shouldn't
need an automated response, since an human touch is generally better than a
For instance, I can configure nmap to scan your site and spoof addresses
from slashdot.org, freshmeat.net, your local dns server, etc. An unattended
script would dutifully block whatever sites I chose to feed to nmap.
I would also install (depending on the type of server), snort, which is a
tcpdump/libpcap-based intrusion detection system that actually looks into
the packet. (especially on a firewall.)
After this, I scan again to make sure I haven't opened any new holes, plus
to make sure that snort, scandetd and ippl are working properly.
I would also, before putting it online, set up aide or tripwire and keep a
copy of the binaries and databases offsite.
Bradley M. Alexander, CISSP | Co-Chairman,
Beowulf System Admin/Security Specialist | NoVALUG/DCLUG Security SIG
Winstar Telecom | email@example.com
(703) 889-1049 | firstname.lastname@example.org
Consciousness: That annoying time between naps.