---

Nu har jeg modtaget icmp type 11 (Time exeded) i 4 dage .. pakkerne
modtager jeg hvert 5 min ..

normalt syntes jeg ikke der er noget skummelt i at modtage disse pakker
men når det er for hvert femte minut og jeg ikke har kontakte sitet
finder jeg skummelt .. findes der nogen teknik der kan via icmp type 11
at nogen kan få fat i en eller anden form for information som kan skade
min maskine og sikkerheden som jeg ikke lige har hørt om ?

Mvh
Kim

---

On Thu, 31 Jan 2002 07:43:28 +0100, "Kim Nielsen"
<knielsenSPAMFREE@proventum.net> wrote:

>Nu har jeg modtaget icmp type 11 (Time exeded) i 4 dage .. pakkerne
>modtager jeg hvert 5 min ..

Hvor modtager du dem fra? Det kan jo tænkes, at det rent faktisk er
100% korrekte svar, måske som følge af at din maskine forsøger at
sende data ud hvert 5. minut.

--
- Peter Brodersen

---

In article <0E768.4450$m6.339904@news000.worldonline.dk>, "Peter
Brodersen" <professionel@nerd.dk> wrote:

> On Thu, 31 Jan 2002 07:43:28 +0100, "Kim Nielsen"
> <knielsenSPAMFREE@proventum.net> wrote:
>
>>Nu har jeg modtaget icmp type 11 (Time exeded) i 4 dage .. pakkerne
>>modtager jeg hvert 5 min ..
>
> Hvor modtager du dem fra? Det kan jo tænkes, at det rent faktisk er 100%
> korrekte svar, måske som følge af at din maskine forsøger at sende data
> ud hvert 5. minut.

Jan 31 07:05:03 deepblue kernel: grsec: icmp type=11 code=0 on eth0
src=195.215.106.189 dst=10.0.0.2

Pakkerne kommer fra denne ip til min maskine .. men jeg har prøvet at
kigge med tcpdump og der komme ikke nogen pakker fra mit netværk .. kun
fra denne ip .. det er det jeg syntes der var skummelt ..

først troede jeg at der var een der havde installeret en trojan som ikke
kunne få adgang til sin "mester" men hverken aide, snort eller grsec
kerne patch har sagt noget .. (Betyder dog ikke at nogen ikke kan komme
ind) men det er lidt skummelt .. derfor skrev jeg til denne gruppe da jeg
ikke lige kan greje om det er et sikkerheds problem eller det er een
eller anden klovn der leger ..

/Kim

>

---

Kim Nielsen wrote:
>
> In article <0E768.4450$m6.339904@news000.worldonline.dk>, "Peter
> Brodersen" <professionel@nerd.dk> wrote:
>
> > On Thu, 31 Jan 2002 07:43:28 +0100, "Kim Nielsen"
> > <knielsenSPAMFREE@proventum.net> wrote:
> >
> >>Nu har jeg modtaget icmp type 11 (Time exeded) i 4 dage .. pakkerne
> >>modtager jeg hvert 5 min ..
> >
> > Hvor modtager du dem fra? Det kan jo tænkes, at det rent faktisk er 100%
> > korrekte svar, måske som følge af at din maskine forsøger at sende data
> > ud hvert 5. minut.
>
> Jan 31 07:05:03 deepblue kernel: grsec: icmp type=11 code=0 on eth0
> src=195.215.106.189 dst=10.0.0.2

Hvis din IP addresse er 10.0.0.2 må du jo side bagved en
masquerading firewall eller noget i den regning. Ifølge
headeren har du postet fra pixexit.proventum.dk hvilket
jo passer meget godt på en masquerading. Men hvis det er
tilfældet burde pakken aldrig komme ind medmindre der
også er blevet sendt noget ud.

De to addresser er så vidt jeg kan se ikke mere end 15
hops fra hinanden, så timeouts burde kun forekomme hvis
der blev sendt pakker med meget små ttl værdier. Det
sker f.eks. hvis man bruger traceroute.

>
> Pakkerne kommer fra denne ip til min maskine .. men jeg har prøvet at
> kigge med tcpdump og der komme ikke nogen pakker fra mit netværk .. kun
> fra denne ip .. det er det jeg syntes der var skummelt ..

Hvis der virkelig ikke kommer pakker fra dit netværk,
hvorfor bliver svarene så overhovedet lukket ind?

Kan du skitsere hvordan dit netværk ser ud, og hvor du
ser pakkerne, og hvor du ellers har kigget efter, om der
blev sendt pakker ud?

--
Kasper Dupont
For sending spam use mailto:razor-report@daimi.au.dk

---

