16. marts 2004 - 14:45Der er
25 kommentarer og 1 løsning
Iptables, udgående trafik?
Hey,
jeg har følgende iptables sat op... problemet er bare at alle req der kommer inde fra ex. hvis jeg skal hente http:://example.com/index.html så kan jeg ikke connecte... Jeg vil gerne have ALT spæret ud af tli undtagen de få ting som ejg selv vælger (ftp, http, nntp)
nogen der kan være behjælpelige, jeg har noget i scriptet (som en ven har hjulpet med) der skulle kunne gøre det men min Debian fortæller:
shell > sh iptables.sh iptables: No chain/target/match by that name iptables: No chain/target/match by that name
# tillad alt lokal trafik iptables -A INPUT -i lo -j ACCEPT
# vi tillader trafik p\xe5 forbindelser, der er blevet oprettet iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT # og vi tillader nye forbindelser, hvis de kommer indefra iptables -A block -m state --state NEW -i $EXT_NETKORT -j ACCEPT
iptables -A INPUT -p tcp -s 12.96.160.0/24 -j ACCEPT # SCANNER FRA servermatrix.com iptables -A INPUT -p udp -s 12.96.160.0/24 -j ACCEPT # SCANNER FRA servermatrix.com
# spær for adgang til visse services #iptables -A INPUT -p tcp -d $INT_IP --dport smtp -j DROP #iptables -A INPUT -p udp -d $INT_IP --dport syslog -j DROP #iptables -A INPUT -p tcp -d $INT_IP --dport swat -j DROP #iptables -A INPUT -p tcp -d $INT_IP --dport printer -j DROP
# blockkæden kobles på INPUT og FORWARD kæderne # Det betyder at der er adgang til alt indefra (på nær det, der blev # droppet lige før, og til ALT udaf, men ingenting udefraiptables -A INPUT -j block iptables -A FORWARD -j block
Med kunstig intelligens skaber HP’s nye OmniBook X 14 en unik og skræddersyet brugeroplevelse målrettet dem, der ønsker høj ydeevne og intelligente funktioner
Jeg er ikke iptables ekspert, men der ligger en udmærket script generator her: http://iptables.1go.dk/
Den burde kunne give dig et skelet du kan arbejde videre på.. Mht. den konkrete fejl ved jeg ikke lige hvad der er galt, men hvorfor er det nødvendigt at lave den nye chain ?
Fordi at hvis der endelig skulle komme noget ind i serveren, så vil der være smart at have lukket for alt, der kan sendes ud, som ikke skal kunne komme ud...
Jeg går ud fra at det er iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT som giver fejlbeskeden no table by that name. Det er de 2 linjer hvor der bliver lagt noget til block table som skulle forestille at lave stateful inspection, - dvs tillade svar traffik fra servere som du selv har bedt om at komme i kontakt med. Det der sker for dig er at du kontakter example.com og denne website svarer rigtig nok, men svaret bliver fanget i din INPUT chain hvor default policy er BLOCK og du registrerer aldrig at du faktisk har fået et svar fordi det havner direkte i /dev/null. Med stateful inspection skulle den automatisk og dynamisk kunne gribe åbne for den slags svar pakker, men det gøre den ikke i det her tilfælde fordi dit "block" table ikke eksisterer og ikke er rigtigt defineret i scriptet.
Det er lidt irriterende at skulle vende tilbage til et forholdsvist komplekst spørgsmål en måned efter at man lagde første svar, men ok.
Jeg har afprøvet dit script nu. Jeg får ikke de to fejl ud af det som du får. Jeg skal ikke kunne sige hvorfor de opstår ud over at der kan mangle en kæde ved navnet block. Skriv iptables -L -n for at se om du har en block kæde. Til trods for at scriptet ikke spyttede fejl ud fra bash så virker det ikke. Grunden er følgende: sunbox:~ # iptables -L -n Chain INPUT (policy DROP) target prot opt source destination ACCEPT icmp -- 12.96.160.0/24 0.0.0.0/0 icmp type 8 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 12.96.160.0/24 0.0.0.0/0 ACCEPT udp -- 12.96.160.0/24 0.0.0.0/0 ACCEPT udp -- 0.0.0.0/0 192.168.0.89 udp dpt:20 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:20 ACCEPT udp -- 0.0.0.0/0 192.168.0.89 udp dpt:21 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:21 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:25 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:110 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:143 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:220 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:585 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:993 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:3306 ACCEPT tcp -- 0.0.0.0/0 192.168.0.89 tcp dpt:10000
Chain block (1 references) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
Dette er de nuværende iptables regler. De bliver evalueret oppefra og ned. Som du kan se kommer der en pakke ind i INPUT, dvs inbound, og så går den igennem alle de regler, og havner til sidst med default policy som er DROP i INPUT chain. Ikke så fedt.. Den når aldrig at evaluere det der stateful tingel-tangel i block chain. Derfor er løsningen at tvinge en pakke over i block chain før den når bunden af INPUT chain og dermed bliver sendt til bit bucket. Det gøres ved at smide disse to linjer ind i scriptet:
iptables -A INPUT -p tcp -j block iptables -A OUTPUT -p tcp -j block nederst i sektionen tillad adgang til visse services udefra.
Sammenlign så output af iptables -L -n med før.
Jeg ved ikke hvorfor den smider fejl i hovedet af dig. Du kan prøve at indsætte sådan noget som: echo "1" iptables blah blah echo "2" mellem hver linje. Du kan nemlig rimelig nemt lokalisere præcist hvilke linjer det drejer sig om med den slags debug output.
NB. Jeg skriver dette indlæg med scriptet aktiveret med ændringerne. Så hvis det kommer igennem så må det jo virke :)
Strych9, undskyld det kommet så sent men havde ikke fået en "reminder" pr mail så det gik lige i glemmeren.
men den giver mig følgende, nu:
> iptables -t nat -F -iptables v1.2.9: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) -Perhaps iptables or your kernel needs to be upgraded. > iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT -iptables: No chain/target/match by that name > iptables -A block -m state --state NEW -i $EXT_NETKORT -j ACCEPT -iptables: No chain/target/match by that name
det er efter jeg har indsat de to linier du har skrevet. Kan stadig ikek få adgang til ting udefra.
ok, nu hvor den første fejl kommer med så ved jeg godt hvorfor det ikke virker.
Gør følgende:
Kør scriptet en gang skriv lsmod Følgende moduler skal være loadet: ipt_state, iptable_nat, ip_conntrack, iptable_filter, ip_tables skriv modprobe navn-på-moduler-der-mangler
Mulighed 1: modprobe virker tilføj disse linjer i toppen af script iptables -F modprobe navn-på-moduler-der-mangler
Mulighed 2: modprobe virker ikke Se om depmod -a får modprobe til at virke hvis ikke så skal du til at lave en ny kernel, for så mangler du simpelthen den funktion i kernel som kan få nat og stateful inspection til at virke. Den del af iptables der er i kernel hedder "Netfilter" og der er en option der hedder nat og en der hedder connection tracking. Dem skal du have med. Hvis du compilerer dem som moduler så husk depmod -a inden du forsøger igen (den genopbygger modules.dep i /lib/modules/´uname -a´/ - intern dependency information for kernel moduler).
Det giver mig dette, og du har ret modulerne er ikke installeret! > lsmod Module Size Used by Not tainted iptable_filter 1728 1 (autoclean) ip_tables 10400 1 [iptable_filter] 8139too 14112 1 mii 1008 0 [8139too] > modprobe ip_conntrack modprobe: Can't locate module ip_conntrack > modprobe iptable_nat modprobe: Can't locate module iptable_nat > modprobe ipt_state modprobe: Can't locate module ipt_state
Altså modprobe er på maskinen, men kan ikke finde modulerne? Jeg har så gået til mulihed 2:
> depmod -a depmod: *** Unresolved symbols in /lib/modules/2.4.19-ac4/kernel/drivers/media/radio/miropcm20.o
men giver mig dette?
Skal jeg kompilere en ny kernel? Isåfald hvilke fald grupper skal jeg passe på? Jeg har ikke adgang til serveren fysisk, så skal helst ikke have fat i supporten hos min host mere end højst nødvendigt.
Når jeg kompilere en ny kernel, vil indstillingerne så som default indeholde det som min nuværende kernel er sat op til, så jeg skal ændre nogle få ting?
>Når jeg kompilere en ny kernel, vil indstillingerne så som >default indeholde det som min nuværende kernel er sat op til, > så jeg skal ændre nogle få ting?
Nope. Det er helt forfra, med mindre du selv har lavet den nuværende kernel manuelt.
Hvis du er nervøs for sammenbrud så gør dette. Find de sources som har lavet din nuværende kernel. Det SKAL være det samme source tree. Dvs der må være en debian pakke der hedder noget med 2.4.19-ac4 sources.
Så kan du springe skridtet hvor du installerer kernel over, og i stedet gøre følgende: make menuconfig (og få Netfilter nat osv med, som moduler!) make dep make make modules make modules_install depmod -a
og så skulle det virke. Du behøver ikke engang at genstarte.
Man kan sige at hvis den installerer modulerne i denne folder /lib/modules/2.4.19-ac4/ så er det sikkert i orden. Læg mærke til hvad du ellers har i /lib/modules inden du går igang.
Men modutils (modprobe/insmod/depmod) skal nok brokke sig hvis det ikke er det rigtige source træ. I værste fald kommer du bare til at skifte kernel ud også.
Ja der er meget muligt at den kernel version er for gammel til at have compile fixes for gcc 3.33 Lidt overraskende at du har en så ny gcc på en debian. Plejer at være tudsegamle pakker :) Hvis du ikke vil nedgradere gcc og muligvis også glibc (hovedpine!), så må du simpelthen have en nyere kernel som feks 2.4.26 og så kommer du desværre ikke om ved at skifte hele sættet af kernel + moduler ud og genstarte maskinen.
Tjae, jeg har sat unstable i min sources list så det er nok derfor jeg har så ny en gcc.
hvordan vil jeg kunne afinstallere og så sikre mig at jeg får en ældre version installeret istedet for, nu vil den jo så bare installere den nyeste?
Jeg prøvede at få installeret ny kernel, men det var totalt rodet at finde rundt og der kom forskellige fejlmeddelelser og så rettede man nogle ting til og så var der noget andet der ikke virkede... frustrerende men man bliver da lidt klogere.
Nu ligger det sådan at gcc og glibc hænger sammen som ærtehalm i en linux installation. De skal compiles og linkes mod hinanden og der er en masse kompliceret crap med rekursive dependencies osv. Sagen er at hvis du nedgraderer glibc, så vil alle programmer som du har compileret siden du opdaterede den ikke længere virke! De skal linkes om, og du risikerer at se din installation lide en langsom død. Med disse to komplekse forhold så er det faktisk bedst at lade være..
Jeg vil anbefale at du holder dig til at installere en 2.4.26 kernel på den. Det er nemmere.
Der er iøvrigt en fejl i det script kan jeg se nu, men det kan vi vende tilbage til når du engang har fået modulerne i orden..
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
