Betydningen av Linux systemvariabler i forbindelse med Firewalls.

I denne opgave finder du en netfilter tutorial, der forklare en del af det

http://www.giac.org/practical/Peter_Vestergaard_GCFW.zip

Beklager at jeg svarer på eget spørsmål, det er jo egentlig litt "dumt", men fant bare noe her (som bør tas vare på, mener jeg).

Vedrørende den første problemstillingen så står det noe her:

http://www.securiteam.com/exploits/5LP0O2A35G.html

To stop machines running Linux from responding to broadcasts, you need to add "1" to the /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts file:

# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Or add it to your /etc/sysctl.conf file (recommended):

net.ipv4.icmp_echo_ignore_broadcasts = 1

Den første dreier seg altså om å få den til å slutte å svare på broadcasts. Det virker jo ellers rimelig og fornudftig at en firewall maskin ikke skal svare på broadcasts.

Har nyere Linux den samme innstillingen ?

bufferzone -> Takker for meget interessant tutorial. Har sett gjennom. Det står egentlig ikke så mye som går i dybden når det gjelder dette med oppsett av systemparametre, av det som jeg kan se, sånn umiddelbart, men det ser ut som om det står veldig mye annet interessant i dette kompendiet. Oppdaget at det ser ut som om det ligger flere slike kompendier lagt ut på nett: http://www.giac.org/GCFW_400.php

Fantastisk .. her ligger det jo tusenvis av sider av forskjellige casetudier. Bør holde til et par kvelder .. :)

Vedrørende den første problemstillingen:

Denne filen "/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts" finnes også på Fedora Core 2. (Gikk inn på min testserver og sjekket dette)

Default verdi er "0".

Dette betyr sannsynligvis at Fedora Core 2 som default svarer på broadcasts og at det for en firewallmaskin vil være fordelaktig å sette systemvariablen til "1" slik at svar til broadcasts "skrus av".

Men hva i alle dager betyr dette ?

for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do

Det har vel noa å gjøre med å tygge seg gjennom flere directory, og sette flere variabler, men hva står bokstaven f for ??

Fant noe her .. "f" må vel i all enkelhet stå for "files"
Og stjernen står vel for alle directory under /proc/sys/net/ipv4/conf/ som har filen accept_source_route (??)

" echo 0 > $f " Kan dette bety: skriv null inn i filen ?

Har sjekket testserver.

Filene /proc/sys/net/ipv4/conf/*/accept_source_route finnes hos Fedora Core 2 og default verdi er satt til 1.

* erstatter lo, etho, eth1, eth2 osv.

Spørsmål .. vil det at koden kjøre medføre at variablene settet til 0 ?
Hva vil være effekten av dette ?

Resultatet av at dette scriptet ble kjørt var faktisk at samtlige av disse variablene ble satt til "0"

# Disable Source Routed Packets
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
    echo 0 > $f
done

Men hva er nå det praktiske resultatet av dette ? Hva vil det eventuelt si å "disable source routed packets" !!??

Det ser også ut til at det finnes en helt annen måte å sette disse parametrene på i Redhat/Fedora:

http://forum.sans.org/discus/messages/81/9249.html?1070549941

(Har sjekket med testserver, filen er der.)

Her har vi vel noe om source route:
http://www.linuxgazette.com/issue77/lechnyr.html

Normally, a host has no control over the route any particular packet takes beyond its first hop. It is up to the other hosts on the network to complete the delivery. IP Source Routing (SRR) is a method of specifying the exact path that a packet should take among the other hosts to get to its destination. This is generally a bad idea for the security conscious, as someone could direct packets to you through a trusted interface and effectively bypass your security in some cases

Konklusjon: Det vil vanlig vis (men ikke alltid) være en god ide å sette disse systemvariablene til "0", slik som R Ziegler foreslår i sin bok også for nyere Linux, For eksempel Fedora Core 2. (???)

(***Men for treport firewalls der man skal kommunisere fra lan til dmz, så blir det kanskje et unntak ??)

# Enable TCP SYN Cookie Protection
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Finner noe i denne:
http://www.linuxgazette.com/issue77/lechnyr.html

If you have compiled your kernel with CONFIG_SYNCOOKIES, you will be able to optionally turn on or off protection against SYN flood attacks. Note the emphasis, as compiling the kernel with this value does not enable it by default.

Finnes filen hos Fedora 2, og hva er verdien ?

Et annet interessant spørsmål: Virker denne syn flood protection bare i forhold til input/output chain eller virker den også i forhold til forwarding chain ?

Den finnes hos Fedora Core 2 og default verdi er 0.
Konklusjon: Det kan uansett ikke være noen ulempe å sette denne verdien til "1"
slik at synflood protection på kernelnivå blir aktivisert, i den grad dette er kompilert inn i kernel (vil tro at dette er tilfellet.)

# Disable ICMP Redirect Acceptance
for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
    echo 0 > $f
done

Problemstilling rundt accept_redirects er ok behandlet her:
http://www.linuxgazette.com/issue77/lechnyr.html
under avsnitt: ICMP Specific Settings

Fedora Core 2 har verdiene default satt til "1".

Konklusjon: Bør settes til "0"

# Don¹t send Redirect Messages
for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
    echo 0 > $f
done

Står noe her:
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.policy_routing.html

If you now turn off icmp redirects on the director.
director:/etc/lvs# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

Finnes filen i Fedora og hva er default verdi ?

Den finnes og default verdi er "1".

Konklusjon: Bør settes til "0"

# Drop Spoofed Packets coming in on an interface, which if replied to,
# would result in the reply going out a different interface.
for f in /proc/sys/net/ipv4/conf/*/# Drop Spoofed Packets coming in on an interface, which if replied to,
# would result in the reply going out a different interface.
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
    echo 1 > $f
