/ Forside / Teknologi / Operativsystemer / Linux / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Linux
#NavnPoint
o.v.n. 11177
peque 7911
dk 4814
e.c 2359
Uranus 1334
emesen 1334
stone47 1307
linuxrules 1214
Octon 1100
10  BjarneD 875
ipchains igen
Fra : Peter Andersen


Dato : 04-10-01 16:00

Jeg har lidt poroblemer med hvad jeg skal blokere mht. -dport og -sport.

Jeg kan blokere de services (ftp osv) der kører på min box med -dport, men
det nytter heller ikke noget jeg blokere 1-65535 med -dport..

Hvordan er det nu det hænger sammen? hvad skal jeg blokere med henholdsis d
og sport....´

Hvilke porte skal jeg la være åbne for KUN at kunne køre HTTP og hvordan
bliver forbindelsen oprettet, her tænker jeg også på hvad der sker mht.
førnævnte source og destination porte....

Noge måske lidt OT, men det hænger jo sammen med IPCHAINS....

vh. Peter



 
 
Kent Friis (04-10-2001)
Kommentar
Fra : Kent Friis


Dato : 04-10-01 16:35

Den Thu, 4 Oct 2001 16:59:37 +0200 skrev Peter Andersen:
>Jeg har lidt poroblemer med hvad jeg skal blokere mht. -dport og -sport.
>
>Jeg kan blokere de services (ftp osv) der kører på min box med -dport, men
>det nytter heller ikke noget jeg blokere 1-65535 med -dport..
>
>Hvordan er det nu det hænger sammen? hvad skal jeg blokere med henholdsis d
>og sport....´
>
>Hvilke porte skal jeg la være åbne for KUN at kunne køre HTTP og hvordan
>bliver forbindelsen oprettet, her tænker jeg også på hvad der sker mht.
>førnævnte source og destination porte....
>
>Noge måske lidt OT, men det hænger jo sammen med IPCHAINS....

ipchains -A INPUT --dport 80 -j ACCEPT
ipchains -A INPUT -j REJECT

Mvh
Kent
--
IIS should be kept behind a PIX or better firewall, with port 80 closed.

Peter Andersen (04-10-2001)
Kommentar
Fra : Peter Andersen


Dato : 04-10-01 18:55

"Kent Friis" <kfr@fleggaard.dk> wrote in message
news:9phvio$oee$1@sunsite.dk...
> Den Thu, 4 Oct 2001 16:59:37 +0200 skrev Peter Andersen:
> >Jeg har lidt poroblemer med hvad jeg skal blokere mht. -dport og -sport.
> >
> >Jeg kan blokere de services (ftp osv) der kører på min box med -dport,
men
> >det nytter heller ikke noget jeg blokere 1-65535 med -dport..
> >
> >Hvordan er det nu det hænger sammen? hvad skal jeg blokere med henholdsis
d
> >og sport....´
> >
> >Hvilke porte skal jeg la være åbne for KUN at kunne køre HTTP og hvordan
> >bliver forbindelsen oprettet, her tænker jeg også på hvad der sker mht.
> >førnævnte source og destination porte....
> >
> >Noge måske lidt OT, men det hænger jo sammen med IPCHAINS....
>
> ipchains -A INPUT --dport 80 -j ACCEPT
> ipchains -A INPUT -j REJECT

hmm det kan jeg ikke få til at virke....

jeg har:
ipchains -P input -j DENY

ipchains -A input -p tcp --dport 21:23 -j DENY
........flere af samme slags for at blokere hvad der kører på linux. Er det
den rigtige måde at gøre det på?

det virker kun hvis jeg skriver:
ipchains -A input -j ACCEPT

burde det ikke også virke hvis jeg skrev:
ipchains -A input -p all --sport 1:65535 -j ACCEPT
ipchains -A input -p all --dport 1:65535 -j ACCEPT
men det gør det ikke!!






Kent Friis (04-10-2001)
Kommentar
Fra : Kent Friis


Dato : 04-10-01 19:20

