Logging and Trapping Port Scanning Tools

Logging and Trapping Port Scanning Tools is a must step after Port Scanning through Pen Testing was done successfully. The following Lab will go through how port scans are being logged and what are the the mechanisms used to Trap the attackers when they tend to use Information Gathering tools (Port scanning) such nmap. Besides, I will show you how to generate simple and useful IPtables reports for daily, weekly, or monthly use.

Objectives:

1. Generating Invalid Packets Logging Reports

2. Generating TCP Scan Logging Reports

3. Generating UDP Scan Logging Reports

4. Other Types of IPtables Logging Reports

5. Managing IPtables xt_recent Hitcount/Traps

Prerequisites:

A. Basic Linux Debian, Ubuntu, or CentOS Knowledge

B. If you haven’t built a VPS yet, login to DigitalOcean or Vultr

C. Linux VM/VPS Fundamental Configuration Labs

Recommendations:

For better performance, use VPS with at least 2 CPUs, 4G Memory, 1G Bandwidth, and SSD Storage drive.

Generating Invalid Packets Logging Reports

As you know, I have dedicated a file especially for IPtables firewall logging at Redirecting IPtables Firewall Logging Location. Logging intruders attempts useful for many reasons, 1) to verify your IPtables rules, 2) for your own records if needed, 3) IPtables logging will be used later on by the Intrusion detection tools to block repeaters. So, in this Lab, I will focus at how nmap scan types get logged and trapped using IPtables Firewall xt_recent Module.

In my previous, Lab Scanning IPtables Firewall using Nmap Tool, I went through most known nmap scan types that are being used by attackers to gather information about your VPS, and demonstrated how IPtables Firewall Dropped and Blocked such scan types. In this part of the Lab, I will show you how IPtables logged these attempts and trapped the Attacker IP Address.

Note: Due to Pen Testing, I noticed that the Log service glitched after too much logging. Restart the service before going further, otherwise, you won’t be able to view the up2date logging.

Debian Based

service rsyslog restart

Red Hat Based

service rsyslog restart

Or Systemd Based Systems

systemctl restart rsyslog.service

Run the following steps (1 to 4)

1. Invalid Packets Scan Report

You can view Invalid Packets Logs which will include -sX, -sN- and -sF Port Scan types as well, using the following command:

Debian Based

grep -i "IPT Drop INVALID Packets: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$15,$16}' | uniq -c | sort -n | tail

CentOS Based

grep -i "IPT Drop INVALID Packets: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13,$14}' | uniq -c | sort -n | tail

Note: Both commands work just fine at both Operating Systems, however, you need to tweak print numbers. At Debian 15 and 16 show the Source and destination IPs. At CentOS, 13 and 14 do the job.

Below, you will see an output if your VPS IPtables Firewall already logged the attempts. The last line shows the number of Invalid Packets attempts made by my home IP Address based on dates shown. April 7 were the highest number of attempts.

  1 Apr 9 22:44:11 IPT Drop INVALID Packets: SRC=8.35.179.200
  1 Apr 9 22:47:08 IPT Drop INVALID Packets: SRC=27.188.63.121
  1 Apr 9 22:54:59 IPT Drop INVALID Packets: SRC=184.0.85.152
  1 Apr 9 23:09:12 IPT Drop INVALID Packets: SRC=200.150.2.194
  1 Apr 9 23:31:53 IPT Drop INVALID Packets: SRC=8.35.179.200
  1 Apr 9 23:44:34 IPT Drop INVALID Packets: SRC=8.35.179.200
  1 Apr 9 23:45:31 IPT Drop INVALID Packets: SRC=13.92.194.185
  1 Apr 9 23:47:17 IPT Drop INVALID Packets: SRC=64.50.230.77
  2 Apr 11 22:56:32 IPT Drop INVALID Packets: SRC=103.255.237.65
  7 Apr 11 22:56:32 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS

Note: there is a tail command at the end of the upper long command, if you can’t see any output, use -n 100 at the end of the tail command to view hundred lines instead of 10 lines. Or use more command instead of tail.

What does the following mean?

uniq -c > each IP Address in here is uniq field, hence, will show its attempts.

