---

Hej!

Undskyld jeg spørger lidt om ping:

Jeg prøver at pinge nogle navne-adresser og nogle Ip-adresser?

Hvorfor kan man pinge nogle IP-adresser og ikke andre?
Eksempelvis kan jeg pinge dmi.dk / 81.19.238.5
Desuden kan jeg pinge dr.dk / 129.142.20.35

men jeg kan ikke pinge jubii.dk og dsb.dk.

Er det et problem hos mig - eller er det af sikkerhedsmæssige årsager hos
virksomheden at man lukker af for ping!
Jeg gætter på det sidstnævnte (at virksomhederne lukker af for denne
mulighed), men så kan jeg ikke forstå hvorfor DR giver lov til at man kan
pinge deres web-server!

For at afprøve ping prøver jeg at give en lidt større bufferstørrelse. Jeg
kan sagtens pinge med
1024 bytes - men der er en grænse. Jeg kan f.eks. ikke pinge med 3000 bytes.
Hvorfor ikke? Hvordan opstår denne begrænsning?


Med venlig hilsen
Christian Thorsen

Svar venligst i gruppen og ikke pr. mail

---

Christian Thorsen wrote:
>
> Hej!
>
> Undskyld jeg spørger lidt om ping:
>
> Jeg prøver at pinge nogle navne-adresser og nogle Ip-adresser?
>
> Hvorfor kan man pinge nogle IP-adresser og ikke andre?
> Eksempelvis kan jeg pinge dmi.dk / 81.19.238.5
> Desuden kan jeg pinge dr.dk / 129.142.20.35
>
> men jeg kan ikke pinge jubii.dk og dsb.dk.
>
> Er det et problem hos mig - eller er det af sikkerhedsmæssige årsager hos
> virksomheden at man lukker af for ping!

Nogle personer tror, det hjælper på sikkerheden at sætte en firewall
op, der lukker for alle echo request. Men i praksis gør det blot
fejlfinding mere besværligt.

> Jeg gætter på det sidstnævnte (at virksomhederne lukker af for denne
> mulighed), men så kan jeg ikke forstå hvorfor DR giver lov til at man kan
> pinge deres web-server!

De har nok indset, at det ikke tjener noget formål at lukke.

>
> For at afprøve ping prøver jeg at give en lidt større bufferstørrelse. Jeg
> kan sagtens pinge med
> 1024 bytes - men der er en grænse. Jeg kan f.eks. ikke pinge med 3000 bytes.
> Hvorfor ikke? Hvordan opstår denne begrænsning?

Jeg kan uden problemer anvende buffer helt op på 4000 bytes.
Men der kan være stedder, hvor der lukkes for fragmenterede
icmp pakker. Det kan også være, at du anvender software, der
sætter don't fragment flaget.

>
> Med venlig hilsen
> Christian Thorsen
>
> Svar venligst i gruppen og ikke pr. mail

Det burde ikke være nødvendigt, at sige det.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

> Nogle personer tror, det hjælper på sikkerheden at sætte en firewall
> op, der lukker for alle echo request. Men i praksis gør det blot
> fejlfinding mere besværligt.

Prøver disse perosner at lukke for Ping of Death eller noget andet?
Eller hvorfor vil de lukke for alle echo request ???

> Jeg kan uden problemer anvende buffer helt op på 4000 bytes.
> Men der kan være stedder, hvor der lukkes for fragmenterede
> icmp pakker. Det kan også være, at du anvender software, der
> sætter don't fragment flaget.

Jeg burger et stykke software som hedder Winodws .......
Ifølge deres hjælp, er det kun hvis der sættes et paramter -f i
ping-kommandoen!
Så jeg går ud fra som default at den godt må defragmentere!
Tror du begrænsningen er i Windows implementering af ping - eller ?

Du har en grænse på 4000 - hvorfor er din grænse på 4000. Hvorfor kan du
ikke pinge med 10000 ????


--
Med venlig hilsen
Christian Thorsen

(Svar venligst i gruppen og ikke pr. mail)



Jeg er stadig n

---

Christian Thorsen wrote:
>
> > Nogle personer tror, det hjælper på sikkerheden at sætte en firewall
> > op, der lukker for alle echo request. Men i praksis gør det blot
> > fejlfinding mere besværligt.
>
> Prøver disse perosner at lukke for Ping of Death eller noget andet?

Muligvis, men så ville jeg da hellere nøjes med at lukke for
fragmenterede ICMP pakker. Man kan altid sende 512 bytes
uden pakken bliver fragmenteret. (Jeg er ikke 100% sikker på
grænsen, men jeg tror det er 512 bytes + headers.)

> Eller hvorfor vil de lukke for alle echo request ???

Jeg kan ikke komme på nogen god grund.

>
> Jeg burger et stykke software som hedder Winodws .......

Jeg har aldrig hørt om det.

>
> Du har en grænse på 4000 - hvorfor er din grænse på 4000. Hvorfor kan du
> ikke pinge med 10000 ????

Jeg prøvede ikke mere end 4000, grænsen ligger i nærheden af
32KB. Hvorfor det er 32 og ikke 64 kan jeg ikke gennemskue.
Men nu lykkedes det mig lige at give mit kabelmodem et ping
of death, så jeg gider ikke prøve mere.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

>> Eller hvorfor vil de lukke for alle echo request ???

>Jeg kan ikke komme på nogen god grund.

Simple access-lister: tillad http-trafik og den nødvendige (dvs.
nødvendige for at webserveren kan køre optimalt) ICMP-trafik.
Afvis al anden trafik. Det er klart den sikreste fremgangsmåde.
Nok er der næppe nogen systemer, der stadig er overfølsom over
for Ping of Death, men hvorfor frivilligt udsætte sine systemer
for en evt. Ping of Death II?

Det er jo nu engang webservere. Vil man vide, om webserveren
fungerer eller om der er hul til den, kan man bruge en browser.
Er der ikke hul, er traceroute vejen frem. Ping kan ikke bruges
til noget som helst i den sammenhæng.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> Er der ikke hul, er traceroute vejen frem.

Ja, og traceroute kan enten bruge UDP pakker eller
ICMP echo request pakker. Jeg har endnu ikke set
et sted, hvor traceroute med UDP pakker virkede
mens traceroute med echo request ikke virkede.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

>> Er der ikke hul, er traceroute vejen frem.

>Ja, og traceroute kan enten bruge UDP pakker eller
>ICMP echo request pakker. Jeg har endnu ikke set
>et sted, hvor traceroute med UDP pakker virkede
>mens traceroute med echo request ikke virkede.

Hvis du kommer så langt som til firmaets gateway, behøver du
jo ikke vide mere: så er det enten webserveren eller hele
firmaets netværk, der er gået ned. Hvilken af de to, der er
problemet, er ret underordnet.

Mvh.
   Klaus.

---

In article <almupa$auj$1@katie.ellegaard.dk>, Klaus Ellegaard wrote:
>
>>Ja, og traceroute kan enten bruge UDP pakker eller
>>ICMP echo request pakker. Jeg har endnu ikke set
>>et sted, hvor traceroute med UDP pakker virkede
>>mens traceroute med echo request ikke virkede.
>
> Hvis du kommer så langt som til firmaets gateway, behøver du
> jo ikke vide mere: så er det enten webserveren eller hele
> firmaets netværk, der er gået ned. Hvilken af de to, der er
> problemet, er ret underordnet.

Behøver jeg minde dig om en dag, hvor jeg måtte ringe til UUnet og
forklare dem hvor de havde en statisk route for meget? ;)

--
Andreas Plesner Jacobsen | You will gain money by an immoral action.

---

Kasper Dupont <kasperd@daimi.au.dk> wrote:
> Jeg prøvede ikke mere end 4000, grænsen ligger i nærheden af
> 32KB. Hvorfor det er 32 og ikke 64 kan jeg ikke gennemskue.

