The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

LogWatch - Mystery Traffic

Discussion in 'General Discussion' started by GeekPatrolMille, Oct 16, 2005.

  1. GeekPatrolMille

    GeekPatrolMille Well-Known Member

    Joined:
    Mar 12, 2004
    Messages:
    84
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    McKinney, Texas, USA
    I was hoping to get some input on how to track this odd log entry. It hac been getting just a little bit longer (more ports added) ofer the past few months and I am not able to clearly see if this is a hacked box or just some attempted exploits that have failed. In either case, I want to remove the offending customer, it is originating from my server.

    I have recently blocked 6 Class B networks 38.29.0.0, 38.30.0.0, 38.31.0.0, 38.129.0.0, 38.130.0.0, 38.131.0.0 due to constant DOS attack and I hoped this would have stopped the following log entries, but no luck...

    65.16.AA.BB & AA.CC I am not so worried about but the AA.DD address is a DNS address and has no public websites and AA.EE is a shared host with about 20 sites on it.

    Any thoughts?

    Thanks,
    Gregory A. Miller
    AGBSM, LLC


    From 65.16.AA.BB - 1 packet to tcp(800)

    From 65.16.AA.CC - 1 packet to tcp(800)

    From 65.16.AA.DD - 306 packets to udp(3055,3126,3575,3622,4548,4596,4703,4822,4976,5151,6129,6209,6670,6698,6711,6747,6788,6852,7270,7287,7928,7939,7959,8013,8397,8416,8624,8656,8723,8803,8881,8988,9686,9734,10343,10439,10854,10870,11030,11031,11049,11063,11228,11246,11377,11382,11398,11405,11413,11436,11592,11608,11618,11629,11772,11775,11789,11804,11819,11829,11845,11857,11873,12035,12052,12187,12197,12336,12350,12356,12367,12514,12515,12529,12546,12682,12701,12829,12831,12854,12868,12880,12898,13038,13041,13054,13243,13288,13590,13606,13867,13881,13891,13901,13916,13934,14135,14155,14332,14336,14353,14374,14379,14395,14600,14619,14831,14880,15056,15075,15092,15130,15139,15154,16143,16166,16398,16415,19231,19276,20125,20144,20228,20265,20288,20326,20365,20899,20936,20995,21245,21261,21288,21314,21332,21343,21401,21479,21573,21839,21869,22154,22164,22168,22487,22494,22508,22535,22745,22836,23095,23102,23110,23123,23133,23150,23311,23332,23531,23542,28091,28100,28255,28272,28283,28308,28487,28492,28501,28512,28517,28533,28697,28705,28720,28725,28736,28745,28925,28950,29113,29126,29140,29164,29372,29379,29395,29413,30633,30663,30698,30751,30777,30809,31333,31380,31814,31827,31954,31970,32261,32396,32427,32779,32795,32851,32862,32875,33873,34406,34417,34440,34448,34559,34568,34770,35255,35424,35437,35681,35691,35889,35907,35922,35940,35947,35964,36136,36140,36156,36167,36177,36200,36396,36408,36606,36616,36623,36656,36856,36864,36879,36900,36908,36916,36931,36949,36972,37197,37205,37219,37246,37723,37782,38377,38446,38791,38810,39049,39053,39063,39088,39108,39138,39152,39373,39397,39676,39685,39703,39738,60454,61004,61019,61038,61101,61923,61961,62487,62506,62982,63019,63721,63726,63747,63769,63798,63814,63847,63878,63906,63932,63965,64019,64630,64659)

    From 65.16.AA.EE - 22 packets to udp(1027,1539,1601,1669,1670,1685,1732,52655,57351,57358,57368,57370,57373,60972)tcp(5190)
     
  2. GeekPatrolMille

    GeekPatrolMille Well-Known Member

    Joined:
    Mar 12, 2004
    Messages:
    84
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    McKinney, Texas, USA
    Final thought...

    I am certain you see the issue but since I was not specific, these entries appear as if they are trying to originate from these servers and APF is blocking the attempts (which is good) but I would like to remove the source of the problem for good measure. I am just lost as to what to look for.

    -greg
     
  3. bamasbest

    bamasbest Well-Known Member

    Joined:
    Jan 10, 2004
    Messages:
    531
    Likes Received:
    0
    Trophy Points:
    16
    Well, a good thing that APF is doing its job.

    However, truly stopping these dos attacks from actually reaching your box(es) would best be handled by your DC at the switch.

    IMX, some DC's are very pro-active and as soon as they detect a dos attack, they investigate and kill it.

    Other DC's could either care less, or only act when server owners report such issues.
     
  4. GeekPatrolMille

    GeekPatrolMille Well-Known Member

    Joined:
    Mar 12, 2004
    Messages:
    84
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    McKinney, Texas, USA
    I think you misunderstood... I just added the information of the DOS attack as a side note. The real issue I am trying to investigate is the apparent outbound traffic from the four addresses which I want to try and track backwards into my system and eliminate the source.
     
  5. GeekPatrolMille

    GeekPatrolMille Well-Known Member

    Joined:
    Mar 12, 2004
    Messages:
    84
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    McKinney, Texas, USA
    Something new to add...

    Oct 16 04:04:16 ls05 kernel: ** OUT_UDP DROP ** IN= OUT=eth0 SRC=65.16.99.54 DST=206.81.245.136 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=45265 LEN=38
    Oct 16 04:19:38 ls05 kernel: ** OUT_UDP DROP ** IN= OUT=eth0 SRC=65.16.99.54 DST=206.81.245.136 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=45506 LEN=38
    Oct 16 04:19:38 ls05 kernel: ** OUT_UDP DROP ** IN= OUT=eth0 SRC=65.16.99.54 DST=206.81.245.136 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=45510 LEN=38
    Oct 16 04:21:45 ls05 kernel: ** OUT_UDP DROP ** IN= OUT=eth0 SRC=65.16.99.54 DST=206.81.245.136 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=45553 LEN=38
    Oct 16 04:21:45 ls05 kernel: ** OUT_UDP DROP ** IN= OUT=eth0 SRC=65.16.99.54 DST=206.81.245.136 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=45529 LEN=38
    Oct 16 04:23:45 ls05 kernel: ** OUT_UDP DROP ** IN= OUT=eth0 SRC=65.16.99.54 DST=206.81.245.136 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=45590 LEN=38
    Oct 16 04:23:45 ls05 kernel: ** OUT_UDP DROP ** IN= OUT=eth0 SRC=65.16.99.54 DST=206.81.245.136 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=45605 LEN=38
    Oct 16 04:25:45 ls05 kernel: ** OUT_UDP DROP ** IN= OUT=eth0 SRC=65.16.99.54 DST=206.81.245.136 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=45631 LEN=38
    Oct 16 04:27:15 ls05 kernel: ** OUT_UDP DROP ** IN= OUT=eth0 SRC=65.16.99.54 DST=206.81.245.136 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=45647 LEN=38
    Oct 16 04:42:37 ls05 kernel: ** OUT_UDP DROP ** IN= OUT=eth0 SRC=65.16.99.54 DST=206.81.245.136 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=45820 LEN=38

    This is just a random sampling of about 100 per day... I was able to track it back to a client who hosts their own email but I host their DNS (secondary backup) and primary WWW.

    Also I found this...
    Oct 9 04:26:26 ls05 MailScanner[11509]: Infected message 1EOXRl-0007Mq-TH came from 206.81.245.136
    Oct 14 14:47:15 ls05 MailScanner[17449]: Infected message 1EQVWL-00037f-AI came from 206.81.245.136
    Oct 3 13:33:55 ls05 MailScanner[9489]: Infected message 1EMV8J-0005qQ-UQ came from 206.81.245.136
    Oct 3 14:04:45 ls05 MailScanner[8264]: Infected message 1EMVc8-0007Df-Rn came from 206.81.245.136
    Oct 4 11:17:13 ls05 MailScanner[13084]: Infected message 1EMpTY-000331-JB came from 206.81.245.136
    Oct 7 03:26:54 ls05 MailScanner[30425]: Infected message 1ENnZ4-00085M-6T came from 206.81.245.136
    Sep 25 21:38:50 ls05 MailScanner[32537]: Infected message 1EJisz-0002qu-Ou came from 206.81.245.136

    These again are a small cross section of the total number. I see in MailScanner that each of these is from an email getting trapped and eliminated as having the SomeFool attached.

    ClamAV Module: document.zip was infected: Worm.SomeFool.P ClamAV Module: data.rtf .scr was infected: Worm.SomeFool.P
    MailScanner: Windows Screensavers are often used to hide viruses (data.rtf .scr)
    No programs allowed (data.rtf .scr)
    ClamAV Module: data.rtf .scr was infected: Worm.SomeFool.P MailScanner: Windows Screensavers are often used to hide viruses (data.rtf .scr)
    No programs allowed (data.rtf .scr)

    Further logs in one of the time frames where the issue shows up show nothing:
    66.249.66.41 - - [15/Oct/2005:21:03:47 -0500] "GET /robots.txt HTTP/1.1" 404 - "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
    66.249.66.41 - - [15/Oct/2005:21:03:48 -0500] "GET /about.pdf HTTP/1.1" 200 28970 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.htm
    l)"
    70.49.14.175 - - [16/Oct/2005:02:57:10 -0500] "GET / HTTP/1.1" 200 754 "-" "-"
    61.78.61.222 - - [16/Oct/2005:06:00:12 -0500] "GET /robots.txt HTTP/1.1" 404 - "-" "NaverBot-1.0 (NHN Corp. / +82-2-3011-1989 / nhnbot@naver.com)"
    61.78.61.222 - - [16/Oct/2005:06:00:13 -0500] "GET / HTTP/1.1" 200 754 "-" "NaverBot-1.0 (NHN Corp. / +82-2-3011-1989 / nhnbot@naver.com)"
    68.88.68.0 - - [16/Oct/2005:07:06:56 -0500] "GET /LHContact.html HTTP/1.1" 404 - "http://www.google.com/search?hl=en&q=lackey+hershman&spell=1" "Mozilla/4.0
    (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"


    I have examined their server at their location, which I manage for them, and it would not appear that they have any virus problems on any server or client. They did go though a reign of several days where they were bombarded with emails from a single source that contained the SomeFool attachment.

    I keep a pretty close watch on the log files on my servers and this is really the only consistent issue which escapes a logical explanation. It would appear that my client server is somehow trying to send data out random ports but originating from port 53. Every other log entry where the APF drops a packet would show my server being the destination not the source.
     

Share This Page