I've been a tad busy recently but I didn't want to let this go because it's quite fun.....

The results from the Thanksgiving weekend have been siiting on my drive waiting to be looked at since monday and it bothers me. The base log, (single line per connection text file is about 366k), is attached. What I will do is take a "scoot" through it and annotate "interesting things " with the word "Tiger". What you can do is look at these notes and open the file in a text editor and do a find for "Tiger" then keep doing "Find Next" to keep jumping to the next point of interest....

It's sort of a cursory exam but it is a little enlightening....

I turned off the ms-sql-s listener because once some of them find it open they keep hammering away for hours even though the port has been closed.... I didn't want the extraneous rubbish so i ditched it.

Notes:-

1. This navix.net scanner for what appears to be various exploits is a little broken, (the checksum is bad.... ooops, bad programming...)

2. This Navix.net box really like port 113, I have noticed it a lot in this log and subsequent logs... I'm not sure what it's trying to acheive, anyone have any thoughts. Notice also something that I said in my previous post regarding somethin happens and it seems to "kick off" other things.... Look at the other navix.net boxes that start trying right after this.... There has to be a "trigger" here....

3. This is probably one of the SSH brute forcers but because it doesn't get the appropriate SSH response it throws another SYN and then quits on the original connection....

4. Some worms just don't give up.... Even though the response to a SYN is RST ACK they keep sending SYN's.... like it's going to change... Kinda like some of my users that try to get to yahoo mail and get the "access denied" page and keep trying every hour to see if they can sneak by.... LOL

5. Now this SSH brute forcer seems to have the right idea... It doesn't get what it wants so it RST's me and moved on.... There's more than one SSH brute forcer out there or was this a human? The timing indicates it could have been.... maybe....

6. OMG.... Someone is looking for eDonkey..... Is there an exploit.... Won't find it here...

7. In case you don't know these messenger things are spam looking for boxes with the Messenger service open and the message tells them they are owned and need to "click here" to fix their box.... Yes, if the messenger service is open the chances are high that there are more exploitable ports open too so the spam is right.... However, I wouldn't trust the solution....

8. Got me a nice little executable here.... Used Ethereal to follow the conversation, saved it and scanned it thinking that if it is a known piece of malware the signature will be there and be recognized, it isn't.... I don't know if the sigs also have offsets etc. as part of them - I didn't think they would because it would make evasion too easy.... but maybe they do... any comments anyone?

9. Here's a classic spammer.... Note the response from WormRadar... It does this a lot.... Accepts a bit of a conversation, suckering them in and then everything after results in a "command not supported" response.... gotta be frustrating if a human were sat on the other end.... Bummer....

10. IIRC this was a different executable than the one in 8. I did the same and got no alarm from the AV.... I need to know if they employ offsets otherwise there are things being moved around that are unrecognized....

11. Another unrecognized executable.....

12. I don't recall exactly but this was a small exe that I didn't get a chance to look at.

13. This was a biggie... Wormradar is emulating the Kuang2 trojan... Again... whole executable.... no recognition from AV.... I gotta think they use offsets in the sigs and the ethereal "follow conversation" messes them up.

14. More stuff.... No time to AV it....

15. More Kuang2.... Different from the first I seem to recall.... Not AV tested

16. More Kuang... maybe same as the first seems different to the second.

17. I guess I didn't do what 653217hfc38.tampabay.rr.com wanted the first time.... He came back..... LOL

18. I'm skimming this so this may have happened before but this box sent a broadcast, (255.255.255.255), and then came right back on the same port to have a go at me.... then he tested almost everything even though my box doesn't seem to have replied to the broadcast.... I'll have to chack the filter on this though...

19. It does look like my box might be responding to the broadcast and the filter is not showing it.... Gotta check that filter.....

20. Odd... No outgoing packets.... but getting SYN ACK's... Spoof or mistake? Not enough to be some form of a DDoS...

21. Here's an IMAP attempt, first I've seen and coincides with the two new IMAP exploits... early in the period... maybe it was just a 'spec" attempt and not related to the exploits.

All in all, having been capturing the traffic for 10 days or more now and scanning the results this is all pretty "vanilla" stuff.... You will also notice that there are _no_, (I scanned... remember), connections that would exploit a new box on the net automatically.... They are all looking for previously exploited boxes.... Frankly I find that a little surprising.... I have no filters on the border router and this box is outside the firewall.... It is locked down... but the connection attempts would still show.....

I'll try to keep this going and maybe keep making the box more vulnerable to see what happens..... But it's a comfort level issue.....