E:\>ping -n 1 -l 65500 217.157.2.33
Pinging 217.157.2.33 with 65500 bytes of data:
Reply from 217.157.2.33: bytes=65500 time=120ms TTL=64

Godt cisco har fået fixet CBOS, ellers var min c577 væltet.
http://www.google.com/search?q=CSCds23921

--
Knud,
der blev vildt berømt på CSCds23921
"The vulnerability CSCds23921 was discovered by a customer"

---

Kasper Dupont <kasperd@daimi.au.dk> wrote

> Christian Thorsen wrote:
>
>> Eller hvorfor vil de lukke for alle echo request ???
>
> Jeg kan ikke komme på nogen god grund.

Der er to måder at håndtere IP-filtre på: 1) at lukke for det der
er farligt 2) kun at åbne for det der er absolut påkrævet for at en
tjeneste kan virke.

Efterhånden som vores software bliver mere og mere kompleks, bliver
både trusler og risici sværere og sværere at overskue. Det kan
være endog meget svært at svare på hvad "der er farligt". Derfor
bliver model 2 attraktiv. Hvis du har en webserver, så åbner du
for tcp/80, og kun det. Du begrænser sårbarheden så meget du kan.

Det gælder faktisk ikke kun for forewalls mod omverdenen. Det
bliver mere og mere udbredt at køre filtre i ip-stakken på servere
og arbejdsstationer. IPchains til Linux er et eksempel. En
arbejdsstation med sådan et filter svarer kun på nettet, hvis det
vil nedsætte maskinens anvendelighed hvis den ikke gør det, og den
svarer kun IP-numre der på forhånd vides at have behov for at
forbinde sig.

Når man filtrere ICMP echo væk, så er det ikke fordi man beskytter
sig mod noget bestemt. Det er fordi, man ikke syn's det giver
mening at kende alt det, man skal beskytte sig imod. I stedet er
spørgsmål "er det essentielt for min webservers funktion at den kan
pinges udefra". Hvis svaret er nej (og det er det nok), så ryger
ICMP echo pakker ud. Det gør der iøvrigt osse hvis de kommer fra
nabo-maskinen på LANet, når nu vi alligevel er igang.

/Lars

---

In article <Xns9285EF8D4FE2fischersukdk@130.227.3.84>, Lars Fischer wrote:
>
> Efterhånden som vores software bliver mere og mere kompleks, bliver
> både trusler og risici sværere og sværere at overskue. Det kan
> være endog meget svært at svare på hvad "der er farligt". Derfor
> bliver model 2 attraktiv. Hvis du har en webserver, så åbner du
> for tcp/80, og kun det. Du begrænser sårbarheden så meget du kan.

Det burde være almindelig etikette over for andre sysadmer/netadmer at
man har åbent for ICMP echo og replies, da det giver dem en bedre
mulighed for at analysere evt problemer.

--
Andreas Plesner Jacobsen | baz bat bamus batis bant.
| -- James Troup

---

Andreas Plesner Jacobsen <apj@daarligstil.dk> wrote

> Det burde være almindelig etikette over for andre
> sysadmer/netadmer at man har åbent for ICMP echo og replies, da
> det giver dem en bedre mulighed for at analysere evt problemer.

Gør det? Jeg kan ikke lige komme i tanke om, hvad det skulle være for
nogen problemer jeg kan analysere ved at pinge, skal vi sige,
www.dr.dk.

Jeg er enig i at ping kan være meget nyttigt - på mit eget net. Skal
jeg ud af mit eget net er traceroute svaret. Og der er jeg faktisk
ligeglad med, om jeg kommer ind til www.dr.dk - bare jeg kommer hen
til deres hoveddør.

Det eneste sted ping kan være nyttigt eksternt er til måling af af
latency - og det er endda ganske usikkert. Og igen - der har jeg
typisk ikke brug for at komme ind på det fjerne net, kun tæt på.
Traceroute er svaret.

/Lars

---

In article <Xns928694038D37fischersukdk@130.227.3.84>, Lars Fischer wrote:
>
> Traceroute er svaret.

Windows traceroute bruger ICMP echo ;)

--
Andreas Plesner Jacobsen | I just asked myself... what would John DeLorean do?
|    -- Raoul Duke

---

Andreas Plesner Jacobsen wrote:
>
> In article <Xns928694038D37fischersukdk@130.227.3.84>, Lars Fischer wrote:
> >
> > Traceroute er svaret.
>
> Windows traceroute bruger ICMP echo ;)

Ja, og på Linux er det en option. Og jeg bruger den altid,
da der er endnu flere stedder, hvor der er lukket for UDP.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

> > Windows traceroute bruger ICMP echo ;)
>
> Ja, og på Linux er det en option. Og jeg bruger den altid,
> da der er endnu flere stedder, hvor der er lukket for UDP.

Hm... det forsåtr jeg faktisk ikke rigtigt!
Hvad bruger en Linux-box hvis denne option ikke er valgt?
Og hvorfor bruge ICMP echo hvor der er lukket for UDP ?

Med venlig hilsen
Christian Thorsen

(Svar venligst i gruppen og ikke pr. mail)

---

Christian Thorsen wrote:
>
> > > Windows traceroute bruger ICMP echo ;)
> >
> > Ja, og på Linux er det en option. Og jeg bruger den altid,
> > da der er endnu flere stedder, hvor der er lukket for UDP.
>
> Hm... det forsåtr jeg faktisk ikke rigtigt!
> Hvad bruger en Linux-box hvis denne option ikke er valgt?

UDP pakker startende med destination port 33435 og lægger
en til portnummeret hver gang.

> Og hvorfor bruge ICMP echo hvor der er lukket for UDP ?

Fordi det virker. Og fordi det er en uskik at sende pakker
til tilfældige UDP porte og håbe på, at de er lukkede.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

> Windows traceroute bruger ICMP echo ;)

Bruges der ikke ICMP echo hvis jeg bruger traceroute fra en Linux-box
og/eller en Cisco-routers CLI (IOS) ???
Hvis nej: Hva' bruger traceroute fra disse 2 så?


--
Med venlig hilsen
Christian Thorsen

(Svar venligst i gruppen og ikke pr. mail)

---

On Wed, 11 Sep 2002 10:58:52 +0200, "Christian Thorsen"
<send.svar.her.i.gruppen@hotmail.com> wrote:

> Bruges der ikke ICMP echo hvis jeg bruger traceroute fra en Linux-box
> og/eller en Cisco-routers CLI (IOS) ???

Nej.

> Hvis nej: Hva' bruger traceroute fra disse 2 så?

UDP.

-A
--
http://www.hojmark.org/

---

> bliver model 2 attraktiv. Hvis du har en webserver, så åbner du
> for tcp/80, og kun det. Du begrænser sårbarheden så meget du kan.

Hvis man nu gerne vil pinge? Hvilken port skal man så åbne for?

Kører ICMP på en bestemt port?

Med venlig hilsen
Christian Thorsen

(Svar venligst i gruppen og ikke pr. mail)

---

Christian Thorsen wrote:
>
> > bliver model 2 attraktiv. Hvis du har en webserver, så åbner du
> > for tcp/80, og kun det. Du begrænser sårbarheden så meget du kan.
>
> Hvis man nu gerne vil pinge? Hvilken port skal man så åbne for?
>
> Kører ICMP på en bestemt port?

Nej, der er ikke portnumre i ICMP protokollen.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

On Wed, 11 Sep 2002 10:55:38 +0200, "Christian Thorsen"
<send.svar.her.i.gruppen@hotmail.com> wrote:

> Hvis man nu gerne vil pinge? Hvilken port skal man så åbne for?

IP-protokol 1.

> Kører ICMP på en bestemt port?

Den kører ikke på nogen.

-A
--
http://www.hojmark.org/