Den Thu, 4 Oct 2001 19:55:12 +0200 skrev Peter Andersen:
>"Kent Friis" <kfr@fleggaard.dk> wrote in message
>news:9phvio$oee$1@sunsite.dk...
>> Den Thu, 4 Oct 2001 16:59:37 +0200 skrev Peter Andersen:
>> >Jeg har lidt poroblemer med hvad jeg skal blokere mht. -dport og -sport.
>> >
>> >Jeg kan blokere de services (ftp osv) der kører på min box med -dport,
>men
>> >det nytter heller ikke noget jeg blokere 1-65535 med -dport..
>> >
>> >Hvordan er det nu det hænger sammen? hvad skal jeg blokere med henholdsis
>d
>> >og sport....´
>> >
>> >Hvilke porte skal jeg la være åbne for KUN at kunne køre HTTP og hvordan
>> >bliver forbindelsen oprettet, her tænker jeg også på hvad der sker mht.
>> >førnævnte source og destination porte....
>> >
>> >Noge måske lidt OT, men det hænger jo sammen med IPCHAINS....
>>
>> ipchains -A INPUT --dport 80 -j ACCEPT
>> ipchains -A INPUT -j REJECT
>
>hmm det kan jeg ikke få til at virke....
>
>jeg har:
>ipchains -P input -j DENY
>
>ipchains -A input -p tcp --dport 21:23 -j DENY
>.......flere af samme slags for at blokere hvad der kører på linux. Er det
>den rigtige måde at gøre det på?

Nej.

Den rigtige(tm) måde at gøre det på, er at lukke for ALT (-P input -j
DENY), og så åbne for de ting du vil have ind. Så glemmer man ikke at
rette i firewall'en den dag man kommer til at starte fx portmap og
rpc.statd[1].

>det virker kun hvis jeg skriver:
>ipchains -A input -j ACCEPT
>
>burde det ikke også virke hvis jeg skrev:
>ipchains -A input -p all --sport 1:65535 -j ACCEPT
>ipchains -A input -p all --dport 1:65535 -j ACCEPT
>men det gør det ikke!!

Det giver ikke mening at angive hverken "-p all" eller "--sport 1:65535"
- det man angiver er de ting pakken skal overholde. Ikke dem der er
ligegyldige.

Mvh
Kent

[1] Det er en af de farlige...
--
IIS should be kept behind a PIX or better firewall, with port 80 closed.

Allan Olesen (04-10-2001)
Kommentar
Fra : Allan Olesen


Dato : 04-10-01 20:19

"Peter Andersen" <peterandersen@e-box.dk> wrote:

>Jeg har lidt poroblemer med hvad jeg skal blokere mht. -dport og -sport.

Et godt udgangspunkt er:
Bloker alt, åbn derefter for det, du har brug for, og log det, du ikke
har åbnet for.

Det er lettere at overskue end en lukning af bestemte porte, og hvis
du glemmer noget, opdager du hurtigt, at eller andet ikke virker, og
så kan du bare kigge i loggen og finde de pakker, der burde have været
lukket igennem.

Et meget kort ipchains script, der gør præcis det, kunne se således
ud:

# Default policy er "afvis indgående pakker på alle interfaces":
ipchains -P input DENY; ipchains -F input
ipchains -P forward DENY; ipchains -F forward
ipchains -P output ACCEPT; ipchains -F output

# Åbn for alt fra lo-interfacet:
ipchains -A input -p all -j ACCEPT -i lo

# Åbn for alt fra eth0 (kun hvis det er et rent lokalnets-interface):
# ipchains -A input -p all -j ACCEPT -i eth0

# Åbn for øvrige tcp-pakker, som ikke er SYN-pakker:
ipchains -A input -p tcp -j ACCEPT \! -y
# (Den er meget generel, og kan evt. begrænses yderligere til bestemte
# source porte som f.eks. 25, 80 og 110, og til bestemte destination
# porte i det område, du bruger til udgående forbindelser, se
# nedenfor.)

# Log resten:
ipchains -A input --log