In article <3C59358F.3DED4282@daimi.au.dk>, "Kasper Dupont"
<kasperd@daimi.au.dk> wrote:
>
> Hvis din IP addresse er 10.0.0.2 må du jo side bagved en masquerading
> firewall eller noget i den regning. Ifølge headeren har du postet fra
> pixexit.proventum.dk hvilket jo passer meget godt på en masquerading.
> Men hvis det er tilfældet burde pakken aldrig komme ind medmindre der
> også er blevet sendt noget ud.
Jeps . .nu er det en hjemme maskine (insecurity.dk) men stadig det samme
... routeren er den dsl router fra cybercity ..

> De to addresser er så vidt jeg kan se ikke mere end 15 hops fra
> hinanden, så timeouts burde kun forekomme hvis der blev sendt pakker med
> meget små ttl værdier. Det sker f.eks. hvis man bruger traceroute.
Men kræver det ikke at jeg bruger tracerouter inde fra mit netværk for at
maskinen med en teledk ip kan svare tilbage med icmp 11

>> Pakkerne kommer fra denne ip til min maskine .. men jeg har prøvet at
>> kigge med tcpdump og der komme ikke nogen pakker fra mit netværk .. kun
>> fra denne ip .. det er det jeg syntes der var skummelt ..
>
> Hvis der virkelig ikke kommer pakker fra dit netværk, hvorfor bliver
> svarene så overhovedet lukket ind?
Det er også det jeg finder skummelt .. men tcpdump melder ikke om at
noget bliver sendt fra min maskine og ud .. derfor tænkte jeg i første
omgang at det var et hul i cisco routeren men har ikke kunne finde et
sådanne exploit ..

> Kan du skitsere hvordan dit netværk ser ud, og hvor du ser pakkerne, og
> hvor du ellers har kigget efter, om der blev sendt pakker ud?
jeg kører med grsecurity patch i kernen (Linux 2.4.17) og den logger icmp
og tcp/udp pakker som ikke er blevet håndteret + der er en firewall som
ikke tillader noget andet end på nedenstående porte .. men det jeg finder
skummelt er at de kommer forbi routeren der kun nat'er port 22,25,80,443
til min maskine på det interne net ..

mit netværk:

cybercity adsl router -> Linux box (min gateway) -> Interne netvær (består af 2 linux maskiner + 1 openbsd)

og det er på gatewayen jeg fanger disse pakker (Grunden til at jeg har en
gateway efter routeren er at jeg ikke stoler på cybercity/cisco's adsl
udstyr) .. jeg er dog ikke bekymret (Endnu) da pakkerne ikke kommer videre end gatewayen men
det er lidt skummelt. Og jeg har ikke oplevet det før .. det sker engang
i mellem at jeg modtager disse pakker men med præcis 5 min. forskel er
ikke sket før

Håber det hjælper lidt til at fejlfinde dette .. jeg har kontaktet
abuse@cybercity som ikke vil håndtere problemet da det er en teledk ip ..
derefter kontaktede jeg csirt@csirt som ikke har svaret endnu ..