---

Men hvis man kun lukker for fragmenterede ICMP-pakker, gvider det så ikke
hackeren mulighed for at lave ne Ping of Death.

Jeg mener en hacker kan vel bare sætte "pinge-riet" igang med en masse små
pakker a 32 bytes, der til gengæld kommer fra mange forskellige IP-adresser
på samme tid (og altså en masse pakker samtidig)!

Er det så ikke bedre at man bare slukker helt muligheden for at pinge...?
Du må meget gerne forklare lidt... så bli'r jeg glad!

> > Jeg burger et stykke software som hedder Winodws .......
>
> Jeg har aldrig hørt om det.

Joken faldt lidt til jorden pga. min tavefejl hva'?
Men hvis du ikke kneder WINDOWS kan jeg da fortælle at det er ej
tredjepartsprogram jeg bruger! Det er egentlig meget smart og et nogenlunde
alternativ til Linux............



Med venlig hilsen
Christian Thorsen

(Svar venligst i gruppen og ikke pr. mail)

---

Christian Thorsen wrote:
>
> Men hvis man kun lukker for fragmenterede ICMP-pakker, gvider det så ikke
> hackeren mulighed for at lave ne Ping of Death.

Så vidt jeg erindrer er problemet netop, at man ved at fragmentere
på en bestemt måde kan sende for store pakker. Hvis man lukker for
fragmenterede pakker vil du slet ikke kunne sende pakker større
end MTU.

En pakke har en øvre grænse på ca. 64KB. Men hvis det sidste
fragment har et startoffset lige under grænsen og en størrelse på
1-1.5KB vil den samlede pakke fylde 65KB. Det kan gøre til et
bufferoverløb.

>
> Jeg mener en hacker kan vel bare sætte "pinge-riet" igang med en masse små
> pakker a 32 bytes, der til gengæld kommer fra mange forskellige IP-adresser
> på samme tid (og altså en masse pakker samtidig)!

Det har ikke noget med PoD at gøre, det er flooding. Du undgår
ikke flooding ved at lukke for pakkerne. Når pakkerne når til din
firewall har de allerede brugt din downstream kapacitet. Du kan
selvfølgelig begrænse raten på svarene, så du ikke bruger hele din
upstream ved at besvare dem alle. Den optimale løsning vil være
en prioritering af pakker på upstreamen. Du kan f.eks. give icmp
reply pakkerne den lavest mulige prioritet på upstreamen. Jeg har
dog ikke selv sat mig ind i, hvordan man sætter den slags op.

>
> Er det så ikke bedre at man bare slukker helt muligheden for at pinge...?

Nej, jeg mener stadig at alle bør have lukket op for ping. Det gør
fejlfinding nemmere. Jeg vil mene, at nogle begrænsninger i en
firewall vil være rimeligt:

* Luk for fragmenterede ping requests/replies.
* Sæt TTL til en fast værdi på alle indkommende pakker. F.eks. 15.
* Tillad kun indgående ping requests, hvis du ville tillade andre
pakker med samme source og destination IP. Hvis blot en eneste
mulig pakke ville blive lukket igennem bør ping også tillades.
* Giv echo replies lavest mulig prioritet på udgående pakker.

Desuden bør firewallen sende icmp port unreachable eller tcp
reset i stedet for bare at droppe pakker til en given port. Man
kan igen vælge at lægge nogle af de samme begrænsninger på, som
jeg foreslog til icmp echo.

> Du må meget gerne forklare lidt... så bli'r jeg glad!
>
> > > Jeg burger et stykke software som hedder Winodws .......
> >
> > Jeg har aldrig hørt om det.
>
> Joken faldt lidt til jorden pga. min tavefejl hva'?

Det havde jeg slet ikke set. Selvfølgelig har jeg hørt om det,
jeg er bare træt af folk, der går ud fra, at jeg kender det.

Jeg ved nok ca. lige så meget om Windows, som du ved om Linux.

> Det er egentlig meget smart og et nogenlunde
> alternativ til Linux............

Hvor kan jeg downloade sourcen?

>
>

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

>Nej, jeg mener stadig at alle bør have lukket op for ping. Det gør
>fejlfinding nemmere.

For hvem?

De fleste større installationer sidder bag content switche eller
lignende. Her er ping ind til selve applikationsserverne ligemeget
(content switchen vil fortælle dig, om applikationen er i live, og
resten er sådan set ligemeget).

Ping til content switchen kan man ikke bruge til noget - den er en
netenhed som alt andet, og hvis ping virker, betyder det ikke,
at applikationen virker. Det giver lige så meget mening at pinge en
Ethernet-switch hos en transit-ISP for at se, om deres ATM-udstyr
virker.

>* Tillad kun indgående ping requests, hvis du ville tillade andre
> pakker med samme source og destination IP. Hvis blot en eneste
> mulig pakke ville blive lukket igennem bør ping også tillades.

Hvorfor bevidst gøre dig selv udsat for Ping of Death II - eller
noget tilsvarende? For mig at se svarer det til at tilbyde chargen
og daytime... irrelevante services, der potentielt set kan bruges
til at hærge én med. Måske ikke lige nu men så engang i fremtiden.

>Desuden bør firewallen sende icmp port unreachable eller tcp
>reset i stedet for bare at droppe pakker til en given port.

Heller ikke enig. En webserver er en webserver. Hvis nogen snakker
andet end port 80 med en webserver, har de enten ondt i sinde eller
er for dumme til at bruge nettet. Hvorfor spilde strøm på dem?

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> >Nej, jeg mener stadig at alle bør have lukket op for ping. Det gør
> >fejlfinding nemmere.
>
> For hvem?

For alle, der undersøger netværksproblemer.

>
> De fleste større installationer sidder bag content switche eller
> lignende. Her er ping ind til selve applikationsserverne ligemeget
> (content switchen vil fortælle dig, om applikationen er i live, og
> resten er sådan set ligemeget).
>
> Ping til content switchen kan man ikke bruge til noget - den er en
> netenhed som alt andet, og hvis ping virker, betyder det ikke,
> at applikationen virker. Det giver lige så meget mening at pinge en
> Ethernet-switch hos en transit-ISP for at se, om deres ATM-udstyr
> virker.

Jeg aner ikke hvad en content switch er, men hvis det
er den sidste enhed, der kører med en normal IP stak
er det også denne enhed, der bør besvare icmp echo.

>
> >* Tillad kun indgående ping requests, hvis du ville tillade andre
> > pakker med samme source og destination IP. Hvis blot en eneste
> > mulig pakke ville blive lukket igennem bør ping også tillades.
>
> Hvorfor bevidst gøre dig selv udsat for Ping of Death II - eller
> noget tilsvarende? For mig at se svarer det til at tilbyde chargen
> og daytime... irrelevante services, der potentielt set kan bruges
> til at hærge én med. Måske ikke lige nu men så engang i fremtiden.

Jeg gør mig ikke bevidst sårbar over for nogen angreb,
det ville jo faktisk forudsætte, at der var et kendt
hul. Jeg siger bare, det er dumt at lukke for features,
der er essentielle for fejlfinding, og som mig bekendt
er et krav i en eller anden RFC.

>
> >Desuden bør firewallen sende icmp port unreachable eller tcp
> >reset i stedet for bare at droppe pakker til en given port.
>
> Heller ikke enig. En webserver er en webserver. Hvis nogen snakker
> andet end port 80 med en webserver, har de enten ondt i sinde eller
> er for dumme til at bruge nettet.

Sikke da noget sludder, folk kan da godt komme til at
begå en fejl. Det behøver jo ikke betyde, at man har
ondt i sinde.

> Hvorfor spilde strøm på dem?

Den kommentar er da helt til grin. Hvis du dropper
pakkerne vil der blot komme en sekvens af timeouts og
retransmisioner, det tjener intet formål. Det er da
meget mere fornuftigt bare at få det overstået med det
samme ved at sende det korrekte svar.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

