Det finnes en rekke brannmurkonfigurasjonsløsninger på Linux, men mange av dem er egentlig bare iptables-grensesnitt, og noen er ikke helt vellykkede. I prinsippet er det ikke ille når du raskt kan sette opp en brannmur, men når du forstår iptables kan du gjøre det raskere og mer subtilt. Tweaking iptables er vanligvis ikke tilgjengelig for grensesnitt.
La oss komme i gang. La oss starte enkelt, og så vil vi komplisere konfigurasjonen. Det er allerede en artikkel på siden om autoloading av iptables-regler, så vi vil ikke vurdere innlastingsregler nå, men vil fokusere på selve reglene. Brannmuren er alltid konfigurert under root-kontoen.
Nettverkstilkoblingsscenarier
Før du setter opp en brannmur, er det viktig å ha en nøyaktig ide om hvilke nettverkstilkoblinger og hvordan som bør etableres under systemdrift, slik at alle tjenester kan fungere normalt. Jo mer nøyaktig bildet vi har av driften av nettverkstjenester, både som kjører på vår server og på andre servere, jo mer finjustert kan systemet være. Derfor er det tilrådelig å alltid først beskrive scenariene for hvordan alt skal fungere, og først deretter begynne å konfigurere brannmuren. Skriptet kan skrives i et hvilket som helst tekstredigeringsprogram. Først beskriver vi alle eksterne tjenester som serveren jobber med, og deretter alle tjenestene som fungerer på serveren. Hvorfor er det nødvendig? For å nøyaktig representere arbeidsprosessen, uten å fordype seg i den tekniske delen. Etter å ha skrevet det mest nøyaktige skriptet, kan du begynne å sette opp brannmuren. Beskrivelsen i skriptet skal se omtrent slik ut:
1) Alle brukere kan se nettstedet. Som standard er nettstedet på russisk.
2) Hvis brukere kom fra adresser<список-адресов-или-маска-подсети>, så skal de vises siden på ukrainsk. I vårt eksempel vil dette for eksempel være en nettbutikk med ett domenenavn, vist på russisk eller ukrainsk, og som selger sitt eget sett for Russland og Ukraina. Vi vil ganske enkelt ha to nettsteder, en på russisk, den andre på ukrainsk, og adressen som klienten kom fra vil avgjøre hvilket nettsted han vil gå til. Eksemplet er hentet fra hodet, i praksis løses selvfølgelig slike spørsmål annerledes. Du kan også forhindre visning av nettstedet fra kinesiske adresser på grunn av konstant spam i kinesiske kommentarer.
3) Post skal være tilgjengelig fra kontoret, den skal ikke være tilgjengelig fra andre steder.
4) Det skal være mulig å koble til VPN fra utsiden
5) Vi kan bare bruke noen få DNS-servere som vi stoler på. Alle andre DNS-servere må være utilgjengelige
6) …..
Etc. Jeg tror det er nok for et enkelt eksempel. Poenget er å definere bildet av nettverksinteraksjon så nøyaktig som mulig. Ethvert skript har bare ett mål - å formalisere interaksjon med brukere og tjenester før det kompileres beskrivelser av tilkoblinger, inkludert port, protokoll, kildeadresse, destinasjonsadresse for hver tilkobling.
Sette opp iptables: Den enkleste konfigurasjonen
Hvis vi snakker om kampservere, kan brannmurinnstillingene på to servere variere sterkt, avhengig av oppgavene disse serverne utfører. Derfor vil jeg prøve å beskrive de generelle prinsippene som kan brukes når du setter opp en brannmur for eventuelle servere. Dette er bare en base for ytterligere tilpasning.
Først av alt må du fjerne de innlastede reglene:
iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD
INNPUT, OUTPUT, FORWARD - dette er de tre hovedkjedene som pakker går langs, innkommende, utgående og går fra grensesnitt til grensesnitt.
Etter det må du angi standardpolicyen. Det er bare to av dem - ACCEPT og DROP, godta pakker eller ikke. For en kampserver bør du alltid velge DROP, og deretter åpne alt som er nødvendig og ikke mer.
For å sette slike retningslinjer må du først tillate tilkoblinger via SSH, vi vil anta at vi ikke endret standardporten (som vanligvis bør gjøres på kampservere umiddelbart etter installasjon av SSH-serveren).
Iptables -t filter -A INPUT -p tcp -m tcp --dport 22 -j GODKJENNER
Og etter det kan du allerede begynne å endre standardpolicyene:
iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP
For OUTPUT-kjeden, for nå, kan du la standardpolicyen ACCEPT, som tillater utgående tilkoblinger, du kan bytte til den etter å ha konfigurert INPUT-kjeden, når vi nekter innkommende tilkoblinger. På mange servere er det nok å sette opp INPUT-kjeden riktig, men vi skal se på å sette OUTPUT-kjeden senere for en strammere konfigurasjon.
Så. For øyeblikket har vi kun SSH-serverporten åpen for innkommende tilkoblinger; tilkoblinger vil ikke gå gjennom til alle andre porter. Nå må du legge til tilkoblingsgodkjenning til portene til andre tjenester, hvis de kjører på serveren din.
Iptables -t filter -A INPUT -p tcp -m tcp --dport 25 -j GODKJENNER
DNS (vanligvis er det tilstrekkelig å tillate UDP, men TCP kan også legges til):
Iptables -t filter -A INPUT -p udp -m udp --dport 53 -j GODKJENNER
Iptables -t filter -A INPUT -p tcp -m tcp --dport 80 -j GODKJENNER
Iptables -t filter -A INPUT -p tcp -m tcp --dport 110 -j GODKJENNER
Iptables -t filter -A INPUT -p tcp -m tcp --dport 443 -j GODKJENNER
Men det er ikke alt. Porter er åpne, tjenester er tilgjengelige fra utsiden, men post fungerer ikke og domenenavn løser seg ikke. Faktum er at når du spør etter DNS-servere, sendes spørringen fra en vilkårlig ledig port blant de uprivilegerte, akkurat som en tilkobling til en annen e-postserver. Og disse tjenestene sender svaret til samme port. Og denne havnen, som du forstår, er stengt for oss. Vi kan åpne denne porten, men vi vet ikke hvilken port den utgående tilkoblingen kommer fra. Derfor kan vi gjøre det enkleste mulig - tillate tilkoblinger fra spesifikke porter på den eksterne datamaskinen:
Iptables -t filter -A INPUT -p tcp -m tcp --sport 25 -j GODKJENNER
Iptables -t filter -A INPUT -p udp -m udp --sport 53 -j GODKJENNER
Disse to reglene tillater innkommende tilkoblinger fra portene 25/tcp og 53/udp, så når pakker ankommer fra disse portene ved hjelp av riktig protokoll, vil de bli akseptert. Hvis du planlegger å oppdatere systemet, programvaren eller installere pakker som er nødvendige for arbeidet, må du tillate tilkoblinger fra port 80 på eksterne maskiner.
Nå har vi den enkleste iptables-konfigurasjonen klar.
Etter å ha lagt reglene til tabellene, må du lagre dem. For å gjøre dette kan du bruke for eksempel et script.
Håndtering av tilkoblingskilder
Gå videre. vi trenger en tilkobling på visse porter, ikke med hele Internett, men med visse maskiner, med visse IP-adresser. Derfor kan vi komplisere reglene litt ved å legge til adressen til pakkekilden til dem.
Iptables -t filter -A INPUT -s 123.123.123.123 -p tcp -m tcp --dport 22 -j GODKJENNER
Denne regelen lar deg motta pakker på port 22 via TCP kun fra kilden med adressen 123.123.123.123, dette indikeres av "-s" parameteren (kilde). På denne måten kan du begrense tilkoblinger til serveren via SSH til én spesifikk IP-adresse, eller til et spesifikt subnett hvis du spesifiserer en subnettmaske som tilkoblinger er tillatt fra i stedet for en spesifikk IP-adresse.
Hvis du alltid bruker samme e-postgateway som serveren din sender e-post gjennom, så kan du for eksempel begrense tilkoblinger fra port 25/tcp ved å spesifisere denne gatewayen som kilde.
Regler for et spesifikt nettverksgrensesnitt eller IP-adresse
En server kan ha flere nettverksgrensesnitt. Vanligvis er det minst to av dem - det eksterne nettverket og det såkalte loopback-grensesnittet 127.0.0.1, som ikke kan nås fra utsiden hvis det ikke er tilsvarende pakkevideresending. Du kan også ha minst én annen IP-adresse delt med nettverksgrensesnittaliaset, eller et annet fysisk nettverksgrensesnitt. Og visse tjenester kan kjøre på hver IP-adresse eller nettverksgrensesnitt. For eksempel på en webserver Apache, og på den andre domenenavntjenesteserveren bind9. Og når du tillater tilkoblinger til en spesifikk port uten å spesifisere dette nettverksgrensesnittet, åpner du tilgang til denne porten på alle grensesnitt. Derfor er det to måter å begrense omfanget av en tillatelse.
Den første måten er å spesifisere IP-adressen som tilgang skal tillates for.
Iptables -t filter -A INPUT -d 234.234.234.234 -p tcp -m tcp --dport 22 -j GODKJENNER
Dette eksemplet viser hvordan en destinasjonsadresse kan brukes i en iptables-regel. I dette tilfellet kan du også bruke kildeadressen:
Iptables -t filter -A INPUT -s 123.123.123.123 -d 234.234.234.234 -p tcp -m tcp --dport 22 -j GODKJENNER
I dette eksemplet begrenser vi allerede tilgang til to adresser, som lar deg få tilgang til serveren på 234.234.234.234 via SSH fra adressen 123.123.123.123, du vil ikke kunne få tilgang fra andre adresser.
Den andre måten er å spesifisere navnet på nettverksgrensesnittet. Denne metoden kan også brukes når den eksterne adressen kan endres. Hvis adressen på nettverksgrensesnittet endres, mister du tilgangen til serveren med det forrige alternativet. Grensesnittnavnet er spesifisert som følger:
Iptables -t filter -A INPUT -i eth0 -s 123.123.123.123 -p tcp -m tcp --dport 22 -j GODKJENNER
Dette alternativet tillater SSH-tilgang på eth0-nettverksgrensesnittet, det vil ikke være noen SSH-tilgang på andre nettverksgrensesnitt.
Alt vi nettopp har dekket er bare begynnelsen, neste del vil fortsette ...
Velkommen alle sammen! I fortsettelsen publiserer jeg denne praktiske artikkelen om Linux nettverksfilter. I artikkelen vil jeg vurdere typiske eksempler på implementering av iptables-regler på Linux, samt vurdere måter lagrer den opprettede iptables-konfigurasjonen.
Konfigurere nettfilter/iptables for en arbeidsstasjon
La oss starte med en elementær oppgave - Linux brannmurimplementering på skrivebordet. I de fleste tilfeller, på desktop Linux-distribusjoner, er det ikke noe presserende behov for å bruke en brannmur, fordi. slike distribusjoner kjører ingen tjenester som lytter på nettverksporter, men av hensyn til forebygging vil det ikke være overflødig å organisere beskyttelse. For kjernen er heller ikke immun mot hull. Så, vi har Linux, med eth0, det spiller ingen rolle via DHCP eller statisk...
For innstillinger brannmur Jeg prøver å overholde følgende retningslinjer: forby alt, og deretter hva som må tillates. Så la oss gjøre det i dette tilfellet. Hvis du har et nyinstallert system og du ikke har prøvd å sette opp et nettverksfilter på det, vil reglene se omtrent slik ut:
Nettfilter:~# iptables -L Kjede INPUT (policy ACCEPT) mål prot opt kilde destinasjon Chain FORWARD (policy ACCEPT) mål prot opt kilde destinasjon Kjede OUTPUT (policy ACCEPT) mål prot opt kilde destinasjon
Dette betyr at standardpolicyen for filtrere tabeller i alle kjeder AKSEPTERER og det er ingen andre regler som forbyr noe. Så la oss først forby ALT og pakker(ikke prøv å gjøre dette eksternt - du vil umiddelbart miste tilgangen):
Nettfilter:~# iptables -P INPUT DROP netfilter:~# iptables -P OUTPUT DROP netfilter:~# iptables -P FORWARD DROP
Med disse kommandoene setter vi MISTE misligholde. Dette betyr at enhver pakke som ikke eksplisitt har en regel som tillater det, blir automatisk droppet. Siden vi ikke har satt noen regler ennå, vil alle pakker som kommer til datamaskinen din bli avvist, så vel som de du prøver å sende til nettverket. Som en demonstrasjon kan du prøve å pinge datamaskinen din gjennom loopback-grensesnittet:
Nettfilter:~# ping -c2 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) byte med data. ping: sendmsg: Operasjon ikke tillatt ping: sendmsg: Operasjon ikke tillatt --- localhost ping-statistikk --- 2 pakker overført, 0 mottatt, 100 % pakketap, tid 1004ms
Faktisk er dette et helt ikke-fungerende nettverk og dette er ikke veldig bra, fordi. noen demoner bruker et loopback-grensesnitt for å utveksle med hverandre, som, etter handlingene som er utført, ikke lenger fungerer. Dette kan forstyrre driften av slike tjenester. Derfor er det først og fremst viktig tillate overføring av pakker gjennom innkommende loopback-grensesnitt og utgående loopback-grensesnitt i INPUT-tabellene(for å kunne motta sendte pakker) og PRODUKSJON(for å kunne sende pakker) hhv. Så sørg for å gjøre:
netfilter:~# iptables -A INPUT -i lo -j ACCEPT netfilter:~# iptables -A OUTPUT -o lo -j ACCEPT
Etter det vil ping til localhost fungere:
Nettfilter:~# ping -c1 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) byte med data. 64 byte fra 127.0.0.1 (127.0.0.1): icmp_seq=1 ttl=64 time=0.116 ms --- 127.0.0.1 ping-statistikk --- 1 pakker sendt, 1 mottatt, 0 % pakketap, tid 116ms rtt min/ avg/max/mdev = 0,116/0,116/0,116/0,116 ms
Hvis tilnærmingen til å sette opp brannmuren ikke er veldig fanatisk, kan du aktivere ICMP-protokollen:
netfilter:~# iptables -A INPUT -p icmp -j GODKJENNER nettfilter:~# iptables -A OUTPUT -p icmp -j GODKJENNER
Det vil være tryggere å spesifisere følgende lignende iptables-kommando:
Netfilter:~# iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT netfilter:~# iptables -A OUTPUT -p icmp -j GODTAR
Denne kommandoen lar ICMP-ekkoforespørsels- og ekkosvarpakketypene forbedre sikkerheten.
Å vite at datamaskinen vår ikke er infisert (er det slik?), og den etablerer bare sikre utgående tilkoblinger. Og også, å vite at sikre tilkoblinger er tilkoblinger fra den såkalte. ephemeral port range , som er satt av kjernen i filen /proc/sys/net/ipv4/ip_local_port_range, kan tillate utgående tilkoblinger fra disse sikre portene:
Nettfilter:~# cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 netfilter:~# iptables -A OUTPUT -p TCP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A OUTPUT -p UDP sport 32768:61000 -j GODTAR
Hvis du ikke er paranoid med å begrense utgående pakker, kan du begrense deg til én kommando iptables for å tillate alle utgående tilkoblinger på alle protokoller og porter:
Nettfilter:~# iptables -A OUTPUT -j ACCEPT netfilter:~# # eller bare sett standard policy til ACCEPT for OUTPUT kjeden netfilter:~# iptables -P OUTPUT ACCEPT
Videre, å vite at nettverkstilkoblinger i nettfilter har 4 tilstander ( NY,ETABLERTE,RELATERT ogUGYLDIG) og nye utgående tilkoblinger fra den lokale datamaskinen (med NEW-tilstanden) er tillatt i de to siste iptables-kommandoene, som allerede etablerte tilkoblinger og flere har tilstander ETABLERTE ogI SLEKT, følgelig, og også vite at de kommer til det lokale systemet gjennom , kan vi tillate bare de TCP- og UDP-pakkene som ble forespurt av lokale applikasjoner for å nå datamaskinen vår:
Netfilter:~# iptables -A INPUT -p TCP -m tilstand --state ETABLISTERT,RELATED -j GODKJENNER nettfilter:~# iptables -A INNPUT -p UDP -m tilstand --state ETABLERT,RELATERT -j GODTAR
Dette er faktisk alt! Hvis noen nettverkstjenester fortsatt kjører på skrivebordet, må du legge til de riktige reglene for innkommende og utgående tilkoblinger. For eksempel, for at ssh-serveren skal fungere, som mottar og sender forespørsler på TCP-port 22, må du legge til følgende iptables-regler:
Nettfilter:~# iptables -A INPUT -i eth0 -p TCP --dport 22 -j ACCEPT nettfilter:~# iptables -A OUTPUT -o eth0 -p TCP --sport 22 -j ACCEPT
De. for en hvilken som helst tjeneste, må du legge til én regel hver til INPUT- og OUTPUT-kjedene, som tillater henholdsvis mottak og sending av pakker ved å bruke denne porten for et spesifikt nettverksgrensesnitt (hvis grensesnittet ikke er spesifisert, vil det være tillatt å motta/sende pakker via et hvilket som helst grensesnitt).
Konfigurere nettfilter/iptables for å koble flere klienter til en enkelt tilkobling.
La oss nå se på vår Linux som en gateway for et lokalt nettverk til det eksterne Internett. La oss late som det grensesnitt eth0 er koblet til internett og har IP 198.166.0.200, og grensesnitt eth1 koblet til LAN og har IP 10.0.0.1. Som standard i Linux-kjernen videresende pakker gjennom FORWARD-kjeden(pakker som ikke er beregnet på det lokale systemet) er deaktivert. For å aktivere denne funksjonen må du sette verdien til 1 i filen :
Nettfilter:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Til videresending av pakker bevart etter omstart, er det nødvendig i filen /etc/sysctl.conf avkommenter (eller bare legg til) linjen net.ipv4.ip_forward=1.
Så vi har en ekstern adresse (198.166.0.200), i det lokale nettverket er det en rekke hypotetiske klienter som har og sender forespørsler til det eksterne nettverket. Hvis disse klientene sender forespørsler til det eksterne nettverket gjennom gatewayen "som den er", uten konvertering, vil den eksterne serveren ikke kunne svare på dem, fordi. returadressen vil være mottakeren fra det "lokale nettverket". For at denne ordningen skal fungere riktig, er det nødvendig å erstatte avsenderadressen med den eksterne adressen til Linux-gatewayen. Dette oppnås ved å (maskere) i , i .
Netfilter:~# iptables -A FORWARD -m conntrack --ctstate ETABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A FORWARD -m conntrack --ctstate NEW -i eth1 -s 10.0.0.1/24 -j ACCEPT netfilter: ~# iptables -P FORWARD DROP netfilter:~# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Så, i rekkefølge fra topp til bunn, tillater vi allerede etablerte tilkoblinger kjede FREM, filtertabell, så lar vi nye tilkoblinger etableres i kjede FREM, filtertabell, som kom fra eth1-grensesnittet og fra 10.0.0.1/24-nettverket. Alle andre pakker som går gjennom FREMOVER kjede- kast. Deretter utfører vi maskering (erstatning av pakkeavsenderadressen i overskriftene) av alle pakker som går ut fra eth0-grensesnittet.
Merk. Det er en generell anbefaling: bruk -j MASQUERADE-regelen for grensesnitt med en dynamisk oppnådd IP (for eksempel via DHCP fra leverandøren). For en statisk IP kan -j MASQUERADE erstattes med tilsvarende -j SNAT -to-source IP_interface_eth0. I tillegg er SNAT i stand til å "huske" etablerte tilkoblinger når grensesnittet er midlertidig utilgjengelig. Sammenligning av MASQUERADE og SNAT i tabellen:
I tillegg til reglene ovenfor, kan du også legge til regler for å filtrere pakker destinert for den lokale verten - som beskrevet i . Det vil si, legg til nekte og tillat regler for innkommende og utgående tilkoblinger:
Nettfilter:~# iptables -P INPUT DROP netfilter:~# iptables -P OUTPUT DROP netfilter:~# iptables -A INPUT -i lo -j ACCEPT netfilter:~# iptables -A OUTPUT -o lo -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT netfilter:~# iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT netfilter:~# iptables -A OUTPUT -p icmp -j ACCEPT netfilter:~# cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 netfilter:~# iptables -A OUTPUT -p TCP --sport 32768:61000 -j ACCEPT netfilter:~# iptables -A OUTPUT -p UDP sport 32768:61000 -j ACCEPT netfilter:~# iptables -A INPUT -p TCP -m state --state ETABLISHED,RELATED -j ACCEPT netfilter:~# iptables -A INPUT -p UDP -m state --state ETABLISHED,RELATED -j GODTAR
Som et resultat, hvis en av de lokale nettverksvertene, for eksempel 10.0.0.2, prøver å kontakte en av Internett-vertene, for eksempel 93.158.134.3 (ya.ru), med , vil kildeadressen deres erstattes med ekstern gateway-adresse i POSTROUTING-tabellkjeden nat, det vil si at utgående IP 10.0.0.2 vil bli erstattet med 198.166.0.200. Fra synspunktet til den eksterne verten (ya.ru), vil det se ut som om selve gatewayen kommuniserer direkte med den. Når den eksterne verten starter responsoverføringen av data, vil den adressere dem til gatewayen, det vil si 198.166.0.200. Ved gatewayen vil imidlertid destinasjonsadressen til disse pakkene bli erstattet med 10.0.0.2, hvoretter pakkene vil bli overført til den virkelige mottakeren på det lokale nettverket. For en slik invers transformasjon trenger ingen tilleggsregler spesifiseres - dette vil bli gjort av det samme MASQUERADE operasjon, som husker hvilken vert fra det lokale nettverket som sendte forespørselen og hvilken vert som må returnere det innkommende svaret.
Merk: helst stilltiende akseptert, før alle iptables-kommandoer klare kjeder som regler vil bli lagt til:
Nettfilter:~# iptables -F CHAIN_NAME
Gir tilgang til tjenester på gatewayen
La oss anta at en bestemt tjeneste kjører på gatewayen vår, som må svare på forespørsler som kommer fra Internett. La oss si at det fungerer på en eller annen TCP-port nn. For å gi tilgang til denne tjenesten er det nødvendig å modifisere filtertabellen i INPUT-kjeden (for å kunne motta nettverkspakker adressert til den lokale tjenesten) og filtertabellen i OUTPUT-kjeden (for å tillate svar på innkommende forespørsler).
Så vi har, som maskerer (erstatter avsenderens adresse med feil) pakker til det eksterne nettverket. Og lar deg godta alle etablerte tilkoblinger. Å gi tilgang til tjenesten vil bli utført ved å bruke følgende tillatelsesregler:
Nettfilter:~# iptables -A INPUT -p TCP --dport nn -j GODKJENNER nettfilter:~# iptables -A OUTPUT -p TCP --sport nn -j ACCEPT
Disse reglene tillater innkommende tcp-tilkoblinger til port nn og utgående tcp-tilkoblinger fra port nn. I tillegg kan du legge til ytterligere restriktive parametere, for eksempel tillate innkommende tilkoblinger kun fra det eksterne grensesnittet eth0 (nøkkel -jeg eth0) etc.
Gir tilgang til tjenester på det lokale nettverket
La oss anta at det i vårt lokale nettverk er en vert med IP X.Y.Z.1, som skal svare på nettverksforespørsler fra det eksterne nettverket på TCP-port xxx. For å få riktig respons fra tjenesten fra det lokale nettverket når en ekstern klient får tilgang til den eksterne IP-en på port xxx, er det nødvendig å sende forespørsler som kommer til den eksterne IP-porten xxx til den tilsvarende verten i det lokale nettverket. Dette oppnås ved å endre destinasjonsadressen i en pakke som ankommer den angitte porten. Denne handlingen kalles DNAT og brukes i PREROUTING-kjeden i nat-tabellen. Og tillat også passasje av disse pakkene i FORWARD-kjeden i filtertabellen.
Igjen, la oss gå nedover stien. Så vi har, som maskerer (erstatter avsenderens adresse med feil) pakker til det eksterne nettverket. Og lar deg godta alle etablerte tilkoblinger. Å gi tilgang til tjenesten vil bli utført ved å bruke følgende tillatelsesregler:
Netfilter:~# iptables -t nat -A PREROUTING -p tcp -d 198.166.0.200 --dport xxx -j DNAT --to-destination XYZ1 netfilter:~# iptables -A FORWARD -i eth0 -p tcp -d XYZ 1 --dport xxx -j GODTAR
Lagrer de angitte reglene ved omstart
Alle regler som er lagt inn i konsollen - etter omstart vil operativsystemet bli tilbakestilt til sin opprinnelige tilstand (les - slettet). For å lagre alle angitte iptables-kommandoer, det er flere måter. For eksempel er en av dem å sette alle brannmurregler i initialiseringsfilen. Men denne metoden har en betydelig ulempe: hele tidsperioden fra starten av nettverksundersystemet til starten av den siste tjenesten og deretter rc.local-skriptet fra SystemV, vil operativsystemet ikke være beskyttet. Tenk deg en situasjon, for eksempel hvis en tjeneste (for eksempel NFS) starter sist og når den starter, oppstår det en slags feil før rc.local-skriptet startes. Følgelig starter aldri rc.local, og systemet vårt blir til ett stort hull.
Så den beste ideen ville vært initialisere netfilter/iptables-regler mens du laster. Debian har et flott verktøy for dette - katalogen /etc/network/if-up.d/, der du kan legge inn skript som kjører når nettverket starter. Det er også kommandoer iptables-lagre Og iptables gjenoppretting, som lagrer dump netfilterreglene fra kjernen til henholdsvis og gjenoppretter reglene til kjernen.
Så, iptables lagringsalgoritme er noe sånt som dette:
- Tilpass brannmuren til dine behov ved å bruke
- lag en dump av de opprettede reglene ved å bruke kommandoen iptables-save > /etc/iptables.rules
- skape import skript dumpen som ble opprettet ved nettverksoppstart (i katalogen /etc/network/if-up.d/), og ikke glem å gjøre den kjørbar:
Dump av regler mottatt iptables-save-kommandoen har et tekstformat, henholdsvis egnet for redigering. Utgangssyntaksen til iptables-save-kommandoen er som følger:
# Generert av iptables-save v1.4.5 på Sat Des 24 22:35:13 2011 *filter:INPUT ACCEPT :FORWARD ACCEPT ....... # comment -A INNPUT -i lo -j ACCEPT -A INNPUT ! -i lo -d 127.0.0.0/8 -j REJECT ........... -A FORWARD -j REJECT COMMIT # Fullført lørdag 24. desember 22:35:13 2011 # Generert av iptables-save v1 .4.5 på lørdag 24. desember 22:35:13 2011 *rå ...... FORBINDELSE
Linjer som begynner med # - kommentarer, linjer på * er navnet på tabellene, mellom tabellnavnet og ordet BEGÅ inneholder parametere som sendes til iptables-kommandoen. COMMIT parameter- indikerer fullføringen av parametrene for tabellen ovenfor. Linjer som starter med et kolon definerer kjeder som inneholder denne tabellen i formatet:
:kjedepolicy [pakker:bytes]
hvor kjede- kjedenavn, politikk- standard kjedepolicy for denne tabellen, og deretter tellerne for pakker og byte på tidspunktet kommandoen ble utført.
Hos RedHat iptables kommandolagringsfunksjoner utført ved start og stopp av nettverket, kjører filen /etc/sysconfig/iptables. Og administrasjonen av denne filen ligger hos iptables-demonen.
Som et annet alternativ for å lagre regler, kan du vurdere å bruke parameteren opp i fil /etc/nettverk/grensesnitt med et filargument som inneholder iptables-kommandoene som setter de nødvendige reglene.
Utfall
Det blir nok for i dag. Mer komplekse implementeringer av brannmuren, jeg vil definitivt bli publisert i de følgende artiklene.
Med vennlig hilsen Mc.Sim!
IPTables er et Linux-brannmuradministrasjonsverktøy. Det er et kraftig og hendig verktøy for og uønskede tilkoblinger. Hele prosessen er pakket inn i iptables-regler som kan redigeres og vises. Flere detaljer er gitt i artikkelen.
skapelseshistorie
Før IPTables på et Linux-system brukte IPFW-brannmuren, lånt fra BSD. Så, fra og med 2.4 Linux-kjernen, kom den med Netfilter-brannmuren og IPTables-verktøyet for å administrere den. I metodikken til arbeidet hennes ble alle aspekter bevart og litt utvidet funksjonelt.
Strukturen og strukturen til IPTables
Når en pakke kommer inn i brannmuren, går den gjennom flere kontroller. Dette kan være en kontrollsum eller en annen analyse på kjernenivå. Da er det på tide å gå gjennom PREROUTING-kjeden. Deretter sjekkes det i henhold til hvilken omdirigering til neste kjede som finner sted. Hvis pakken ikke har en adresse, som for eksempel i TCP, blir den dirigert til FORWARD-kjeden. I tilfeller der det er en spesifikk adresse, følger INPUT-kjeden, og deretter demonene eller tjenestene den er ment for. Responsen fra dem skal også gå gjennom flere kjeder, for eksempel OUTPUT. Det siste leddet i denne prosessen er POSTROUTING-kjeden.
Nå litt om kjeder. Hver av dem inneholder flere tabeller. Navnene deres kan gjentas, men dette påvirker ikke arbeidet på noen måte, siden de ikke henger sammen.
Tabellene inneholder igjen flere regler. Faktisk er en regel en viss betingelse som pakken som kontrolleres må overholde. Avhengig av utfallet utføres en viss handling på pakken.
Når den passerer gjennom alle stadier av nettverket, besøker pakken sekvensielt alle kjeder og sjekkes i hver for samsvar med betingelsen til en viss regel. Hvis tabellen ikke er generert av brukeren, blir standardhandlingen tatt, i utgangspunktet er det ACCEPT, som lar deg fortsette å gå videre, eller DROP, som stopper pakken.
De forhåndsinnstilte kjedene kommer i følgende kategorier:
- PREROUTING. Innledende behandling av alle innkommende pakker.
- INNGANG. Dette inkluderer de pakkene som er rettet direkte til den lokale datamaskinen.
- FRAMOVER. Brukes for "transitpakker" som følger rutetabellen.
- PRODUKSJON. Brukes til utgående pakker.
- POSTRUTING. Den siste fasen i passeringen av den utgående pakken til alle kjeder.
I tillegg til de innebygde kjedene kan brukere opprette eller slette sine egne.
Vise og administrere IPTables-regler
Som nevnt tidligere inneholder alle kjeder visse betingelser for pakker. IPTables-verktøyet brukes til å vise og administrere IPTables-regler. Hver enkelt regel er en linje med et sett med betingelser for pakker, samt handlinger på dem, avhengig av utfallet.
Formatet på kommandoen ser slik ut: iptables [-t navn på tabellen som skal behandles] kommando for å kalle [kriterier] [handling som skal utføres].
Alt som er vedlagt kan utelates. Hvis det er en tabellparameter, vil filteret bli brukt. For å bruke et spesifikt navn, må du legge til -t-bryteren. Den kalte kommandoen lar deg kalle den nødvendige handlingen, for eksempel legge til en IPTables-regel eller fjerne den. "Kriterier" spesifiserer parametrene som utvalget vil finne sted etter. Og i "handlingen" brukes handlingen som skal utføres hvis betingelsen er oppfylt.
Kommandoer for å lage og vise IPTables-regler
- Legg til (-A). Når du bruker kommandoen, spesifiserer du kjeden og tabellen du vil legge til den nødvendige regelen til. Verdien av laget er at det gjør det på slutten av hele listen.
- Slett (-D). Som navnet tilsier, sletter den regelen. Som parametere kan du spesifisere både det fulle navnet og numrene som er tildelt dem.
- Gi nytt navn til kjede (-E). Endrer navnet på kjeden. Kommandoen spesifiserer det gamle navnet, deretter det nye navnet.
- Skyll (-F). Fjerner absolutt alle reglene for et bestemt bord.
- Sett inn (-I). Denne kommandoen setter inn den nødvendige regelen på stedet angitt av nummeret.
- Liste(-L). Se Iptables-regler. Hvis ingen tabell er spesifisert, vil standardfilteret bli brukt.
- Politikk (-P). Standardpolicyen for den angitte kjeden brukes.
- Erstatt (-R). Endrer regelen under det angitte nummeret til det nødvendige.
- Slett kjede (-X). Denne kommandoen sletter alle opprettede kjeder. Bare de forhåndsinnstilte forblir.
- Null (-Z). Tilbakestiller tellerne for overførte data i den angitte kjeden.
Litt om alternativer for pakkevalg
De kan grovt deles inn i tre typer:
- Generelle kriterier. De kan spesifiseres for alle regler. De krever ikke tilkobling av spesielle utvidelser og moduler, og avhenger heller ikke av hvilken protokoll som skal brukes.
- Ikke generelle kriterier. De blir tilgjengelige ved bruk av de generelle kriteriene.
- Eksplisitt. For å bruke denne typen må du koble til spesielle plug-ins for nettfilter. I tillegg må -m-bryteren brukes i kommandoen.
Det er verdt å snakke litt om de ofte opptrådte parameterne som brukes i pakkeanalyse:
- Protokoll (-p). Indikerer protokoll.
- Kilde(-er). Denne parameteren spesifiserer IP-adressen til kilden som pakken kom fra. Det kan spesifiseres på flere måter. En bestemt vert, adresse eller et helt undernett.
- Destinasjon (-d). Destinasjonsadressen til pakken. Også, som den forrige, kan den beskrives på flere måter.
- I-grensesnitt (-i). Spesifiserer det innkommende grensesnittet til pakken. Brukes hovedsakelig for NAT eller på systemer med flere grensesnitt.
- Ut-grensesnitt (-o). utgående grensesnitt.
Noen få eksempler
For å se IPTables nat-regler? du må bruke kommandoen - "iptables -L -t nat". Finn ut den generelle statusen til brannmuren - "iptables -L -n -v". I tillegg lar denne kommandoen deg se IPTables-reglene som er tilgjengelige i hele systemet. Sett inn regelen på et bestemt sted i tabellen, for eksempel mellom første og andre linje - "iptables -I INPUT 2 -s 202.54.1.2 -j DROP". Se så om det ble lagt til - "iptables -L INPUT -n --line-numbers".
For å blokkere en spesifikk adresse, for eksempel 12.12.12.12 - "iptables -A INPUT -s 12.12.12.12 -j DROP".
Hjelp til iptables - "mann iptables". Hvis du trenger informasjon om en spesifikk kommando - "iptables -j DROP -h".
Endelig
Bruk IPTables-kommandoer med forsiktighet, da feilkonfigurasjon (uvitende) kan føre til nettverksfeil eller fullstendig feil. Derfor er det verdt å studere manualene og instruksjonene i detalj før du konfigurerer. I dyktige hender kan IPTables gjøres om til en pålitelig beskytter av nettverkstilkoblinger. Systemadministratorer bruker aktivt verktøyet til å opprette tilkoblinger isolert fra uautorisert tilgang.
En pålitelig brannmur er en av de viktigste aspektene ved å beskytte ethvert moderne operativsystem. De fleste Linux-distribusjoner inkluderer flere forskjellige brannmurverktøy. Denne guiden fokuserer på en av de mest populære - iptables.
Så iptables er en standard brannmur inkludert i de fleste Linux-distribusjoner som standard (nftables utvikles for å erstatte den). Faktisk er iptables et brukergrensesnitt for å administrere netfiltersystemet, som igjen administrerer Linux-nettverksstakken. iptables sammenligner hver innkommende pakke mot et sett med etablerte regler og bestemmer deretter hva de skal gjøre med den neste.
Det handlet om hvordan akkurat iptables fungerer. Denne artikkelen fokuserer på praktiske eksempler som viser hvordan du lager et grunnleggende sett med regler for en Ubuntu 14.04-server.
Grunnleggende iptables-kommandoer
Denne delen inneholder de grunnleggende kommandoene som du kan bruke til å lage et komplekst sett med regler og kontrollere iptables-grensesnittet generelt.
Huske: iptables-kommandoer må kjøres med root-privilegier. Dette betyr at du må gjøre ett av følgende:
- logg inn som root-bruker;
- bruk su eller sudo -i for å utvide rotskallet;
- start alle kommandoer med sudo (anbefalt måte i Ubuntu).
Denne veiledningen bruker det siste alternativet.
Så først må du se på listen over gjeldende iptables-regler. -L-flagget brukes til dette:
sudo iptables -L
Kjedeinngang (policy ACCEPT)
målprot opt-kildedestinasjon
Kjede OUTPUT (policy ACCEPT)
målprot opt-kildedestinasjon
Som du kan se, inneholder listen tre standardkjeder (INPUT, OUTPUT og FORWARD), hver med et standard policysett (for øyeblikket ACCEPT). Du kan også se kolonnenavnene. Men selve reglene er ikke inkludert i denne listen, siden Ubuntu ikke leveres med et sett med standardregler.
Med -S-flagget kan denne listen vises i et annet format som gjenspeiler kommandoene som trengs for å aktivere reglene og retningslinjene:
sudo iptables -S
-P INNGANG GODKJENT
-P FRAM GODKJENT
-P OUTPUT AKSEPTERT
For å replikere konfigurasjoner, er alt du trenger å gjøre å skrive sudo iptables på begynnelsen av hver resultatlinje. (Avhengig av konfigurasjonene dine, kan denne prosedyren være litt mer komplisert når du kobler til eksternt; hvis reglene som tillater gjeldende tilkobling ikke allerede er satt, bør du ikke angi DROP-policyen.)
For å tilbakestille gjeldende regler (hvis noen), skriv inn:
sudo iptables -F
Igjen, standardpolicyen er veldig viktig på dette tidspunktet fordi den ikke endres med den forrige kommandoen selv om alle regler er fjernet fra kjedene.
Før du tilbakestiller reglene for en ekstern tilkobling, må du sørge for at INPUT- og OUTPUT-kjedene har ACCEPT-policyen satt. Dette gjøres slik:
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -F
Når du har opprettet regler som tillater eksterne tilkoblinger, kan du angi DROP-policyen. Så la oss fortsette direkte til å lage regler.
Lage iptables-regler
Som nevnt ovenfor fokuserer denne veiledningen på å jobbe med INPUT-kjeden, siden den er ansvarlig for innkommende trafikk. Først må vi vurdere den allerede nevnte regelen - regelen som tillater den nåværende SSH-tilkoblingen.
Det ser slik ut:
sudo iptables -A INPUT -m conntrack --ctstate ETABLISHED,RELATED -j ACCEPT
Selvfølgelig kan det i begynnelsen virke utrolig komplisert; For å forstå denne regelen, gjør deg kjent med dens komponenter:
- -EN INNGANG: flagg -A legger til ( legge til) regel til slutten av kjeden. Denne delen av kommandoen forteller iptables å legge til regelen på slutten av INPUT-kjeden.
- -m conntrack: i tillegg til et sett med grunnleggende funksjoner, har iptables også et sett med utvidelser, eller moduler, som er ansvarlige for tilleggsfunksjonene til brannmuren. Denne delen av kommandoen sier at brukeren trenger tilgang til funksjonene til conntrack-modulen. Denne modulen lar deg bruke kommandoer som bestemmer hva du skal gjøre med en pakke basert på forholdet til tidligere tilkoblinger.
- --ctstat: en av kommandoene som er tilgjengelige når du kaller opp conntrack-modulen. Denne kommandoen lar deg spore forholdet mellom pakker og andre pakker som er sett tidligere. Den er satt til ETABLISHED (som aksepterer pakker som er en del av en eksisterende tilkobling) og RELATED (aksepterer pakker som er knyttet til en allerede etablert tilkobling). Det er denne delen av regelen som er ansvarlig for gjeldende SSH-sesjon.
- — jAKSEPTERER: spesifiserer handlingen (målet) som skal utføres på pakken som samsvarer med regelen. I dette tilfellet vil iptables godta pakker som oppfyller de tidligere kriteriene.
Denne regelen bør plasseres i begynnelsen for å sikre at allerede eksisterende tilkoblinger samsvarer med reglene, blir akseptert og forlater kjeden før de når DROP-reglene.
Ved å be om en liste over regler kan du se endringene:
sudo iptables -L
Kjedeinngang (policy ACCEPT)
målprot opt-kildedestinasjon
GODKJEN ALLE -- hvor som helst hvor som helst ctstate RELATED, ETABLERT
Kjede FRAM (policy GODKJENNER)
målprot opt-kildedestinasjon
Kjede OUTPUT (policy ACCEPT)
målprot opt-kildedestinasjon
Nå som du er kjent med den grunnleggende syntaksen, lag noen flere regler som godtar en tilkobling.
Å lage andre viktige forbindelser
Tidligere ble iptables instruert om ikke å droppe alle nåværende tilkoblinger, men også å akseptere alle tilkoblinger relatert til dem. Nå må du lage regler som godtar tilkoblinger som ikke oppfyller kriteriene ovenfor.
La to porter være åpne: SSH-porten (denne veiledningen bruker standardporten 22; hvis denne verdien er endret, sørg for å angi den nye verdien); la oss også anta at denne datamaskinen kjører en webserver på port 80 som standard (ikke legg til denne regelen hvis den ikke er det).
Så linjene som skal brukes til å lage slike regler ser slik ut:
sudo iptables -A INPUT -p tcp --dport 22 -j GODKJENNER
sudo iptables -A INPUT -p tcp --dport 80 -j GODTAR
Som du kan se, er de veldig like den første regelen; kanskje de har en enda enklere struktur. Nye alternativer:
- — stcp: Dette alternativet lar pakker som bruker TCP (en strømorientert protokoll som brukes av de fleste applikasjoner fordi den gir pålitelig kommunikasjon) passere.
- — dport: dette alternativet er tilgjengelig når du bruker flagget -p tcp. Den spesifiserer den innkommende porten som pakkens port må samsvare med. Den første regelen tillater TCP-pakker destinert for port 22, og den andre regelen godtar TCP-trafikk destinert for port 80.
Nå må vi lage en annen ACCEPT-regel for å sikre at serveren fungerer som den skal. Vanligvis kommuniserer tjenester ved å utveksle pakker; for å gjøre dette bruker de et loopback-nettverks pseudo-grensesnitt – den såkalte loopback-enheten, som dirigerer trafikk tilbake til kilden, og ikke til andre datamaskiner.
Det vil si at hvis tjeneste 1 trenger å etablere en forbindelse med tjeneste 2 som lytter etter forbindelser på port 4555, sender tjeneste 1 en pakke til port 4555 ved hjelp av en tilbakekoblingsenhet. Denne oppførselen bør tillates fordi det er en viktig betingelse for at mange programmer skal fungere riktig.
For å gjøre dette, legg til følgende regel:
sudo iptables -I INNPUT 1 -i lo -j GODTAR
Det er litt forskjellig fra de tidligere reglene; vurdere det mer detaljert:
- — JegINNGANG 1: -I-flagget forteller iptables å sette inn regelen. Dette flagget er forskjellig fra -A-flagget (som ganske enkelt legger til regelen på slutten av kjeden); den spesifiserer kjeden der regelen skal legges til og plasseringen av regelen i den. I dette tilfellet må regelen settes inn helt i begynnelsen av INPUT-kjeden, som et resultat av at alle reglene vil flytte en posisjon. Denne regelen bør plasseres i begynnelsen av kjeden, siden den er en av hovedreglene og ikke bør avhenge av de andre.
- — Jeglo: Denne regelkomponenten lar pakker som bruker lo-grensesnittet ("lo" er et annet navn for loopback-enheten) passere gjennom. Dette betyr at enhver pakke som bruker dette grensesnittet må aksepteres.
For å se gjeldende regler, bruk -S-flagget, fordi -L-flagget ikke viser noe informasjon (for eksempel grensesnittet som regelen er bundet til, som er veldig viktig i tilfellet med den siste regelen):
sudo iptables -S
-P INNGANG GODKJENT
-P FRAM GODKJENT
-P OUTPUT AKSEPTERT
-A INNGANG -i lo -j GODTAR
-A INPUT -m conntrack --ctstate RELATED,ETABLISHED -j ACCEPT
-A INNGANG -p tcp -m tcp --dport 22 -j GODKJENNER
-A INNGANG -p tcp -m tcp --dport 80 -j GODKJENNER
Opprette DROP-regler
Så for øyeblikket er det laget 4 regler som aksepterer pakker basert på visse kriterier. Men akkurat nå blokkerer ikke serveren noen andre pakker.
Hvis en pakke krysser INPUT-kjeden og ikke samsvarer med noen av de fire reglene, vil standardpolicyen (ACCEPT) bli utført, som på en eller annen måte vil akseptere pakken. Nå må det endres.
Dette kan gjøres på to måter, som har ganske betydelige forskjeller.
Den første måten er å redigere standardpolicyen til INPUT-kjeden; for denne typen:
sudo iptables -P INPUT DROP
Denne policyen vil overvåke og slippe alle pakker som ikke samsvarer med noen av INPUT-kjedereglene. En konsekvens av denne typen konstruksjon er at den vil slippe pakker selv etter at selve reglene har blitt droppet.
Selvfølgelig øker dette sikkerhetsnivået til serveren; Dette kan imidlertid få alvorlige konsekvenser hvis brukeren ikke har noen annen måte å koble seg til serveren på. Oftest tilbyr vertsleverandører en nettkonsoll for å koble til serveren i tilfelle slike problemer. En slik konsoll fungerer som en virtuell lokal tilkobling, så iptables vil ikke svare på den.
Du kan få serveren til å tilbakestille tilkoblingen automatisk hvis reglene slettes. Dette vil gjøre serveren sikrere og vanskeligere å nå. Det betyr også at du kan legge til regler på slutten av kjeden, og samtidig vil alle uønskede pakker bli droppet.
En alternativ tilnærming er å legge til en regel på slutten av kjeden som sletter alle ikke-samsvarende pakker samtidig som ACCEPT-policyen opprettholdes.
For å returnere ACCEPT-policyen til INPUT-kjeden, skriv inn:
sudo iptables -P INPUT ACCEPT
Nå kan du legge til en regel på slutten av denne kjeden som sletter alle ikke-matchende pakker:
sudo iptables -A INPUT -j DROP
Under normale driftsforhold vil resultatet være nøyaktig det samme som ved bruk av DROP-policyen. Denne regelen sletter hver pakke som når den, noe som forhindrer pakker som ikke samsvarer med reglene fra å nå serveren.
I utgangspunktet brukes den andre tilnærmingen når det er nødvendig å beholde ACCEPT-policyen som aksepterer trafikk. Det vil si at selv om alle regler er tilbakestilt, kan brukeren få tilgang til maskinen på nettverket. Denne tilnærmingen lar deg utføre standardhandlingene uten å måtte endre policyen som gjelder for den tomme kjeden.
Dette betyr selvfølgelig også at enhver regel som må legges til på slutten av kjeden, må komme før droppregelen. Dette kan gjøres enten ved å midlertidig fjerne tilbakestillingsregelen:
sudo iptables -D INPUT -j DROP
sudo iptables -A INPUT new_rule
sudo iptables -A INPUT -j DROP
eller ved å sette inn en ny regel på slutten av kjeden (men før tilbakestillingsregelen), spesifisere linjenummeret. For å legge til regelen på linje 4, skriv:
sudo iptables -I INPUT 4 new_rule
Hvis det er mange regler, er det ganske problematisk å manuelt beregne linjenummeret; i et slikt tilfelle kan iptables nummerere linjene:
sudo iptables -L --linjetall
Kjedeinngang (policy DROP)
1 GODKJEN ALLE -- hvor som helst hvor som helst
2 GODKJEN ALLE -- hvor som helst hvor som helst ctstate RELATED, ETABLERT
3 ACCEPT tcp -- hvor som helst hvor som helst tcp dpt:ssh
4 ACCEPT tcp -- hvor som helst hvor som helst tcp dpt:http
Kjede FRAM (policy GODKJENNER)
num mål prot opt kildedestinasjon
Kjede OUTPUT (policy ACCEPT)
num mål prot opt kildedestinasjon
Dette lar deg forsikre deg om at regelen ble skrevet inn på riktig linje.
Lagrer iptables-innstillinger
Som standard forblir alle ulagrede regler i kraft til neste server omstart; umiddelbart etter en omstart vil ulagrede regler gå tapt.
Dette er nyttig i noen tilfeller, da det lar brukere som ved et uhell har blokkert seg selv få tilgang til serveren. Men i de fleste tilfeller er det fortsatt mer praktisk å lagre reglene og laste dem når serveren starter.
Dette kan gjøres på flere måter; den enkleste er å bruke iptables-persistent-pakken, som kan lastes ned fra standard Ubuntu-depot:
sudo apt-get oppdatering
sudo apt-get install iptables-persistent
Under installasjonen vil pakken spesifisere om gjeldende regler skal lagres for videre automatisk lasting; hvis gjeldende regler er testet (tillater SSH-tilkoblinger) og oppfyller alle kravene, kan de lagres.
Når installasjonen er fullført, vil det være en ny tjeneste kalt iptables-persistent som vil kjøre ved omstart av serveren og gjenoppta de etablerte reglene.
Resultater
Denne veiledningen hjelper deg med å konfigurere brannmuren i henhold til brukerens krav. Selvfølgelig er det mange flere slike verktøy, og noen av dem kan være enklere å bruke; Likevel er iptables et av de beste verktøyene, om ikke annet fordi det demonstrerer noen av de grunnleggende netfilterstrukturene og er inkludert i mange systemer.
Tags: ,Flere ganger har jeg vært borti at selv generelt intelligente mennesker gjør helt utilgivelige feil. For eksempel åpner de porten som databasen spinner på til hele Internett. Dette er ofte tilfellet med DevOps-nybegynnere som har skrevet kode hele livet, og nå inkluderer deres plikter også å sette opp servere. Det er gode veiledninger på nettet om grunnleggende brannmuroppsett på Linux og andre *nix, men ofte er dette ark for flere skjermer. Så jeg håper denne mer konsise opplæringen vil være nyttig for noen.
Viktig! Det er veldig enkelt å feilaktig brannmure en maskin slik at du ikke får tilgang til den igjen. Dette gjelder spesielt for nettskyhosting. For eksempel, hvis du lukker alle porter fra 1024 til 65536 i AWS, vil maskinen av en eller annen grunn lukkes etter omstart generelt alt havner. Hvis du er vert i skyene, er det bedre å konfigurere brannmuren gjennom nettgrensesnittet som tilbys av verten.
En liten merknad om terminologi. Brannmuren innebygd i Linux-kjernen kalles Netfilter, og iptables er et verktøy for å administrere denne brannmuren. Mange tror feilaktig at brannmuren kalles iptables. Dette er ikke sant. Å si noe som "Jeg filtrerer pakker med iptables" viser din uvitenhet til andre.
Generelt, hvilke oppgaver kan løses med Netfilter:
- Tillat/nekt innkommende trafikk til visse porter ved å bruke visse protokoller (IPv4/IPv6, TCP/UDP) fra spesifiserte adresser (IP, MAC) eller subnett;
- Alt er likt for utgående trafikk;
- Du kan for eksempel fullstendig ignorere alle ICMP-pakker;
- Sette opp NAT, se artikkelen om ruteren basert på Raspberry Pi ;
- Jeg hørte at ekte guruer kan sette opp DDoS og brute force-beskyttelse, begrense nettverkstilgang til spesifikke applikasjoner, brukere eller grupper, og gjøre andre sprø ting;
Jeg legger merke til at iptables-verktøyet virket for meg personlig i begynnelsen ekstremt upraktisk sammenlignet med ipfw i FreeBSD. Heldigvis, etter å ha lekt med den en stund, blir alle disse mange flaggene som -A, -D, -j og andre kjent, så vær tålmodig. La oss ta en titt på de grunnleggende kommandoene.
Vis alle regler:
iptables -L -n
Du legger kanskje merke til at Netfilter har noen "kjeder" (kjeder) - i hvert fall INPUT, OUTPUT og FORWARD. Jeg personlig har også en Docker-kjede på maskinen min. For første gang kan du tenke på de to første som henholdsvis all innkommende og utgående trafikk, og midlertidig glemme resten. Det er en god sjanse for at du aldri trenger dem i det hele tatt.
Fjern alle regler:
iptables -F
Endre policyen (standard oppførsel) til kjeden:
iptables -P INPUT DROP
iptables -P INPUT ACCEPT
Nekt tilgang fra vert/subnett:
iptables -A INPUT -s 123.45.67.89 -j DROP
iptables -A INPUT -s 123.45.0.0/ 16 -j DROP
Du kan også bruke domenenavn:
iptables -A INPUT -s eksempel.ru -j DROP
Forbud mot utgående forbindelser:
iptables -A OUTPUT -d 123.45.67.89 -j DROP
Negativer kan brukes i regler:
iptables -EN INNGANG! -s 123.45.67.89 -j DROPPE
Slette en regel etter nummeret i kjeden:
iptables -D INPUT 1
Fjerne en regel basert på hva den gjør:
iptables -D INPUT -s 123.45.67.89 -j DROP
Alternativet -p spesifiserer protokollen. Du kan bruke all, icmp, tcp, udp eller protokollnummeret fra /etc/protocols. Flagg - -sport spesifiserer porten som pakken ble sendt fra, og - -dport angir destinasjonsporten:
iptables -A INPUT -p tcp --sport 80 -j GODTAR
iptables -A INPUT -p tcp --dport 80 -j GODTAR
Sette inn en regel i begynnelsen av kjeden:
iptables -I INPUT ...
Eller du kan spesifisere en spesifikk stilling:
iptables -I INPUT 3 ...
iptables-save > /etc/iptables.rules
Gjenopprett regler:
iptables gjenoppretting< / etc/ iptables.rules
La oss nå se på noen praktiske eksempler. Slik ser for eksempel netsplit-emulering ut i en test som sjekker oppførselen til en applikasjon som bruker Akka Cluster:
run(node1, s "iptables -A INPUT -s $node2 -j DROP")
run(node1, s "iptables -A INPUT -s $node3 -j DROP")
run(node1, s "iptables -A OUTPUT -d $node2 -j DROP")
run(node1, s "iptables -A OUTPUT -d $node3 -j DROP")
Restaurering er nøyaktig det samme, bare -A-flagget erstattes med -D-flagget.
Et annet eksempel. Det kreves å finne ut hvilke porter som lytter på maskinen og lukke de ekstra. Vi går til bilen og sier:
netstat-tuwpln
Eksempelutgang:
Aktive Internett-tilkoblinger (bare servere)
Proto Recv-Q Send-Q Lokal adresse Utenlandsk adresse Status PID/Prog navn
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3210/nginx
tcp 0 0 0.0.0.0:4369 0.0.0.0:* LYTT 1789/epmd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 797/sshd
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 990/postgres
Nginx og SSHd ser på internett, det er greit. PostgreSQL lytter kun til det lokale grensesnittet, så det er ingen problemer med det heller. Men epmd stikker ut (du kan sjekke med telnet fra en annen maskin), og dette er ikke bra. Du kan bare lukke port 4369. Hvordan du gjør dette ble vist ovenfor. Eller du kan gå enda lenger og nekte alle forbindelser fra utsiden til port 81 og eldre.
