---

Nu har jeg brugt det meste af dagen på læse en zillion
guides/handbooks/howtos/etc om ppp, ipfw osv. osv. og er nu meget mere
forvirret end da jeg startede. Og det hele startede bare fordi at nu ville
jeg ha en firewall (tilføjet til slut) op og køre (på FreeBSD) ... og som
så ikke rigtig virkede... (kunne ikke få traceroute til at du). Så nu vil
jeg tillade mig at bruge jer som mur til at kaste et par bolde op ad.

Min opsætning er ret simpel:

Min maskine <-> modem <-> udbyder

Hvilket skulle være det samme som:

MyHost <-> tun0 <-> ppp0 <-> ISP

Så lang så godt, ingen hovedpine der. Problemet begynder at opstå nåh der
så skal tildeles IP'er...

MyHost er 127.0.0.1 ... og så falder jeg fra. I min ppp.conf har jeg:

set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0

10.0.0.1 skulle så være et alias for MyHost/tun0 (begge? ... kun den ene?
Eller...) og 10.0.0.2 skulle så være et alias for ISP'en (... eller er
10.0.0.1-2 kun en "intern" forbindelse mellem tun0 og ISP?)... hvad de
255.255.255.0 skal gøre... aner jeg ikke.

Nåh... det var så ppp.conf... i rc.conf fortsætter forvirringen.

network_interfaces="auto" eller "lo0 tun0" eller "lo0 tun0 ppp0"? "auto"
synes at hindre at noget som helst virker. Skulle det ikke, vel?

ifconfig_lo0="inet 127.0.0.1" Det skulle vist være nok?
ifconfig_tun0="" eller "inet 10.0.0.1 netmask 255.0.0.0" eller noget helt
3.?
ifconfig_ppp0= Skal den sættes... og i så fald til hvad?

Jeg har prøvet stort set alle kombinationer af ovenstående jeg kan komme
på, uden det store held. Mit problem med min firewall er der stadig. Får
konstant følgende hits på den:

Apr 18 21:05:26 mekanix /kernel: ipfw: 65435 Deny P:2 212.242.169.254
224.0.0.1 in via tun0

212.242.169.254 er svjv ISP/opkoblingspunktets IP. Hvad er "P:2" for
noget? 224.0.0.1 eksisterer ikke, den er åbenbart mig selv:

PING 224.0.0.1 (224.0.0.1): 56 data bytes
64 bytes from 212.242.169.142: icmp_seq=0 ttl=255 time=3.433 ms
64 bytes from 212.242.169.142: icmp_seq=0 ttl=255 time=4.015 ms (DUP!)

Hvor i alverden kommer 224.0.0.1 fra? 212.242.169.142 er så min IP på
internettet. Og hvad er det der gøre at jeg ikke kan lave nogen traceroute
(men godt pinge)?

Til sidst, hvor kan jeg læse noget ret basalt om IP, IPFW osv. (bog, URL)?

#Nakket fra freebsd.org
# Firewall rules
# Written by Marc Silver (marcs@draenor.org)
# http://draenor.org/ipfw
# Freely distributable
# Define the firewall command (as in /etc/rc.firewall) for easy
# reference. Helps to make it easier to read.
fwcmd="/sbin/ipfw"

# Force a flushing of the current rules before we reload.
$fwcmd -f flush

# Divert all packets through the tunnel interface.
$fwcmd add divert natd all from any to any via tun0

# Allow all data from my network card and localhost. Make sure you
# change your network card (mine was fxp0) before you reboot. :)
$fwcmd add allow ip from any to any via lo0
#$fwcmd add allow ip from any to any via xl0

# Allow all connections that I initiate.
$fwcmd add allow tcp from any to any out xmit tun0 setup

# Once connections are made, allow them to stay open.
$fwcmd add allow tcp from any to any via tun0 established