>> >Nej, jeg mener stadig at alle bør have lukket op for ping. Det gør
>> >fejlfinding nemmere.
>>
>> For hvem?

>For alle, der undersøger netværksproblemer.

Det forstår jeg stadig ikke. Hvis du ikke kan pinge www.firma.dk,
kan du så umiddelbart deraf konstatere præcist, hvor problemet er?

Hvis du derimod bruger traceroute i stedet, får du ofte at vide,
hvor problemet ligger. ping kan ikke bruges til noget som helst.

Hvis man kunne pinge TCP port 80, ja. Men som udgangspunkt kan du
ikke pinge ret mange større installationers webservere (heller ikke
selvom de svarer, for det vil ikke være webserveren, der svarer).

>Jeg aner ikke hvad en content switch er, men hvis det
>er den sidste enhed, der kører med en normal IP stak
>er det også denne enhed, der bør besvare icmp echo.

Content switche er lag 4+ switche. De sidder foran applikations-
servere og modtager requests (http, ftp, dns, you name it) fra
nettet. Så beslutter switchen hvilken applikationsserver, der
skal svare, og sender requesten videre til denne server.

Hvis alle applikationsserverne er nede, vil du stadig kunne pinge
content switchen (hvis den tillader det). Det siger bare intet
om problemet, så ping til content switche vil bare forvirre mere
end det hjælper.

Applikationsserverne bag content switchen vil oftest køre på
RFC1918-adresser, så dem kan du ikke pinge.

>Jeg gør mig ikke bevidst sårbar over for nogen angreb,
>det ville jo faktisk forudsætte, at der var et kendt
>hul. Jeg siger bare, det er dumt at lukke for features,
>der er essentielle for fejlfinding, og som mig bekendt
>er et krav i en eller anden RFC.

Mit argument er, at ping er totalt ubrugelig til fejlfinding.
Medmindre man er administrator af maskinen og derfor ved, hvad
det er, man pinger, og hvordan man kan give sig selv lov til
det.

At det evt. er et krav, er ikke noget godt argument for at
lave unødvendige sikkerhedshuller.

>> Heller ikke enig. En webserver er en webserver. Hvis nogen snakker
>> andet end port 80 med en webserver, har de enten ondt i sinde eller
>> er for dumme til at bruge nettet.

>Sikke da noget sludder, folk kan da godt komme til at
>begå en fejl. Det behøver jo ikke betyde, at man har
>ondt i sinde.

"Hvis nogen snakker med andet". Ikke "Hvis nogen kommer til at".

>> Hvorfor spilde strøm på dem?

>Den kommentar er da helt til grin. Hvis du dropper
>pakkerne vil der blot komme en sekvens af timeouts og
>retransmisioner, det tjener intet formål. Det er da
>meget mere fornuftigt bare at få det overstået med det
>samme ved at sende det korrekte svar.

Det hjælper folk, der portscanner, ustyrligt meget at afvise deres
pakker. Det ser jeg ingen grund til.

Strømspildet var et forsøg på at være morsom.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> >> >Nej, jeg mener stadig at alle bør have lukket op for ping. Det gør
> >> >fejlfinding nemmere.
> >>
> >> For hvem?
>
> >For alle, der undersøger netværksproblemer.
>
> Det forstår jeg stadig ikke. Hvis du ikke kan pinge www.firma.dk,
> kan du så umiddelbart deraf konstatere præcist, hvor problemet er?

Nej, men det kan give mig et fingerpeg.

>
> Hvis du derimod bruger traceroute i stedet, får du ofte at vide,
> hvor problemet ligger. ping kan ikke bruges til noget som helst.

Ja, et traceroute program kan fortælle meget mere. Men det
ændrer sådan set intet på mit argument. Mange af disse
traceroute programmer bruger jo netop icmp echo request.
På Unix og lignende systemer bruges som regel UDP pakker
som default. Men der er altså færre, der ønsker at åbne
for 100 UDP porte end icmp echo.

>
> Hvis man kunne pinge TCP port 80, ja.

Men det kan man jo ikke, da ICMP og TCP er to forskellige
protokoller, og ICMP har ikke portnumre. Jeg har tit
ønsket mig en traceroute, der kunne sende TCP SYN pakker.
(Man skulle naturligvis passe på at ikke lave en SYN
flood.) Eller evt. en traceroute, hvor man kunne tage en
vilkårlig pakke fra sin upstream og bruge den som testpakke.

> Men som udgangspunkt kan du
> ikke pinge ret mange større installationers webservere (heller ikke
> selvom de svarer, for det vil ikke være webserveren, der svarer).
>
> >Jeg aner ikke hvad en content switch er, men hvis det
> >er den sidste enhed, der kører med en normal IP stak
> >er det også denne enhed, der bør besvare icmp echo.
>
> Content switche er lag 4+ switche. De sidder foran applikations-
> servere og modtager requests (http, ftp, dns, you name it) fra
> nettet. Så beslutter switchen hvilken applikationsserver, der
> skal svare, og sender requesten videre til denne server.
>
> Hvis alle applikationsserverne er nede, vil du stadig kunne pinge
> content switchen (hvis den tillader det). Det siger bare intet
> om problemet, så ping til content switche vil bare forvirre mere
> end det hjælper.
>
> Applikationsserverne bag content switchen vil oftest køre på
> RFC1918-adresser, så dem kan du ikke pinge.

Er det ikke stort set det samme som en ganske almindelig
port forwarding? Jeg mener I dette tilfælde, at content
switchen bør besvare icmp echo request. At et svar er
ensbetydende med, at serveren er i live, er i mine øjne
ikke noget problem. Det er sådan set ikke forskelligt fra
hvad jeg er vant til. Jeg ser da tit computere, der er
gået ned, men stadig svarer på icmp echo request. Hvis
blot jeg kan konstatere, om content switchen svarer, så
ved jeg sådan set alt, jeg har behov for at vide.

>
> >Jeg gør mig ikke bevidst sårbar over for nogen angreb,
> >det ville jo faktisk forudsætte, at der var et kendt
> >hul. Jeg siger bare, det er dumt at lukke for features,
> >der er essentielle for fejlfinding, og som mig bekendt
> >er et krav i en eller anden RFC.
>
> Mit argument er, at ping er totalt ubrugelig til fejlfinding.
> Medmindre man er administrator af maskinen og derfor ved, hvad
> det er, man pinger, og hvordan man kan give sig selv lov til
> det.

Jeg bruger da tit traceroute til at finde ud af, hvor på
nettet et problem kan ligge.

>
> At det evt. er et krav, er ikke noget godt argument for at
> lave unødvendige sikkerhedshuller.

Kan du dokumentere, at det er et sikkerhedshul? Hvis du
blot begrænser det til ufragmenerede echo requests, tror
jeg ikke på, at der er et problem.

>
> >> Heller ikke enig. En webserver er en webserver. Hvis nogen snakker
> >> andet end port 80 med en webserver, har de enten ondt i sinde eller
> >> er for dumme til at bruge nettet.
>
> >Sikke da noget sludder, folk kan da godt komme til at
> >begå en fejl. Det behøver jo ikke betyde, at man har
> >ondt i sinde.
>
> "Hvis nogen snakker med andet". Ikke "Hvis nogen kommer til at".

Jeg siger bare, at man skal have at vide, at der ikke
er noget at komme efter.

>
> >> Hvorfor spilde strøm på dem?
>
> >Den kommentar er da helt til grin. Hvis du dropper
> >pakkerne vil der blot komme en sekvens af timeouts og
> >retransmisioner, det tjener intet formål. Det er da
> >meget mere fornuftigt bare at få det overstået med det
> >samme ved at sende det korrekte svar.
>
> Det hjælper folk, der portscanner, ustyrligt meget at afvise deres
> pakker. Det ser jeg ingen grund til.

