---

Hej.

Jeg har spekuleret på en ting:

Skal der lukkes for ICMP ind gennem en firewall?

Nogle siger at det forhindrer nogle angreb.
Andre siger, at det ikke fjerner nogle angreb

Hvad skal man tro?

Grunden til at jeg spørger er:
Hvis det alligevel ikke fjerner nogle angreb er det jo synd at fjerne et
nyttigt værktøj som muligheden for at pinge!

---

> Skal der lukkes for ICMP ind gennem en firewall?

Nej, og mig bekendt er det ikke muligt at lukke ICMP hvis du vil have glæde
af internettet......men er ikke helt sikker !!!

Hilsen Anders

---

A.I. wrote:

> Nej, og mig bekendt er det ikke muligt at lukke ICMP hvis du vil have glæde
> af internettet......men er ikke helt sikker !!!

Du kan lukke for ICMP, men du skal vente langtid på fx. en connection
refused (REJECT), da en meddelelse som denne bliver sendt via icmp.

Vh. Bo

---

> Du kan lukke for ICMP

...Hvordan???

PS. Vi er gået til vintertid

---

A.I. wrote:

>>Du kan lukke for ICMP
>
>
> ..Hvordan???

Med en firewall

Jeg vil nødigt udtale mig, da jeg ikke benytter Windows, hvilket jeg
forudsætter du/I gør.

/Bo

---

Kan man i en FW lukke for PING - men have åben for alt andet ICMP-traffik!

Og endnu engang er mit spm: Er det smart?
Hvilke fordele / uelemper har det ?

---

"[2600] Benny Sorensen" <beny_sorensen@hotmail.com> skrev

> Kan man i en FW lukke for PING - men have åben for alt andet ICMP-traffik!
>
> Og endnu engang er mit spm: Er det smart?
> Hvilke fordele / uelemper har det ?

Hvis du har ICMP forwarding enablet på din FW, kan du udsættes, for angreb,
der er relaterede til ICMP protokollen.

Disse er bl.a.: Denial of service, Spoofing , Ping flood, OS
fingerprinting, Ping Sweeps, Enumeration m.m.

Læs evt. denne glimrende artikel fra SANS:

http://rr.sans.org/threats/ICMP_attacks.php

Kig også på den her, omhandler egentlig IRC, men gode artikler om Nuke
attacks, firewalls, Kevin Mitnick, hacking generelt...

http://www.irchelp.org/irchelp/security

Hvis virkelig skal gå i dybden så download pdf reporten fra dem her:

http://www.sys-security.com/html/projects/icmp.html

Hvis du ikke tillader ICMP at passere din firewall, mister du muligheden for
at få fejlmeddelelser fra hosts og routere på nettet, og din time-out på et
givent connection attempt vil blive så meget større. Altså ikke så smart.

ICMP protokollen er originalt tænkt som et fejlfindingsværktøj, surt at
nogen fandt på at bruge den til suspekte formål, men sådan er livet jo!

Istedet for bare blindt at lukke for alle services på et system, mener jeg
det er bedre at forstå de vigtige services, vurdere riscici og så monitorere
disse services.

Så sæt et IDS system op ex. Snort:

http://www.snort.org/

Windows port her:

http://www.datanerds.net/~mike/snort.html


Håber det besvarede nogle af dine spørgsmål.

--
"Intelligence is the ability to avoid doing work, yet getting the work done"
Linus Torvalds

---

Den Sat, 30 Nov 2002 11:08:27 +0100 skrev MikeU:
>"[2600] Benny Sorensen" <beny_sorensen@hotmail.com> skrev
>
>> Kan man i en FW lukke for PING - men have åben for alt andet ICMP-traffik!
>>
>> Og endnu engang er mit spm: Er det smart?
>> Hvilke fordele / uelemper har det ?
>
>Hvis du har ICMP forwarding enablet på din FW, kan du udsættes, for angreb,
>der er relaterede til ICMP protokollen.
>
>Disse er bl.a.: Denial of service, Spoofing , Ping flood, OS
>fingerprinting, Ping Sweeps, Enumeration m.m.

Denial of Service: Har ikke noget med ICMP at gøre, DoS imod en web-
server gøres fx på TCP port 80.

Spoofing: Kan gøres på mange måder, de fleste involverer ikke ICMP.

Ping flood: fylde linien op med trafik. Selvom firewall'en smider
pakkerne væk, når de er ankommet, er linien stadig fyld med trafik.
At blokere ICMP virker altså ikke. Derudover kan et tilsvarende angreb
laves på alle andre protokoller, incl IP.

OS fingerprinting: Benytter sig SVJV primært af forskelle i TCP, det
bliver højst lidt mere usikkert af at lukke for ICMP. Iøvrigt er OS
fingerprinting ikke et angreb.

Ping sweeps: Ikke et angreb.

Enumeration: Den betegnelse har jeg ikke hørt før i denne sammenhæng,
hvad dækker det over? Det plejer at blive brugt i sammenhængen:
enum color { red, green, blue };

Mvh
Kent
--
Linux 0.12 is out
Windows XP is now obsolete!!!

---

Kent Friis <leeloo@phreaker.net> wrote:
> Enumeration: Den betegnelse har jeg ikke hørt før i denne sammenhæng,
> hvad dækker det over?