sort -n > will sort per attempt base, remove sort -n to show per date instead.

tail -n 100 > will show the last 100 lines, tail by itself shows only 10 lines.

SRC= which is the source IP Address that tried to send Invalid Packets.

For instance, I picked up the first IP address and ran look ip tool against it, at this link http://whatismyipaddress.com/ip/208.100.26.228, and once I clicked the Blacklist bottom, I found that this IP has been blacklisted by some known blacklists.

IPv6 Version of the Report

Note: when you search for IPv6 logging, use “IP6” instead of “IPT” prefix, besides, IPv6 source IP Address (SRC) filed located at field 13 instead of 14 for IPT. Move the bar to see the whole command.

grep -i "IP6 Drop INVALID Packets: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | uniq -c | sort -n | tail

If IPv6 report return nothing, it means no Invalid attempt logged yet.

2. Invalid Packets Scan Report for Specific IP

Since you most probably run Nmap scans from your home, Stealth Nmap Scan types will be logged as “IPT Drop INVALID Packets: “, adding grep -i YOUR-HOME-IP-ADDRESS to the end of the command, will show you the “IPT Drop INVALID Packets” generated from your Home IP address.

grep -i "IPT Drop INVALID Packets: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | sort | uniq -c | sort -n | grep -i YOUR-HOME-IP-ADDRESS | tail

Below, the output shows the number of Invalid Packets attempts made by my home IP Address based on date shown. April 11 was 7 attempts.

  1 Apr 8 16:19:06 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 20:20:00 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 20:21:15 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 22:14:04 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 22:26:07 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 23:13:00 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 23:17:47 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS
  1 Apr 9 11:07:30 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS
  1 Apr 9 11:08:53 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS
  7 Apr 11 22:56:32 IPT Drop INVALID Packets: SRC=MY-HOME-IP-ADDRESS

3. Report Based on Number of Attempts

If you just want to know the total number of Invalid Packets attempts against your VPS from all IP Addresses, run the following command:

grep -i "IPT Drop INVALID Packets:" /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | awk '($(NF-1) = /IPT Drop INVALID Packets:/){print $NF}' | uniq -c | sort -n | tail

This Invalid Packet report counts all the attempts apart of a date. Over all, the last IP Address below was the highest IP Address since it was my home IP Address.

  6 SRC=73.210.215.187
  7 SRC=141.101.96.187
  7 SRC=87.98.147.126
  8 SRC=178.210.80.163
  8 SRC=8.35.179.200
  10 SRC=46.253.147.175
  10 SRC=54.72.218.58
  11 SRC=141.101.96.169
  27 SRC=120.76.124.48
  74 SRC=MY-HOME-IP-ADDRESS

IPv6 Version of the Report

grep -i "IP6 Drop INVALID Packets:" /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | awk '($(NF-1) = /IP6 Drop INVALID Packets:/){print $NF}' | uniq -c | sort -n | tail

4. View PACKET-CHECK Trap

If you enabled INVALID Trapping, INVALID will be trapped for few seconds as well to slow down the attempt of sending Invalid packets including the Nmap Stealth Scan types such -sX, -sN, and -sF for 15 seconds. Therefore, disallowing the attacker’s scanner from gathering any information by trapping the IP Address 15 seconds.

I have found out that 15 seconds is enough against Invalid Packets scans such -sX, -sN, and -sF. I don’t recommend you enable INVALID Packet rules with trapping unless you have too, since it might disrupt other legitimate service.

Note: when I did a -sS, -sA, or -Pn scan types against my VPS, TCP-PORTSCAN trapped my home IP Address immediately, then I got disconnected from SSH session right away, however, my legitimate traffic such browsing the website kept working just fine, meaning, IPtables was smart enough to block bad traffic from my home IP Address and keep the good traffic flowing.

Let’s view PACKET-CHECK trap:

cat /proc/net/xt_recent/PACKET-CHECK | awk '{print $1}' | sort -n | tail

TIP: Since the trap is only for 15 seconds, you might or might not see a list of IP Addresses.

src=8.35.179.200
src=122.139.102.227
src=1.25.148.117
src=13.92.194.185
src=120.76.124.48
src=213.141.36.157
src=177.160.226.187
src=146.135.109.6
src=141.101.96.169
src=115.238.191.86

