Zywall wordt intern aangevallen

[oeroe.b]

Beste mensen,

Op dit moment heb ik een klein bedrijfje van rond de 30 werkstations waar ik bij klus als student. Heb pas een zywall geinstalleerd en alles verloopt prima. Alleen nu krijg ik telkens berichtjes van het apparaat dat we intern pakketjes blijven versturen. Onderstaande meldingen stuurt hij dan per e-mail naar me toe. (soms wel 10 keer per dag)

Time: 12/13/2005, 18:08:24
Message: UDP Flood to Host
Source: 10.0.0.135, 18784
Destination:32.106.195.244, 52203 (from ATM1 Outbound)

Time: 12/14/2005, 11:16:50
Message: SYN Flood to Host
Source: 10.0.0.135, 1379
Destination:64.207.147.24,

Nu is mijn vraag, hoe moet ik dit aanpakken om te zoeken waar dit netwerk verkeer vandaan komt. Ik heb al in de logs gekeken maar merk hier niets speciaals. Wat is de gemakkelijkste manier om nu de machine te ondekken die dit verstuurd?


groetjes Oeroe

[Tuumke]

oeroe.b schreef op donderdag 15 december 2005 @ 11:16:
Beste mensen,

Op dit moment heb ik een klein bedrijfje van rond de 30 werkstations waar ik bij klus als student. Heb pas een zywall geinstalleerd en alles verloopt prima. Alleen nu krijg ik telkens berichtjes van het apparaat dat we intern pakketjes blijven versturen. Onderstaande meldingen stuurt hij dan per e-mail naar me toe. (soms wel 10 keer per dag)

Time: 12/13/2005, 18:08:24
Message: UDP Flood to Host
Source: 10.0.0.135, 18784
Destination:32.106.195.244, 52203 (from ATM1 Outbound)

Time: 12/14/2005, 11:16:50
Message: SYN Flood to Host
Source: 10.0.0.135, 1379
Destination:64.207.147.24,

Nu is mijn vraag, hoe moet ik dit aanpakken om te zoeken waar dit netwerk verkeer vandaan komt. Ik heb al in de logs gekeken maar merk hier niets speciaals. Wat is de gemakkelijkste manier om nu de machine te ondekken die dit verstuurd?


groetjes Oeroe

Source: 10.0.0.135, 18784
Source: 10.0.0.135, 1379

-edit-
Port Info:
dbreporter 1379/tcp Integrity Solutions
dbreporter 1379/udp Integrity Solutions
van http://www.iana.org/assignments/port-numbers

IPinfo
32.106.195.244
AT&T Global Network Services
3200 Lake Emma Road
Lake Mary, FL
US

64.207.147.24
Media Temple
8520 National Blvd.
Building A
Culver City, CA
US

via www.all-nettools.com/toolbox

Probeer anders is op dat systeem
een port lister te draaien zoals bijv Fport of OpenPorts
en c&p dat is hierzo in (als je dat tenminste wilt)
misschien draait er wel een of andere rare service?

[ Voor 32% gewijzigd door Tuumke op 15-12-2005 11:37 ]

[webfreakz.nl]

Machine 10.0.0.135 verstuurd het pakketje, dus je moet bij die machine gaan zoeken. Misschien dat er P2P software opstaat? (ik noem maar wat)

[-Jaap-io]

Ik zie in je post het source adres staan, is dat niet de computer die de oorzaak is?

verder zou je ethereal kunnen gebruiken om al het netwerk verkeer te scannen. Hubje tussen netwerk en firewall, laptop op hubje met ethereal en scannen maar (niet op een switch want dan krijg je niet al het netwerk verkeer )

[CodeCaster]

webfreakz.nl schreef op donderdag 15 december 2005 @ 11:19:
Machine 10.0.0.135 verstuurd het pakketje, dus je moet bij die machine gaan zoeken. Misschien dat er P2P software opstaat? (ik noem maar wat)

Inderdaad, een SYN en UDP flood lijkt mijns inziens op een P2P programma. SYN wordt gebruikt om een connectie op te zetten: P2P programma's maken er soms honderden. UDP is dan wel weer connectionless, maar wordt ook gebruikt door P2P.

Gokje: Kijk welke PC dat IP-adres (10.0.0.135) heeft en verwijder Shareaza.

