Är det säkert att inaktivera anslutningsspårning i iptables?

Mikhail Morfikov

2014-07-13 13:41:57 UTC

view on stackexchange narkive permalink

När jag läste om NOTRACK -målet för raw -tabellen i iptables, stötte jag på en artikel som tyder på att för viss trafik kan du (eller till och med bör) inaktivera anslutningsspårning. De två exemplen var: (1) alla typer av dirigerade paket och (2) om du har en webbserver eller andra tjänster som äter resurser, bör du också inaktivera anslutningsspårning för sådan tjänst. Jag har ingen webbserver, men jag har några p2p-klienter. Följande är standardregler för anslutningsspårning:

  iptables -t filter -A INPUT -m conntrack --ctstate RELATED, ESTABLISHED -j ACCEPTiptables -t filter -A INPUT -m connectrack --ctstate INVALID -j DROPiptables -t filter -A INPUT -p udp -m conntrack --ctstate NEW -j udpiptables -t filter -A INPUT -p tcp -m tcp --tcp-flags FIN, SYN, RST, ACK SYN -m conntrack --ctstate NEW -j tcp

och i udp och tcp kedjorna öppnar jag port för en torrentklient med:

  iptables -t filter -A udp -p udp -dport 33333 -m anslutning --ctstate NY -j ACCEPTiptabeller -t filter -A tcp -p tcp --dport 33333 -m anslutning - -ctstate NYTT -j ACCEPT

När jag kontrollerar anslutningsposter:

  # cat / proc / net / nf_conntrack | wc -l3569

Nu skulle alternativet vara att ställa in NOTRACK i tabellen raw för denna typ av trafik, till exempel:

  iptables -t raw -A notrack_in -p udp --dport 33333 -j NOTRACKiptables -t raw -A notrack_in -p udp --dport 33333 -j ACCEPTiptables -t raw -A notrack_in -p tcp --dport 33333 -j NOTRACKiptables -t raw -A notrack_in -p tcp --dport 33333 -j ACCEPT

och det behöver också två regler i filtertabellen:

  iptables -t filter -A INPUT -p udp --dport 33333 -j ACCEPTiptables -t filter -A INPUT -p tcp --dport 33333 -j ACCEPT

After den här åtgärden minskade antalet poster i / proc / net / nf_conntrack till 150-200, och det finns ingen rad med port 33333.

Min fråga är denna: Är det säkert att inaktivera anslutningsspårning? Skulle det vara nödvändigt att lägga till regler i iptables? Vilka är för- och nackdelarna med denna lösning?

Det korta svaret

Vanligtvis behöver du bara anslutningsspårning för utgående anslutningar. Om någon lokal enhet ansluter till Internet registrerar brandväggen att denna specifika IP och port försökte skapa en anslutning till den andra IP: n och porten.

Således när svaret från Internet kommer, kommer brandväggen vet att låta det passera, eftersom det har sett ett utgående paket tidigare. Om det inte fanns någon anslutningsspårning på plats måste du placera uttryckliga regler om varifrån eller vart ett paket kan resa (till exempel tillåta alla paket från port 80 på google.com. Det är lätt att se att detta skulle göra brandväggsregler ganska komplicerade.

Det långa svaret

Det finns bara subtila skillnader mellan de två lösningarna om de används för inkommande anslutningar. En skillnad är på vilket system CPU-belastningen för kontrollpaket sker. Om du har en dedikerad dator / router / brandvägg (kallad brandvägg härifrån) som gör detta, med anslutningsspårning aktiverad, kommer den här enheten att kontrollera åtminstone troligheten för ett paket. Detta kommer att göra applikationsservern (servern som får paketen) från att göra det.

rimligheten hänvisar till att paketet kommer från den förväntade värden och den förväntade porten i fallet av UDP och dessutom på sekvensnumret i fallet med TCP.

Vanligtvis kan valideringen bara ske i applikationslagret, eftersom giltigheten endast kan säkerställas baserat på protokollet i själva applikationen.

Det finns tre konsekvenser av dessa antaganden:

CPU- och nätverksbelastningen flyttas mot "kanten" av nätverket när det gäller tillståndsspårning. Det betyder att den (vanligtvis) första enheten i ditt nätverk kommer att utföra någon grundläggande inspektion av paketet innan den vidarebefordras till det lokala nätverket och därmed håller ditt interna nätverk rent och belastningen på brandväggen.

Applikationsservern behöver bara oroa sig för om paketet är giltigt, det vill säga om data i paketet överensstämmer med det förväntade protokollet.

Detta kan öppna möjligheten att köra en UDP-anslutning, beroende på protokollet. Om applikationen inte har något (eller inget tillförlitligt) sätt att autentisera avsändaren av ett paket, accepterar den rätt nyttolast från vilken IP-adress som helst. Till exempel i en dataöverföring skulle det vara möjligt att skicka skräp till mottagaren om UDP-paketet godkänns.

Ändå är vanlig praxis (om inte i högsäkerhetsmiljöer) att använda ( allmänt) anslutningsspårning endast för utgående anslutningar, för att inte uttryckligen behöva tillåta varje internetserver att svara på en begäran från det lokala nätverket. För inkommande anslutningar tillåter du vanligtvis bara (definierad) port att nås (-A INPUT -p tcp --dport 80 -j ACCEPT). Detta skulle gälla för nya anslutningar, men skulle också gälla för befintliga anslutningar, undvika omkostnader, för att hålla reda på anslutningen. På samma sätt skulle du bara vidarebefordra paket till en specifik destinationsport till en applikationsserver i ditt lokala nätverk.

applikationsspecifik anslutningsspårning

Det finns ett fall som jag inte nämnde ännu och det är applikationsspecifik anslutningsspårning. För några protokoll (ftp, irc, tftp, amanda, sip och möjligen andra, se till exempel http://www.iptables.info/en/connection-state.html#COMPLEXPROTOCOLS) kan det finnas vara speciella iptables-moduler för att möjliggöra avancerad spårning av anslutningen. Till exempel i FTP skulle du öppna en anslutning från klienten till servern på port 21, kallad kontrollanslutning, som bör öppnas i brandväggen på normalt sätt. Inuti denna kanal definierar klienten och servern sedan en andra anslutning där råfildata skulle skickas. Vanligtvis upprättas denna anslutning från servern till klienten (i ACTIVE-läge). Denna lokala och fjärrport är till synes slumpmässiga, så de kan inte definieras i en statisk brandväggskonfigurationsfil. Om det fanns en brandvägg med iptables i klientens nätverk skulle det förneka denna anslutning, eftersom det inte finns någon tidigare anslutning. Med applikationsspecifik anslutningsspårning skulle modulen titta in i "paketinnehållet" för att se om ett sådant avtal har gjorts och brandväggen tillåter en ny inkommande anslutning på den överenskomna porten, även om det inte fanns någon anslutning på den tidigare.