Scriptet åbner groft sagt for alt indefra, men kun for pakker udefra,
som ikke vil kunne bruges til at etablere en forbindelse. Det er dog
ikke færdigt, for du skal også have åbnet for nogle typer icmp- og
udp-pakker udefra, før alt (f.eks. dns) virker.

Et mere omfattende script (hvorfra jeg har stjålet ovenstående) kan
ses på http://www.sslug.dk/sikkerhed/

>Jeg kan blokere de services (ftp osv) der kører på min box med -dport, men
>det nytter heller ikke noget jeg blokere 1-65535 med -dport..

Næ, du skal jo nødvendigvis give plads til svar på den trafik, du selv
etablerer.

Et godt trick er at tvinge alle dine egne udgående forbindelser til at
bruge et begrænset område af source porte.

Det gøres med kommandoen:
echo "32768 40960" >/proc/sys/net/ipv4/ip_local_port_range

Nu ved du næsten med sikkerhed, at alt indgående trafik til andre
porte end 32768-40960 er af en type, du ikke ønsker.

>Hvordan er det nu det hænger sammen? hvad skal jeg blokere med henholdsis d
>og sport....´
>
>Hvilke porte skal jeg la være åbne for KUN at kunne køre HTTP

Altså adgang udefra til en webserver på din maskine, som ikke kører
https eller andet sjov?

Så har du som udgangspunkt kun brug for at tillade pakker udefra med
port 80 som destination port.

>og hvordan
>bliver forbindelsen oprettet, her tænker jeg også på hvad der sker mht.
>førnævnte source og destination porte....

Sådan lige ud af hovedet med forbehold for fejl:

Maskinen udefra sender en pakke til dig med en såkaldt SYN-pakke, som
har SYN-flaget sat, for at åbne forbindelsen. Source port vil være
tilfældig, og destination port vil være port 80.

Din maskine kvitterer med en såkaldt SYN/ACK-pakke, som har SYN- og
ACK-flagene sat, for at fortælle, at forbindelsen er åben. Portene er
de samme, men da denne pakke går den anden vej, er der naturligvis
byttet rundt på source og destination port.

Derefter kommer den almindelige trafik, som består af pakker uden
SYN-flag, men både med og uden ACK-flag, stadig mellem de to
ovennævnte porte.

Til sidst afsluttes forbindelsen ved at en af maskinerne sender en
pakke med FIN-flag og modtager en pakke med FIN- og ACK-flag.

Alle pakker nævnt her er tcp-pakker.

Som du kan se, er tcp-pakker generelt ret lette at have med at gøre,
for man kan se på dem, om de er "farlige" i den forstand, at de
forsøger at forhandle en forbindelse.

Udp-pakker er værre, da der ikke finder nogen forhandling sted for at
åbne for udp-trafik. Pakkerne sendes bare frem og tilbage. Du kan
derfor ikke umiddelbart se på en udp-pakke udefra, om den er svar på
en pakke, du selv har sendt. Der kan derfor være ide i kun at åbne for
udp-pakker fra nogle helt enkelte maskiner, du stoler på. Ofte vil det
være tilstrækkeligt at åbne for de dns- og ntp-servere, man benytter.

Hvis du vil have bedre styr på udp-pakker, kommer ipchains til kort.
I stedet bliver du nødt til at køre stateful inspection, hvor der
populært sagt holdes regnskab med, hvad man har sendt, og hvad man
forventer at modtage. Iptables til kerne 2.4 bruger stateful
inspection.


Vi kan jo forøvrigt lige så godt tage denne fra din anden tråd med det
samme:
>En anden ting: er der nogen grund til at sætte regler op for forward?
>hvorfor ikke bare gøre det hele på input... alle pakke løber jo igennem
>input alligevel!

Regler for forward kan være gode, hvis maskinen er gateway for dit
lokalnet. Så kan du bruge forward-regler til at undgå, at bestemte
typer trafik fra lokalnettet ryger ud på Internettet, mens du samtidig
beholder muligheden for at samme type trafik kan nå frem maskinen
selv.