[ Voor 200% gewijzigd door CodeCaster op 15-12-2005 11:43 ]

[Tuumke]

CodeCaster schreef op donderdag 15 december 2005 @ 11:33:
Adres in USA

via www.all-nettools.com/toolbox

Misschien is dat wel een intern adres?

die 32.* of die 64.* ? dacht het niet

[ Voor 24% gewijzigd door Tuumke op 15-12-2005 11:36 ]

[CodeCaster]

Tuumke schreef op donderdag 15 december 2005 @ 11:35:
[...]


die 32.* of die 64.* ? dacht het niet

Ik heb die reply al verwijderd hoor Ik dacht dat je die 10.0.0.135 opgezocht had

Dan nog heeft ie vrij weinig aan die adressen...

[oeroe.b]

thnx voor de snelle reacties.


voor de duidelijkheid zywall heeft 2 portjes interne netwerk is op 192.168.1.1 ->
aan de externe kant 10.0.0.140 die weer is aangesloten op het modem 10.0.0.135

Het is dus geen pc die 135! probleem is al het verkeer gaat door de zywall naar het modem. dus ik kan niet zien wie nou de veroorzaker is. Ik dacht dus dat kan ik zien in de logs, maar daar zie ik niets bijzonders

[ Voor 11% gewijzigd door oeroe.b op 15-12-2005 11:50 ]

[Verwijderd]

Zo te zien is het outbound en ligt het probleem binnen jouw netwerkje. Wellicht kun je met een packetsniffer achterhalen van welk werkstation het afkomt, en die uit het netwerk trekken. Daarna kun je gaan kijken wat ermee aan de hand is (spyware/share programma/virus etc.)

[webfreakz.nl]

oeroe.b schreef op donderdag 15 december 2005 @ 11:48:
thnx voor de snelle reacties.

voor de duidelijkheid zywall heeft 2 portjes interne netwerk is op 192.168.1.1 ->
aan de externe kant 10.0.0.140 die weer is aangesloten op het modem 10.0.0.135

Het is dus geen pc die 135! probleem is al het verkeer gaat door de zywall naar het modem. dus ik kan niet zien wie nou de veroorzaker is.

Dan moet je of dit doen, óf alle pc's afgaan!

Maybe kan je alvast die porten blokkeren zodat die error message (tijdelijk?) niet meer komt?

[-Jaap-io]

Volgens mij kan je in de packet header van een tcp-ip packet ook het orginele adres zien. Dus voordat het "ge-nat"werd op de zyxel. uit mijn hoofd gezegt heet het source-adres.

Dit is van belang als het packetje terug komt op de router zodat die de source weet.

deze headers zijn met te lezen met ethereal

ik zat er nog even over na te denken,
Maar je krijgt een mail van de zyxel?
Die zyxel wordt overspoeld met berichten bestemd voor 32.nog.wat.ip, dat klopt dan toch niet
het lijkt wel of dat modem 10.0.0.135 die berichten het verkeerde netwerk opstuurd....

[ Voor 32% gewijzigd door -Jaap-io op 15-12-2005 12:02 ]

[Tuumke]

post anders oko nog is eventjes het log van
Time: 12/14/2005, 11:16:50
rondom die tijd.

[Taigu]

Alleen nu krijg ik telkens berichtjes van het apparaat dat we intern pakketjes blijven versturen.

Iets specifiekere meldingen zou prettig zijn. Heb je Zyxel hier al over gebeld ? Zo op het eerste gezicht lijkt het me een wat paranoia SYN Flood / UDP Flood detection op het apparaat. Dit wordt veroorzaakt (zoals eerder aangegeven) door het feit dat je modem hiervoor ook in NAT modus staat.

Misschien is het sowieso verstandig te kijken of je het DSL router/modem in bridge modus kan instellen. Je Zywall krijgt dan op de WAN poort je internet IP adres en in geval van attacks kun je dan meer vertrouwen op src en dest. ip's. Een beetje googlen leidt je dan naar dit soort pagina's, wel aardig leesvoer.

[oeroe.b]

heb even gekeken 's avonds en vond het volgende log! De machine is dus de DNS server, ik heb hier geen wijzigingen aangebracht. Tevens heb ik de netwerkkaart gescand met TDIMon en vond ik dus dat de server de hele tijd broadcast berichtjes verzend. Dit lijkt mij niet normaal, als er niemand is ??