men noget kunne tyde på at det er en router (altså ip'en)

Mvh
Kim

---

"Kim Nielsen" <knielsenSPAMFREE@proventum.net> wrote in message
news:a3bhad$llv$1@sunsite.dk...

> Det er også det jeg finder skummelt .. men tcpdump melder ikke om at
> noget bliver sendt fra min maskine og ud .. derfor tænkte jeg i første
> omgang at det var et hul i cisco routeren men har ikke kunne finde et
> sådanne exploit ..

Jeg har lignende oplevelser med at smurf-agtige pakker lukkes igennem af min
Cisco 677 fra CyberCity (se evt. min tråd tidligere).

Kan der er være en generel fej i CCs opsætning af routere?

--
Mvh. Mogens
Bach.scient. i datalogi. Søger IT-job på Fyn!
www.momech.dk

---

Mogens Meier Christensen wrote:
>
> "Kim Nielsen" <knielsenSPAMFREE@proventum.net> wrote in message
> news:a3bhad$llv$1@sunsite.dk...
>
> > Det er også det jeg finder skummelt .. men tcpdump melder ikke om at
> > noget bliver sendt fra min maskine og ud .. derfor tænkte jeg i første
> > omgang at det var et hul i cisco routeren men har ikke kunne finde et
> > sådanne exploit ..
>
> Jeg har lignende oplevelser med at smurf-agtige pakker lukkes igennem af min
> Cisco 677 fra CyberCity (se evt. min tråd tidligere).
>
> Kan der er være en generel fej i CCs opsætning af routere?

Det er vel ikke utænkeligt. I så fald burde man nok orientere
CC. Men de er nok ligeglade, det er vel ikke for at forbedre
kundernes sikkerhed at de sætter routerne op. Så så længe de
kan håndtere den normale trafik gør det vel ikke noget, at
der slipper noget uønsket igen.

Det minder mig iøvrigt om en underlighed på mit eget
kabelmodem Motorola Surfboard SB4100, det har en standby
knap, som slukker dioderne og lukker for netforbindelsen. Jeg
blev noget overrasket, da det en dag gik op for mig, at den
kun lukkede for udgående pakker, indgående pakker blev stadig
lukket igennem. Er der andre, der har oplevet noget lignende?

--
Kasper Dupont
For sending spam use mailto:razor-report@daimi.au.dk

---

"Kim Nielsen" skrev:

> Men kræver det ikke at jeg bruger tracerouter inde fra mit netværk for at
> maskinen med en teledk ip kan svare tilbage med icmp 11

Det behøver ikke at være en traceroute.
En ICMP type 11 sendes fra en router, hvis TTL tælles ned til 0,
i en hvilkensomhelst ip pakke.
Formatet for en icmp type 11 er således at source ip adressen
er den router som sender icmp pakken. M.a.o. er det ikke den
adresse som din router/workstation forsøgte at nå. Du kan se
en del af din afsendte pakke i datadelen af icmp pakken. Ved at
analysere den del, kan du m.a.o. få en meget bedre ide om hvad
der er årsagen til denne helt normale kontrolpakke.

Misbrug er der ikke tale om.

/Bjørn Kristensen

---

"Bjørn Kristensen" wrote:
>
> "Kim Nielsen" skrev:
>
> > Men kræver det ikke at jeg bruger tracerouter inde fra mit netværk for at
> > maskinen med en teledk ip kan svare tilbage med icmp 11
>
> Det behøver ikke at være en traceroute.
> En ICMP type 11 sendes fra en router, hvis TTL tælles ned til 0,
> i en hvilkensomhelst ip pakke.
> Formatet for en icmp type 11 er således at source ip adressen
> er den router som sender icmp pakken. M.a.o. er det ikke den
> adresse som din router/workstation forsøgte at nå. Du kan se
> en del af din afsendte pakke i datadelen af icmp pakken. Ved at
> analysere den del, kan du m.a.o. få en meget bedre ide om hvad
> der er årsagen til denne helt normale kontrolpakke.
>
> Misbrug er der ikke tale om.
>
> /Bjørn Kristensen

Mig bekendt afsender man normalt ikke pakker med TTL værdier
på mindre end 30, i dette tilfælde kom svaret fra en maskine,
der tilsyneladende kun er 15 hops væk. Desuden burde man kun
se disse svar, hvis man rent faktisk har sendt pakken. Det
er korrekt, at man er nødt til at kigge på mere end blot
ICMP pakkens afsender. Man skal også kigge på den oprindelige
pakkes header.

--
Kasper Dupont
For sending spam use mailto:razor-report@daimi.au.dk

---

"Kasper Dupont" <kasperd@daimi.au.dk> wrote in message
news:3C5B9D48.4DE7D38C@daimi.au.dk...

> Mig bekendt afsender man normalt ikke pakker med TTL værdier
> på mindre end 30, i dette tilfælde kom svaret fra en maskine,
> der tilsyneladende kun er 15 hops væk. Desuden burde man kun

Der kan være forskellige "loop" fænomener, som gør at TTL
tælles ned flere gange af den samme router.
( ip pakken routes, og kommer tilbage til samme router )

/Bent

---

"Bjørn Kristensen" <uanvendelig@c.dk> skrev i en meddelelse
news:3c5b89d9$0$224$edfadb0f@dspool01.news.tele.dk...

> en del af din afsendte pakke i datadelen af icmp pakken. Ved at
> analysere den del, kan du m.a.o. få en meget bedre ide om hvad
> der er årsagen til denne helt normale kontrolpakke.

Her er en lynvejledning i at dekode en ip pakke:

Der opsamles fra en maskine på 10.0.16.77
v.h.a. tcp dump, hvor man sørger for at
sætte interface i promiscuous mode. Det
er for at kunne se trafik fra andre enheder
på det lokale netværk.
-x vis hex data
-s 200 vis indtil 200 bytes
-n ingen decode af ip til navne
-p promiscuous
-i eth0 opsamling på interface eth0

For at lave noget trafik der kunne ligne problemet
er der valgt en tracert:
( En tracert fra en normal PC består af et antal ping,
hvor TTL er sat til 1, 2, 3 o.s.v. )

Fra 10.0.16.3 udføres tracert mod 10.1.1.1,
og en router med ip adressen 195.249.0.77 svarer med
en ICMP type 11

På en linux med ip adressen 10.0.16.77 udføres:
tcpdump not -x -s 200 -p -n -i eth0

Outputtet fra tcpdump herunder er lettere modificeret,
med byte numre.

20:58:08.423482 P 195.249.0.77 > 10.0.16.3: icmp:
time exceeded in-transit [tos 0xc0]
byte 0-15 45c0 0038 4f43 0000 fe01 8e78 c3f9 004d
byte 16-31 0a00 1003 0b00 52c4 0000 0000 4500 005c
byte 32-47 0405 0000 0101 9098 0a00 1003 0a01 0101
byte 48- 0800 3b3b 0100 5e00

byte 09: protocol = 01 ; ICMP
byte 20: hex 0b = type 11
Datadelen indeholder noget af den originale pakke:
byte 37: org. type = 01 ; ICMP
byte 40: org. source 10.0.16.3 ( hex 0a001003 )
byte 44: org. dest 10.1.1.1 ( hex 0a010101 )

Hvis org type = 6 ( tcp ) eller 17 ( UDP ) kan det
være nyttigt at dekode porte

byte 48 49 org. Source port
byte 50 51 org. Destination port

God fornøjelse
/Bjørn

---

In article <3c5ef384$0$227$edfadb0f@dspool01.news.tele.dk>, "Bjørn
Kristensen" <uanvendelig@c.dk> wrote:

> "Bjørn Kristensen" <uanvendelig@c.dk> skrev i en meddelelse
> news:3c5b89d9$0$224$edfadb0f@dspool01.news.tele.dk...
>
>> en del af din afsendte pakke i datadelen af icmp pakken. Ved at
>> analysere den del, kan du m.a.o. få en meget bedre ide om hvad der er
>> årsagen til denne helt normale kontrolpakke.
>
> Her er en lynvejledning i at dekode en ip pakke:
>
[SNIP]

Tak .. det vil jeg prøve .. da jeg stadig ikke kan finde nogen forklaring
på det .. den eneste ændring er at mønsteret har ændret sig til hvert 20
min

/Kim

---

In article <a3nvof$p83$1@sunsite.dk>, "Kim Nielsen"
<knielsenSPAMFREE@proventum.net> wrote:
>>
>> Her er en lynvejledning i at dekode en ip pakke:
>>

Den gav lidt .. tcpdump -x -s 200 -p -n -i eth0 host 195.215.106.189
viser:

08:00:03.943549 195.215.106.189 > 10.0.0.2: icmp: time exceeded in-transit
          4500 0038 0000 0000 f901 892e c3d7 6abd
          0a00 0002 0b00 45b8 0000 0000 4500 004a
          be49 4000 0111 1f84 0a00 0002 c3c0 ce13
          8000 0035 0036 2edc

byte 40: 0a00 0002 = 10.0.0.2 port 1280
byte 44: c3c0 ce13 = 195.192.206.19 port 53

og jeg har nu fundet problemet .. jeg takker __mange__ gange

/Kim

---

"Kim Nielsen" <knielsenSPAMFREE@proventum.net> wrote in message
news:a3o2pj$5b6$1@sunsite.dk...

> og jeg har nu fundet problemet .. jeg takker __mange__ gange

Ahem - selvom det muligvis er pinligt, kan du så ikke hjælpe os andre til at
undgå samme problem ved at fortælle om det? :)


