RE: [cisco-ttl] arp packets

From: Uğur Güngör (ugungor_at_tarnet.net.tr)
Date: Wed Jan 05 2005 - 07:01:59 GMT

  • Next message: zeynep zeynep: "[cisco-ttl] catalyst 6509 Sup1A"

    Yanlıs anlamıs da olabilirim ama anladıgım kadarıyla networkte sacma sapan
    arp req dolasıyorsa bunun nedeni windowz un rpc acigini kullanan blaster
    tarzı bir worm olabilir. Client lar windows 2000 yada xp mi vede sec.update
    leri guncelmi? (Bu W32.Welchia ya benziyor )

    This information is designed to help network administrators identify systems
    that W32.Blaster.Worm, W32.Welchia.Worm, or possibly other RPC worms have
    infected.

    You must have a sniffer, such as tcpdump or windump, which should be placed
    in a network location that sees a lot of traffic, so that you will see as
    many infection attempts as possible.

    W32.Blaster.Worm
    Sniff for traffic destined for port 135/tcp, 4444/tcp, and 69/udp. The
    correlation of these three types of traffic going from one machine to
    another most likely indicates a successful infection.

    In the following example, the interesting ports are displayed in bold font:

    17:15:36.395032 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
    17:15:36.395323 192.168.0.3.135 > 192.168.0.1.1294: tcp 0 (DF)
    17:15:36.395436 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
    17:16:19.508095 192.168.0.1.1294 > 192.168.0.3.135: tcp 72 (DF)
    17:16:19.508310 192.168.0.1.1294 > 192.168.0.3.135: tcp 1460 (DF)
    17:16:19.508346 192.168.0.1.1294 > 192.168.0.3.135: tcp 244 (DF)
    17:16:19.508362 192.168.0.3.135 > 192.168.0.1.1294: tcp 0 (DF)
    17:16:19.508541 192.168.0.3.135 > 192.168.0.1.1294: tcp 60 (DF)
    17:16:19.508681 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
    17:16:19.508720 192.168.0.3.135 > 192.168.0.1.1294: tcp 0 (DF)
    17:16:19.512201 192.168.0.3.135 > 192.168.0.1.1294: tcp 0 (DF)
    17:16:19.512346 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
    17:16:19.904949 192.168.0.1.1314 > 192.168.0.3.4444: tcp 0 (DF)
    17:16:19.905031 192.168.0.3.4444 > 192.168.0.1.1314: tcp 0 (DF)
    17:16:19.905160 192.168.0.1.1314 > 192.168.0.3.4444: tcp 0 (DF)
    17:16:19.952874 192.168.0.3.4444 > 192.168.0.1.1314: tcp 42 (DF)
    17:16:19.984939 192.168.0.1.1314 > 192.168.0.3.4444: tcp 36 (DF)
    17:16:19.985029 192.168.0.3.4444 > 192.168.0.1.1314: tcp 63 (DF)
    17:16:20.083469 192.168.0.3.1049 > 192.168.0.1.69: udp 20
    17:16:20.118800 192.168.0.1.69 > 192.168.0.3.1049: udp 516

    In the above case, machine 192.168.0.1 is clearly infecting machine
    192.168.0.3.

    However some machines are protected, so the Blaster traffic will not always
    look like this. For instance:

        * If the attacked machines are patched, the 69/udp traffic and most of
    the 4444/tcp traffic will not be there because the shell code will not run.
        * If the attacked machines have port 135 firewalled, the 4444/tcp and
    69/udp traffic will not be there and the 135/tcp traffic will only be failed
    connection attempts

    In such cases, it is still possible to distinguish between the worm and a
    legitimate connection to port 135/tcp, by looking for these characteristics:

        * Traffic on port 135 with specific packet sizes can tell you quickly
    whether an infection was attempted. Specifically, the three packet sizes (in
    bold) are associated with the RPC/DCOM exploit, which both Blaster and
    Welchia used (and other pieces of malware used them, too):
          17:15:36.395032 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
          17:15:36.395323 192.168.0.3.135 > 192.168.0.1.1294: tcp 0 (DF)
          17:15:36.395436 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
          17:16:19.508095 192.168.0.1.1294 > 192.168.0.3.135: tcp 72 (DF)
          17:16:19.508310 192.168.0.1.1294 > 192.168.0.3.135: tcp 1460 (DF)
          17:16:19.508346 192.168.0.1.1294 > 192.168.0.3.135: tcp 244 (DF)

        * Rapid succession of connections from one host to a series of hosts
    with nearby IP addresses. For instance:
          17:07:54.032412 15.54.153.107.1038 > 15.54.152.106.135: tcp 0 (DF)
          17:07:54.032657 15.54.153.107.1039 > 15.54.152.107.135: tcp 0 (DF)
          17:07:54.032901 15.54.153.107.1040 > 15.54.152.108.135: tcp 0 (DF)
          17:07:57.032668 15.54.153.107.1039 > 15.54.152.107.135: tcp 0 (DF)
          17:08:14.060589 15.54.153.107.1074 > 15.54.152.125.135: tcp 0 (DF)
          17:08:14.062041 15.54.153.107.1078 > 15.54.152.129.135: tcp 0 (DF)
          17:08:14.064937 15.54.153.107.1086 > 15.54.152.137.135: tcp 0 (DF)
          17:08:17.061195 15.54.153.107.1086 > 15.54.152.137.135: tcp 0 (DF)
          17:08:23.069724 15.54.153.107.1086 > 15.54.152.137.135: tcp 0 (DF)
          17:08:35.489747 15.54.153.107.1104 > 15.54.152.141.135: tcp 0 (DF)
          17:08:44.307318 15.54.153.107.1145 > 15.54.152.177.135: tcp 0 (DF)
          17:08:44.308202 15.54.153.107.1148 > 15.54.152.180.135: tcp 0 (DF)

    Also notice that the ephemeral source ports on the attacking machine
    increase monotonically by one per connection attempt, because the attacker
    devotes almost all his/her network connections to attacking new machines in
    quick succession.

    W32.Welchia.Worm
    The traffic on port 135 looks the same as that of Blaster. In particular,
    the port 135 packet sizes highlighted above are the same. However, Welchia
    has a connect-back shellcode, so that network traffic during an infection
    looks slightly different. Look for a ping, then traffic on port 135/tcp,
    666-to-765/tcp, then 69/udp, like this:

    11:47:47.576542 169.254.56.166 > 169.254.189.84: icmp: echo request
    11:47:47.578331 169.254.189.84 > 169.254.56.166: icmp: echo reply
    11:47:47.612221 169.254.56.166.1038 > 169.254.189.84.135: tcp 0 (DF)
    11:47:47.624560 169.254.189.84.135 > 169.254.56.166.1038: tcp 0 (DF)
    11:47:47.624664 169.254.189.84.135 > 169.254.56.166.1038: tcp 0 (DF)
    11:47:47.625523 169.254.56.166.1038 > 169.254.189.84.135: tcp 0 (DF)
    11:47:47.625556 169.254.56.166.1038 > 169.254.189.84.135: tcp 0 (DF)
    11:47:47.626258 169.254.56.166.1038 > 169.254.189.84.135: tcp 72 (DF)
    11:47:47.636660 169.254.189.84.135 > 169.254.56.166.1038: tcp 60 (DF)
    11:47:47.637403 169.254.56.166.1038 > 169.254.189.84.135: tcp 1460 (DF)
    11:47:47.637593 169.254.56.166.1038 > 169.254.189.84.135: tcp 244 (DF)
    11:47:47.649841 169.254.189.84.135 > 169.254.56.166.1038: tcp 0 (DF)
    11:47:47.649901 169.254.189.84.3008 > 169.254.56.166.707: tcp 0 (DF)
    11:47:47.650456 169.254.56.166.707 > 169.254.189.84.3008: tcp 0 (DF)
    11:47:47.656558 169.254.189.84.3008 > 169.254.56.166.707: tcp 0 (DF)
    11:47:47.656640 169.254.189.84.135 > 169.254.56.166.1038: tcp 0 (DF)
    11:47:47.656735 169.254.189.84.3008 > 169.254.56.166.707: tcp 39 (DF)
    11:47:47.657001 169.254.56.166.1038 > 169.254.189.84.135: tcp 0 (DF)
    11:47:47.657737 169.254.56.166.1038 > 169.254.189.84.135: tcp 0 (DF)
    11:47:47.678106 169.254.189.84.135 > 169.254.56.166.1038: tcp 0 (DF)
    11:47:47.800623 169.254.189.84.3008 > 169.254.56.166.707: tcp 104 (DF)
    11:47:47.801332 169.254.56.166.707 > 169.254.189.84.3008: tcp 0 (DF)
    11:47:47.801817 169.254.56.166.707 > 169.254.189.84.3008: tcp 22 (DF)
    11:47:47.809133 169.254.189.84.3008 > 169.254.56.166.707: tcp 21 (DF)
    11:47:47.943421 169.254.56.166.707 > 169.254.189.84.3008: tcp 0 (DF)
    11:47:47.945248 169.254.189.84.3008 > 169.254.56.166.707: tcp 152 (DF)
    11:47:47.958809 169.254.56.166.707 > 169.254.189.84.3008: tcp 24 (DF)
    11:47:47.963702 169.254.189.84.3008 > 169.254.56.166.707: tcp 24 (DF)
    11:47:48.147203 169.254.56.166.707 > 169.254.189.84.3008: tcp 0 (DF)
    11:47:48.148097 169.254.189.84.3008 > 169.254.56.166.707: tcp 156 (DF)
    11:47:48.148492 169.254.56.166.707 > 169.254.189.84.3008: tcp 57 (DF)
    11:47:48.154321 169.254.189.84.3008 > 169.254.56.166.707: tcp 57 (DF)
    11:47:48.344809 169.254.56.166.707 > 169.254.189.84.3008: tcp 0 (DF)
    11:47:48.397446 169.254.189.84.3009 > 169.254.56.166.69: udp 20

    Protected machines will not be infected, so the traffic above will not
    always take place. But as long as you can sniff the pings, you can tell,
    with good reliability, whether the ping request originates from Welchia, by
    looking at the ping payload, which is filled with 0xaa.

    This is a complete dump of a Welchia ping request:

    11:47:47.576542 169.254.56.166 > 169.254.189.84: icmp: echo request
    0x0000 4500 005c 599d 0000 8001 970c a9fe 38a6 E..\Y.........8.
    0x0010 a9fe bd54 0800 fa51 0200 a658 aaaa aaaa ...T...Q...X....
    0x0020 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
    0x0030 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
    0x0040 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
    0x0050 aaaa aaaa aaaa aaaa aaaa aaaa ............

    To filter only such ping requests with a sniffer like tcpdump or windump,
    and not show the legitimate pings, you can use a command such as:

    "tcpdump -qn icmp and ip[40] = 0xaa" or
    "windump -qn icmp and ip[40] = 0xaa"

    This will result in a display of all Welchia pings.

    Another thing to look for is a succession of ARP requests for consecutive
    addresses from the same host, like this:

    11:43:50.435946 arp who-has 169.254.14.115 tell 169.254.56.166
    11:43:50.438301 arp who-has 169.254.14.116 tell 169.254.56.166
    11:43:50.445362 arp who-has 169.254.14.117 tell 169.254.56.166
    11:43:50.460087 arp who-has 169.254.14.118 tell 169.254.56.166
    11:43:50.466885 arp who-has 169.254.14.119 tell 169.254.56.166
    11:43:50.482358 arp who-has 169.254.14.120 tell 169.254.56.166
    11:43:50.484681 arp who-has 169.254.14.121 tell 169.254.56.166
    11:43:50.498546 arp who-has 169.254.14.122 tell 169.254.56.166
    11:43:50.505680 arp who-has 169.254.14.123 tell 169.254.56.166
    11:43:50.514562 arp who-has 169.254.14.124 tell 169.254.56.166
    11:43:50.531488 arp who-has 169.254.14.125 tell 169.254.56.166
    11:43:50.534873 arp who-has 169.254.14.126 tell 169.254.56.166
    11:43:50.546532 arp who-has 169.254.14.127 tell 169.254.56.166
    11:43:50.554933 arp who-has 169.254.14.128 tell 169.254.56.166
    11:43:50.570009 arp who-has 169.254.14.129 tell 169.254.56.166
    11:43:50.577407 arp who-has 169.254.14.130 tell 169.254.56.166
    11:43:50.588931 arp who-has 169.254.14.131 tell 169.254.56.166
    11:43:50.600770 arp who-has 169.254.14.132 tell 169.254.56.166
    11:43:50.606802 arp who-has 169.254.14.133 tell 169.254.56.166

    Uğur Güngör
    Sistem/Network

    TARNET TARIM KREDİ BİLİŞİM ve İLETİŞİM HİZMETLERİ SAN. ve TİC. A.Ş.
    Adres    : Kazakistan cad (4.cad) 136/1 06510 Emek/ANKARA
    Tel         : 0312 2150997 - 113
    Fax        : 0312 2237886

    -----Original Message-----
    From: Gb74ist [mailto:gurcan_basural_at_yahoo.com]
    Sent: Tuesday, January 04, 2005 5:26 PM
    To: cisco-ttl_at_yahoogroups.com
    Subject: Re: [cisco-ttl] arp packets

    10.0.0.0 255.255.0.0 ile 10.1.0.0 255.255.0.0 networkleri modem ip leri için
    yani 130000 ip buna karşılık pc ipleri için 195.174.x.0 195.174.y.0 arasında
    31 tane network ve yaklaşık 8000 ip ayarlanmış durumda.

    arp isteği :pc ipleri için yollanıyor ve de kullanılan veya kullanılmayan
    ipler de sorgulanıyor .yani 195 ile başlayanlar , 10... olanlar değil bu
    fark edermi acaba düşünürken

    cmts bu arp sorgulamasını yapmak zorunda mı ?

    cmtsin bu sorgulamasını kısıtlıyamaz mıyız?

     

    Ilker Temir <ilker_at_ilkertemir.com> wrote: Kablo networkleri uzmanlik
    alanimim disinda ancak burada dikkati ceken
    onemli noktalar var. Interface uzerinde kullandiginiz IP networkleri cok
    genis bir adres alanini kapsiyor (70 binin uzerinde).

    Sorun buyuk ihtimalle bu network adresinde bulunan ama kullanilmayan
    adreslerden kaynaklaniyor. Herhangi bir uc nokta 10'lu network'te bir
    portscan yaptiginda dahi router bu adreslerin her biri icin ARP requesti
    gondermek durumunda, ki tanimladiginiz soruna oldukca uyuyor. Daha uzun
    ag maskeleri kullanarak (ozellikle 10.0.0.0/16 networku icin) iyilesme
    saglayabilirsiniz saniyorum.

    Bu arada brodcast bir interface'e yonelttiginiz bir statik route var mi?
    Eger varsa (ozellikle kisa ag maskesine sahip), sorunun kaynaklarindan
    biri olabilir.

    Ilker

    Gb74ist wrote:
    >
    > arp paketlerinin yollandığı interface configuration aşağıdaki şekildedir
    >
    > debug çıktılarını vermeye cesaret edmiyorum , ancak olanak olursa
    yollayacağım ,
    >
    >
    >
    >
    >
    >
    >
    > interface Cable3/0
    >
    > bandwidth 27000
    >
    > ip address 195.174.96.10 255.255.240.0 secondary
    >
    > ip address 195.174.112.10 255.255.252.0 secondary
    >
    > ip address 10.0.0.1 255.255.0.0
    >
    > ip helper-address 62.248.101.242
    >
    > load-interval 30
    >
    > cable tftp-enforce
    >
    > cable shared-secret 7 00344151166F11505C156717512110314B2C55307B197D036061
    >
    > cable max-hosts 10
    >
    > cable insertion-interval 500
    >
    > cable bundle 1 master
    >
    > cable downstream annex B
    >
    > cable downstream modulation 64qam
    >
    > cable downstream interleave-depth 32
    >
    > cable downstream frequency 537000000
    >
    > cable downstream channel-id 0
    >
    > cable upstream 0 description (Erenkoy)- FN:18+10+27+30+41
    >
    > cable upstream 0 frequency 37008000
    >
    > cable upstream 0 power-level 0
    >
    > cable upstream 0 channel-width 3200000
    >
    > cable upstream 0 minislot-size 2
    >
    > cable upstream 0 modulation-profile 1
    >
    > no cable upstream 0 rate-limit
    >
    > cable upstream 0 s160-atp-workaround
    >
    > no cable upstream 0 shutdown
    >
    > cable upstream 1 description (Erenkoy)- FN:05+07+15+22
    >
    > cable upstream 1 frequency 37008000
    >
    > cable upstream 1 power-level 0
    >
    > cable upstream 1 channel-width 3200000
    >
    > cable upstream 1 minislot-size 2
    >
    > cable upstream 1 modulation-profile 1
    >
    > no cable upstream 1 rate-limit
    >
    > cable upstream 1 s160-atp-workaround
    >
    > no cable upstream 1 shutdown
    >
    > cable upstream 2 description (Erenkoy)- FN:13+02+45+46
    >
    > cable upstream 2 frequency 42000000
    >
    > cable upstream 2 power-level 0
    >
    > cable upstream 2 channel-width 3200000
    >
    > cable upstream 2 minislot-size 2
    >
    > cable upstream 2 modulation-profile 1
    >
    > no cable upstream 2 rate-limit
    >
    > cable upstream 2 s160-atp-workaround
    >
    > no cable upstream 2 shutdown
    >
    > cable upstream 3 description (Soyak)- FN:01
    >
    > cable upstream 3 frequency 33008000
    >
    > cable upstream 3 power-level 0
    >
    > cable upstream 3 channel-width 3200000
    >
    > cable upstream 3 minislot-size 2
    >
    > cable upstream 3 modulation-profile 1
    >
    > no cable upstream 3 rate-limit
    >
    > cable upstream 3 s160-atp-workaround
    >
    > no cable upstream 3 shutdown
    >
    > cable upstream 4 frequency 33008000
    >
    > cable upstream 4 power-level 0
    >
    > cable upstream 4 channel-width 3200000
    >
    > cable upstream 4 minislot-size 2
    >
    > cable upstream 4 modulation-profile 1
    >
    > no cable upstream 4 rate-limit
    >
    > cable upstream 4 s160-atp-workaround
    >
    > no cable upstream 4 shutdown
    >
    > cable upstream 5 description (Kucukyali)- FN:01+02+03+04+05+06+07+Ultra
    >
    > cable upstream 5 frequency 33008000
    >
    > cable upstream 5 power-level 0
    >
    > cable upstream 5 channel-width 3200000
    >
    > cable upstream 5 minislot-size 2
    >
    > cable upstream 5 modulation-profile 1
    >
    > no cable upstream 5 rate-limit
    >
    > cable upstream 5 s160-atp-workaround
    >
    > no cable upstream 5 shutdown
    >
    > cable dhcp-giaddr policy
    >
    > no keepalive
    >
    > !
    >
    >
    > ---------------------------------
    > Do you Yahoo!?
    > Send holiday email and support a worthy cause. Do good.
    >
    > [Non-text portions of this message have been removed]
    >
    >
    >
    > Bu listenin Cisco Systems ile herhangi bir baglantisi bulunmamaktadir.
    >
    > Listeden cikmak için cisco-ttl-unsubscribe_at_yahoogroups.com adresine bir
    e-posta gönderebilirsiniz.
    > Yahoo! Groups Links
    >
    >
    >
    >
    >
    >
    >

    Bu listenin Cisco Systems ile herhangi bir baglantisi bulunmamaktadir.

    Listeden cikmak için cisco-ttl-unsubscribe_at_yahoogroups.com adresine bir
    e-posta gönderebilirsiniz.

    Yahoo! Groups SponsorADVERTISEMENT

    ---------------------------------
    Yahoo! Groups Links

       To visit your group on the web, go to:
    http://groups.yahoo.com/group/cisco-ttl/
      
       To unsubscribe from this group, send an email to:
    cisco-ttl-unsubscribe_at_yahoogroups.com
      
       Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

                    
    ---------------------------------
    Do you Yahoo!?
     Send holiday email and support a worthy cause. Do good.

    [Non-text portions of this message have been removed]

    Bu listenin Cisco Systems ile herhangi bir baglantisi bulunmamaktadir.

    Listeden cikmak için cisco-ttl-unsubscribe_at_yahoogroups.com adresine bir
    e-posta gönderebilirsiniz.
    Yahoo! Groups Links

     

    Bu listenin Cisco Systems ile herhangi bir baglantisi bulunmamaktadir.

    Listeden cikmak için cisco-ttl-unsubscribe_at_yahoogroups.com adresine bir e-posta gönderebilirsiniz.
    Yahoo! Groups Links

    <*> To visit your group on the web, go to:
        http://groups.yahoo.com/group/cisco-ttl/

    <*> To unsubscribe from this group, send an email to:
        cisco-ttl-unsubscribe_at_yahoogroups.com

    <*> Your use of Yahoo! Groups is subject to:
        http://docs.yahoo.com/info/terms/
     



    This archive was generated by hypermail 2.1.5 : Wed Jan 05 2005 - 11:04:25 GMT