Archief
- De topics van lang geleden
@home verkeer crasht servers?
Hallo,
Ik beheer een aantal hosting machines, waaronder een paar win2k servers.
Nu constateren we de laatste weken veelvuldig bluescreen stop errors met
een fout in tcp/ip.sys. Deze servers zijn allemaal up to date mbt laatste
hotfixes, sp4 e.d. Ik heb de vermoedelijke packets gecaptured die de
machines laten crashen:
09:32:23.375465 217.120.183.168 > 80.79.3x.xxx: icmp: 217.122.160.11
unreachable - need to frag for 80.79.3x.xxx.80 > 217.122.160.11.3033: [|tcp]
(DF) [tos 0x80] (ttl 119, id 43310, len 48) (DF) (ttl 56, id 13700, len 56)
09:32:23.384618 80.79.3x.xxx > 217.122.160.11: (frag 43311:44@64) (ttl 128,
len 64)
09:32:23.384651 80.79.3x.xxx > 217.122.160.11: (frag 43312:44@64) (ttl 128,
len 64)
<etc>
09:10:27.689664 82.74.32.220 > 80.79.3x.xxx: icmp: 212.120.106.47
unreachable - need to frag for 80.79.3x.xxx.80 > 212.120.106.47.1102: [|tcp]
(DF) [tos 0x80] (ttl 119, id 5995, len 48) (ttl 56, id 35124, len 56)
09:10:27.839032 80.79.3x.xxx > 212.120.106.47: (frag 6016:44@64) (ttl 128,
len 64)
09:10:27.839073 80.79.3x.xxx > 212.120.106.47: (frag 6017:44@64) (ttl 128,
len 64)
<etc>
22:08:05.320938 217.120.194.191 > 80.79.3x.xxx: icmp: 217.120.195.115
unreachable - need to frag for 80.79.3x.xxx.80 > 217.120.195.115.2199: [|tcp]
(DF) [tos 0x60] (ttl 118, id 23231, len 48) (ttl 55, id 48020, len 56)
22:08:05.366400 80.79.3x.xxx > 217.120.195.115: (frag 23247:44@64) (ttl
128, len 64)
22:08:05.366445 80.79.3x.xxx > 217.120.195.115: (frag 23248:44@64) (ttl
128, len 64)
<etc>
Telkens na deze "need to frag, but don't fragment bit set" icmp messages
crasht win2k. Dit is voor het eerst opgetreden eind november. Waarschijnlijk
heeft @home een wijziging in hun netwerk gedaan waardoor er met een
kleine mtu (522 bytes) gewerkt wordt. Schijnbaar triggert dit een onbekende
bug in de win2k tcp/ip stack. Het is op zich normaal dat er in netwerken met
kleine mtu gefragmenteerd wordt, echter alleen bij verkeer afkomstig/naar
het @home netwerk gaat het mis. Het zijn telkens dezelfde routers met veel
verschillende @home klanten erachter. Een ping naar zo'n ip ziet er zo uit:
xxxx@xxxx:~> ping 217.120.195.115
PING 217.120.195.115 (217.120.195.115) from 80.79.3x.xx : 56(84) bytes of
data.
From 217.120.194.191: icmp_seq=1 Frag needed and DF set (mtu = 0)
From 217.120.194.191 icmp_seq=1 Frag needed and DF set (mtu = 552)
64 bytes from 217.120.195.115: icmp_seq=1 ttl=119 time=15.613 msec
64 bytes from 217.120.195.115: icmp_seq=2 ttl=119 time=16.953 msec
64 bytes from 217.120.195.115: icmp_seq=3 ttl=119 time=17.451 msec
Ik kan me niet voorstellen dat wij de enige zijn die dit geconstateerd hebben.
Het is wel zo dat deze servers abnormaal veel verkeer van @home
afhandelen omdat ze op hun portal links hebben staan die gebruik maken
van die machines.
We hebben het probleem opgelost door ICMP verkeer helemaal te blocken.
Echter, vermoedelijk kunnen @home klanten nu niet meer bij deze servers.
Als het DF bit gezet is zullen routers verderop in het netwerk het verkeer niet
gaan fragmenteren, als het goed is.
Thoughts, anyone?
Ik beheer een aantal hosting machines, waaronder een paar win2k servers.
Nu constateren we de laatste weken veelvuldig bluescreen stop errors met
een fout in tcp/ip.sys. Deze servers zijn allemaal up to date mbt laatste
hotfixes, sp4 e.d. Ik heb de vermoedelijke packets gecaptured die de
machines laten crashen:
09:32:23.375465 217.120.183.168 > 80.79.3x.xxx: icmp: 217.122.160.11
unreachable - need to frag for 80.79.3x.xxx.80 > 217.122.160.11.3033: [|tcp]
(DF) [tos 0x80] (ttl 119, id 43310, len 48) (DF) (ttl 56, id 13700, len 56)
09:32:23.384618 80.79.3x.xxx > 217.122.160.11: (frag 43311:44@64) (ttl 128,
len 64)
09:32:23.384651 80.79.3x.xxx > 217.122.160.11: (frag 43312:44@64) (ttl 128,
len 64)
<etc>
09:10:27.689664 82.74.32.220 > 80.79.3x.xxx: icmp: 212.120.106.47
unreachable - need to frag for 80.79.3x.xxx.80 > 212.120.106.47.1102: [|tcp]
(DF) [tos 0x80] (ttl 119, id 5995, len 48) (ttl 56, id 35124, len 56)
09:10:27.839032 80.79.3x.xxx > 212.120.106.47: (frag 6016:44@64) (ttl 128,
len 64)
09:10:27.839073 80.79.3x.xxx > 212.120.106.47: (frag 6017:44@64) (ttl 128,
len 64)
<etc>
22:08:05.320938 217.120.194.191 > 80.79.3x.xxx: icmp: 217.120.195.115
unreachable - need to frag for 80.79.3x.xxx.80 > 217.120.195.115.2199: [|tcp]
(DF) [tos 0x60] (ttl 118, id 23231, len 48) (ttl 55, id 48020, len 56)
22:08:05.366400 80.79.3x.xxx > 217.120.195.115: (frag 23247:44@64) (ttl
128, len 64)
22:08:05.366445 80.79.3x.xxx > 217.120.195.115: (frag 23248:44@64) (ttl
128, len 64)
<etc>
Telkens na deze "need to frag, but don't fragment bit set" icmp messages
crasht win2k. Dit is voor het eerst opgetreden eind november. Waarschijnlijk
heeft @home een wijziging in hun netwerk gedaan waardoor er met een
kleine mtu (522 bytes) gewerkt wordt. Schijnbaar triggert dit een onbekende
bug in de win2k tcp/ip stack. Het is op zich normaal dat er in netwerken met
kleine mtu gefragmenteerd wordt, echter alleen bij verkeer afkomstig/naar
het @home netwerk gaat het mis. Het zijn telkens dezelfde routers met veel
verschillende @home klanten erachter. Een ping naar zo'n ip ziet er zo uit:
xxxx@xxxx:~> ping 217.120.195.115
PING 217.120.195.115 (217.120.195.115) from 80.79.3x.xx : 56(84) bytes of
data.
From 217.120.194.191: icmp_seq=1 Frag needed and DF set (mtu = 0)
From 217.120.194.191 icmp_seq=1 Frag needed and DF set (mtu = 552)
64 bytes from 217.120.195.115: icmp_seq=1 ttl=119 time=15.613 msec
64 bytes from 217.120.195.115: icmp_seq=2 ttl=119 time=16.953 msec
64 bytes from 217.120.195.115: icmp_seq=3 ttl=119 time=17.451 msec
Ik kan me niet voorstellen dat wij de enige zijn die dit geconstateerd hebben.
Het is wel zo dat deze servers abnormaal veel verkeer van @home
afhandelen omdat ze op hun portal links hebben staan die gebruik maken
van die machines.
We hebben het probleem opgelost door ICMP verkeer helemaal te blocken.
Echter, vermoedelijk kunnen @home klanten nu niet meer bij deze servers.
Als het DF bit gezet is zullen routers verderop in het netwerk het verkeer niet
gaan fragmenteren, als het goed is.
Thoughts, anyone?
Reacties (9)
11-12-2003, 11:26 door
SirDice
Heb je al eens contact opgenomen met @home zelf?
11-12-2003, 11:50 door
Alucard2
Door SirDice
Heb je al eens contact opgenomen met @home zelf?
Heb je al eens contact opgenomen met @home zelf?
Uiteraard.
Weet je hoe lang het duurt voor iemand reageert op mail aan
[email]abuse@home.nl[/email]?
Gewoon regulier netwerkverkeer dat je servers zou doen crashen?
Wat dacht je ervan om je servers van een fatsoenlijk OS te
voorzien?
Wat dacht je ervan om je servers van een fatsoenlijk OS te
voorzien?
Dit zijn gewone tos icmp messages die elke server zouden
moeten accepteren of rejecten...
ligt dus meer aan jou servers dan aan @home
of installeer idd een fatsoenlijk OS op een server ipv
windows.. (debian :P)
moeten accepteren of rejecten...
ligt dus meer aan jou servers dan aan @home
of installeer idd een fatsoenlijk OS op een server ipv
windows.. (debian :P)
Misschien heeft het meer zin om naar een ander adres te
mailen dan abuse@.
Het is immers een configuratie probleem, aan jouw of huner
zijde.
HTH
mailen dan abuse@.
Het is immers een configuratie probleem, aan jouw of huner
zijde.
HTH
Quote: "Installeer een fatsoenlijke OS"
Stakkers zijn jullie, iemand komt met een serieus probleem en het enig
wat jullie kunnen mekkeren is dat hij een ander OS moet installeren.
ZUCHT, wordt er zo moe van.
Stakkers zijn jullie, iemand komt met een serieus probleem en het enig
wat jullie kunnen mekkeren is dat hij een ander OS moet installeren.
ZUCHT, wordt er zo moe van.
Door Anoniem
Quote: "Installeer een fatsoenlijke OS"
Stakkers zijn jullie, iemand komt met een serieus probleem en het enig
wat jullie kunnen mekkeren is dat hij een ander OS moet installeren.
ZUCHT, wordt er zo moe van.
Quote: "Installeer een fatsoenlijke OS"
Stakkers zijn jullie, iemand komt met een serieus probleem en het enig
wat jullie kunnen mekkeren is dat hij een ander OS moet installeren.
ZUCHT, wordt er zo moe van.
Idd eindelijk een serieuze vraag en dan wordt er weer door een
ogenschijnlijke n00b zo'n stom antwoord gegeven.
Door Anoniem
Idd eindelijk een serieuze vraag en dan wordt er weer door een
ogenschijnlijke n00b zo'n stom antwoord gegeven.
Door Anoniem
Quote: "Installeer een fatsoenlijke OS"
Stakkers zijn jullie, iemand komt met een serieus probleem en het enig
wat jullie kunnen mekkeren is dat hij een ander OS moet installeren.
ZUCHT, wordt er zo moe van.
Quote: "Installeer een fatsoenlijke OS"
Stakkers zijn jullie, iemand komt met een serieus probleem en het enig
wat jullie kunnen mekkeren is dat hij een ander OS moet installeren.
ZUCHT, wordt er zo moe van.
Idd eindelijk een serieuze vraag en dan wordt er weer door een
ogenschijnlijke n00b zo'n stom antwoord gegeven.
Misschien hebben de routers van @home last van het black hole
probleem
Zie Microsoft Knowledge Base Article - 159211
Wellicht kun je hier iets mee. (even snel een antwoord, ga weer verder
met werken)
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