Firewall default policy: TCP (L to W)
59|2005-12-15 23:54:29 |192.168.1.12:1059 |192.43.172.30:53 |ACCESS PERMITTED
Firewall default policy: UDP (L to W)
60|2005-12-15 23:54:29 |192.168.1.12:1059 |192.43.172.30:53 |ACCESS PERMITTED
Firewall default policy: UDP (L to W)
61|2005-12-15 23:54:25 |192.168.1.12:1059 |64.21.152.8:53 |ACCESS DROPPED
Firewall rule match: UDP (L to W, rule:2)
62|2005-12-15 23:54:25 |192.168.1.12:1059 |64.21.152.8:53 |ACCESS DROPPED
Firewall rule match: UDP (L to W, rule:2)
63|2005-12-15 23:54:25 |192.168.1.12:1059 |192.43.172.30:53 |ACCESS PERMITTED
Firewall default policy: UDP (L to W)
64|2005-12-15 23:54:25 |192.168.1.12:1059 |192.43.172.30:53 |ACCESS PERMITTED
Firewall default policy: UDP (L to W)
65|2005-12-15 23:54:23 |192.168.1.12:1059 |192.43.172.30:53 |ACCESS PERMITTED
Firewall default policy: UDP (L to W)
66|2005-12-15 23:54:22 |192.168.1.12:1059 |192.43.172.30:53 |ACCESS PERMITTED
Firewall default policy: UDP (L to W)
67|2005-12-15 23:54:21 |192.168.1.12:1059 |64.21.152.7:53 |ACCESS DROPPED
Firewall rule match: UDP (L to W, rule:2)
68|2005-12-15 23:54:21 |192.168.1.12:1059 |64.21.152.7:53 |ACCESS DROPPED

[Taigu]

Ern wat is rule 2 dan in je firewall ? Voor de duidelijkheid 192.168.1.12 is jouw DNS server ?

[Verwijderd]

die 64.x.x.x is een externe DNS-server. Ik weet niet waarom hij daarnaartoe probeert te connecten, maar kun je die niet ergens terugvinden in de instellingen van je eigen DNS server? (de 192.168.1.12)

[Taigu]

Kunnen meerdere zaken zijn:

- De server staat ingesteld als forwarder (lijkt me niet)
- De server is een ROOT DNS server (lijkt me ook niet)
- De server is authorative voor bepaalde domeinen en jouw server queriet die machine (lijkt me in eerste instantie het geval)

Maar kun je de 2e regel van je lan-wan ruleset misschien toelichten ? Mag jouw dns server alleen naar buiten DNS verkeer versturen naar bep servers ? Het verkeer naar 192.43.172.30 (wat wel een echte root dns server is) wordt wel toegestaand. De root hint vertelt jouw server wat de auth. server is voor een bep domein, jouw server gaat bij de auth. server queryen en dan loopt het mis. Indien je fw regel 2 niet zo apart is, is het wat mij betreft een paranoia UDP Spoof detectie op je fw, veroorzaakt door NAT op je router.

[ Voor 31% gewijzigd door Taigu op 16-12-2005 11:53 ]

[oeroe.b]

buddhole schreef op vrijdag 16 december 2005 @ 11:51:
Kunnen meerdere zaken zijn:

- De server staat ingesteld als forwarder (lijkt me niet)
- De server is een ROOT DNS server (lijkt me ook niet)
- De server is authorative voor bepaalde domeinen en jouw server queriet die machine (lijkt me in eerste instantie het geval)

Maar kun je de 2e regel van je lan-wan ruleset misschien toelichten ? Mag jouw dns server alleen naar buiten DNS verkeer versturen naar bep servers ? Het verkeer naar 192.43.172.30 (wat wel een echte root dns server is) wordt wel toegestaand. De root hint vertelt jouw server wat de auth. server is voor een bep domein, jouw server gaat bij de auth. server queryen en dan loopt het mis. Indien je fw regel 2 niet zo apart is, is het wat mij betreft een paranoia UDP Spoof detectie op je fw, veroorzaakt door NAT op je router.