done

Noe her:
http://lists.debian.org/debian-firewall/2003/12/msg00031.html
http://www.sslug.dk/emailarkiv/sikkerhed/2002_09/msg00082.html

Ikke så lett å bli helt klok på denne problemstillingen, men parametret finnes hos Fedora Core 2, og den er satt med default instilling "1"

Konklusjon: Den kan beholde sin default verdi som er "1"

# Log packets with impossible addresses.
for f in /proc/sys/net/ipv4/conf/*/log_martians; do
    echo 1 > $f
done

http://www.linuxgazette.com/issue77/lechnyr.html

Packets that have source addresses with no known route are referred to as "martians". For example, if you have two different subnets plugged into the same hub, the routers on each end will see each other as martians. To log such packets to the kernel log, which should never show up in the first place, you'll need to issue:

if [ -r /proc/sys/net/ipv4/conf/all/log_martians ]; then
  echo "Enabling logging of martians"
  echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
fi

Og hos Fedora Core 2:
Den finnes og den er satt til "0".

Konklusjon: Det kan vel ikke være spesielt viktig om denne systemvariablen er satt til "0". Man kan godt sette den til "1" Desom man ønsker det.

Konklusjon vedrørende setting av Linux systemvariabler på firewall gateway:

Man kan med fordel sette variablene slik som foreslått i R Ziegeler sitt script.

En moderne Linux distribusjon som Fedora Core 2 har alle de aktuelle variablene på "riktig plassering".

Det kan finne et mulig unntak for oppsett med DMZ, der man kanskje vil miste routingen til DMZ sonen dersom man setter denne til null:

# Disable Source Routed Packets
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
    echo 0 > $f
done

Vet ikke sikkert. Man kan jo prøve det ?? (Og så bare la den skifte mellom echo 0 og 1.)

Hvis det er andre som hare mer infor så kan det selvfølgelig legges ut flere points !

*****************
For ordene skyld:
*****************

Oppsettet med systemparametre er nå testkjørt på en to port firewall. Fungerte problemfritt.

Dette oppsettetmed systemparametre settes helt i toppen av et firewallscript,
dersom man ønsker å bruke dette som en "hardening" av selve operativsystmet,
eller kernelparametere om man vil.

Dersom man lager en firewall løsning som inneholder en DMZ løsning så kan det
tenkes at denne må forandres:

# Disable Source Routed Packets
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
    echo 0 > $f
done

etter forandring:

# Disable Source Routed Packets
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
    echo 1 > $f
done


Grunn: Kan tenkes at routingen mellom dmz/lan ellers vil stanse opp.

Fint om den som eventuelt tester dette legger beskjed.

Jeg har prøvd både med 1 og 0 og begge deler fungerer.
Setter den til 0.

Tror jeg kanskje har oppdaget en nokså tricky feil, eller i hvert fall risikofaktor, ved framgangsmåten over.

Det viser seg at når man setter kernelvariablene på denne måten vha script, så blir endringene ikke permanente. Så snart man rebooter så går verdiene tilbake til default.

Konfigureringsverdiene for nettverket leses inn før nettverkskortene kommer opp. Det vil si at nettverkortene kjøres i gang på basis av default systemsetting og ikke ut i fra de endringene som vi ønsker.

Til sist i bootsekvensen når firewall script kjører så vil vi få systemparametrene satt til de ønskede verdier, men mon dette ikke kan være for sent i forhold til å få alle funksjonene til å virke slik som vi ønsker.

Gjennomførte noen eksperimenter med utgangspunkt i konfigurasjonsfilen /etc/sysctl.conf

Tok vekk hele oppsettet med endringer i kernelparametre fra firewallscriptet og laget i stedet disse endringer i /etc/sysctl.conf

# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0
# net.ipv4.ip_forward = 1


# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1


# Andre endringer for aa hardne systemet for bruk som firewall

net.ipv4.icmp_echo_ignore_broadcasts = 1

net.ipv4.conf.default.accept_source_route = 0

net.ipv4.tcp_syncookies = 1

net.ipv4.conf.default.accept_redirects = 0

net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.default.log_martians = 1


Legg merke til den spesielle skrivemåten med prefiks net.ivp4.conf.. osv.

Når man i stedet setter opp endringene på denne måten i denne konfigureringsfilen, så ser det ut som om de blir liggende "steady state" i stedet for å "flippe" fram og tilbake (Med feil verdi på det tidspunkt at nettverkskorene kjøres opp.)

Når det gjelder et par av parametrene net.ipv4.ip_forward og accept_source_route så kan det vel kanskje variere ut fra type av firewall hvordan disse bør stå.

Er fortsatt taknemmelig for alle videre uttestinger og tilbakemeldinger.

jacov -> Det vil være spesielt interressant å vite om "accept_source_route" vil få forskjellig effekt enten den settes fra /etc/sysctl.conf eller fra firewallscript.

Finner ikke filen /etc/sysctl.conf
Ved å kjøre kommandoen: sysctl -a får jeg listed ut (blandt annet linjene under)

net.ipv4.conf.eth2.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0


Mvh.
Verner

/etc/sysctl.conf

Husker ikke hvilken distro du sa det var.

Den er da her på Fedora 2

Det som kan væere et problem (men det er ikke sikkert at det er et problem) det er at når maskinen går ned og startes opp så setter den systemvariablene til andre verdier enn det som framgår av scriptet (For Fedora Core 2).

Etter at scriptet har kjørt så vil man kunne lese de riktige verdiene.

Problemstillingen er: Hva skjer med den igangkjøring av nettverk mm dersom systemvariablene har en feil vedi i oppstartfasen for så å få en riktig verdi i en senere fase i oppstartsekvensen (når firewall script kjøres.)

Det var ikke Redhat eller Fedora du brukte ??

(Kan være at et slikt script gir permanente endringer på andre distribusjoner)

Forslag til kontroll: Boot maskinen uten firewallscript og se om systemvariablene har forandret seg eller om de ligger der med permanente endringer. (Selvfølgelig bare hvis du ønsker det selv for å være på den maks sikre side. På Fedora 2 så er det helt sikkert at verdiene "flippes" fram og tilbake med mindre man endrer i /etc/sysctl.conf men hos andre distros så kan det jo fungere helt annerledes)

kjører slackware 10.
tester det i kveld.

OK kan tenkes at dette med sysctl.conf og systemverdier som under visse forhold skifter skifter fram og tilbake er en spesifik Redhat/Fedora sak.

Mener ellers at den firewallen du holder på å få ferdig er mer avansert enn mye annet ..

Finnes problemstillingen med at systemvariablene kan "flippe" frem og tilbake også for Slackware ? (Egentlig ikke mer viktig enn det som du synes selv. Bare litt nyskjerrig og vurderer jo sånn sett hele tiden å prøve ut nye distribusjoner.)

Har ikke fått sett på det ennå.
Testet tidligere ut check point fw-1. Denne hadde mulighet for å definere grupper av host, nett, tjenester. Vet du om det lar seg gjøre med iptables?
Kunne f.eks tenkt meg at lan+wlan var en gruppe siden de skal ha samme regelverk.

Tja, si det .. Kan du spesifisere litt mer hvordan dette fungerte med check point, for eksempel med ett eller to praktiske eksempler.

Når det gjelder lan wlan, mener du da lan og wireless lan ? Kjører ikke disse allerede ut fra sitt eget nettverkskort på firewall som har sine egne firewalling regler både inn og ut ? (Missforstår jeg spørsmålet ?)