MEGOLDVA: Windows ARP/DHCP stacket megtámadó kártevő?

Microsoft Windows

Kedves informatikus kollégák!

Nem figyeltetek fel a napokban egy olyan kártevő terjedésére, ami a fertőzött gépeket arra veszi rá, hogy az őket kiszolgáló DHCP szervernek olyan téves hibaüzeneteket (DHCP DECLINE) küldjenek, amelyek miatt az úgy érzékeli, hogy kifogyott a kiosztható címekből, ezért az újonnan bedugott gépeknek nem jut cím és nem tudnak internetezni? A kártevő különös ismertetőjele, hogy a fertőzött gépek gyakran IP-cím ütközésre panaszkodnak, és sárga háromszöggel jelölik meg az internetkapcsolatukat.

Wiresharkos elemzés alapján úgy tűnik, hogy a kliens kér egy IP-címet a DHCP szervertől, és miután megkapta, a biztonság kedvéért egy gratuitous ARP kéréssel még utána akar nézni, nem használja-e már egy másik gép a hálózaton. Eddig hibátlannak mondanám a gép működését, de ezután - annak ellenére, hogy egy gép sem küld neki ARP választ arra vonatkozóan, hogy foglalt lenne a szóban forgó cím - a kliens mégis "azt hiszi", hogy a címet már használja valaki, ezért a felhasználónak "IP-cím ütközés" üzenetet küld, a DHCP szervernek pedig DHCP DECLINE csomagot. Ez utóbbi azt jelenti, hogy a kliens tudomása szerint az imént kiosztott cím már használatban volt. A DHCP szervernek kötelessége, hogy a DECLINE üzenet által hivatkozott címet foglaltnak tekintse! A windows DHCP szerver az DECLINE-vel "letiltott" címeket "BAD_ADDRESS" megjelöléssel jelzi be az adatbázisába, és foglaltnak tekinti, vagyis nem osztja ki a klienseknek. A fertőzött (vagy csak simán hibás?) kliens azonban a DHCP DECLINE üzenet elküldése után sajnos új címet kér a DHCP szervertől, majd azt is foglaltnak hiszi, megint DECLINE-t küld, és így megy tovább.

Pár ilyen fertőzött gép hamar elfogyasztja a DHCP szerver kiosztható címeit, ezáltal működésképtelenné téve azt (és az egész hálózati szegmenst). Ugyanaz a jelenség, mint amit az alábbiakban taglalnak, de minden jel szerint nem a cisco router, hanem a kliens szoftverhibája vagy fertőzöttsége okozza:

https://lists.isc.org/pipermail/dhcp-users/2010-August/012211.html

Pár napja jelentek meg az ilyen hibás gépek a hálózatunkban, eddig már kb. húsz ilyet fogtunk. Nem találkoztatok még ilyesmivel?

  • 8012 megtekintés

( neutrino v | 2013. 09. 16., h – 16:06 )

Vedd ki a cisco routert és tesztelj egyet direktben, akkor kiderül hogy a hálózati eszköz vagy a kliens a szar...
-------------------------
A csapatjáték fontos. Nem csak téged lőhetnek!

A cisco routert nem lehet kivenni, mert több mint ezer kliens van mögötte kb. 50 vlan-ban, de úgy tűnik, nem a hálózati eszköz, hanem maga a hálózat okozza a problémát. Talán pont az, hogy olyan nagy... Valami Windows frissítés tehette "túlérzékennyé", esetleg egyenesen hibássá a gépeket.

(no offense) standard hálózatos válasz: "szar a kliens/biztos Windows frissítés", Függetlenül attól, hogy csak 1 vlant érint.
(ontopic) biztos, hogy nem kap vissza Arp response-t vagy akár a saját Arp kérését?
a hibás klienseken reprodukálható a hiba? (minden dhcp kérése így végzi?)
ha reprodukálható, kezdjetek el letiltogatni minden, a halozati stacket érintő programot (viruskeresők pl)
ha nem reprodukálható, nézzetek az adott hálót, nem valaszolgat-e valaki mindenféle arpra?
lehet dhcp relay hiba is (autodiscover bekapcsolva hp procurve switchen?)
meghibásodott halozati eszköz is lehet.

Üdv,
Marci

( nice | 2013. 09. 16., h – 22:39 )

Van egy áthidaló megoldásom a problémára:

Egy transzparens Linux tűzfalat tettem a DHCP szerver elé. A tűzfal egyik portja (eth1) a DHCP szerver felé néz, a másik (eth0) pedig a hálózati szegmens fennmaradó része (kliensgépek, többi szerver, default gateway, stb.) felé. Az eth0 és eth1 interfészek nem rendelkeznek IP-címmel, csak az őket összekötő bridge interfész:


# ip address show
1: lo: mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
2: eth0: mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 1000
    link/ether 00:16:3e:0b:e9:99 brd ff:ff:ff:ff:ff:ff
3: eth1: mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 1000
    link/ether 00:16:3e:0b:ea:99 brd ff:ff:ff:ff:ff:ff
4: br1: mtu 1500 qdisc noqueue state UP
    link/ether 00:16:3e:0b:e9:99 brd ff:ff:ff:ff:ff:ff
    inet ***.***.***.***/** brd ***.***.***.255 scope global br1

# brctl show
bridge name bridge id STP enabled interfaces
br1 8000.00163e0be999 no eth0
                         eth1

A tűzfalon folyamatosan fut egy szkript, ami iptables segítségével letiltja, hogy az egy percen belül két DHCP DECLINE üzenet küldő kliensektől továbbmenjenek a DHCP kérések a DHCP szerver felé:


#!/bin/bash

tshark -l -i eth1 -T fields -e eth.src -f 'udp and src port 68 and dst port 67' -R 'bootp.option.dhcp==4' | stdbuf -o L sed -r 's/\x0d//g;s/:/_/g;s/^/MAC_/' |\
while read DECL
do
 NOW="$(date +%s)"
 if (( NOW - 60 < ${DECL} ))
 then
  MEK=$(echo $DECL | sed -s 's/^MAC_//;s/_/:/g')
  iptables -I FORWARD -m physdev --physdev-in eth0 -m mac --mac-source "$MEK" -p udp --sport 68 --dport 67 -j DROP
  echo -e "A lazado gepet elszigeteltem a DHCP szervertol.\nVirusirtot neki!" | mail -s "Uj DHCP kartevo a halozaton: ${MEK}" 'admin@********.hu'
  unset ${DECL}
 else
  eval ${DECL}=$NOW
 fi
done

Végül is nem rossz szkript ;-)

De amint az alábbiakból láthatod, csak tüneti kezelést nyújt. Igaz, minden valószínűség szerint többféle rendellenesség tüneteinek enyhítésére használható. Ha viszont a nálunk jelentkezett probléma végső okát akarjuk megkeresni, akkor ez kell:

#!/bin/bash

tshark -l -i eth0 -T fields -e eth.src -f 'arp' -R 'arp.opcode==1 and arp.src.proto_ipv4==0.0.0.0 and arp.dst.hw_mac!=00:00:00:00:00:00 and arp.dst.hw_mac!=ff:ff:ff:ff:ff:ff' | stdbuf -o L sed -r 's/\x0d//g;s/:/_/g;s/^/MAC_/' |\
while read DECL
do
 if [[ -z ${!DECL} ]]
 then
  MEK=$(echo $DECL | sed -s 's/^MAC_//;s/_/:/g')
  echo -e "Ugyanolyan csomag, mint amit a halozatot osszeomlaszto D-Link DI-524 kuldott!" | mail -s "Hibas ARP kerdes a ${MEK} cimrol" 'admin@*********.hu'
  eval ${DECL}='valami'
 fi
done

( igiboy | 2013. 09. 17., k – 09:43 )

Nagyon hasonló eset ismerős. Nálam mikrotik routerek. Több hálózat összekötve. Átjárható egymás között. DHCP probléma lett természetesen, mivel a DHCP szerver is kommunikálni akart más hálóba. Tíltva lettek a megfelelő portok. Működött minden szépen, majd egy nap szoltak hogy nem megy 1-2 gép. Ezek windows XP gépek voltak DHCP-n. Roterben a /ip dhcp-server lease táblában rengeteg szemetet találtam, sok bejegyzés csak foglalta a helyet, ugyanannak a gépnek a MAC-jével. Egylőre fordítottam a helyzeten és minden tilva kivéve ami kell. A helyzet megoldódott. (átmenetileg)
Ugyanakkor amikor az XP panaszkodott, akkor linux (CentOS, Fedora) minden gond nélkül csatlakozott. Úgyanúgy ahogy előző nap még az XP-k is.

( nice | 2013. 09. 17., k – 09:53 )

A Windowsos kollégák arról számolnak be, hogy egy teljes kártevőirtás az esetek többségében megszünteti a problémát. Akkor talán mégsem a Windows update okozta. Főleg, hogy olyan gép is áldozatul esett, ami még nem volt frissítve.

Ilyenkor egy HBR jut csak eszembe: WTF??? :)
Napok óta(ha jól értelek, nem tegnap keletkezett a probléma) nyűglődsz vele, sejthető, hogy valami vírus vagy egyéb szemét került a gépekre és a kedves windows-os kollégáknak nem az az első dolguk, hogy az összes gépen végigzavarni egy keresést/irtást?

Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Több mint ezer gép van csak a mi telephelyünkön, de itt is több épületbe szétszórva, egymástól akár kilométeres távolságra, és a fertőzött gépek ugye elérhetetlenek távolról. Néhány fertőzött gép pedig rövid időn belül lehalasztaná a hálózatot, mostanra pedig közel negyven van belőlük...

( nice | 2013. 09. 17., k – 16:14 )

Megvan a bűnös! A problémát egy D-Link DI-524 wireless router okozta, ami ipari mennyiségben küldözgetett az alábbi wireshark szűrőfeltételnek megfelelő ARP kéréseket:

'arp.opcode==1 and arp.src.proto_ipv4==0.0.0.0 and arp.dst.hw_mac!=00:00:00:00:00:00 and arp.dst.hw_mac!=ff:ff:ff:ff:ff:ff'

Ezeket az ARP kéréseket az ethernet broadcast címre küldte a router, és az arp.src.hw_mac mezőben a saját MAC címét adta meg, az arp.dst.proto_ipv4 mezőben pedig az éppen "összeomlasztani kívánt" gép IP címét. Ez eddig hibátlan ARP kérésnek tűnik, azonban érdekes módon az arp.src.proto_ipv4 mezőben 0.0.0.0-át adott meg, és még érdekesebb, hogy az arp.dst.hw_mac mezőbe beírta a kérdéses IP címtulajdonosát! Tehát tudta, hogy ki az, mégis rákérdezett egy ilyen furcsa csomaggal.

Sem azt nem értem, minek küldött ilyen értelmetlen kéréseket, sem azt, hogy a Windows gépek miért érzékelték úgy ennek hatására, hogy IP-cím ütközés van. Na, mindegy. A probléma megoldva, bár ráment pár napom és éjszakám :-(