Enumeration (optaelling, kortlaegning) af netvaerk og maskiner er noget
man goer foer et indbrud. Man indsamler saa mange oplysninger man kan,
OS, navne og versioner af services, kortlaegger host dependencies og
evt. trust relationships, stier og filenavne, osv.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

---

"Kent Friis" <leeloo@phreaker.net> skrev

> >"[2600] Benny Sorensen" <beny_sorensen@hotmail.com> skrev
> >
> >> Kan man i en FW lukke for PING - men have åben for alt andet
ICMP-traffik!
> >>
> >> Og endnu engang er mit spm: Er det smart?
> >> Hvilke fordele / uelemper har det ?
> >
> >Hvis du har ICMP forwarding enablet på din FW, kan du udsættes, for
angreb,
> >der er relaterede til ICMP protokollen.
> >
> >Disse er bl.a.: Denial of service, Spoofing , Ping flood, OS
> >fingerprinting, Ping Sweeps, Enumeration m.m.
>
> Denial of Service: Har ikke noget med ICMP at gøre, DoS imod en web-
> server gøres fx på TCP port 80.

Og dog. Du snakker selv om en Linux box, kig evt. her:

http://www.iss.net/security_center/static/5975.php

>
> Spoofing: Kan gøres på mange måder, de fleste involverer ikke ICMP.

Og dog: ARP og ICMP eredirects eksisterer da, kig evt. her:

http://www.insecure.org/sploits/arp.games.html

>
> Ping flood: fylde linien op med trafik. Selvom firewall'en smider
> pakkerne væk, når de er ankommet, er linien stadig fyld med trafik.
> At blokere ICMP virker altså ikke. Derudover kan et tilsvarende angreb
> laves på alle andre protokoller, incl IP.

IP i sig selv er en connectionless protocol, den bruges kun på OSI level 3,
altså til routing, du kan ikke bare sige at IP protokollen kan bruges til et
angreb, medmindre du taler om angreb på router protokoller. Prøv at kigge på
IP info'en i en sniffer, protokollen har kun simple adresseringsformål.
Når du laver et Ping, sender din TCP/IP stack en ICMP Echo request ud til
den forespurgte host. ICMP er jo bare en del af TCP/IP suiten. Jeg forstår
ikke helt dit svar?!

>
> OS fingerprinting: Benytter sig SVJV primært af forskelle i TCP, det
> bliver højst lidt mere usikkert af at lukke for ICMP. Iøvrigt er OS
> fingerprinting ikke et angreb.

Alle OS'er har hver deres måde at bruge TCP/IP stacken på, og derfor
forskellige karakteristika, i deres kommunikation. BSD kerner er forskellige
fra Linux kerner, der er forskellige fra Windows osv. Derfor kan du basalt
set bruge alle protokoller til at OS fingerprinte med inkl ICMP. kig i mit
forrige svar omkring pdf'en fra Sys-security:

http://www.sys-security.com/html/projects/icmp.html

eller her:

http://www.insecure.org/nmap/nmap-fingerprinting-article.html

>
> Ping sweeps: Ikke et angreb.

Hvis du bruger et Ping tool til at lave netværkstest med nej, men hvis du
bruger det til at lave et hostcheck, med senere planer om scanning/indbrud,
så jo.

>
> Enumeration: Den betegnelse har jeg ikke hørt før i denne sammenhæng,
> hvad dækker det over? Det plejer at blive brugt i sammenhængen:
> enum color { red, green, blue };

Dækker over begrebet at danne et billede over en netværkstopologi, og
services på eksisterende hosts. Ex. en mapning med cheops, SNMP ressourcer
eller scanning for delte fileshares med Legion.

Mvh.

Mike

--
"Intelligence is the ability to avoid doing work, yet getting the work done"
Linus Torvalds

---

Den Sat, 30 Nov 2002 12:10:37 +0100 skrev MikeU:
>"Kent Friis" <leeloo@phreaker.net> skrev
>
>> >"[2600] Benny Sorensen" <beny_sorensen@hotmail.com> skrev
>> >
>> >> Kan man i en FW lukke for PING - men have åben for alt andet
>ICMP-traffik!
>> >>
>> >> Og endnu engang er mit spm: Er det smart?
>> >> Hvilke fordele / uelemper har det ?
>> >
>> >Hvis du har ICMP forwarding enablet på din FW, kan du udsættes, for
>angreb,
>> >der er relaterede til ICMP protokollen.
>> >
>> >Disse er bl.a.: Denial of service, Spoofing , Ping flood, OS
>> >fingerprinting, Ping Sweeps, Enumeration m.m.
>>
>> Denial of Service: Har ikke noget med ICMP at gøre, DoS imod en web-
>> server gøres fx på TCP port 80.
>
>Og dog. Du snakker selv om en Linux box, kig evt. her:
>
>http://www.iss.net/security_center/static/5975.php

Det bliver ikke løst ved at lukke for ICMP. Det vil bare få PMTU
discovery til at holde op med at virke, da man heller ikke længere
modtager reelle "would fragment" pakker. Dette problem kan umiddelbart
kun klares ved at slukke for PMTU discovery.

>> Spoofing: Kan gøres på mange måder, de fleste involverer ikke ICMP.
>
>Og dog: ARP og ICMP eredirects eksisterer da, kig evt. her:
>
>http://www.insecure.org/sploits/arp.games.html