Jeg kører f.eks. en smtp-server på min gateway. Hvis der kommer trafik
fra en af de andre lokale maskiner til port 25 på en maskine ude på
Internettet, skyldes det fejlopsætning eller virus/orme. Jeg har
derfor lavet en forward-regel, der lukker for trafik til port 25. En
input-regel ville også have spærret for trafik til maskinens egen
smtp-server.

(Jeg må nok bryde sammen og tilstå, at jeg først lavede port
25-reglen, da min 1-årige datter _havde_ installeret SirCam-ormen.)


--
Allan Olesen, Lunderskov

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

Peter Andersen (04-10-2001)
Kommentar
Fra : Peter Andersen


Dato : 04-10-01 23:01


"Allan Olesen" <aolesen@post3.tele.dk> wrote in message
news:3bbcb687$0$8090$edfadb0f@dtext.news.tele.dk...
> "Peter Andersen" <peterandersen@e-box.dk> wrote:
>
> >Jeg har lidt poroblemer med hvad jeg skal blokere mht. -dport og -sport.
>
> Et godt udgangspunkt er:
> Bloker alt, åbn derefter for det, du har brug for, og log det, du ikke
> har åbnet for.
>
> Det er lettere at overskue end en lukning af bestemte porte, og hvis
> du glemmer noget, opdager du hurtigt, at eller andet ikke virker, og
> så kan du bare kigge i loggen og finde de pakker, der burde have været
> lukket igennem.
>
> Et meget kort ipchains script, der gør præcis det, kunne se således
> ud:
>
> # Default policy er "afvis indgående pakker på alle interfaces":
> ipchains -P input DENY; ipchains -F input
> ipchains -P forward DENY; ipchains -F forward
> ipchains -P output ACCEPT; ipchains -F output
>
> # Åbn for alt fra lo-interfacet:
> ipchains -A input -p all -j ACCEPT -i lo
>
> # Åbn for alt fra eth0 (kun hvis det er et rent lokalnets-interface):
> # ipchains -A input -p all -j ACCEPT -i eth0
>
> # Åbn for øvrige tcp-pakker, som ikke er SYN-pakker:
> ipchains -A input -p tcp -j ACCEPT \! -y
> # (Den er meget generel, og kan evt. begrænses yderligere til bestemte
> # source porte som f.eks. 25, 80 og 110, og til bestemte destination
> # porte i det område, du bruger til udgående forbindelser, se
> # nedenfor.)
>
> # Log resten:
> ipchains -A input --log
>
> Scriptet åbner groft sagt for alt indefra, men kun for pakker udefra,
> som ikke vil kunne bruges til at etablere en forbindelse. Det er dog
> ikke færdigt, for du skal også have åbnet for nogle typer icmp- og
> udp-pakker udefra, før alt (f.eks. dns) virker.
>
> Et mere omfattende script (hvorfra jeg har stjålet ovenstående) kan
> ses på http://www.sslug.dk/sikkerhed/
>
> >Jeg kan blokere de services (ftp osv) der kører på min box med -dport,
men
> >det nytter heller ikke noget jeg blokere 1-65535 med -dport..
>
> Næ, du skal jo nødvendigvis give plads til svar på den trafik, du selv
> etablerer.
>
> Et godt trick er at tvinge alle dine egne udgående forbindelser til at
> bruge et begrænset område af source porte.
>
> Det gøres med kommandoen:
> echo "32768 40960" >/proc/sys/net/ipv4/ip_local_port_range
>
> Nu ved du næsten med sikkerhed, at alt indgående trafik til andre
> porte end 32768-40960 er af en type, du ikke ønsker.
>
> >Hvordan er det nu det hænger sammen? hvad skal jeg blokere med henholdsis
d
> >og sport....´
> >
> >Hvilke porte skal jeg la være åbne for KUN at kunne køre HTTP

Nej jeg mente nu bare for at modtaget HTTP (hvis man kan sige det)..