Du kan da bare sætte en begrænsning på raten. Hvis du
maksimalt besvarer en uønsket pakke per sekund vil et
portscan ikke give noget brugbart resultat.

>
> Strømspildet var et forsøg på at være morsom.
>
> Mvh.
> Klaus.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

>> Det forstår jeg stadig ikke. Hvis du ikke kan pinge www.firma.dk,
>> kan du så umiddelbart deraf konstatere præcist, hvor problemet er?

>Nej, men det kan give mig et fingerpeg.

Men - som skrevet ovenfor - et fingerpeg der langt fra altid er
præcist. I de fleste større tilfælde er det et lige så godt
fingerpeg at tælle antallet af nullermænd under musen.

>Ja, et traceroute program kan fortælle meget mere. Men det
>ændrer sådan set intet på mit argument. Mange af disse
>traceroute programmer bruger jo netop icmp echo request.
>På Unix og lignende systemer bruges som regel UDP pakker
>som default. Men der er altså færre, der ønsker at åbne
>for 100 UDP porte end icmp echo.

Det behøver de jo heller ikke. Du vil få svar fra alle routere
undervejs, og så snart du har ramt firmaets eget netværk, har
du egentlig ikke behov for at vide mere. At den sidste maskine
måske smider pakken væk, gør ingenting. Du kan igen ikke være
sikker på, at den sidste maskine overhovedet er en computer -
det kan også være en switch.

>Men det kan man jo ikke, da ICMP og TCP er to forskellige
>protokoller, og ICMP har ikke portnumre. Jeg har tit
>ønsket mig en traceroute, der kunne sende TCP SYN pakker.

Det spilder unødige ressourcer hos værterne undervejs. Eller
rettere, på den maskine du prøver at kontakte.

>gået ned, men stadig svarer på icmp echo request. Hvis
>blot jeg kan konstatere, om content switchen svarer, så
>ved jeg sådan set alt, jeg har behov for at vide.

Jaeh, så ved du, at du ikke aner, hvad eller hvor problemet
er - eller om der overhovedet er et problem

>> Mit argument er, at ping er totalt ubrugelig til fejlfinding.
>> Medmindre man er administrator af maskinen og derfor ved, hvad
>> det er, man pinger, og hvordan man kan give sig selv lov til
>> det.

>Jeg bruger da tit traceroute til at finde ud af, hvor på
>nettet et problem kan ligge.

Præcis - traceroute er en god ting. Ping er nærmest ligegyldig
og ofte vildledende selv hvis du får et svar.

>> At det evt. er et krav, er ikke noget godt argument for at
>> lave unødvendige sikkerhedshuller.

>Kan du dokumentere, at det er et sikkerhedshul? Hvis du
>blot begrænser det til ufragmenerede echo requests, tror
>jeg ikke på, at der er et problem.

Jeg vil hellere vende den om: medmindre du kan dokumentere,
at ingen platforme har (og heller aldrig vil få) problemer
med ufragmenterede echo requests, er de et potentielt hul.

>> Det hjælper folk, der portscanner, ustyrligt meget at afvise deres
>> pakker. Det ser jeg ingen grund til.

>Du kan da bare sætte en begrænsning på raten. Hvis du
>maksimalt besvarer en uønsket pakke per sekund vil et
>portscan ikke give noget brugbart resultat.

Det giver endnu mere komplekse systemer, hvilket igen giver
en større sikkerhedsrisiko.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> >> Det forstår jeg stadig ikke. Hvis du ikke kan pinge www.firma.dk,
> >> kan du så umiddelbart deraf konstatere præcist, hvor problemet er?
>
> >Nej, men det kan give mig et fingerpeg.
>
> Men - som skrevet ovenfor - et fingerpeg der langt fra altid er
> præcist. I de fleste større tilfælde er det et lige så godt
> fingerpeg at tælle antallet af nullermænd under musen.

Sludder, ping kan give et utroligt godt billede af hvor stabil
netforbindelsen er. Hvis jeg har problemer med at komme i
kontakt med en webserver er det første jeg gør, at prøve med
ping for at se om problemet ligger på netforbindelsen. Hvis jeg
meget gerne vil i kontakt med serveren kunne jeg godt finde på,
at lade et script pinge serveren indtil der kommer hul igennem
og så give mig besked.

>
> >Ja, et traceroute program kan fortælle meget mere. Men det
> >ændrer sådan set intet på mit argument. Mange af disse
> >traceroute programmer bruger jo netop icmp echo request.
> >På Unix og lignende systemer bruges som regel UDP pakker
> >som default. Men der er altså færre, der ønsker at åbne
> >for 100 UDP porte end icmp echo.
>
> Det behøver de jo heller ikke. Du vil få svar fra alle routere
> undervejs, og så snart du har ramt firmaets eget netværk, har
> du egentlig ikke behov for at vide mere.

Jeg når jo netop ikke firmaets netværk, når den første maskine
indenfor firmaet blot unlader at svare. Jeg kan i dette tilfælde
ikke se, om problemet ligger indenfor eller udenfor virksomheden.
Jeg kan faktisk ikke engang se, hvor langt jeg er fra firmaets
netværk, medmindre jeg på forhånd kender ruten.

> At den sidste maskine
> måske smider pakken væk, gør ingenting. Du kan igen ikke være
> sikker på, at den sidste maskine overhovedet er en computer -
> det kan også være en switch.

Jeg er lige glad med hvad det er, bare jeg kan se, at jeg faktisk
er nået indenfor huset. Hvis den ikke svarer kan jeg jo ikke se,
om problemet ligger indenfor eller udenfor.

>
> >Men det kan man jo ikke, da ICMP og TCP er to forskellige
> >protokoller, og ICMP har ikke portnumre. Jeg har tit
> >ønsket mig en traceroute, der kunne sende TCP SYN pakker.
>
> Det spilder unødige ressourcer hos værterne undervejs.

Det gør da absolut ingen forskel for routerne undervejs, om jeg
bruger TCP SYN eller ICMP ECHO REQUEST. Medmindre routerne
insisterer på at lave overflødig analyse af pakkerne.

> Eller
> rettere, på den maskine du prøver at kontakte.

En SYN pakke udgør jo ikke større belastning end en normal request
til serveren. Hvis jeg endeligt modtager en acknowledge af min TCP
SYN pakke skal jeg naturligvis stoppe og så afbryde forbindelsen
med en passende pakke. (Jeg ved ikke lige, om man bør bruge en
reset eller en fin pakke til det.)

>
> >gået ned, men stadig svarer på icmp echo request. Hvis
> >blot jeg kan konstatere, om content switchen svarer, så
> >ved jeg sådan set alt, jeg har behov for at vide.
>
> Jaeh, så ved du, at du ikke aner, hvad eller hvor problemet
> er - eller om der overhovedet er et problem

Når jeg går i gang med at lede er det fordi, der er et problem.
Det er noget sludder at sige, at jeg ikke ved om der er et problem.
Hvis jeg vil i kontakt med en server, og den ikke svarer, er der
et problem. Og hvis serveren svarer på en ICMP ECHO REQUEST ved
jeg, at fejlen ikke er en manglende netværksforbindelse mellem mig
og serveren.

>
> >> Mit argument er, at ping er totalt ubrugelig til fejlfinding.
> >> Medmindre man er administrator af maskinen og derfor ved, hvad
> >> det er, man pinger, og hvordan man kan give sig selv lov til
> >> det.
>
> >Jeg bruger da tit traceroute til at finde ud af, hvor på
> >nettet et problem kan ligge.
>
> Præcis - traceroute er en god ting. Ping er nærmest ligegyldig
> og ofte vildledende selv hvis du får et svar.

Hvorfor vil du så lukke for traceroute?

>
> >> At det evt. er et krav, er ikke noget godt argument for at
> >> lave unødvendige sikkerhedshuller.
>
> >Kan du dokumentere, at det er et sikkerhedshul? Hvis du
> >blot begrænser det til ufragmenerede echo requests, tror
> >jeg ikke på, at der er et problem.
>
> Jeg vil hellere vende den om: medmindre du kan dokumentere,
> at ingen platforme har (og heller aldrig vil få) problemer
> med ufragmenterede echo requests, er de et potentielt hul.

Du vil altså heller have et system du ved ikke virker
end et hvor du har stort set 100% sikkerhed for at der
ikke er noget hul?

>
> >> Det hjælper folk, der portscanner, ustyrligt meget at afvise deres
> >> pakker. Det ser jeg ingen grund til.
>
> >Du kan da bare sætte en begrænsning på raten. Hvis du
> >maksimalt besvarer en uønsket pakke per sekund vil et
> >portscan ikke give noget brugbart resultat.
>
> Det giver endnu mere komplekse systemer, hvilket igen giver
> en større sikkerhedsrisiko.

Jeg har svært ved at få øje på nogen potentiel risiko ved
at begrænse raten på nogle svar. Og du har formodentlig
allerede brug for en del QoS.

Og en målrettet portscanning kan da også gennemføres uden
at få svar tilbage. Jeg kan under alle omstændigheder
sende SYN pakker til alle porte, og hvis du overtræder
standarden ved at kun sende svar for åbne porte, betyder
det blot, at jeg har færre svar at behandle.

Og hvis du faktisk mener, at du har brug for at forhindre
portscan har du allerede et problem.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

>Sludder, ping kan give et utroligt godt billede af hvor stabil
>netforbindelsen er. Hvis jeg har problemer med at komme i
>kontakt med en webserver er det første jeg gør, at prøve med
>ping for at se om problemet ligger på netforbindelsen. Hvis jeg
>meget gerne vil i kontakt med serveren kunne jeg godt finde på,
>at lade et script pinge serveren indtil der kommer hul igennem
>og så give mig besked.

Det er en fin plan, men det er ikke nogen grund til at bede
alle om at tillade ICMP echo. Basalt set er det jo ikke en
tjeneste, webserver-ejeren har behov for at tilbyde, og det
er ikke en tjeneste, man kan forvente (udover af historiske
årsager).

>> Det behøver de jo heller ikke. Du vil få svar fra alle routere
>> undervejs, og så snart du har ramt firmaets eget netværk, har
>> du egentlig ikke behov for at vide mere.

>Jeg når jo netop ikke firmaets netværk, når den første maskine
>indenfor firmaet blot unlader at svare.

Det er jo så spørgsmålet, om den gør det. Border-routeren vil
sikkert nok snakke med dig, men alt andet vil nok lade være.
I DR-tilfældet ender en traceroute på pos1-0.dr.apl.uni2.net.
Det er da rigeligt information til at vide, at forbindelsen
til DR i hvert fald ikke fejler noget. Hvis noget bagved ikke
virker, er det altså i DRs netværk eller DRs webserver, der
er nede.

>> Det spilder unødige ressourcer hos værterne undervejs.

>Det gør da absolut ingen forskel for routerne undervejs, om jeg
>bruger TCP SYN eller ICMP ECHO REQUEST. Medmindre routerne
>insisterer på at lave overflødig analyse af pakkerne.

Prioriteringen i routeren er garanteret forskellig. ICMP er som
regel den laveste.

>Når jeg går i gang med at lede er det fordi, der er et problem.
>Det er noget sludder at sige, at jeg ikke ved om der er et problem.
>Hvis jeg vil i kontakt med en server, og den ikke svarer, er der
>et problem. Og hvis serveren svarer på en ICMP ECHO REQUEST ved
>jeg, at fejlen ikke er en manglende netværksforbindelse mellem mig
>og serveren.

Eller rettere: du ved, at du kan nå en content switch, der som
sådan godt kan sidde adskillige hop (og i ekstreme tilfælde mange
tusind kilometer) fra webserveren. Med andre ord: du ved ikke ret
meget mere, end du ville få ud af tracerouten til firmaets første
router.

>> Præcis - traceroute er en god ting. Ping er nærmest ligegyldig
>> og ofte vildledende selv hvis du får et svar.

>Hvorfor vil du så lukke for traceroute?

Det vil jeg også først i det sidste hop.

>> Det giver endnu mere komplekse systemer, hvilket igen giver
>> en større sikkerhedsrisiko.

>Jeg har svært ved at få øje på nogen potentiel risiko ved
>at begrænse raten på nogle svar. Og du har formodentlig
>allerede brug for en del QoS.

Vi er enige om, at enhver ekstra linje kode/konfiguration giver
en større risiko for (sikkerheds)fejl?

Og nej, QoS er faktisk ikke særligt meget anvendt i praksis...
endnu. Ikke når vi snakker almindelige webtjenester i hvert
fald.

>Og hvis du faktisk mener, at du har brug for at forhindre
>portscan har du allerede et problem.

Mit system er simplere => mindre sandsynlighed for fejl. At
det så også har den (utiltænkte) bieffekt, at det kan irritere
nogle portscannere, er da bare endnu bedre.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> >Sludder, ping kan give et utroligt godt billede af hvor stabil
> >netforbindelsen er. Hvis jeg har problemer med at komme i
> >kontakt med en webserver er det første jeg gør, at prøve med
> >ping for at se om problemet ligger på netforbindelsen. Hvis jeg
> >meget gerne vil i kontakt med serveren kunne jeg godt finde på,
> >at lade et script pinge serveren indtil der kommer hul igennem
> >og så give mig besked.
>
> Det er en fin plan, men det er ikke nogen grund til at bede
> alle om at tillade ICMP echo. Basalt set er det jo ikke en
> tjeneste, webserver-ejeren har behov for at tilbyde, og det
> er ikke en tjeneste, man kan forvente (udover af historiske
> årsager).

Her er et par citater jeg kunne finde i RFC 792:

I indledningen står der:
ICMP is actually an integral part of IP, and
must be implemented by every IP module.

I afsnitet om echo står der:
The data received in the echo message must be
returned in the echo reply message.

Jeg kan ikke finde det sted, hvor der står, at det
er en valgfri feature.

>
> >> Det behøver de jo heller ikke. Du vil få svar fra alle routere
> >> undervejs, og så snart du har ramt firmaets eget netværk, har
> >> du egentlig ikke behov for at vide mere.
>
> >Jeg når jo netop ikke firmaets netværk, når den første maskine
> >indenfor firmaet blot unlader at svare.
>
> Det er jo så spørgsmålet, om den gør det. Border-routeren vil
> sikkert nok snakke med dig, men alt andet vil nok lade være.
> I DR-tilfældet ender en traceroute på pos1-0.dr.apl.uni2.net.

Det kommer faktisk an på, hvad du tracer med. Hvis du bruger
ICMP echo slutter et trace af dr.dk på www.dr.dk.

> Det er da rigeligt information til at vide, at forbindelsen
> til DR i hvert fald ikke fejler noget.

Ja, men vil det samme være tilfældet alle andre stedder?

> Hvis noget bagved ikke
> virker, er det altså i DRs netværk eller DRs webserver, der
> er nede.

Ja, ja, hvis jeg når langt nok til at jeg kan se, at jeg
når ind på DRs netværk kan jeg i princippet være ligeglad
med resten. Men er det nu også helt tydligt, at
pos1-0.dr.apl.uni2.net er inde på DRs netværk? Jeg synes
ikke det er særlig tydligt, jeg kan faktisk godt være i
tvivl.

>
> >> Det spilder unødige ressourcer hos værterne undervejs.
>
> >Det gør da absolut ingen forskel for routerne undervejs, om jeg
> >bruger TCP SYN eller ICMP ECHO REQUEST. Medmindre routerne
> >insisterer på at lave overflødig analyse af pakkerne.
>
> Prioriteringen i routeren er garanteret forskellig. ICMP er som
> regel den laveste.

Fint, hvorfor vil du så tvinge folk til at bruge noget
andet end ICMP til fejlfinding?

>
> >Når jeg går i gang med at lede er det fordi, der er et problem.
> >Det er noget sludder at sige, at jeg ikke ved om der er et problem.
> >Hvis jeg vil i kontakt med en server, og den ikke svarer, er der
> >et problem. Og hvis serveren svarer på en ICMP ECHO REQUEST ved
> >jeg, at fejlen ikke er en manglende netværksforbindelse mellem mig
> >og serveren.
>
> Eller rettere: du ved, at du kan nå en content switch, der som
> sådan godt kan sidde adskillige hop (og i ekstreme tilfælde mange
> tusind kilometer) fra webserveren. Med andre ord: du ved ikke ret
> meget mere, end du ville få ud af tracerouten til firmaets første
> router.

I mine øjne er context switchen den maskine, jeg taler med.
At den er afhængig af andre maskiner i et netværk bagved
kan jeg ikke forholde mig til. Jeg kan heller ikke forholde
mig til, om en webserver, der ikke svarer, er gået ned,
eller om det skyldes en bagvedliggende filserver,
databaseserver eller måske noget helt tredje.

>
> >> Præcis - traceroute er en god ting. Ping er nærmest ligegyldig
> >> og ofte vildledende selv hvis du får et svar.
>
> >Hvorfor vil du så lukke for traceroute?
>
> Det vil jeg også først i det sidste hop.

Og dermed får du det til at se ud som om sidste hop, eller
linket dertil er gået ned. Og det eneste man så har at
forholde sig til er næstsidste hop. Det hjælper ikke på
fejlfinding, at give et falskt billede af netværket.

>
> >> Det giver endnu mere komplekse systemer, hvilket igen giver
> >> en større sikkerhedsrisiko.
>
> >Jeg har svært ved at få øje på nogen potentiel risiko ved
> >at begrænse raten på nogle svar. Og du har formodentlig
> >allerede brug for en del QoS.
>
> Vi er enige om, at enhver ekstra linje kode/konfiguration giver
> en større risiko for (sikkerheds)fejl?

Ja, hvis du insiterer på at der ikke må ofres flere
resourcer på kvalitetssikring.

>
> Og nej, QoS er faktisk ikke særligt meget anvendt i praksis...
> endnu. Ikke når vi snakker almindelige webtjenester i hvert
> fald.

Jeg har ikke sat mig ind i hvordan man sætter QoS op, men
jeg kan da se mange situationer, hvor det ville være en
fordel.

>
> >Og hvis du faktisk mener, at du har brug for at forhindre
> >portscan har du allerede et problem.
>
> Mit system er simplere => mindre sandsynlighed for fejl. At
> det så også har den (utiltænkte) bieffekt, at det kan irritere
> nogle portscannere, er da bare endnu bedre.

Jeg er fuldstændig ligeglad med portscannere. Dine fejl
i opsætningen kan være til gene for legitime brugere,
og derfor skal det gøres rigtigt.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

>Klaus Ellegaard wrote:

Skal vi ikke bare sige, at vi har luftet vores forskellige meninger
om det?

Med hensyn til overholdelse af RFC'er, så skal man passe lidt på
med at følge dem for slavisk. Eksempelvis er der ikke én eneste
news-server i verden (well, næsten så), der følger RFC'erne for
dem. Det ville simpelthen ikke virke i praksis.

Så hvis man skal hive compliance frem, vil jeg mene, at man skal
være konsekvent: så skal man overholde samtlige RFC-standarder
og aldrig nogensinde træde et komma ved siden af. Uanset hvad det
betyder for resten af nettet, for sikkerheden eller for en selv.

Gør man ikke det, er compliance et ret dårligt argument, for så
er det jo kun dem, man selv "lige finder smarte", man kræver
overholdt.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> >Klaus Ellegaard wrote:
>
> Skal vi ikke bare sige, at vi har luftet vores forskellige meninger
> om det?
>
> Med hensyn til overholdelse af RFC'er, så skal man passe lidt på
> med at følge dem for slavisk. Eksempelvis er der ikke én eneste
> news-server i verden (well, næsten så), der følger RFC'erne for
> dem. Det ville simpelthen ikke virke i praksis.
>
> Så hvis man skal hive compliance frem, vil jeg mene, at man skal
> være konsekvent: så skal man overholde samtlige RFC-standarder
> og aldrig nogensinde træde et komma ved siden af. Uanset hvad det
> betyder for resten af nettet, for sikkerheden eller for en selv.
>
> Gør man ikke det, er compliance et ret dårligt argument, for så
> er det jo kun dem, man selv "lige finder smarte", man kræver
> overholdt.

Nu står der jo intet sted, at man skal implementere samtlige
protokoller. Men hvis man implementerer dem bør det gøres
rigtigt.

Der findes da givetvis detaljer i nogle RFC'er, som er direkte
tåbelige. Det kunne f.eks. være umuligt at implementere, eller
ville uundgåeligt føre til sikkerhedsproblemer. Men det er
altså ikke tilfældet med ICMP ECHO.

Disse fejl i RFC'erne bliver da normalt også rettet i senere
udgaver. Den eneste jeg lige kan komme i tanke om, er ikke et
decidret sikkerhedshul. RFC-850 satte en øvre grænse på, hvor
lang en tråd i en nyhedsgruppe kunne være, det blev rettet i
RFC-1036.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

> Men der kan være stedder, hvor der lukkes for fragmenterede
> icmp pakker. Det kan også være, at du anvender software, der
> sætter don't fragment flaget.

Jamen hvor er grænsen for, hvornår en ICMP-pakke bliver fragmenteret?
Hvor mange bytes kan en ICMP-pakke indeholde ?


--
Med venlig hilsen
Christian Thorsen

(Svar venligst i gruppen og ikke pr. mail)

---

Den Tue, 10 Sep 2002 14:43:56 +0200 skrev Christian Thorsen:
>> Men der kan være stedder, hvor der lukkes for fragmenterede
>> icmp pakker. Det kan også være, at du anvender software, der
>> sætter don't fragment flaget.
>
>Jamen hvor er grænsen for, hvornår en ICMP-pakke bliver fragmenteret?

Det afhænger af MTU'en på det netværks-segment med den laveste MTU.
(Maximum Transfer Unit).

Mvh
Kent
--
Mails skrevet før 12:00 skal læses med det forbehold, at hjernen først
forventes at være færdig med at boote på det tidspunkt, og indholdet
derfor kan indeholde random data der tilfældigvis lå i den
uinitializerede cache.

---

> Det afhænger af MTU'en på det netværks-segment med den laveste MTU.
> (Maximum Transfer Unit).

Tak for det!
Hvordan checker jeg MTU i en Cisco-router med IOS ?
Hvordan sætter jeg MTU i en Cisco-router med IOS ?

Der er en ting jeg ikke rigtig forstår:
Når vi snakker om MTU - er det så det maximale antal bytes som en pakke på
layer 2 eller på layer 4 kan indeholde ???


Med venlig hilsen
Christian Thorsen

(Svar venligst i gruppen og ikke pr. mail)

---

Christian Thorsen wrote:
>
> > Det afhænger af MTU'en på det netværks-segment med den laveste MTU.
> > (Maximum Transfer Unit).
>
> Tak for det!
> Hvordan checker jeg MTU i en Cisco-router med IOS ?
> Hvordan sætter jeg MTU i en Cisco-router med IOS ?