De kan kun bruges sålænge man sidder på samme netværkssegment, så at
spærre igennem en firewall vil være meningsløst, da en firewall
netop sidder imellem segmenterne.

>> Ping flood: fylde linien op med trafik. Selvom firewall'en smider
>> pakkerne væk, når de er ankommet, er linien stadig fyld med trafik.
>> At blokere ICMP virker altså ikke. Derudover kan et tilsvarende angreb
>> laves på alle andre protokoller, incl IP.
>
>IP i sig selv er en connectionless protocol, den bruges kun på OSI level 3,
>altså til routing, du kan ikke bare sige at IP protokollen kan bruges til et
>angreb, medmindre du taler om angreb på router protokoller. Prøv at kigge på
>IP info'en i en sniffer, protokollen har kun simple adresseringsformål.
>Når du laver et Ping, sender din TCP/IP stack en ICMP Echo request ud til
>den forespurgte host. ICMP er jo bare en del af TCP/IP suiten. Jeg forstår
>ikke helt dit svar?!

Flooding går simpelthen ud på at fylde linien op med trafik. Man behøver
ikke mere end IP, for at fylde linien op. Der behøver ikke være noget
reelt indhold i pakkerne.

>> OS fingerprinting: Benytter sig SVJV primært af forskelle i TCP, det
>> bliver højst lidt mere usikkert af at lukke for ICMP. Iøvrigt er OS
>> fingerprinting ikke et angreb.
>
>Alle OS'er har hver deres måde at bruge TCP/IP stacken på, og derfor
>forskellige karakteristika, i deres kommunikation. BSD kerner er forskellige
>fra Linux kerner, der er forskellige fra Windows osv. Derfor kan du basalt
>set bruge alle protokoller til at OS fingerprinte med inkl ICMP. kig i mit
>forrige svar omkring pdf'en fra Sys-security:

Korrekt, og da du kan bruge alle protokoller, hjælper det jo ikke at
lukke for ICMP, hvis man har åbent for TCP/80.

>> Ping sweeps: Ikke et angreb.
>
>Hvis du bruger et Ping tool til at lave netværkstest med nej, men hvis du
>bruger det til at lave et hostcheck, med senere planer om scanning/indbrud,
>så jo.

Nej, selvom det ofte bliver brugt som forberedelse til et angreb,
er det ikke i sig selv et angreb.

Hvis man har sikkerheden i orden, er det faktisk kun en fordel, hvis
folk undersøger ens ydre netværk, inden de sætter et angreb igang. Så
kan de se at der ikke er noget at komme efter, og ret hurtigt opgive
projektet. I stedet for bare at skyde med spredehagl, i håb om at
et eller andet går igennem.

Mvh
Kent
--
The frozen north will hatch a flightless bird,
who will spread his wings and dominate the earth
And cause an empire by the sea to fall
To the astonishment, and delight of all.

---

MikeU wrote:
>
> Når du laver et Ping, sender din TCP/IP stack en ICMP Echo request ud til
> den forespurgte host. ICMP er jo bare en del af TCP/IP suiten. Jeg forstår
> ikke helt dit svar?!

Udtrykket TCP/IP bruges alt for tit. I stedet for at skrive TCP/IP bør
man overevje hvad det egentlig er for en protokol man snakker om og så
skrive det i stedet. I det nævnte eksempel er TCP overhovedet ikke
involveret. ICMP bygger direkte ovenpå IP. UDP og TCP bygger også hver
for sig direkte ovenpå IP, dog med lidt hjælp fra ICMP.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

---

On Sat, 30 Nov 2002 10:10:21 +0100,
[2600] Benny Sorensen <beny_sorensen@hotmail.com> wrote:

> Kan man i en FW lukke for PING - men have åben for alt andet ICMP-traffik!

Ja, det kan man godt.

> Og endnu engang er mit spm: Er det smart?

Nej.

--
Jesper

---

On Sat, 30 Nov 2002 10:10:21 +0100, "[2600] Benny Sorensen"
<beny_sorensen@hotmail.com> wrote:

> Kan man i en FW lukke for PING - men have åben for alt andet
> ICMP-traffik!

Ja.

ICMP er faktisk en række forskellige type af meddelelser, og dem
der benyttes til ping er blot et par af dem.

Ping virker basalt set ved, at maskine A sender en ICMP Echo
Request (aka ICMP Type 8), der besvares af maskine B med en ICMP
Echo Reply (aka ICMP Type 0). Så man kan lukke for ping ved at
lukke for indgående trafik af ICMP Type 8.

> Og endnu engang er mit spm: Er det smart?

Hmm. Det spørgsmål kan ikke rigtig besvares med et ja eller nej.

Der er fordele ved at ping virker (typisk ved fejlsøgning), og
der er ikke *nødvendigvis* nogen ulemper ved at det virker. Men
nogle operativsystemer (især dem fra Redmond) har haft problemer
med sikkerheden ifm. ping, og andre operativsystemer kan risikere
at få det, og det kan være argument for at lukke for det.

Mange vælger at lukke for at trafik, som de ikke med sikkerhed
kan sige, der er en væsentlig grund til at se. Det kan fx betyde,
at man kun lukker op for port 80/tcp ind til en web-server.

Man kan diskutere, hvor stor fordelen er ved at kunne pinge en
web-server, når den vigtigste måde at checke om den virker er ved
at snakke HTTP med den.

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

---

Asbjorn Hojmark wrote:
>
> Man kan diskutere, hvor stor fordelen er ved at kunne pinge en
> web-server, når den vigtigste måde at checke om den virker er ved
> at snakke HTTP med den.

Det er en fordel ved fejlfinding. Hvis ikke man kan komme i kontakt
med serveren kan ping give et fingerpeg om, hvor fejlen ligger. Ved
at lukke for ping betyder det at man kan få et forkert fingerpeg om,
hvor fejlen ligger, og dermed bliver det sværere at få rettet fejlen.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

---

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

>Det er en fordel ved fejlfinding. Hvis ikke man kan komme i kontakt
>med serveren kan ping give et fingerpeg om, hvor fejlen ligger. Ved
>at lukke for ping betyder det at man kan få et forkert fingerpeg om,
>hvor fejlen ligger, og dermed bliver det sværere at få rettet fejlen.

Som administrator af en webserver synes jeg, det er en fordel,
at folk ikke kan fejlfinde mit system. Det vil jeg gerne selv
gøre.

Hvis folk vil fejlfinde deres eget system, kan de traceroute.
Hvis de når min border, er resten mit problem, og så behøver
den enkelte bruger ikke fejlfinde yderligere.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> Hvis folk vil fejlfinde deres eget system, kan de traceroute.
> Hvis de når min border, er resten mit problem, og så behøver
> den enkelte bruger ikke fejlfinde yderligere.

Hvis det er sådan du gerne vil have det, så er det sådan set
helt fint med mig. Så skal du bare sætte din firewall til at
besvare pakker, som du ikke vil lukke ind.

Jeg synes det er helt fint, hvis alle ICMP echo request
besvares allerede i firewallen. Så behøves man ikke lukke
dem ind. Desuden bør man også sende port unreachable tilbage
for alle de UDP pakker man ikke vil lukke ind. På den måde
vil traceroute virke som forventet.

Hvis firewallen derimod smidder pakkerne væk uden at svare,
vil man ikke kunne se, at den er nået, og traceroute vil
blive ved med at sende pakker indtil den får et svar eller
er nået over maxhop, dette er ikke nogen god opsætning.

Hvis man ønsker at undgå en kortlægning af nettet bagved
firewallen, er det nok en god idé at ændre TTL på alle de
pakker, der lukkes ind. Hvis man når det er besluttet at
lukke pakken ind sætter TTL til et tal større end
"dybden på nettet bagved, så vil det ikke kunne kortlægges
udefra.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

---

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

>Jeg synes det er helt fint, hvis alle ICMP echo request
>besvares allerede i firewallen. Så behøves man ikke lukke
>dem ind. Desuden bør man også sende port unreachable tilbage
>for alle de UDP pakker man ikke vil lukke ind. På den måde
>vil traceroute virke som forventet.

Jeg er enig i, at netværkskomponenter skal svare på ICMP. En
firewall (eller applikationen) skal lukke igennem/svare på
det, den er designet til. Hvis det irriterer en tusindedel
af en promille af brugerne, at den ikke svarer på noget som
helst andet, nåja, synd for ham. See if I care.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> Jeg er enig i, at netværkskomponenter skal svare på ICMP. En
> firewall (eller applikationen) skal lukke igennem/svare på
> det, den er designet til. Hvis det irriterer en tusindedel
> af en promille af brugerne, at den ikke svarer på noget som
> helst andet, nåja, synd for ham. See if I care.

Du tager fejl. Du burde nok læse, hvad RFC 792 har at sige
om den sag.

Men det er da efterhånden gået op for mig at du er fuldstændig
ligeglad med hvad andre synes. Så jeg kan jo bare håbe, at du
aldrig bliver administrator af et netværk af betydning.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

---

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

> Klaus Ellegaard wrote:
> >
> > Jeg er enig i, at netværkskomponenter skal svare på ICMP. En
> > firewall (eller applikationen) skal lukke igennem/svare på
> > det, den er designet til. Hvis det irriterer en tusindedel
> > af en promille af brugerne, at den ikke svarer på noget som
> > helst andet, nåja, synd for ham. See if I care.
>
> Du tager fejl. Du burde nok læse, hvad RFC 792 har at sige
> om den sag.

Der er en ny tendens på internettet. Den hedder sikkerhed fremfor
brugervenlighed. Al information der slipper ud af et netværk kan
principelt misbruges, hvorfor mange kompetente netværksadministratorer
lukker for al trafik der ikke eksplicit er tilladt. Herunder
f.eks. ICMP pakker der ikke er direkte nødvendige for brugen af
TCP/UDP/IP.

Hvorfor er du interesseret i at fejlfinde på mit netværk? Hvis der er
noget galt kan du fortælle mig det, så skal jeg nok løse problemet.

--
Thomas Bjorn Andersen - tbaNOSPAM200211@gen-v.net
+++ATH

---

Thomas Bjorn Andersen wrote:
> Der er en ny tendens på internettet. Den hedder sikkerhed fremfor
> brugervenlighed. Al information der slipper ud af et netværk kan
> principelt misbruges, hvorfor mange kompetente netværksadministratorer
> lukker for al trafik der ikke eksplicit er tilladt. Herunder
> f.eks. ICMP pakker der ikke er direkte nødvendige for brugen af
> TCP/UDP/IP.

Selvfølgelig skal du ikke åbne alt ICMP traffik men kun den delmængde du
har brug for.

> Hvorfor er du interesseret i at fejlfinde på mit netværk? Hvis der er
> noget galt kan du fortælle mig det, så skal jeg nok løse problemet.

Hvorfor er du ikke interesseret i hører om fejl med MTU-, TTL-, filtre-,
routnings- problemer.

--
Christian E. Lysel, http://www.spindelnet.dk/

Kunst? http://www.firewallmonkeys.com/songs/

---

"Christian E. Lysel" <news.sunsite.dk@spindelnet.dk> writes:

>> Hvorfor er du interesseret i at fejlfinde på mit netværk? Hvis der er
>> noget galt kan du fortælle mig det, så skal jeg nok løse problemet.

>Hvorfor er du ikke interesseret i hører om fejl med MTU-, TTL-, filtre-,
>routnings- problemer.

Det har man en netværksafdeling med sniffere og andre behagelige
ting til at gå efter (og kolleger rundt om i verden hvis man har
brug for fejlsøgningsassistance fra andre net). Så folk behøver
såmænd bare brokke sig.

Hvordan kan man ellers sikre kvaliteten i fejlsøgning og -retning
i henhold til ISO9002/TQM-instruktionerne? Det kan som absolut
bedste scenarie blive dobbeltarbejde, fordi man selv skal lave
præcis den samme fejlsøgning om igen.

PMTU er i øvrigt næppe et problem i praksis. Filtre er heller
ikke et problem, hvis de er sat rigtigt op. TTL kan da aldrig
være destinationens problem (det opdager du i så fald et hop
før).

Routing foregår langt, langt, langt væk fra applikationerne. Det
tætteste routing-mæssige, man normalt kommer i store miljøer, er
"en" gateway, der kører HSRP. Hvad der sker bag dem, kan du fint
traceroute dig frem til. Det er der jo ikke lukket for.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>>Hvorfor er du ikke interesseret i hører om fejl med MTU-, TTL-, filtre-,
>>routnings- problemer.
>
>
> Det har man en netværksafdeling med sniffere og andre behagelige
> ting til at gå efter (og kolleger rundt om i verden hvis man har
> brug for fejlsøgningsassistance fra andre net). Så folk behøver
> såmænd bare brokke sig.

Du får det til at lyde som fx MTU fejl er statiske.


--
Christian E. Lysel, http://www.spindelnet.dk/

Kunst? http://www.firewallmonkeys.com/songs/

---

"Christian E. Lysel" <news.sunsite.dk@spindelnet.dk> writes:

>> brug for fejlsøgningsassistance fra andre net). Så folk behøver
>> såmænd bare brokke sig.

>Du får det til at lyde som fx MTU fejl er statiske.

I forhold til applikationen er de. I forhold til de nærmeste
netværkskomponenter er de ikke.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>>Du får det til at lyde som fx MTU fejl er statiske.
> I forhold til applikationen er de. I forhold til de nærmeste
> netværkskomponenter er de ikke.

Et setup med mobile brugere, der fx bruger VPN og kører applikationer
over dette kan sagtens give masser af problemer, hvis man ignorer ICMP
beskeder omkring MTU fejl.

I ovennævnte er netværkskomponenterne ej "de nærmeste", hvilket måske
forklarer vores forskellige syn på sagen.

VPN og MTU problemer som jeg ser, løses nemmest ved at tillade
oplysninger om MTU problemer via ICMP. Dette ser jeg ikke som muligt at
fejlsøge manuelt, men lader PMTU om. Enhederne der tolket MTU beskeder
skal desuden ikke være alt for naive.

Endvidere kan preformancen optimeres hvis VPN gatewayerne kan genpakke
IP fragmenterne, udfra ICMP oplysninger.


--
Christian E. Lysel, http://www.spindelnet.dk/

Kunst? http://www.firewallmonkeys.com/songs/

---

"Christian E. Lysel" <news.sunsite.dk@spindelnet.dk> writes:

>Et setup med mobile brugere, der fx bruger VPN og kører applikationer
>over dette kan sagtens give masser af problemer, hvis man ignorer ICMP
>beskeder omkring MTU fejl.

Nu har jeg heller ikke tænkt mig at ignorere de nødvendige dele;
PMTU er en god plan i en del tilfælde, i andre ligemeget.

Til gengæld ser jeg ingen (reel) grund til at RST'e eller ICMP'e
sære connection-forsøg, traceroutes, pings og den slags. Som jeg
skrev: det er ikke noget, der er relevant for maskinens funktion
som applikationsserver. PMTU kan derimod godt være det - igen
afhængig af hvad maskinen laver. Er det en non-recursive DNS-
server, kan det f.eks. være stort set ligemeget.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Nu har jeg heller ikke tænkt mig at ignorere de nødvendige dele;
> PMTU er en god plan i en del tilfælde, i andre ligemeget.

Enig.


> Til gengæld ser jeg ingen (reel) grund til at RST'e eller ICMP'e

Ej ident forsøg? :)

> sære connection-forsøg, traceroutes, pings og den slags. Som jeg

traceroutes og ping er ej typisk indeholdt i mine pakkefiltre.

Traceroutes kan laves på andre måder.

> skrev: det er ikke noget, der er relevant for maskinens funktion
> som applikationsserver. PMTU kan derimod godt være det - igen
> afhængig af hvad maskinen laver. Er det en non-recursive DNS-
> server, kan det f.eks. være stort set ligemeget.

:)


--
Christian E. Lysel, http://www.spindelnet.dk/

Kunst? http://www.firewallmonkeys.com/songs/

---

Den Sun, 1 Dec 2002 16:39:30 +0000 (UTC) skrev Klaus Ellegaard:
>"Christian E. Lysel" <news.sunsite.dk@spindelnet.dk> writes:
>
>>Et setup med mobile brugere, der fx bruger VPN og kører applikationer
>>over dette kan sagtens give masser af problemer, hvis man ignorer ICMP
>>beskeder omkring MTU fejl.
>
>Nu har jeg heller ikke tænkt mig at ignorere de nødvendige dele;
>PMTU er en god plan i en del tilfælde, i andre ligemeget.
>
>Til gengæld ser jeg ingen (reel) grund til at RST'e eller ICMP'e
>sære connection-forsøg,

RST betyder Connection refused, Go away, Nobody home, og alt i den
retning. Får man en RST er det altså spild af tid at forsøge
diverse angreb.

Kommer pakkerne derimod ikke igennem, er det et tegn på at "her sidder
en luser med en fejlkonfigureret ZoneAlarm, og tror at den beskytter
mod influenza". Alle tiders angrebsmål, der skal nok være masser af
sikkerhedshuller.

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.

---

Thomas Bjorn Andersen wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > Klaus Ellegaard wrote:
> > >
> > > Jeg er enig i, at netværkskomponenter skal svare på ICMP. En
> > > firewall (eller applikationen) skal lukke igennem/svare på
> > > det, den er designet til. Hvis det irriterer en tusindedel
> > > af en promille af brugerne, at den ikke svarer på noget som
> > > helst andet, nåja, synd for ham. See if I care.
> >
> > Du tager fejl. Du burde nok læse, hvad RFC 792 har at sige
> > om den sag.
>
> Der er en ny tendens på internettet. Den hedder sikkerhed fremfor
> brugervenlighed.

Du mener vel sikkerhed fremfor korrekt opførsel.

> Al information der slipper ud af et netværk kan
> principelt misbruges,

Hvis man er *så* paranoid kan man ligesågodt trække netkablet ud.

> hvorfor mange kompetente netværksadministratorer
> lukker for al trafik der ikke eksplicit er tilladt.

ICMP er ikke blot eksplicit tilladt, det er faktisk et krav.

> Herunder
> f.eks. ICMP pakker der ikke er direkte nødvendige for brugen af
> TCP/UDP/IP.
>
> Hvorfor er du interesseret i at fejlfinde på mit netværk?

Det er jeg heller ikke, jeg er blot interesseret i at kunne
se hvor fejlen ligger. Hvis du smider pakker væk så snart de
kommer indenfor dit netværk, kan man jo ikke se, om fejlen
ligger indenfor eller udenfor netværket. Jeg kan med andre
ord ikke se, om du har sat din firewall forkert op, eller om
netværkskablet lige udenfor er blevet ødelagt.

> Hvis der er
> noget galt kan du fortælle mig det, så skal jeg nok løse problemet.

Det kræver jo, at jeg ved, hvor problemet ligger.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

---

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

>> hvorfor mange kompetente netværksadministratorer
>> lukker for al trafik der ikke eksplicit er tilladt.

>ICMP er ikke blot eksplicit tilladt, det er faktisk et krav.

RFC'erne beskriver en ideel verden. I praksis beskriver de nogle
guidelines, som man bør overholde i det omfang, der er snedigt
og ikke i strid med ens øvrige procedurer og ønsker.

Det er ikke mig, der siger sådan. Det er praktisk talt alle,
der arbejder med internettet på et professionelt plan med en
eller anden form for kommerciel indgangsvinkel.

For eksempel ville ingen peere med din news-server, hvis du
satte den op efter de relevante RFCer.

På samme måde er det med applikationsservere og ligegyldige
services på IP-stakken.

>> Hvorfor er du interesseret i at fejlfinde på mit netværk?

>ligger indenfor eller udenfor netværket. Jeg kan med andre
>ord ikke se, om du har sat din firewall forkert op, eller om
>netværkskablet lige udenfor er blevet ødelagt.

Det er du da også ligeglad med? Hvis du ved, at din del af
forbindelsen virker, kan resten jo være ligemeget?

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>
> Det er du da også ligeglad med? Hvis du ved, at din del af
> forbindelsen virker, kan resten jo være ligemeget?

Nej. Jeg er først tilfreds, når jeg ved nok om hvor problemet
ligger, til at jeg kan finde ud af, hvem det kan fejlmeldes til.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

---

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

>Men det er da efterhånden gået op for mig at du er fuldstændig
>ligeglad med hvad andre synes. Så jeg kan jo bare håbe, at du
>aldrig bliver administrator af et netværk af betydning.

Too late

Mvh.
   Klaus.

---

On Sun, 01 Dec 2002 02:23:29 +0100, Kasper Dupont
<kasperd@daimi.au.dk> wrote:

>> Man kan diskutere, hvor stor fordelen er ved at kunne pinge en
>> web-server, når den vigtigste måde at checke om den virker er ved
>> at snakke HTTP med den.

> Det er en fordel ved fejlfinding.

Hvis man er interesseret i at vide, om web-serveren svarer, kan
man lave en HTTP-forbindelse. Hvis man ikke får svar, kan man
lave en traceroute for at finde ud af, om der er en vej hen til
web-serveren.

Nu har man al den information man har brug for til at kunne sende
en mail med en fejlmeddelelse i den rigtige retning. Ping kan
derimod ikke bidrage med noget.

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

---

Asbjorn Hojmark wrote:
>
> On Sun, 01 Dec 2002 02:23:29 +0100, Kasper Dupont
> <kasperd@daimi.au.dk> wrote:
>
> >> Man kan diskutere, hvor stor fordelen er ved at kunne pinge en
> >> web-server, når den vigtigste måde at checke om den virker er ved
> >> at snakke HTTP med den.
>
> > Det er en fordel ved fejlfinding.
>
> Hvis man er interesseret i at vide, om web-serveren svarer, kan
> man lave en HTTP-forbindelse. Hvis man ikke får svar, kan man
> lave en traceroute for at finde ud af, om der er en vej hen til
> web-serveren.

Pointen er jo netop, at hvis pakker bliver droppet uden svar vil
traceroute give et forkert billede af hvor fejlen ligger. Og jeg
kender ingen traceroute implementation, der gør brug af TCP SYN
pakker.

>
> Ping kan derimod ikke bidrage med noget.

Ping er jo ikke det eneste program, der bruger icmp echo request.
Traceroute bruger det f.eks. også. Jeg ved godt at Unix/Linux
implementationen bruger UDP som default, men det er en god idé
at sætte den til at bruge icmp i stedet.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

---

On Mon, 02 Dec 2002 05:20:35 +0100, Kasper Dupont
<kasperd@daimi.au.dk> wrote:

> Pointen er jo netop, at hvis pakker bliver droppet uden svar vil
> traceroute give et forkert billede af hvor fejlen ligger.

Det synes jeg ikke.

Hvis du fx kan se, at du ikke kan komme længere end til et punkt
i Netværk As net, så behøver du ikke mere information for at
kunne sende Netværk A en mail om, at de har et problem.

Servere virtualiseres ofte (fx med load-balancing, clustering
eller lignende), og så giver et ping af den adresse, som du
kender som serverens, ikke mening.

Hvis web-stedet www.palle.dk i virkeligheden er et setup med
redundante load-balancing devices og 30 web- og applikations- og
databaseservere bagved, hvem er det så egentlig du forventer et
Echo Reply fra?

> Og jeg kender ingen traceroute implementation, der gør brug af
> TCP SYN pakker.

Det er heller ikke nødvendigt.

> Ping er jo ikke det eneste program, der bruger icmp echo request.

Og hvad så? Hvis det er en web-server, man forsøger at få fat i,
så giver det ikke meget mening at forsøge at bruge den som ping-
reply server.

> Traceroute bruger det f.eks. også.

Og hvad så? Det interessante er i hvilket administrativt domæne
fejlen ligger, ikke hvor i det administrative domæne fejlen
ligger.

> Jeg ved godt at Unix/Linux implementationen bruger UDP som
> default, men det er en god idé at sætte den til at bruge icmp
> i stedet.

Hvorfor?

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

---

Asbjorn Hojmark wrote:
>
> On Mon, 02 Dec 2002 05:20:35 +0100, Kasper Dupont
> <kasperd@daimi.au.dk> wrote:
>
> > Pointen er jo netop, at hvis pakker bliver droppet uden svar vil
> > traceroute give et forkert billede af hvor fejlen ligger.
>
> Det synes jeg ikke.
>
> Hvis du fx kan se, at du ikke kan komme længere end til et punkt
> i Netværk As net, så behøver du ikke mere information for at
> kunne sende Netværk A en mail om, at de har et problem.
>
> Servere virtualiseres ofte (fx med load-balancing, clustering
> eller lignende), og så giver et ping af den adresse, som du
> kender som serverens, ikke mening.

Jo det giver mening.

>
> Hvis web-stedet www.palle.dk i virkeligheden er et setup med
> redundante load-balancing devices og 30 web- og applikations- og
> databaseservere bagved, hvem er det så egentlig du forventer et
> Echo Reply fra?

Jeg forventer selvfølgelig at få svar fra den enhed, der
fordeler forespørgslerne ud til serverne.

>
> > Og jeg kender ingen traceroute implementation, der gør brug af
> > TCP SYN pakker.
>
> Det er heller ikke nødvendigt.

Jo, hvis det er det eneste serveren svarer på.

>
> > Ping er jo ikke det eneste program, der bruger icmp echo request.
>
> Og hvad så? Hvis det er en web-server, man forsøger at få fat i,
> så giver det ikke meget mening at forsøge at bruge den som ping-
> reply server.

Det giver bestemt mening. Hvis den svarer på echo request, men
ikke på HTTP requests har jeg en meget kraftig indikation af, at
problemet ligger på serveren og ikke på netværket ind i mellem.