Men nu skal jeg lige ha fat i det!
Når en ude på nettet vil se noget på fx. en HTTP server jeg har kørende på
min maskine, så vil der blive sendt en pakke til mig om at få afgang til
port 80 og ikke andre! ?
Hvis jeg bruger DENY på alle input pakker med -dport på port 80 vil
forbindelsen IKKE gå igennem. ?

Hvis jeg på lokal nettet (eller linux maskinen) vil se en HTTP side i min
browser, så er destination på pakken herfra så port 80.. Men hvad med source
porten på pakken jeg sender herfra? det er vel ikke 80? Du skriver at source
porten vil være tilfældig for afsendte pakker? Dvs. at der vil være en port
åben på MIN maskine til at modtage den information (pakker) som afsendes fra
den HTTP server jeg har fat i?
Udgør de source porte, der vel bliver åbnet temperert, nogen risiko? dvs. er
der nogen jeg skal åbne eller lukke?
Men der var det du skrev:
"Det gøres med kommandoen: echo "32768 40960"
>/proc/sys/net/ipv4/ip_local_port_range"
Gider du ikke lige uddybe det.. fx hvorfor lige dem? hvor mange skal jeg
vælge? hvor mange bruges på samme tid osv..!

> Maskinen udefra sender en pakke til dig med en såkaldt SYN-pakke, som
> har SYN-flaget sat, for at åbne forbindelsen. Source port vil være
> tilfældig, og destination port vil være port 80.
>
> Din maskine kvitterer med en såkaldt SYN/ACK-pakke, som har SYN- og
> ACK-flagene sat, for at fortælle, at forbindelsen er åben. Portene er
> de samme, men da denne pakke går den anden vej, er der naturligvis
> byttet rundt på source og destination port.
>
> Derefter kommer den almindelige trafik, som består af pakker uden
> SYN-flag, men både med og uden ACK-flag, stadig mellem de to
> ovennævnte porte.
>
> Til sidst afsluttes forbindelsen ved at en af maskinerne sender en
> pakke med FIN-flag og modtager en pakke med FIN- og ACK-flag.

ok det har jeg fat i....

EN hel anden ting: når jeg bruger nogle ip_masq moduler, vil mine regler i
IPCHAINS ha nogen indvirkning på dem?

Men tak for dit gode svar..






Allan Olesen (07-10-2001)
Kommentar
Fra : Allan Olesen


Dato : 07-10-01 20:26

"Peter Andersen" <peterandersen@e-box.dk> wrote:

>Nej jeg mente nu bare for at modtaget HTTP (hvis man kan sige det)..

OK. Det er kan klares med de basale regler, jeg havde stillet op.

>Men nu skal jeg lige ha fat i det!
>Når en ude på nettet vil se noget på fx. en HTTP server jeg har kørende på
>min maskine, så vil der blive sendt en pakke til mig om at få afgang til
>port 80 og ikke andre! ?
>Hvis jeg bruger DENY på alle input pakker med -dport på port 80 vil
>forbindelsen IKKE gå igennem. ?

Næ, men hvis det er din eneste regel, kan du heller ikke selv kontakte
webservere ude i verden, for her sender du selv pakker med destination
port 80. Og _dine_ udgående pakker kommer altså også gennem
input-kæden.

Bortset fra det er det efter min mening grundlæggende forkert at
spærre udefra kommende trafik til bestemte porte. Man starter med at
spærre for al udefra kommende trafik, og så lukker man op for de
enkelte porte, man har behov for.

>Hvis jeg på lokal nettet (eller linux maskinen) vil se en HTTP side i min
>browser, så er destination på pakken herfra så port 80.. Men hvad med source
>porten på pakken jeg sender herfra? det er vel ikke 80? Du skriver at source
>porten vil være tilfældig for afsendte pakker? Dvs. at der vil være en port
>åben på MIN maskine til at modtage den information (pakker) som afsendes fra
>den HTTP server jeg har fat i?

Korrekt.

>Udgør de source porte, der vel bliver åbnet temperert, nogen risiko? dvs. er
>der nogen jeg skal åbne eller lukke?

Hvis du lukker dem, kan du jo ikke modtage den trafik, du har bedt om.

Man kan naturligvis tænke sig, at du helt tilfældig modtager uvelkomne
pakker på en bestemt port, hvor din maskine i forvejen lytter efter
svar på en udgående forbindelse. Jeg _tror_, at disse pakker i nogle
tilfælde også kan blive sendt videre til den applikation, der har
oprettet forbindelsen - f.eks. din webbrowser. Hvad der så vil ske,
afhænger af applikationen. Men du bliver nok nødt til at acceptere den
risiko.

Og ganske mange pakker (især tcp) vil nok blive afvist, fordi de
simpelt hen ikke passer ind i kommunikationen. Men det er ikke noget,
jeg ved ret meget om.

Her er stateful inspection igen bedre, idet pakken vil blive fanget
"ved døren", fordi den kommer fra en anden ip-adresse, end du har
oprettet din udgående forbindelse til. Til gengæld får man så en falsk
alarm af og til - f.eks. kører TDC et sjovt newsserver-setup, hvor man
risikerer at få svar fra en en anden ip-adresse, end den man har
kontaktet, og den slags ryger lige i loggen.

>Men der var det du skrev:
>"Det gøres med kommandoen: echo "32768 40960"
>>/proc/sys/net/ipv4/ip_local_port_range"
>Gider du ikke lige uddybe det.. fx hvorfor lige dem?

De er ret tilfældigt valgt. Det vigtige er, at du vælger et
portområde, hvor du ikke selv kan regne med at have services til at
lytte. Det gør det lidt mere ukompliceret at skrive filterregler. Den
højeste port, som en Linux-maskine normalt kan risikere at lytte på,
er vistnok 8080/tcp, som bruges af squid.

Hvis maskinen er gateway for andre maskiner på lokalnettet, vil port
61000-65095 desuden blive brugt til udgående masqueradede
forbindelser, så de portnumre bør man nok også holde sig fri af for
ikke at komme til at forstyrre masqueradingen. Til gengæld kan det
være smart at lægge sig umiddelbart under dem, f.eks. port
59000-60999, så man har eet sammenhængende portområde, der bruges til
udgående forbindelser. Det har jeg ikke selv, så jeg har mange
ipchains-regler i dobbelt udgave, een for port 32768-40960 og een for
port 61000-65095, hvor jeg i stedet kunne have nøjedes med een for
port 59000-65095.

>hvor mange skal jeg
>vælge? hvor mange bruges på samme tid osv..!

Prøv at køre en 'netstat -n'. Den viser blandt andet, hvor mange
udgående forbindelser, du har lige nu. Tit har man kun nogle ganske
få. Lige nu har jeg omkring 100 udgående porte åbne, men det skyldes,
at jeg sidder og leger med noget skummelt fildelingssoftware ved navn
eDonkey, hvor man på samme tid spørger en gevaldig masse maskiner,
hvilke dele af en fil, de har.

Så 8000 porte er mange, og de fleste kunne sikkert uden problemer
barbere antallet ned til nogle få hundrede. Det er dog begrænset, hvor
meget sikkerhed, man vinder ved det, eftersom portområdet jo som sagt
skal være valgt, så man ikke har nogle services til at lytte på dem.

>EN hel anden ting: når jeg bruger nogle ip_masq moduler, vil mine regler i
>IPCHAINS ha nogen indvirkning på dem?

Efter hvad jeg har eksperimenteret mig frem til, rammer en indgående
pakke først dine ipchains-regler. Kun hvis den slipper gennem disse
regler, går de videre til dine ip_masq moduler. Dvs. at du f.eks. ikke
skal forvente at skulle hente filer udefra med aktiv ftp, hvis du har
lukket for alle indgående tcp-forbindelser.

Når du svarer, må du forresten godt klippe lidt i det, du citerer. Det
gør det lidt lettere at finde det, du selv skriver.


--
Allan Olesen, Lunderskov

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

Søg
Reklame
Statistik
Spørgsmål : 177513
Tips : 31968
Nyheder : 719565
Indlæg : 6408603
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste