A day in the life of a firewall log
Every now and then when you have one of those days some nice therapy is to go through the firewall logs. After all, whilst junior is doing a good job, you do need to keep your hand in, you never know what you might find.
This particular firewall often has some interesting logs entries as it hooks up to a public C class network. So patterns are often more obvious than may be the case on smaller networks.
The way I broke the logs down is very simple. Using the DSHIELD Universal Firewall Client I reduced the firewall log down to the basic information that is typically submitted to the DSHIELD. It gives me a time, source, destination IP and ports and the protocol. The information left are all the denies, but as I’m looking at a class C anything unusual is likely to hit a closed port on one of the addresses and at this stage I’m interested in getting an idea of what is happening in this particular nick of the woods, nothing more.
So what did 12/12 bring?
Firstly lots of SPAM, both email and Instant Messaging (IM) spam. The mail SPAM is being sent to the secondary MX record. The reason it is bouncing on this particular firewall is because the port is closed, unless the primary mail server can’t be reached. About 13K SPAM emails were “delivered” to the secondary MX address. This is approximately triple the amount delivered to the primary mail server for this site. The sources varied, but the following list of countries was responsible for most of the SPAM (and pretty much anything else as well): China, Russia, Thailand, Peru, Turkey, Italy, Columbia, and Poland.
What else was there?
(btw most of the entries shown were repeated for a significant number of hosts on the subnet)
The explained
Hosts looking for open proxies:
195.10.123.118 3142 abc.def.ghi.198 80 TCP
195.10.123.118 3143 abc.def.ghi.198 443 TCP
195.10.123.118 3148 abc.def.ghi.198 1080 TCP
195.10.123.118 3145 abc.def.ghi.198 3128 TCP
195.10.123.118 3146 abc.def.ghi.198 8000 TCP
195.10.123.118 3144 abc.def.ghi.198 8080 TCP
Looking for SQL servers
203.168.246.177 2256 abc.def.ghi.174 1433 TCP
203.168.246.177 2245 abc.def.ghi.174 3306 TCP
203.168.246.177 1813 abc.def.ghi.191 1433 TCP
203.168.246.177 1814 abc.def.ghi.191 3306 TCP
203.158.191.28 2563 abc.def.ghi.155 3306 TCP
203.158.191.28 2249 abc.def.ghi.165 3306 TCP
203.162.219.133 2093 abc.def.ghi.112 1433 TCP
203.162.219.50 2539 abc.def.ghi.200 1433 TCP
Probing the usual MS ports
203.110.95.199 3153 abc.def.ghi.61 445 TCP
203.110.95.199 1569 abc.def.ghi.64 445 TCP
203.113.133.72 2498 abc.def.ghi.100 139 TCP
203.113.133.72 2504 abc.def.ghi.101 139 TCP
190.137.134.106 1035 abc.def.ghi.60 137 UDP
190.137.134.106 1035 abc.def.ghi.61 137 UDP
Looking for pop3 & SMTP
68.20.167.21 4804 abc.def.ghi.53 110 TCP
68.20.167.21 1112 abc.def.ghi.54 110 TCP
190.2.22.85 1369 abc.def.ghi.110 25 TCP
190.2.22.85 1370 abc.def.ghi.111 25 TCP
Slammer Worm
202.96.87.29 1107 abc.def.ghi.105 1434 UDP
202.96.87.29 1107 abc.def.ghi.106 1434 UDP
SAV Bot (CVE-2006-2630)
203.20.75.18 3884 abc.def.ghi.135 2967 TCP
203.20.75.18 3371 abc.def.ghi.142 2967 TCP
Looking for X11
195.13.58.137 44101 abc.def.ghi.211 6000 TCP
195.13.58.137 44102 abc.def.ghi.212 6000 TCP
Trend Micro Server issue from earlier in the year
58.246.107.14 6000 abc.def.ghi.100 5168 TCP
58.246.107.14 6000 abc.def.ghi.101 5168 TCP
SSH Probes
193.0.121.66 41359 abc.def.ghi.110 22 TCP
193.0.121.66 57590 abc.def.ghi.111 22 TCP
Planetlab
05:42:41 193.55.112.40 59912 abc.def.ghi.136 33434 UDP
06:05:53 193.55.112.40 59912 abc.def.ghi.136 33434 UDP
06:30:54 193.55.112.40 59912 abc.def.ghi.136 33434 UDP
06:49:43 193.55.112.40 59912 abc.def.ghi.136 33434 UDP
07:17:32 193.55.112.40 59912 abc.def.ghi.136 33434 UDP
07:41:10 193.55.112.40 59912 abc.def.ghi.136 33434 UDP
The above entries looked unusual and were traced back to a research facility Planetlab, which has a number of projects, the project hitting the firewall in this case was looking for routing anomalies.
Unix Traceroute - (Thanks Jens)
206.123.64.70 12889 abc.def.ghi.26 33435 UDP - Unix Traceroute
206.123.64.70 17749 abc.def.ghi.26 33437 UDP - Unix Traceroute
The unexplained
For the following I’m yet to find a good explanation so more digging tomorrow. If you have a good explanation, feel free to write in using the contact form.
66.168.182.42 50935 abc.def.ghi.235 4899 TCP
66.168.182.42 50937 abc.def.ghi.236 4899 TCP
66.168.182.42 50938 abc.def.ghi.237 4899 TCP
The DSHIELD database shows a big increase in the number of targets for the last few days, but I haven’t managed to capture anything just yet. The port 4899 belongs to radmin.
Update - The port is used as a backdoor, so the above is likely to be a scan for already compromised hosts.
The following are in my “no Idea” bucket.
192.148.123.44 39841 abc.def.ghi.227 32801 UDP
192.148.123.45 39841 abc.def.ghi.227 32801 UDP
Whilst the following may look like replies to an RDP session, none of the hosts can make an outbound RDP connection.
61.238.148.9 3389 abc.def.ghi.32 36199 TCP
61.238.148.9 3389 abc.def.ghi.33 16763 TCP
61.238.148.9 3389 abc.def.ghi.4 27149 TCP
61.238.148.9 3389 abc.def.ghi.4 55340 TCP
Comparing the logs from the last review and this one, it is obvious that China and Russia are still the biggest sources of attacks, however the number of attacks are down from previous months. There is an increased amount of traffic from Turkey, Italy, Columbia and Peru. Some of this may be explained with the reported move of RBN to other locations such as Turkey and Italy. The increase for Columbia and Peru may have something to do with our Brazilian friends.
Thats a day in the life of my log. If you see anything weird in your logs, or you can explain my few left over log entries (especially port 4899 traffic), let us know.
Mark H - Shearwater
Comments
I believe I can help with the TCP 4899 entries. I see a lot of these scans, looking for radmin installations. This is the default listening port...
Dale
Dale E.
Dec 13th 2007
1 decade ago