>
> > Traceroute bruger det f.eks. også.
>
> Og hvad så? Det interessante er i hvilket administrativt domæne
> fejlen ligger, ikke hvor i det administrative domæne fejlen
> ligger.

Det er korrekt. Men fejlopsætning kan også godt medføre at
fejlen ser ud til at ligge i et nabodomæne til der hvor den
virkelig ligger. Specielt hvis fejlen ligger på et hop lige
før eller efter grænsen.

>
> > Jeg ved godt at Unix/Linux implementationen bruger UDP som
> > default, men det er en god idé at sætte den til at bruge icmp
> > i stedet.
>
> Hvorfor?

1) Jeg synes det er en uskik at sende UDP pakker til mere
eller mindre tilfældige porte, og så håbe på at ingen
lytter.
2) Det er lidt nemmere at få en firewall til at håndtere
ICMP echo request på en fornuftig måde end traceroutes
brug af UDP.
3) Min erfaring siger, at ICMP echo request virker korrekt
på flere systemer end UDP.

Jeg har faktisk aldrig set et system hvor traceroute med UDP
pakker virkede mens traceroute med ICMP pakker ikke virkede.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

---

On Tue, 03 Dec 2002 00:39:34 +0100, Kasper Dupont
<kasperd@daimi.au.dk> wrote:

> Jo det giver mening.

Kasper, du insisterer igen på at køre rundt i din egen på forhånd
fastsatte virkelighed uden at være i stand til at føre en egent-
lig diskussion, og tilsyneladende enten uden at læse eller uden
at forsøge at forstå de svar du får.

Det er sgu helt på linie med Bjarne efterhånden, og jeg har altså
ikke tid til den slags. <<plonk.wav>>

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

---

"[2600] Benny Sorensen" wrote:
>
> Hej.
>
> Jeg har spekuleret på en ting:
>
> Skal der lukkes for ICMP ind gennem en firewall?

Det vil være dumt at lukke for alle ICMP pakker. Udgående ICMP
pakker bør man nok aldrig lukke for, og med en god firewall kan
du tillade indgående ICMP pakker der er sendt som svar på dine
egne udgående pakker, og afvise resten. Jeg ville stadig vælge
at åbne for indgående ICMP echo request eller besvare dem i
firewallen. Desuden bør UDP og TCP pakker droppet i firewallen
resultere i at denne sender en passende ICMP fejlmedelelse, det
vil sige icmp-port-unreachable eller tcp-reset.

Hvis du er nervøs for at blive floodet med echo request, UDP
eller TCP pakker, kan du forhindre at din firewall svarer på
dem alle. Ved at sætte en begrænsning på f.eks. 10 i sekundet
kan du forhindre at en flooding af din downstream også fører
til en flooding af din upstream. Men så længe der er masser af
ledig båndbredde bør der sendes svar på alle indgående pakker.

>
> Nogle siger at det forhindrer nogle angreb.
> Andre siger, at det ikke fjerner nogle angreb

Nogle ICMP pakker kan muligvis misbruges imod nogle systemer.
Men ved at kun tillade svar på egne pakker, burde du være
dækket ind mod det.

De berygtede ping-of-death pakker drejer sig om en fejl ved
samling af fragmenterede pakker. Ved ondskabsfuld brug af
fragmenterede pakker er det muligt at lave en sekvens, der
når disse bliver samlet bliver lidt større end standarden
tillader. Nogle implementationer har et problem med dette.

Jeg ved ikke, om fejlen er specifik for icmp echo request
pakker. Jeg kunne godt forestille mig, at angrebet også kan
laves med andre typer pakker.

Jeg har i den forbindelse spekuleret over, om man i de
gængse firewalls kan lukke helt for fragmenterede pakker,
og om det vil have nogle uheldige bivirkninger.

Mig bekendt bruger de fleste TCP implementationer
do-not-fragment flaget fordi det er bedre at håndtere
opdeling og sammensætning i TCP laget i stedet for IP
laget. Og UDP protokoller bruges typisk med data, der er
små nok til at kunne sendes i en pakke.

Er der nogen der kender situationer, hvor man faktisk har
brug for fragmenterede pakker?

>
> Hvad skal man tro?
>
> Grunden til at jeg spørger er:
> Hvis det alligevel ikke fjerner nogle angreb er det jo synd at fjerne et
> nyttigt værktøj som muligheden for at pinge!

Det er jeg fuldstændig enig i.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
char *mybuf[1==1]; (2==3)[mybuf]="Hello World!";

---

"[2600] Benny Sorensen" <beny_sorensen@hotmail.com> wrote:

>Skal der lukkes for ICMP ind gennem en firewall?

I hvert fald ikke for al icmp: visse icmp-pakker er essentielle
for den del af tcp-protokollen der hedder "Path MTU Discovery".

Hvis du blokerer for de pakker, vil du pludselig en dag opdage at
der er steder du har problemer med at snakke tcp med.

Om man vil blokere for andre icmp-pakker er et spørgsmål om hvor
paranoid man er (nogle ville foretrække formuleringen "hvilken
sikkerhedspolitik man har", og det er også rigtigt).

Jeg foretrækker selv at slippe fx ping igennem til DMZ'en, fordi
jeg vurderer faren som værende meget lille: så lille at selv den
begrænsede behagelighed det er at kunne bruge ping, er vigtigere
for mig.

--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).