Remember, PACKET-CHECK with trapping enabled, will block the IP Address for 15 seconds, you can increase the seconds if needed. It’s not recommended more than 15 seconds though, otherwise your VPS might fall under Denial of Services state.

Besides, Logging on the other hand, allow you to keep proves for your records if needed. So, trapping IP Addresses that generate Invalid IP Packets such -sX, -sN, and -sF scans, will stop them from gathering any port services information.

IPv6 Version of the Report

cat /proc/net/xt_recent/V6PACKET-CHECK | awk '{print $1}' | sort -n | tail

Generating TCP Scan Logging Reports

Run the following steps (1 to 4)

The following commands will generate an output only if TCP scans such -sS, -sA, and -Pn has been executed against your VPS.

1. TCP Packets Scan Report

grep -i "IPT Drop TCP Scans: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | uniq -c | sort -n | tail

Below, the output shows the number of  TCP Scans attempts made by my home IP Address and others based on date shown. April 11 was the highest, 2 attempts.

  1 Apr 6 09:38:12 IPT Drop TCP Scans: SRC=185.92.72.87
  1 Apr 7 08:10:21 IPT Drop TCP Scans: SRC=198.23.213.66
  1 Apr 7 12:09:55 IPT Drop TCP Scans: SRC=93.174.93.94
  1 Apr 7 17:07:05 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 7 20:49:00 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 07:58:27 IPT Drop TCP Scans: SRC=93.174.93.94
  1 Apr 8 08:01:35 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 08:06:32 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 08:08:32 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  2 Apr 11 22:56:32 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS

Again, if I picked one of the IP addresses and ran an ip look tool using this link http://whatismyipaddress.com/ip/93.174.93.94, once I clicked Blacklist bottom, I found that this IP has been blacklisted by some known blacklists as well.

IPv6 Version of the Report

grep -i "IP6 Drop TCP Scans: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | uniq -c | sort -n | tail

2. TCP Packets Scan Report for Specific IP

Generate report against your Home IP Address.

grep -i "IPT Drop TCP Scans: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | sort | uniq -c | sort -n | grep -i YOUR-HOME-IP-ADDRESS | tail

Below, the output shows the number of TCP Scans attempts made by my home IP Address based on date shown. April 11 was the highest number of attempts.

  1 Apr 5 23:50:38 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 6 00:39:57 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 6 01:02:28 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 6 01:29:06 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 7 17:07:05 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 7 20:49:00 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 08:01:35 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 08:06:32 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 8 08:08:32 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS
  2 Apr 11 22:56:32 IPT Drop TCP Scans: SRC=MY-HOME-IP-ADDRESS

3. Report Based on Number of Attempts

If you just want to know the number of Attempts of TCP Packets generated against your VPS from all IP Addresses, run the following command:

grep -i "IPT Drop TCP Scans:" /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | awk '($(NF-1) = /IPT Drop TCP Scans:/){print $NF}' | uniq -c | sort -n | tail

This TCP report counts all the attempts apart of a date. Over all, the last IP Address below was the highest IP Address since it was my home IP Address.

  1 SRC=123.143.119.35
  1 SRC=185.92.72.87
  1 SRC=195.154.200.88
  1 SRC=198.23.213.66
  1 SRC=71.6.186.95
  1 SRC=82.117.208.243
  5 SRC=93.174.93.94
  10 SRC=MY-HOME-IP-ADDRESS

However, I am interested about the bad guy 93.174.93.94 that got 5 attempts. Sure enough, the following link http://whatismyipaddress.com/ip/93.174.93.94 clearly shows that it was blacklisted big time 😉

IPv6 Version of the Report

grep -i "IP6 Drop TCP Scans:" /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | awk '($(NF-1) = /IP6 Drop TCP Scans:/){print $NF}' | uniq -c | sort -n | tail

4. View TCP-PORTSCAN Trap

In addition to logging, TCP Trapping enabled by default and it will block any TCP scan attempt such Nmap -sA, -sS, and -Pn stealth scan types for one day. Therefore, disallowing the attacker’s scanner from gathering any information by trapping his/her IP Address for one day. I have found out that Nmap increases the time in this type of scan to 45 minutes sometimes, so to be in safe side, keep the block duration for one day. (84600 seconds)

Note: A legitimate traffic such browsing the website kept working just fine, meaning, IPtables was smart enough to block bad traffic from my home IP Address and keep the good traffic flowing.

Let’s view TCP-PORTSCAN trap:

cat /proc/net/xt_recent/TCP-PORTSCAN | awk '{print $1}' | sort -n | tail

TIP: Remember, IPtables Script clear the traps the moment you reapply it again. Give it some time, I would say like an hour and check again to see if some bots scan your VPS. However, you should see your home IP Address.

src=36.84.90.155
src=58.221.46.247
src=58.221.46.249
src=58.221.49.53
src=60.190.114.217
src=61.160.195.63
src=69.12.77.200
src=71.6.165.200
src=93.174.93.94
src=93.84.148.180

Remember, TCP-PORTSCAN traps the IP Address for one day, and IPtables will still keep legitimate traffic passing by.

IPv6 Version of the Report

cat /proc/net/xt_recent/V6TCP-PORTSCAN | awk '{print $1}' | sort -n | tail

Generating UDP Scan Logging Reports

Run the following steps (1 to 4)

The following commands will generate an output only if UDP scan such -sU has been executed against your VPS.

1. UDP Packets Scan Report

grep -i "IPT Drop UDP Scans: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | uniq -c | sort -n | tail

Below, the output shows the number of  UDP Scans attempts made by my home IP Address and others based on date shown.

  1 Apr 12 10:09:29 IPT Drop UDP Scans: SRC=80.147.102.130
  1 Apr 12 10:16:31 IPT Drop UDP Scans: SRC=36.249.121.178
  1 Apr 12 10:27:01 IPT Drop UDP Scans: SRC=74.208.112.34
  1 Apr 12 10:44:29 IPT Drop UDP Scans: SRC=181.41.245.33
  1 Apr 12 11:03:51 IPT Drop UDP Scans: SRC=50.30.37.184
  1 Apr 12 11:12:05 IPT Drop UDP Scans: SRC=173.15.223.180
  1 Apr 12 11:19:41 IPT Drop UDP Scans: SRC=37.28.152.58
  1 Apr 12 11:35:17 IPT Drop UDP Scans: SRC=203.143.252.30
  1 Apr 12 11:36:51 IPT Drop UDP Scans: SRC=MY-HOME-IP-ADDRESS
  1 Apr 12 11:41:57 IPT Drop UDP Scans: SRC=MY-HOME-IP-ADDRESS

IPv6 Version of the Report

grep -i "IP6 Drop UDP Scans: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | uniq -c | sort -n | tail

2. UDP Packets Scan Report for Specific IP

Generate report against your Home IP Address.

grep -i "IPT Drop UDP Scans: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | sort | uniq -c | sort -n | grep -i YOUR-HOME-IP-ADDRESS | tail

And that’s how the output should looks like:

Apr 11 22:56:32 IPT Drop UDP Scans: SRC=YOUR-HOME-IP-ADDRESS
Apr 12 11:36:51 IPT Drop UDP Scans: SRC=YOUR-HOME-IP-ADDRESS
Apr 12 11:41:57 IPT Drop UDP Scans: SRC=YOUR-HOME-IP-ADDRESS

3. Report Based on Number of Attempts

If you just want to know the number of Attempts to send Invalid Packets against your VPS from all IP Addresses, run the following command:

grep -i "IPT Drop UDP Scans:" /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | awk '($(NF-1) = /IPT Drop UDP Scans:/){print $NF}' | uniq -c | sort -n | tail

This UDP report counts all the attempts apart of a date. Over all, the last IP Address below was the highest IP Address since it was my home IP Address.

  1 SRC=80.240.216.153
  1 SRC=85.172.12.185
  1 SRC=87.97.71.35
  1 SRC=88.150.206.225
  1 SRC=89.163.145.55
  1 SRC=93.174.93.50
  1 SRC=94.23.30.135
  1 SRC=95.43.14.111
  1 SRC=98.220.26.134
  3 SRC=MY-HOME-IP-ADDRESS

Let’s Look at IP 98.220.26.134 http://whatismyipaddress.com/ip/98.220.26.134 was busted as well by known blacklists.

IPv6 Version of the Report

grep -i "IP6 Drop UDP Scans:" /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | awk '($(NF-1) = /IP6 Drop UDP Scans:/){print $NF}' | uniq -c | sort -n | tail

4. View UDP-PORTSCAN Trap

In addition to logging, UDP Port scan rules got trapping capability as well to block any UDP scan attempt such Nmap -sU stealth scan type for one day. Therefore, disallowing the attacker’s scanner from gathering any information by trapping the IP Address for one day. I have found out that Nmap increases the time in this type of scan as well to 45 minutes sometimes, so to be in safe side, keep the block duration for one day. (84600 seconds)

Note: Same as with TCP-PORTSCAN trap, when I did a -sU scan type against my VPS, UDP-PORTSCAN trapped my home IP Address immediately, however, my legitimate traffic such browsing the website kept working just fine.

Let’s view UDP-PORTSCAN trap:

cat /proc/net/xt_recent/UDP-PORTSCAN | awk '{print $1}' | sort -n | tail

TIP: Remember, IPtables Script clear the traps the moment you reapply it again. Give it some time, I would say like an hour and check again if some bots might scan your VPS. However, you should see your home IP Address.

src=183.60.48.25
src=58.221.55.77
src=69.12.77.200

The first IP Address blacklisted few times per http://whatismyipaddress.com/ip/183.60.48.25. Remember, UDP-PORTSCAN traps the IP Address for one day, and IPtables keeps legitimate traffic passing by.

IPv6 Version of the Report

cat /proc/net/xt_recent/V6UDP-PORTSCAN | awk '{print $1}' | sort -n | tail

TIP: Every week, IPtables log get rotated. Use asterisk at the end of iptables.log* file while generating reports, in order to search across all rotated iptables log files. Usually are called iptables.log.1, .log.2, and son on.

Other Types of IPtables Logging Reports

Note: you got to give your VPS sometime (Like days) before generating other types of reports. You might find something right now, however, if it returns nothing, that means you have to wait till someone tries.

a. SSH IPv4 Brute Force Trap Report

grep -i "IPT Drop SSH Brute-Force: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | uniq -c | sort -n | tail

Based on Number of Attempts

grep -i "IPT Drop SSH Brute-Force: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | awk '($(NF-1) = /IPT Drop SSH Brute-Force:/){print $NF}' | uniq -c | sort -n | tail

Here is a list of bad SSH intruders, among them my home IP Address as well 🙂

   4 SRC=113.160.158.43
   7 SRC=218.23.79.217
  10 SRC=222.255.180.118
  21 SRC=74.208.43.29
  22 SRC=183.3.202.196
  23 SRC=119.146.221.68
  66 SRC=222.186.21.218
  66 SRC=MY-HOME-IP-ADDRESS
  73 SRC=41.220.166.141
 192 SRC=222.186.21.72

This IP 222.186.21.72 is trying so hard to get in 😉 and it’s blacklisted by few lists already.

IPv6 Version of the Report

grep -i "IP6 Drop SSH Brute-Force: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | uniq -c | sort -n | tail

And…

grep -i "IP6 Drop SSH Brute-Force: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | awk '($(NF-1) = /IP6 Drop SSH Brute-Force:/){print $NF}' | uniq -c | sort -n | tail

c. SYN Flood Report

grep -i "IPT Drop SYN Flood: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | uniq -c | sort -n | tail

grep -i "IP6 Drop SYN Flood: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | uniq -c | sort -n | tail

d. ICMP Flood Report

grep -i "IPT Drop ICMP Flood: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | uniq -c | sort -n | tail

grep -i "IP6 Drop ICMP Flood: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | uniq -c | sort -n | tail

e. UDP Flood Report

grep -i "IPT Drop UDP Flood: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | uniq -c | sort -n | tail

grep -i "IP6 Drop UDP Flood: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$13}' | uniq -c | sort -n | tail

f. Finding all types of Attempts made by Specific IP Address

For instance, let’s run this report against one of the SSH Brute Force repeaters:

cat /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | sort | uniq -c | sort -n | grep -i 222.186.21.72

Due to quick Brute Force attacks, this IP Address was Dropped by 2 rules:

 1 Apr 16 06:44:24 IPT Drop SYN Flood: SRC=222.186.21.72
 2 Apr 15 01:09:01 IPT Drop SSH Brute-Force: SRC=222.186.21.72

Managing IPtables xt_recent Hitcount/Traps

These Traps can be used for various reasons, 1) to slow down a connection such light DoS, 2) block an IP Address that violate security policy, and 3) limit number of connections. What I am interested on are Hitcount and Traps. xt_recent Module makes it possible for the IPtables to create Hitcount Labels or Block Traps when used by IPtables script.

For example, and as you already know, if someone scan your VPS using scanning tools such Nmap, then the scanning IP will be blocked by TCP-PORTSCAN or UDP-PORTSCAN Trap, or if the intruder tries to send a lot of traffic to service port like 80 or 443, then the extra traffic will be dropped and trapped using HTTP Hitcount trap.

a. List IPtables xt_recent Module

ls -lah /proc/net/xt_recent/

Or to view Only Hitcount Traps:

ls -lah /proc/net/xt_recent/*HITCOUNT*

Note: that Hitcount traps works differently then TCP, UDP, and SSH Traps. Hitcount dedicated to slow down by not letting a single IP Address exceed 254 IP connection per seconds.

b. View xt_recent SSH Trap

cat /proc/net/xt_recent/SSH-TRAP | awk '{print $1}' | sort -n | tail

c. Verify if a Specific IP Address get trapped

cat /proc/net/xt_recent/SSH-TRAP | awk '{print $1}' | grep -i IP-ADDRESS

d. Verify if your IP address was trapped

cat /proc/net/xt_recent/SSH-TRAP | awk '{print $1}' | grep -i YOUR-HOME-IP-ADDRESS

If you see your home IP Address listed, then for sure it was trapped.

e. Remove your Home IP from the SSH Trap

If after few failure attempts and you still can’t login to a SSH session (won’t happen if you use SSH-Keys), then IPtables Firewall already trapped your home IP Address, therefore, you need to use your web console to release your home IP Address. Note the dash sign before the IP address.

echo -YOUR-HOME-IP-ADDRESS >/proc/net/xt_recent/SSH-TRAP

IPtables SSH Logging Policy

• 5 SSH sessions allowed in 2 minutes (120 seconds), you can increase that time to 5 minutes (300 seconds) if needed.
• Default wait time is 5 Minutes (300 seconds) before trying to open another 5 New SSH Sessions or Putty Windows.
• If you need 10 SSH sessions instead of 5, edit IPtables Script and change the hitcount to 11 instead of 6.
• I recommend to increasing the wait time to 30 Minutes (1800 Seconds) instead, to combat against Brute Force Attack.

Meaning, I was testing my SSH Server the other day. After few minutes, I noticed that I can’t connect anymore. I remembered that I have tried to connect more than 5 times in less than 2 minutes, therefore, IPtables Firewall SSH Rules Blocked my home IP Address for 3 minutes and showed me a connection refused message as shown below:

After the 3 minutes passed, I was able to connect again, and I used the following command to confirm that my Home IP Address was for sure logged:

grep -i "IPT Drop SSH Brute-Force: " /var/log/iptables.log | awk '{print $1,$2,$3,$7,$8,$9,$10,$14}' | sort | uniq -c | sort -n | grep -i MY-HOME-IP-ADDRESS

As you can see, you can go after any specific IP Address even your home IP if you suspect that the Firewall has blocked your IP Address while testing.

Summary

As you can see, xt_recent module makes IPtables very powerful Firewall, besides, logging and reporting can be very useful when you need it, especially at the testing time. There are too many logging types inside the IPtables Script, take a look at the script to generate the report you might need based on the logging options available.

With this Lab, I will conclude the Linux Hardening Rules and IPtables Firewall Labs, it was amazing experience while building, testing, and putting all these Labs together. However, the real fun haven’t started yet 😉 Next, let’s implement Blacklist and Whitelist using IPtables and IPset Labs.

Subject Related