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