Nu er MTU ikke noget routeren selv bestemer. Det er defineret
af de protokoller, den bruger på sine netværksforbindelser.
Hvis routeren forbinder netværk af forskellig type, kan der
sagtens være forskellig MTU på de forskellige netværk. På
ethernet er MTU altid 1500 bytes. Så vidt jeg erindrer er MTU
på ppp som default 1500 bytes, men kan sættes til andre
størrelser. Der er sjældent noget formål med en MTU på mere
end 1500 bytes, da jeg tror de fleste pakker før eller siden
kommer over et net med en MTU på 1500 bytes.

>
> Der er en ting jeg ikke rigtig forstår:
> Når vi snakker om MTU - er det så det maximale antal bytes som en pakke på
> layer 2 eller på layer 4 kan indeholde ???

Kan du ikke omtale lagene ved navn i stedet, så ved jeg
nemlig hvad du snakker om. Når jeg snakker om en MTU på 1500
bytes er de ethernet payloaden. Det vil sige at oveni lægges
ethernet header og trailer, som giver en samlet størrelse på
lidt mere. Når vi kigger på IP pakker vil de første af de
1500 bytes blive brugt på en IP header og de næste bytes
blive brugt på ICMP/UDP/TCP header. Så vidt jeg erindrer har
IP og TCP 20 bytes header hver, så du kan sende 1460 bytes
payload per TCP pakke.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

Christian Thorsen wrote:
>
> > Men der kan være stedder, hvor der lukkes for fragmenterede
> > icmp pakker. Det kan også være, at du anvender software, der
> > sætter don't fragment flaget.
>
> Jamen hvor er grænsen for, hvornår en ICMP-pakke bliver fragmenteret?

Det afhænger af nettet, grænsen er 1500 bytes på ethernet.
Heraf går lidt til headers. (40 bytes så vidt jeg husker.)
Hvis pakken bevæger sig over mange netværk af forskellig
type, kan den blive fragmenteret flere gange og dermed få
mange fragmenter af varierende størelse. Der er et
minimumskrav om, hvor store fragmenter alle netværk skal
kunne håndtere. Grænsen er så vidt jeg husker 512 bytes.

Det er mere effektivt at undgå fragmentering. I en TCP
implementation er det f.eks. en god idé, at finde grænsen
og altid gå lige til grænsen og så lade sliding window
protokollen tage sig af resten.

> Hvor mange bytes kan en ICMP-pakke indeholde ?

Jeg kan ikke huske den eksakte grænse, men det er ca. 64KB.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

> Det er mere effektivt at undgå fragmentering. I en TCP
> implementation er det f.eks. en god idé, at finde grænsen
> og altid gå lige til grænsen og så lade sliding window
> protokollen tage sig af resten.

Hm... jeg er virkelig blevet forvirret?

Fragmenteret... jamen hvis data er meget store, hvordan så undgå at pakke
bliver fragmenteret ?

Hvordan undgå fragmentering?
Ved at sætte MTU eller hva' ?

Som jeg spørger andetsteds i denne tråd - hvor foregår fragmentering - på
linkalget (L2) eller på tranportlaget (L4) ?

Tak for mange gode indlkæg i denne tråd!

Med venlig hilsen
Christian Thorsen

(Svar venligst i gruppen og ikke pr. mail)

---

Christian Thorsen wrote:
>
> > Det er mere effektivt at undgå fragmentering. I en TCP
> > implementation er det f.eks. en god idé, at finde grænsen
> > og altid gå lige til grænsen og så lade sliding window
> > protokollen tage sig af resten.
>
> Hm... jeg er virkelig blevet forvirret?
>
> Fragmenteret... jamen hvis data er meget store, hvordan så undgå at pakke
> bliver fragmenteret ?

Ja, og TCP er designet til at sende store datamængder over IP.
De datamængder, der skal kunne sendes over en TCP forbindelse
er så store, at fragmentering ikke alene løser det. Med
fragmentering kan du sende pakker på op til 64KB, men med TCP
vil man gerne sende mange MB. Og fragmentering har den
ulempe, at hvis du mister et enkelt fragment skal samtlige
fragmenter retransmiteres.

>
> Hvordan undgå fragmentering?
> Ved at sætte MTU eller hva' ?

Nej, man kan ikke sætte MTU. (OK, på nogle net kan man måske,
men det er ikke en fornuftig løsning.) TCP bruger en sliding
window protokol. Modtageren sender bekræftelser om, hvilke
pakker der er modtaget, og afsenderen behøves således kun at
retransmitere de tabte pakker. Modtageren bestemmer, hvor
hurtigt afsenderen må sende. Fra start af har afsenderen lov
til at sende en pakke, efterhånden som kommunikationen
skrider frem skrues hastigheden op, indtil man når nettets
kapacitet.

>
> Som jeg spørger andetsteds i denne tråd - hvor foregår fragmentering - på
> linkalget (L2) eller på tranportlaget (L4) ?

Fragmentering foregår på IP laget. En IP pakke indeles i
flere fragmenter, der sendes som enkelte pakker over
netværkslaget. På TCP laget, der er bygget lige ovenpå IP
laget foregår også en opdeling af data i pakker, men der er
her tale om en sliding window protokol. Det er bedst at
nøjes med opdeling på det ene lag, så TCP bør sende pakker
med en størelse, så de undgår yderlige fragmentering.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

---

Michal Wodzinski wrote:
>
> On Tue, 10 Sep 2002, Kasper Dupont wrote:
>
> > Heraf går lidt til headers. (40 bytes så vidt jeg husker.)
>
> <--->
> the default is 56, which translates into 64 ICMP data bytes when
> combined with the 8 bytes of ICMP header data.
> <--->

Det er kun ICMP headeren, hertil skal så lægges IP headeren.

Jeg slog lige størrelserne op i "Data & Computer Communications":

IPv4 header: 20 bytes
TCP header: 20 bytes
UDP header: 8 bytes
ICMP header: 8 bytes

IPv6 header: 40 bytes

Der stod ikke noget om, hvor store extension headers er i IPv6,
men det er vist ca. det samme som IPv4.

De 40 bytes jeg nævnte var altså forkert, det er kun 28 bytes til
en ICMP pakke. Det er TCP pakkerne, der har 40 bytes header fordelt
på IP og TCP header.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

---

---

---

Michal Wodzinski <michal@null.dk> writes:

>f.eks.

>default input drop
>accept port 80 input

>eller ville det være i orden at gøre den statefull og sige

Det er et godt spørgsmål, og man kan ikke svare på det generelt.
Det er hér, det enkelte steds sikkerhedspolitik kommer lidt ind
i billedet. Men fælles for begge eksempler er, at de holder sig
til det relevante: web-delen.

Dog skal du nok sørge for også at tillade visse ICMP-pakker, men
jeg ser ingen grund til at tillade echo.

Mvh.
   Klaus.

---

---

Michal Wodzinski <michal@null.dk> writes:

>chain input
>icmp_allowed icmp
[osv]

Umiddelbart ser det fornuftigt ud - også med hensyn til ICMP
typer. Jeg skal dog lige skynde mig at sige, at jeg ikke kender
det format, du kører med. Så om det syntaktisk er rigtigt, ved
jeg ikke.

Mvh.
   Klaus.

---

---

Michal Wodzinski wrote:
>
> On Thu, 12 Sep 2002, Kasper Dupont wrote:
>
> >
> > Jeg slog lige størrelserne op i "Data & Computer Communications":
>
> Hmm er det d´er en god bog?

Den bliver brugt i undervisningen på universitetet:
http://www.daimi.au.dk/dDist/litteratur.html

Jeg synes ikke, den er fantastisk god. Men da jeg
ikke har læst andre bøger om emnet, kan jeg ikke
sammenligne.

Der er lidt for meget sniksnak i bogen, og den er
slem til at gentage sig selv. Men hvis man ellers
kan finde ud af at springe over de redundante
afsnit er resten faktisk OK.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk