After my recent dark ages, is time to review my Debian security level... As a starting point, the Securing Debian Manual is a must for ANY Debian administrator. Moreover, there is some useful tools, e.g. tripwire, chkrootkit and fail2ban, too.
Tripwire (http://www.tripwire.com/)
It is a great and handy tool. Tripwire will scan all the directory/files that you are interested in, giving them a MD5 fingerprint, check and compare it periodically, then send you a report though Anacron.
The installation of Tripwire is not too complicated in Debian, just run the following command:
apt-get install tripwireDuring installation dpkg will ask for "site-key passphrase" twice. You can input 2 different set of password for them, but usually I will use the same.
Always use secure password! If you don't know how to generate a suitable password, install
pwgenand run the following command:
pwgen -c -n -y 8
Next, we need to go back to Tripwire configuration. Default Debian setup monitoring to some ALWAYS change directory/files, e.g. /var/log, /proc and so on. As they ALWAYS change, keep on monitoring them will just result as some always warning of change... In my case that seems to be meaningless... So let's mask them from /etc/tripwire/twpol.txt as below:
#
# These files change every time the system boots
#
#(
# rulename = "System boot changes",
# severity = $(SIG_HI)
#)
#{
# /var/lock -> $(SEC_CONFIG) ;
# /var/run -> $(SEC_CONFIG) ; # daemon PIDs
# /var/log -> $(SEC_CONFIG) ;
#}
# These files change the behavior of the root account
#(
# rulename = "Root config files",
# severity = 100
#)
#{
# /root -> $(SEC_CRIT) ; # Catch all additions to /root
# /root/mail -> $(SEC_CONFIG) ;
# /root/Mail -> $(SEC_CONFIG) ;
# /root/.xsession-errors -> $(SEC_CONFIG) ;
# /root/.xauth -> $(SEC_CONFIG) ;
# /root/.tcshrc -> $(SEC_CONFIG) ;
# /root/.sawfish -> $(SEC_CONFIG) ;
# /root/.pinerc -> $(SEC_CONFIG) ;
# /root/.mc -> $(SEC_CONFIG) ;
# /root/.gnome_private -> $(SEC_CONFIG) ;
# /root/.gnome-desktop -> $(SEC_CONFIG) ;
# /root/.gnome -> $(SEC_CONFIG) ;
# /root/.esd_auth -> $(SEC_CONFIG) ;
# /root/.elm -> $(SEC_CONFIG) ;
# /root/.cshrc -> $(SEC_CONFIG) ;
# /root/.bashrc -> $(SEC_CONFIG) ;
# /root/.bash_profile -> $(SEC_CONFIG) ;
# /root/.bash_logout -> $(SEC_CONFIG) ;
# /root/.bash_history -> $(SEC_CONFIG) ;
# /root/.amandahosts -> $(SEC_CONFIG) ;
# /root/.addressbook.lu -> $(SEC_CONFIG) ;
# /root/.addressbook -> $(SEC_CONFIG) ;
# /root/.Xresources -> $(SEC_CONFIG) ;
# /root/.Xauthority -> $(SEC_CONFIG) -i ; # Changes Inode number on login
# /root/.ICEauthority -> $(SEC_CONFIG) ;
#}
#
# Critical devices
#
#(
# rulename = "Devices & Kernel information",
# severity = $(SIG_HI),
#)
#{
# /dev -> $(Device) ;
# /proc -> $(Device) ;
#}Finally, run the following command to rebuild the tripwire configuration, and initialize your system snapshot:
dpkg-reconfigure tripwire
tripwire -m iYou will also need some follow up action during daily operation, tripwire --help can give you some idea:
Database Initialization: tripwire [-m i|--init] [options]
Integrity Checking: tripwire [-m c|--check] [object1 [object2...]]
Database Update: tripwire [-m u|--update]
Policy Update: tripwire [-m p|--update-policy] policyfile.txt
Test: tripwire [-m t|--test] --email addressChkrootkit (http://www.chkrootkit.org/)
A system snapshot can give you a hand for compare if there is any changes, but what if your server already infected and/or hijacked? In this case you will need a system scan tools. Rootkit (http://en.wikipedia.org/wiki/Rootkit) are some of the well-known form of hijack model after a system hack in, and so install chkrootkit can give you a hand for checking.
In case of Debian, install chkrootkit with the following command:
apt-get install chkrootkitThe operation of chkrootkit is quite simple. Just run chkrootkit in CLI and it will give you a simple report. I can't teach you how to fix those infected program in here, because most of them are case by case ;p
Fail2ban (http://www.fail2ban.org/)
So now we have system snapshot, we scan rootkits, what's the next? If you are hosting some public production servers, the brute force attack (http://en.wikipedia.org/wiki/Brute_force_attack) to SSH service should always annoying your system log, and also DNS scan, too. Fail2ban can let you define some rules for system monitoring, keep on checking your log report, setup deny rules into your firewall, which all running automatically in background.
Install fail2ban in Debian with:
apt-get install fail2banBy Debian's default only SSH will be monitoring. All default filters are located in /etc/fail2ban/filter.d and you should activate those services that interested in for monitoring. As mentioned in the header section of /etc/fail2ban/jail.conf, we should create a file called as /etc/fail2ban/jail.local which contain our changes for override, e.g.:
[ssh-ddos]
enabled = true
[apache]
enabled = true
[apache-noscript]
enabled = true
[apache-overflows]
enabled = true
[apache-badbots]
enabled = true
port = http,https
filter = apache-badbots
logpath = /var/log/apache*/*access.log
maxretry = 2
[exim]
enabled = true
port = smtp,ssmtp
filter = exim
logpath = /var/log/exim/mainlog
[courierauth]
enabled = true
port = imap2,imaps,pop3,pop3sSince Fail2ban is running as a system daemon so you will need to restart it after reconfiguration:
/etc/init.d/fail2ban restartFinally, check your firewall setting if there is any update changes, e.g. checking iptables with:
iptable -nvLYou should discover some new firewall chains are setup. In my case, I have setup protection for both courierauth, apache, ssh, apache-overflows, ssh-ddos, apache-noscript and exim, therefore the firewall should look like:
Chain INPUT (policy DROP 46114 packets, 6401K bytes)
pkts bytes target prot opt in out source destination
123 15018 fail2ban-courierauth tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,143,220,993,110,995
1657 280K fail2ban-apache tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
1174 86504 fail2ban-ssh tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
1657 280K fail2ban-apache-overflows tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
1174 86504 fail2ban-ssh-ddos tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
1657 280K fail2ban-apache-noscript tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
38 8460 fail2ban-exim tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465The extra firewall rules will only activation DURING blocking period. When they are still activate, you can discover them with iptables -nvL, e.g.:
Chain fail2ban-apache-badbots (1 references)
pkts bytes target prot opt in out source destination
14 728 DROP all -- * * 119.30.120.220 0.0.0.0/0
711 108K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0In order to change the block history, use cat /var/log/fail2ban.log | grep WARNING, e.g.:
2008-05-18 18:03:11,702 fail2ban.actions: WARNING [apache-badbots] Ban 119.30.120.220
2008-05-18 18:13:11,817 fail2ban.actions: WARNING [apache-badbots] Unban 119.30.120.220Bookmark/Search this post with:
Post new comment