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)
Hosts looking for open proxies:
188.8.131.52 3142 abc.def.ghi.198 80 TCP
184.108.40.206 3143 abc.def.ghi.198 443 TCP
220.127.116.11 3148 abc.def.ghi.198 1080 TCP
18.104.22.168 3145 abc.def.ghi.198 3128 TCP
22.214.171.124 3146 abc.def.ghi.198 8000 TCP
126.96.36.199 3144 abc.def.ghi.198 8080 TCP
Looking for SQL servers
188.8.131.52 2256 abc.def.ghi.174 1433 TCP
184.108.40.206 2245 abc.def.ghi.174 3306 TCP
220.127.116.11 1813 abc.def.ghi.191 1433 TCP
18.104.22.168 1814 abc.def.ghi.191 3306 TCP
22.214.171.124 2563 abc.def.ghi.155 3306 TCP
126.96.36.199 2249 abc.def.ghi.165 3306 TCP
188.8.131.52 2093 abc.def.ghi.112 1433 TCP
184.108.40.206 2539 abc.def.ghi.200 1433 TCP
Probing the usual MS ports
220.127.116.11 3153 abc.def.ghi.61 445 TCP
18.104.22.168 1569 abc.def.ghi.64 445 TCP
22.214.171.124 2498 abc.def.ghi.100 139 TCP
126.96.36.199 2504 abc.def.ghi.101 139 TCP
188.8.131.52 1035 abc.def.ghi.60 137 UDP
184.108.40.206 1035 abc.def.ghi.61 137 UDP
Looking for pop3 & SMTP
220.127.116.11 4804 abc.def.ghi.53 110 TCP
18.104.22.168 1112 abc.def.ghi.54 110 TCP
22.214.171.124 1369 abc.def.ghi.110 25 TCP
126.96.36.199 1370 abc.def.ghi.111 25 TCP
188.8.131.52 1107 abc.def.ghi.105 1434 UDP
184.108.40.206 1107 abc.def.ghi.106 1434 UDP
SAV Bot (CVE-2006-2630)
220.127.116.11 3884 abc.def.ghi.135 2967 TCP
18.104.22.168 3371 abc.def.ghi.142 2967 TCP
Looking for X11
22.214.171.124 44101 abc.def.ghi.211 6000 TCP
126.96.36.199 44102 abc.def.ghi.212 6000 TCP
Trend Micro Server issue from earlier in the year
188.8.131.52 6000 abc.def.ghi.100 5168 TCP
184.108.40.206 6000 abc.def.ghi.101 5168 TCP
220.127.116.11 41359 abc.def.ghi.110 22 TCP
18.104.22.168 57590 abc.def.ghi.111 22 TCP
05:42:41 22.214.171.124 59912 abc.def.ghi.136 33434 UDP
06:05:53 126.96.36.199 59912 abc.def.ghi.136 33434 UDP
06:30:54 188.8.131.52 59912 abc.def.ghi.136 33434 UDP
06:49:43 184.108.40.206 59912 abc.def.ghi.136 33434 UDP
07:17:32 220.127.116.11 59912 abc.def.ghi.136 33434 UDP
07:41:10 18.104.22.168 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)
22.214.171.124 12889 abc.def.ghi.26 33435 UDP - Unix Traceroute
126.96.36.199 17749 abc.def.ghi.26 33437 UDP - Unix Traceroute
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.
188.8.131.52 50935 abc.def.ghi.235 4899 TCP
184.108.40.206 50937 abc.def.ghi.236 4899 TCP
220.127.116.11 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.
18.104.22.168 39841 abc.def.ghi.227 32801 UDP
22.214.171.124 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.
126.96.36.199 3389 abc.def.ghi.32 36199 TCP
188.8.131.52 3389 abc.def.ghi.33 16763 TCP
184.108.40.206 3389 abc.def.ghi.4 27149 TCP
220.127.116.11 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