as long as your iptables is saved regularly, this command is pretty useful for those IPs that just seem to linger and never go away. i have this problem with IPs in korea.
as such, i’ve implemented the following “paranoid” iptables rule which i consider pretty helpful to keep them out for good:
# iptables -t nat -I PREROUTING 1 -s 222.122.0.0/16 -j DROP
simply put, this bans the entire 222.122.x.x subnet on the NAT table and prevents any packets from coming in.
paranoid iptables: block that IP range for good.
port utilization checkup.
i run nmap on localhost on a nightly basis and compare the results (which are emailed to me) against the previous night’s. this way, i can tell if something happened at a certain time if a new port mysteriously opens itself.
today, i encountered an open port on 6010. i investigated who was using them by running the following useful commands, which i am posting here for reference:
# /usr/sbin/lsof -i TCP:6010
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sshd 21176 user 9u IPv4 13084094 TCP localhost:x11-ssh-offset (LISTEN)
guess he was using X11, which opens an additional port.
i further broke this down by looking into the following:
# /sbin/fuser -name tcp 6010
here: 6010
6010/tcp: 24345
this indicated that process ID (pid) 24345 was doing something funny.
so i looked into the pid:
# /usr/sbin/lsof -p 24345
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sshd 24345 user cwd DIR 8,5 4096 2 /
sshd 24345 user rtd DIR 8,5 4096 2 /
sshd 24345 user txt REG 8,5 309200 20922628 /usr/sbin/sshd
sshd 24345 user mem REG 8,5 941024 23234362 /lib/libcrypto.so.0.9.7a
sshd 24345 user mem REG 8,5 14542 23234382 /lib/libutil-2.3.4.so
sshd 24345 user mem REG 8,5 63624 3069543 /usr/lib/libz.so.1.2.1.2
sshd 24345 user mem REG 8,5 56328 23232671 /lib/libselinux.so.1
[snip]
point being: i now knew the source of the open port, and it was harmless.
on the other hand, if it was something to wonder about, i’d have killed the process using kill -9 24345 and have figured out the entry point to the server in order to better secure it.
checking for exploits on a server: my first bash script.
well, this script was inspired by another script, but i’ve modified this to send email results and do a few other things, so i’m quite proud of the accomplishment.
the script (exploitcheck.sh) appears below. you can copy and paste this code snippet to a file with an .sh extension.
click here for the code.
this is a good shell script for use with linux environments where apache or the www user stores a lot of files in the typical directories (e.g. /tmp, /dev/shm, etc. it checks to see if anything abnormal is there and sends you the results when executed.
i’ve put this in my /etc/cron.daily to make sure that it runs on a regular basis.
make sure to change the variables and chmod 755 exploitcheck.sh when you store it on your server.