--
Mvh. Mogens
Bach.scient. i datalogi. Søger IT-job på Fyn!
www.momech.dk

---

In article <a3of8n$2rsj$1@news.cybercity.dk>, "Mogens Meier Christensen"
<mmc@nospam.dk> wrote:

> Ahem - selvom det muligvis er pinligt, kan du så ikke hjælpe os andre
> til at undgå samme problem ved at fortælle om det? :)

Jo meget gerne:

efter at have dumpet pakken i hex som Bjørn forslog fik jeg :

(tcpdump -x -s 200 -p -n -i eth0 host 195.215.106.189)

08:00:03.943549 195.215.106.189 > 10.0.0.2: icmp: time exceeded in-transit
          4500 0038 0000 0000 f901 892e c3d7 6abd
          0a00 0002 0b00 45b8 0000 0000 4500 004a
          be49 4000 0111 1f84 0a00 0002 c3c0 ce13
          8000 0035 0036 2edc

byte 40: 0a00 0002 = 10.0.0.2
byte 44: c3c0 ce13 = 195.192.206.19 port 53

derefter begyndte jeg at sniffe efter den nye ip addresse som er en
forespørgsel på noget dns men dekodningen af pakken viste at den var en
forespørgsel. Den kom fra min interne dns som prøvede at få fat i en
maskine der ikke længere kører root dns eller er nede.

/Kim