# Everyone on the internet is allowed to connect to the following
# services on the machine. This example shows that people may connect
# to ssh and apache.
$fwcmd add allow tcp from any to any 80 setup
$fwcmd add allow tcp from any to any 22 setup

# This sends a RESET to all ident packets.
$fwcmd add reset log tcp from any to any 113 in recv tun0

# Allow outgoing DNS queries ONLY to the specified servers.
$fwcmd add allow udp from any to 212.242.40.3 53 out xmit tun0
$fwcmd add allow udp from any to 212.242.40.51 53 out xmit tun0

# Allow them back in with the answers... :)
$fwcmd add allow udp from 212.242.40.3 53 to any in recv tun0
$fwcmd add allow udp from 212.242.40.51 53 to any in recv tun0

# Allow ICMP (for ping and traceroute to work). You may wish to
# disallow this, but I feel it suits my needs to keep them in.
$fwcmd add allow icmp from any to any

#ICQ stuff - vist ikke særlig elegant gjort...
$fwcmd add allow udp from any to any 4000 out xmit tun0
$fwcmd add allow udp from any 4000 to any in recv tun0

# Deny all the rest.
$fwcmd add 65435 deny log ip from any to any

---

Hmm... nu ser det ud til fungere... umiddelbart. I hvert fald virker
traceroute igen ved at tilføje: '$fwcmd add allow udp from any to
any', men forstår det ikke når de zillioner HOWTO's jeg har læst siger
at '$fwcmd add allow icmp from any to any' skulle være nok for at få
ping og traceroute til at virke.

Et simpelt problem med en simpel løsning (er der nogen problemer ved
at lade alle udp-pakker igennem? Eller findes der en mere elegant
løsning?) som stadig giver mig hovedpine.

Troede indtil i går at min userPPP/netværks-opsætning var helt som den
skulle være. Så nu har jeg prøvet at starte 'from scratch' og fulgt
Handbook trin for trin...

/etc/hosts:
# Taget fra
http://www.freebsd.org/doc/en_US.ISO_8859-1/books/handbook/userppp.html
127.0.0.1 localhost localhost.my.domain
127.0.0.1 localhost.my.domain.
10.0.0.1 mekanix.my.domain mekanix
10.0.0.1 mekanix.my.domain.

/etc/ppp.conf:
[...]
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
add default HISADDR
[...]
/etc/ppp.linkup er tom da ovenstående skulle være nok. (?)

/etc/rc.conf:
hostname="mekanix.my.domain"
gateway_enable="YES"
network_interfaces="lo0 tun0"
router_enable="NO"

Ser meget rigtig ud al sammen.... men når jeg så laver en ping på min
maskine får jeg:

PING mekanix.my.domain (10.0.0.1): 56 data bytes
36 bytes from atm4-0-5.ro1-dix.ip.cybercity.dk (212.242.42.174):
Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 1446 0 0000 fa 01 244f 212.242.169.32 10.0.0.1

Hvorfor er 10.0.0.1 ikke blevet tilknyttet min maskine? Er det ikke
det 'set ifaddr...' gør?

Har prøvet med 'interface_tun0="inet 10.0.0.1 netmask 255.255.255.0"',
hvilket bare forhindrer mig i at få nogen forbindelse overhovedet.

Bjarne

---

Den Thu, 19 Apr 2001 14:04:41 +0200 skrev Bjarne Wichmann Petersen:
>Hmm... nu ser det ud til fungere... umiddelbart. I hvert fald virker
>traceroute igen ved at tilføje: '$fwcmd add allow udp from any to
>any', men forstår det ikke når de zillioner HOWTO's jeg har læst siger
>at '$fwcmd add allow icmp from any to any' skulle være nok for at få
>ping og traceroute til at virke.

Traceroute sender UDP pakker ud, og får ICMP svar tilbage. Så du skal
have åbent for UDP udad, men ikke indad.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: planets.png

---

"Bjarne Wichmann Petersen" <mekanix@nospam.dk> wrote:

>Hmm... nu ser det ud til fungere... umiddelbart. I hvert fald virker
>traceroute igen ved at tilføje: '$fwcmd add allow udp from any to
>any', men forstår det ikke når de zillioner HOWTO's jeg har læst siger
>at '$fwcmd add allow icmp from any to any' skulle være nok for at få
>ping og traceroute til at virke.

Så vidt jeg kan se, kommer svar på traceroute altid tilbage som icmp,
men det er OS-afhængigt, om trafikken den anden vej er udp eller icmp.
Linux=udp, Windows=icmp, FreeBSD=?

>Et simpelt problem med en simpel løsning (er der nogen problemer ved
>at lade alle udp-pakker igennem?

Det lyder katastrofalt i mine ører.

På en tcp-pakke er det enkelt at se, om den er et forsøg på at skabe
forbindelse udefra, eller om den bare kommer som en del af en allerede
etableret forbindelse. Det ses på pakkens SYN- og ACK-flag. Dermed kan
man med simpel pakkefiltrering undgå opkoblingsforsøg udefra.

Samme mulighed har man ikke med udp-pakker. Du kan ikke med simpel
pakkefiltrering beskytte dig mod opkoblingsforsøg udefra. Derfor er
det en god ide generelt at spærre for udp og kun lukke op for maskiner
og porte, du har brug for.

Hvis du generelt vil åbne for udp uden at kompromittere sikkerheden,
skal der noget ekstra til, som holder styr på, hvem man har sendt
pakker til, og dermed kan forvente svar fra. Det er vist noget af det,
de kloge kalder stateful inspection. Det findes ikke i den
Linux-kerne, jeg bruger, så jeg kender ikke meget til det, og jeg ved
slet ikke, om din FreeBSD har det.

En blød mellemvej er en generel spærring for udp-trafik udefra til
alle porte <1024 på din maskine, efterfulgt af en åbning for betroede
maskiner og porte.

--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

In article <9bmp48$9js$1@news.inet.tele.dk>, "Allan Olesen"
<aolesen@post3.tele.dk> wrote:

>>Et simpelt problem med en simpel løsning (er der nogen problemer ved
>>at lade alle udp-pakker igennem?
> Det lyder katastrofalt i mine ører.

.... uha.

> En blød mellemvej er en generel spærring for udp-trafik udefra til
> alle porte <1024 på din maskine, efterfulgt af en åbning for
> betroede maskiner og porte.

Hmm... så noget i stil med:

add allow udp from any to any out xmit tun0 # tillad udp ud
add allow udp from any 4000 to any in recv tun0 #ICQ ind
add deny log udp from any to any in recv tun0 # luk for udp-pakker ind

Her har jeg så vidt jeg kan se lukket for al indgående udp-trafik bortset
fra dem jeg har tilladt (icq). Men hindrer det ikke visse folk at lave en
traceroute på mig?

Bjarne

---

>>>>> "Bjarne" == Bjarne Wichmann Petersen <mekanix@nospam.dk> writes:

> Hmm... så noget i stil med:

> add deny log udp from any to any in recv tun0 # luk for udp-pakker ind

Med saadan en regel faar du lidt svaert ved at lave DNS opslag!

--
Mvh Claus Albøge

"Don't summarize. Don't abbreviate. Don't interpret."
      -- D. J. Bernstein

---

In article <2gi7l0hq7ec.fsf@dacia.kom.auc.dk>, "Claus Alboege"
<tractrix@kom.auc.dk> wrote:

>> add deny log udp from any to any in recv tun0 # luk for udp-pakker
>> ind
> Med saadan en regel faar du lidt svaert ved at lave DNS opslag!

;) de *er* blevet tilladt tidligere i kæden! ;)

root$ ipfw list
00100 divert 8668 ip from any to any via tun0
00200 allow ip from any to any via lo0
00300 allow ip from any to any via xl0
00400 allow tcp from any to any out xmit tun0 setup
00500 allow tcp from any to any via tun0 established
00600 allow tcp from any to any 80 setup
00700 allow tcp from any to any 22 setup
00800 reset log logamount 100 tcp from any to any 113 in recv tun0
00900 allow udp from any to 212.242.40.3 53 out xmit tun0
01000 allow udp from any to 212.242.40.51 53 out xmit tun0
01100 allow udp from 212.242.40.3 53 to any in recv tun0
01200 allow udp from 212.242.40.51 53 to any in recv tun0
01300 allow icmp from any to any
01400 allow udp from any to any out xmit tun0
01500 allow udp from any 4000 to any in recv tun0
01600 deny log logamount 100 udp from any to any in recv tun0
65435 deny log logamount 100 ip from any to any
65535 deny ip from any to any


Bjarne

---

Den Thu, 19 Apr 2001 16:29:36 +0200 skrev Bjarne Wichmann Petersen:
>In article <9bmp48$9js$1@news.inet.tele.dk>, "Allan Olesen"
><aolesen@post3.tele.dk> wrote:
>
>>>Et simpelt problem med en simpel løsning (er der nogen problemer ved
>>>at lade alle udp-pakker igennem?
>> Det lyder katastrofalt i mine ører.
>
>... uha.
>
>> En blød mellemvej er en generel spærring for udp-trafik udefra til
>> alle porte <1024 på din maskine, efterfulgt af en åbning for
>> betroede maskiner og porte.
>
>Hmm... så noget i stil med:
>
>add allow udp from any to any out xmit tun0 # tillad udp ud
>add allow udp from any 4000 to any in recv tun0 #ICQ ind
>add deny log udp from any to any in recv tun0 # luk for udp-pakker ind
>
>Her har jeg så vidt jeg kan se lukket for al indgående udp-trafik bortset
>fra dem jeg har tilladt (icq). Men hindrer det ikke visse folk at lave en
>traceroute på mig?

Det kommer an på hvordan "deny" virker. Hvis den sender "port
unreachable" tilbage, virker traceroute. Hvis den ikke svarer, virker
traceroute ikke. (I begge tilfælde traceroute udefra og ind).

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: planets.png

---

"Bjarne Wichmann Petersen" <mekanix@nospam.dk> wrote:

>add allow udp from any to any out xmit tun0 # tillad udp ud
>add allow udp from any 4000 to any in recv tun0 #ICQ ind
>add deny log udp from any to any in recv tun0 # luk for udp-pakker ind

>Her har jeg så vidt jeg kan se lukket for al indgående udp-trafik bortset
>fra dem jeg har tilladt (icq).

Jeg kender ikke syntaksen under FreeBSD.

Bemærk dog, at du ud over icq og dns også har brug for at åbne for
ntp, hvis du skal foretage noget tidssynkronisering.

>Men hindrer det ikke visse folk at lave en traceroute på mig?

Man kan vel altid lave en traceroute. Spørgsmålet er bare, om der også
kommer svar fra sidste hop (dig). Har du brug for, at man kan gøre
det?

Jeg har sniffet lidt, og det ser ud til, at min Linux først sender en
udp-pakke til port 33435 på den fremmede maskine, når den tracerouter.
Næste hop findes med en pakke til port 33436 og så videre. Det undrer
mig lidt, at man bruger høje porte til det, men hvis det er en
standard (anyone?), kunne du jo eventuelt åbne for indgående udp på
port 33435-33535 - efter først at have sikret dig, at du ikke har
sårbare services til at lytte på de porte (men det er nok ret
usandsynligt).


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Hej Allan Olesen <aolesen@post3.tele.dk>

[XFUT: dk.edb.sikkerhed]

>Jeg har sniffet lidt, og det ser ud til, at min Linux først sender en
>udp-pakke til port 33435 på den fremmede maskine, når den tracerouter.
>Næste hop findes med en pakke til port 33436 og så videre. Det undrer
>mig lidt, at man bruger høje porte til det, men hvis det er en
>standard (anyone?), kunne du jo eventuelt åbne for indgående udp på
>port 33435-33535 - efter først at have sikret dig, at du ikke har
>sårbare services til at lytte på de porte (men det er nok ret
>usandsynligt).

Det er meget naturligt for traceroute via UDP.

* How traceroute works with UDP
Traceroute sends UDP packets to the destination host increasing the
destination UDP port numbers in each packet traceroute sends,
typically starting at destination port 33435. Otherwise the procedure
is the same as with ICMP: increasing TTL's, 3 packets per TTL etc…

http://support.vigilante.com/support/documents/traceroute.htm

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund <larskim@mail.com> wrote:
>Det er meget naturligt for traceroute via UDP.

Husker jeg korrekt hvis jeg paastaar, at Windows's traceroute bruger ICMP
som standard?


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

---

On Fri, 20 Apr 2001 00:43:10 +0200, a@area51.dk (Alex Holst)
wrote:

> Husker jeg korrekt hvis jeg paastaar, at Windows's traceroute bruger ICMP
> som standard?

Ja.

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

---

Hej a@area51.dk (Alex Holst)

>>Det er meget naturligt for traceroute via UDP.
>
>Husker jeg korrekt hvis jeg paastaar, at Windows's traceroute bruger ICMP
>som standard?

Jovist, men hvorfor bringe det ind i billedet. Det var et followup fra
en unix-gruppe.

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund <larskim@mail.com> wrote:

>Det var et followup fra en unix-gruppe.

Ja, men det kunne ikke umiddelbart ses af dit indlæg - og hvorfor
landede vi i det hele taget her i gruppen?

Der er heldigvis ingen tradition for at futte netværks-spørgsmål væk
fra d.e.s.unix, og jeg synes egentlig, at problematikken vedr.
filter-regler i FreeBSD, samt forståelsen af den traceroute-trafik,
der skulle åbnes for, var mindst lige så relevant der som her.


--
Allan Olesen, Lunderskov
Hvorfor er det kun Nej-sigerne, der må køre 55 i byen?

---

Hej Allan Olesen <aolesen@post3.tele.dk>

>>Det var et followup fra en unix-gruppe.
>
>Ja, men det kunne ikke umiddelbart ses af dit indlæg - og hvorfor
>landede vi i det hele taget her i gruppen?

Det lignede en god idé på det tidspunkt.

>Der er heldigvis ingen tradition for at futte netværks-spørgsmål væk
>fra d.e.s.unix, og jeg synes egentlig, at problematikken vedr.
>filter-regler i FreeBSD, samt forståelsen af den traceroute-trafik,
>der skulle åbnes for, var mindst lige så relevant der som her.

Jeg forholdt mig til traceroute og filtre og ikke selve
unix-implementationen, og satte followup til den gruppe jeg fandt
dækkede emnet bedst.

Derudover skal jeg ikke blande mig i hvad unix-gruppen bruges til.

--
Lars Kim Lund
http://www.net-faq.dk/

---

Den Thu, 19 Apr 2001 21:59:27 +0200 skrev Allan Olesen:
>"Bjarne Wichmann Petersen" <mekanix@nospam.dk> wrote:
>
>>add allow udp from any to any out xmit tun0 # tillad udp ud
>>add allow udp from any 4000 to any in recv tun0 #ICQ ind
>>add deny log udp from any to any in recv tun0 # luk for udp-pakker ind
>
>>Her har jeg så vidt jeg kan se lukket for al indgående udp-trafik bortset
>>fra dem jeg har tilladt (icq).
>
>Jeg kender ikke syntaksen under FreeBSD.
>
>Bemærk dog, at du ud over icq og dns også har brug for at åbne for
>ntp, hvis du skal foretage noget tidssynkronisering.
>
>>Men hindrer det ikke visse folk at lave en traceroute på mig?
>
>Man kan vel altid lave en traceroute. Spørgsmålet er bare, om der også
>kommer svar fra sidste hop (dig). Har du brug for, at man kan gøre
>det?
>
>Jeg har sniffet lidt, og det ser ud til, at min Linux først sender en
>udp-pakke til port 33435 på den fremmede maskine, når den tracerouter.
>Næste hop findes med en pakke til port 33436 og så videre. Det undrer
>mig lidt, at man bruger høje porte til det, men hvis det er en
>standard (anyone?),

Det eneste svar traceroute er en "connection refused" (ICMP port
unreachable, hvis vi skal være tekniske), så den skal bare bruge
en port der sandsynligvis ikke er i brug.

>kunne du jo eventuelt åbne for indgående udp på
>port 33435-33535 - efter først at have sikret dig, at du ikke har
>sårbare services til at lytte på de porte (men det er nok ret
>usandsynligt).

Som jeg forstod det var problemet at folk kunne traceroute, men
han ikke selv kan. Så er det udgående udp der skal åbnes for.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: planets.png

---

leeloo@mailandnews.com (Kent Friis) wrote:

>Det eneste svar traceroute er en "connection refused" (ICMP port
>unreachable, hvis vi skal være tekniske), så den skal bare bruge
>en port der sandsynligvis ikke er i brug.

Ok. Det giver til dels mening. Men hvad nu hvis porten _er_ i brug?
På min maskine ligger den i det portområde, jeg har reserveret til
udgående forbindelser, så en (sjælden) gang i mellem vil den være i
brug.

Men konklusionen er vel, at man _ikke_ skal åbne for udp på portene
omkring 33435 for at andre kan traceroute ens maskine. Så mit svar til
Bjarne var forkert.

>Som jeg forstod det var problemet at folk kunne traceroute, men
>han ikke selv kan. Så er det udgående udp der skal åbnes for.

Du læste ikke Bjarnes spørgsmål? Jeg havde ellers citeret det lige
over det, jeg skrev. Men jeg kan da citere det igen:
>Men hindrer det ikke visse folk at lave en traceroute på mig?

--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer

---

Den Fri, 20 Apr 2001 00:14:49 +0200 skrev Allan Olesen:
>leeloo@mailandnews.com (Kent Friis) wrote:
>
>>Det eneste svar traceroute er en "connection refused" (ICMP port
>>unreachable, hvis vi skal være tekniske), så den skal bare bruge
>>en port der sandsynligvis ikke er i brug.
>
>Ok. Det giver til dels mening. Men hvad nu hvis porten _er_ i brug?

Så er der et eller andet program der får en pakke den ikke havde
forventet, og det afhænger nok af (modtager-) programmet, hvad der så
sker.

>På min maskine ligger den i det portområde, jeg har reserveret til
>udgående forbindelser, så en (sjælden) gang i mellem vil den være i
>brug.
>
>Men konklusionen er vel, at man _ikke_ skal åbne for udp på portene
>omkring 33435 for at andre kan traceroute ens maskine. Så mit svar til
>Bjarne var forkert.
>
>>Som jeg forstod det var problemet at folk kunne traceroute, men
>>han ikke selv kan. Så er det udgående udp der skal åbnes for.
>
>Du læste ikke Bjarnes spørgsmål? Jeg havde ellers citeret det lige
>over det, jeg skrev. Men jeg kan da citere det igen:
>>Men hindrer det ikke visse folk at lave en traceroute på mig?

Hmm, jeg læste det som "Men det hindrer ikke..."

Umiddelbart kan man ikke lukke for traceroute til firewall'en (men godt
til maskiner bag ved, hvis man kører stateful inspection (incl.
masquerading), uden at det går ud over andre programmer også. Man
kan derimod godt blokere ping (icmp echo), og dermed også ms-tracert.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: planets.png