zal zo even kijken ben vanmiddag op mn werk. 192.168.1.12 is idd mijn DNS machine. En naar mijn weten is firewall regel 2 een standaard regel op mn zywall. Zou ik die eventueel uit moeten zetten zodat het "auth queryen weer wel goed gaat? Zelf weet ik er weinig van hoe dat gaat met die dns query's naar buiten.

Toen ik gister die scan heb gedaan op dit adres zag ik dat hij de hele tijd bezig was om broadcast berichtjes te versturen naar een dns server waarschijnlijk? dus hij weet zn weg niet te vinden? Lijkt me in ieder geval niet normaal dat de dns de hele tijd broadcast over het netwerk.

[ Voor 12% gewijzigd door oeroe.b op 16-12-2005 12:03 ]

[oeroe.b]

die tweede regel was dus niet een standaard regel. Maar een regel om msn te blokkeren op het netwerk. hiervoor had ik het volgende gedaan op de zyxel website (http://www.zyxel.nl/support/z027.html)

Bij Kazaa dient u poort 1214 te blokkeren voor zowel ingaand en uitgaand verkeer.

MSN is moeilijker:
-blokkeer uitgaand 1863
-blokkeer ip-ranges:

207.0.0.0 255.0.0.0
64.0.0.0 255.0.0.0
65.0.0.0 255.0.0.0

[Verwijderd]

oeroe.b schreef op vrijdag 16 december 2005 @ 12:16:
die tweede regel was dus niet een standaard regel. Maar een regel om msn te blokkeren op het netwerk. hiervoor had ik het volgende gedaan op de zyxel website (http://www.zyxel.nl/support/z027.html)

Bij Kazaa dient u poort 1214 te blokkeren voor zowel ingaand en uitgaand verkeer.

MSN is moeilijker:
-blokkeer uitgaand 1863
-blokkeer ip-ranges:

207.0.0.0 255.0.0.0
64.0.0.0 255.0.0.0
65.0.0.0 255.0.0.0

Nu ik dit lees zou dat 64.x.x.x adres best een MSN server kunnen zijn ja Maar je blokkeert nu inderdaad die range, dus het is logisch dat je firewall die pakketjes dropt.

[Verwijderd]

@nyny83: nee de host 64.21.152.7 is hoogstwaarschijnlijk ook een DNS server (port 53 = dns).

Er is "iets" op zijn netwerk dat een verbinding wil maken. Er wordt aan zijn DNS server (192.168.1.12) om een hostname naar IP adres omzetting gevraagd. Zijn interne DNS server weet het antwoord op deze vraag *NIET*, en vraagt dan aan een root server (192.43.172.30). Deze root server verwijst vervolgens weer door naar een andere DNS server (64.21.152.7) welke meer weet over het gezochte domein/hostname. De firewall blokkeert dit, dus de verbinding mislukt. Zo te zien geeft het "programma/spyware/weet ik veel" geen foutmelding maar gaat enkele seconden later gewoon weer opnieuw proberen om een verbinding te maken.

Misschien moet je DNS logging eens aanzetten om te kijken welke PC deze aanvraag doet.

64.21.152.7 = dns.site5.com
64.21.152.8 = dns2.site5.com

[ Voor 15% gewijzigd door Verwijderd op 16-12-2005 13:27 ]

[Vinnienerd]

Dat oeroe.b bijklust als student is wel duidelijk

[Taigu]

Dat is misschien wat offtopic .

Ik gok dat regel 2 verkeerd is ingesteld met src en dest poorten. Ook blijf ik erbij dat UDP flood detection / Syn flood detection gewoon uitgezet moet worden. Het is misschien niet 100% veilig of de beste config mogelijk, maar als je dat zonodig wilt moet je maar je je router in bridge modus zetten. Als alternatief is het misschien mogelijk tresholds voor de beide flood detections hoger te zetten.

[aZuL2001]

oeroe.b schreef op vrijdag 16 december 2005 @ 12:16:
Maar een regel om msn te blokkeren op het netwerk.

Je zult waarschijnlijk de msn messenger bedoelen.
msn is een vrij algemene naam , maar ook een website. www.msn.nl bijv.

Heeft het betreffende bedrijf daar beleid voor of heb jij dit zelf bedacht ?

En wat als ze nu Skype gaan proberen, of Trillian, of IRC ? of de webmessenger ?