Debuggen von iptables und häufigen Firewall-Fallstricken?

[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT

und stellen Sie dann fest, dass es nicht wirksam wird.

Der Grund dafür ist, dass die -A Option fügt diese neue Regel nach allen bestehenden Regeln hinzu und da sehr oft die letzte Regel in der bestehenden Firewall eine war, die den gesamten Verkehr blockiert, der nicht ausdrücklich erlaubt ist, was zu

...
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
8        0  0    ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080

Oder gleichwertig in iptables-save:

...
iptables -A INPUT  -j REJECT
iptables -A INPUT  -p tcp --dport 8080 -j ACCEPT

und die neue Regel, die den TCP-Port 8080 öffnet, wird niemals erreicht. (wie die Zähler belegen, die hartnäckig bei 0 Paketen und null Bytes bleiben).

Durch Einfügen der Regel mit -I die neue Regel wäre die erste in der Kette gewesen und wird funktionieren.

2. Anzeige der aktuellen Firewall-Konfiguration

Meine Empfehlung für den Firewall-Administrator ist, sich die tatsächliche Konfiguration anzusehen, die der Linux-Kernel ausführt, anstatt zu versuchen, Firewall-Probleme mit benutzerfreundlichen Tools zu diagnostizieren. Sobald Sie die zugrunde liegenden Probleme verstanden haben, können Sie sie oft leicht in einer Angelegenheit lösen, die von diesen Tools unterstützt wird.

Der Befehl [sudo] iptables -L -v -n ist dein Freund (obwohl einige Leute iptables-save mögen besser). Bei Diskussionen über Konfigurationen ist es oft sinnvoll, den --line-numbers zu verwenden Option auch zu Zahlenreihen. Der Verweis auf Regel #X macht die Diskussion etwas einfacher.
Hinweis: NAT-Regeln sind in iptables-save enthalten ausgegeben, müssen aber durch Hinzufügen des -t nat separat aufgeführt werden Option, d. h. [sudo] iptables -L -v -n -t nat --line-numbers .

Das mehrmalige Ausführen des Befehls und das Überprüfen auf inkrementierende Zähler kann ein nützliches Werkzeug sein, um zu sehen, ob eine neue Regel tatsächlich ausgelöst wird.

[[email protected] ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     784K   65M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
2    2789K  866M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3       15  1384 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       117.239.37.150       0.0.0.0/0           reject-with icmp-port-unreachable
2        4   412 REJECT     all  --  *      *       117.253.208.237      0.0.0.0/0           reject-with icmp-port-unreachable

Alternativ die Ausgabe von iptables-save gibt ein Skript, das die obige Firewall-Konfiguration regenerieren kann:

[[email protected] ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT

Es ist eine Frage der Präferenz, was für Sie leichter verständlich ist.

3. Interpretieren der Ausgabe von iptables -L -v -n

Die Richtlinie legt die Standardaktion fest, die die Kette verwendet, wenn keine explizite Regel zutrifft. Im INPUT Kette, die auf AKZEPTIEREN des gesamten Datenverkehrs eingestellt ist.

Die erste Regel in der INPUT-Kette ist sofort interessant, sie sendet den gesamten Datenverkehr (Quelle 0.0.0.0/0 und Ziel 0.0.0.0/0) an TCP-Port 22 (tcp dpt:22). ) der Standardport für SSH zu einem benutzerdefinierten Ziel (fail2ban-SSH ).Wie der Name schon sagt, wird diese Regel von fail2ban gepflegt (ein Sicherheitsprodukt, das unter anderem Systemprotokolldateien auf möglichen Missbrauch scannt und die IP-Adresse des Täters blockiert).

Diese Regel wäre von einer iptables-Befehlszeile ähnlich wie iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH erstellt worden oder wird in der Ausgabe von iptables-save als -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH gefunden . Oft finden Sie eine dieser Notationen in der Dokumentation.

Die Zähler zeigen an, dass diese Regel 784'000 Pakete und 65 Megabyte Daten abgeglichen hat.

Datenverkehr, der dieser ersten Regel entspricht, wird dann von fail2ban-SSH verarbeitet Kette, die als Nicht-Standard-Kette unterhalb der OUTPUT-Kette aufgeführt wird.

Diese Kette besteht aus zwei Regeln, eine für jeden Missbraucher (Quell-IP-Adresse 117.253.221.166 oder 58.218.211.166), der (mit einem reject-with icm-port-unreachable) blockiert wird ).

 -A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
 -A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable

SSH-Pakete, die nicht von diesen blockierten Hosts stammen, sind noch weder erlaubt noch verboten und werden jetzt, da die benutzerdefinierte Kette abgeschlossen ist, anhand der zweiten Regel in der INPUT-Kette geprüft.

Alle Pakete, die nicht für Port 22 bestimmt waren, haben die erste Regel in der INPUT-Kette passiert und werden auch in INPUT-Regel Nr. 2 ausgewertet.

Die INPUT-Regel Nummer 2 bedeutet, dass dies eine statefull Firewall sein soll , das Verbindungen nachverfolgt. Das hat einige Vorteile, nur die Pakete für neue Verbindungen müssen gegen den vollständigen Regelsatz geprüft werden, aber sobald sie erlaubt sind, werden zusätzliche Pakete, die zu einer bestehenden oder verwandten Verbindung gehören, ohne weitere Prüfung akzeptiert.

Eingaberegel Nr. 2 stimmt mit allen offenen und verwandten Verbindungen überein, und Pakete, die mit dieser Regel übereinstimmen, müssen nicht weiter ausgewertet werden.

Hinweis: Regeländerungen in der Konfiguration einer Stateful Firewall wirken sich nur auf neue Verbindungen aus, nicht auf bestehende Verbindungen.

Im Gegensatz dazu testet ein einfacher Paketfilter jedes Paket anhand des vollständigen Regelsatzes, ohne den Verbindungsstatus zu verfolgen. In einer solchen Firewall kein Zustand Schlüsselwörter verwendet werden.

INPUT-Regel Nr. 3 ist ziemlich langweilig, der gesamte Datenverkehr wird mit dem Loopback verbunden (lo oder 127.0.0.1) Schnittstelle ist erlaubt.

Die INPUT-Regeln 4, 5 und 6 werden verwendet, um die TCP-Ports 22, 80 und 443 (die Standardports für bzw. SSH, HTTP und HTTPS) zu öffnen, indem Zugriff auf NEUE Verbindungen gewährt wird (vorhandene Verbindungen werden bereits durch INPUT-Regel 2 zugelassen).

In einer zustandslosen Firewall würden diese Regeln ohne die Zustandsattribute erscheinen:

4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

oder

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Die letzte INPUT-Regel Nr. 7 ist eine Regel, die den gesamten Datenverkehr blockiert, dem in den INPUT-Regeln 1–7 KEIN Zugriff gewährt wurde. Eine ziemlich verbreitete Konvention:Alles, was nicht erlaubt ist, wird verweigert. Theoretisch hätte diese Regel weggelassen werden können, indem die Standardrichtlinie auf REJECT gesetzt wurde.

Untersuchen Sie immer die gesamte Kette.

4. Kenne deine Umgebung

4.1 . Die Einstellungen in einer Software-Firewall wirken sich nicht auf Sicherheitseinstellungen aus, die an anderer Stelle im Netzwerk verwaltet werden, d. h. trotz Öffnen eines Netzwerkdienstes mit iptables Die unveränderten Zugriffskontrolllisten auf Routern oder anderen Firewalls in Ihrem Netzwerk blockieren möglicherweise weiterhin den Datenverkehr...

4.2 . Wenn kein Dienst zuhört, können Sie keine Verbindung herstellen und erhalten unabhängig von den Firewall-Einstellungen einen Verbindungsverweigerungsfehler. Deshalb:

• Bestätigen Sie mit [sudo] netstat -plnut, dass ein Dienst zuhört (auf der richtigen Netzwerkschnittstelle/IP-Adresse) und die Portnummern verwendet, die Sie erwarten oder verwenden Sie alternativ ss -tnlp .
• Falls Ihre Dienste noch nicht laufen sollen, emulieren Sie einen einfachen Listener mit zB netcat:[sudo] nc -l -p 123 oder openssl s_server -accept 1234 [options] wenn Sie einen TLS/SSL-Listener benötigen (überprüfen Sie man s_server für Optionen).
• Stellen Sie sicher, dass Sie sich vom Server selbst verbinden können, d. h. telnet <IP of Server> 123 oder echo "Hello" | nc <IP of Server> 123 oder beim Testen des TLS/SSL-gesicherten Dienstes openssl s_client -connect <IP of Server>:1234 , bevor Sie dasselbe von einem entfernten Host aus versuchen.

4.3 . Machen Sie sich mit den von Ihren Diensten verwendeten Protokollen vertraut. Sie können Dienste, die Sie nicht ausreichend verstehen, nicht richtig aktivieren/deaktivieren. Zum Beispiel:

• wird TCP oder UDP oder beides verwendet (wie bei DNS)?
• Verwendet der Dienst einen festen Standardport (zum Beispiel so etwas wie TCP-Port 80 für einen Webserver)?
• wird alternativ eine dynamische Portnummer gewählt, die variieren kann (d.h. RPC-Dienste wie klassisches NFS, die sich bei Portmap registrieren)?
• berüchtigtes FTP verwendet sogar zwei Ports , sowohl eine feste als auch eine dynamische Portnummer, wenn sie für die Verwendung des passiven Modus konfiguriert ist...
• die Dienst-, Port- und Protokollbeschreibungen in /etc/services stimmen nicht unbedingt mit dem tatsächlichen Dienst überein, der einen Port verwendet.

4.4 . Der Kernel-Paketfilter ist nicht das einzige, was die Netzwerkkonnektivität einschränken kann:

• SELinux schränkt möglicherweise auch Netzwerkdienste ein. getenforce bestätigt, ob SELinux ausgeführt wird.
• Obwohl TCP-Wrapper immer mehr in Vergessenheit geraten, sind sie immer noch ein mächtiges Werkzeug zur Durchsetzung der Netzwerksicherheit. Prüfen Sie mit ldd /path/to/service |grep libwrap und der /hosts.[allow|deny] Steuerdateien.

5. INPUT oder FORWARD Ketten

Das Konzept der Ketten wird hier ausführlicher erklärt, aber kurz gesagt:

Die INPUT In der Kette öffnen und/oder schließen Sie Netzwerkports für Dienste, die lokal auf dem Host ausgeführt werden, auf dem Sie die iptables-Befehle ausgeben.

Der FORWARD In der Kette wenden Sie Regeln an, um den Datenverkehr zu filtern, der vom Kernel an andere Systeme, tatsächliche Systeme, aber auch Docker-Container und virtuelle Gastserver-Server weitergeleitet wird, wenn Ihr Linux-Computer als Bridge, Router, Hypervisor fungiert und/oder Netzwerkadressen übersetzt und Portweiterleitung.

Ein weit verbreiteter Irrglaube ist, dass, da ein Docker-Container oder KVM-Gast lokal läuft, die anzuwendenden Filterregeln in der INPUT-Kette stehen sollten, aber das ist normalerweise nicht der Fall.

6. Kernel-Module

Da der Paketfilter im Linux-Kernel läuft, kann er auch als dynamisches Modul kompiliert werden, eigentlich mehrere Module. Die meisten Distributionen enthalten Netfilter als Module und die erforderlichen Netfilter-Module werden nach Bedarf in den Kernel geladen, aber für einige Module muss ein Firewall-Administrator manuell sicherstellen, dass sie geladen werden. Dies betrifft in erster Linie die Connection-Tracking-Module wie nf_conntrack_ftp die mit insmod geladen werden kann .

Die aktuell in den laufenden Kernel geladenen Module können mit lsmod angezeigt werden .

Die Methode, um sicherzustellen, dass Module über Neustarts hinweg dauerhaft geladen werden, hängt von der Linux-Distribution ab.

Lösung 2:

Iptables/Firewall "Einführung"

Eine Firewall ist im Grunde ein richtlinienbasierter Netzwerkfilter. Linux-Firewalls basieren auf Netfilter; das Netzwerkpaketverarbeitungs-Framework des Kernels, das aus mehreren Kernelmodulen besteht, die bestimmte Aufgaben ausführen:

1. Das FILTER-Modul (standardmäßig immer geladen) ermöglicht uns hauptsächlich, IP-Pakete basierend auf bestimmten Übereinstimmungskriterien zu AKZEPTIEREN oder zu LÖSCHEN.
2. Der NAT-Modulsatz ermöglicht uns die Durchführung von Network Address Translations (SNAT, DNAT, MASQUERADE).
3. Das MANGLE-Modul ermöglicht es uns, bestimmte IP-Paketfelder (TOS, TTL) zu ändern.

Benutzer konfigurieren das Netfilter-Framework so, dass es ihren Firewall-Anforderungen entspricht, indem sie iptables von der Befehlszeile aus verwenden. Mit iptables definieren wir Regeln, die den Kernel anweisen, was mit IP-Paketen zu tun ist, wenn sie unsere Linux-Box erreichen, passieren oder verlassen. Sie haben mehrere spezifische Hook-Punkte auf der Netzwerkpaketflusskarte, an denen sie vom Kernel aufgerufen werden, um ihre Aufgaben zu erfüllen. und POSTROUTING. Es ist leicht zu merken, wenn wir eine TABELLE mit einem "Prozesstyp" und eine KETTE mit dem "Ort" auf der Netzwerkpaketflusskarte verknüpfen, wo Instanzen dieser Prozesse aufgerufen werden.

Da ein IP-Paket auf einer Netzwerkschnittstelle empfangen oder von einem lokalen Prozess erstellt wird, bis es endgültig zugestellt oder verworfen wird, testet die Netfilter-Engine nacheinander die Regeln, die in der Netzwerkpaketflusskarte enthalten sind, und wendet sie an. An jedem Block, der durch ein [email protected] gekennzeichnet ist, kann der Benutzer eine oder mehrere dieser aufeinanderfolgenden Regeln hinzufügen, die ein IP-Paket-Übereinstimmungskriterium und eine entsprechende Vorgehensweise enthalten. Es gibt Aktionen (z. B. ACCEPT, DROP usw.), die von mehr als einer TABLE ausgeführt werden können, und andere Aktionen (z. B. SNAT, DNAT usw.), die TABLE-spezifisch sind.

d.h. wenn ein IP-Paket von einer Netzwerkschnittstelle ankommt, wird es zuerst von der PREROUTING-Kette verarbeitet, die die benutzerdefinierten Regeln der MANGLE-Tabelle, falls vorhanden, aufruft. Wenn es keine Regeln gibt, die mit dem aktuellen Paket übereinstimmen, gilt die entsprechende Standardaktion oder "Richtlinie" von [email protected]. Wenn das Paket an diesem Punkt nicht verworfen wurde, wird der Prozess jetzt fortgesetzt, indem die Regeln der NAT-Tabelle in der PREROUTING-Kette aufgerufen werden (siehe Karte) und so weiter. Um das Regellayout zu vereinfachen, können Benutzer auch ihre eigenen benutzerdefinierten Ketten erstellen und von verschiedenen Punkten der Karte nach Belieben in sie "springen".

Während eingebaute Ketten benutzerdefinierte Richtlinien von entweder ACCEPT- oder DROP-Paketen haben können, haben benutzerdefinierte Ketten immer eine unveränderliche Standardrichtlinie von RETURN an den Aufrufer, um den Prozess fortzusetzen.

Iptables-Befehle

Die Hauptbefehle von iptables füllen die Netzwerkpaketflusskarte mit den erforderlichen Verarbeitungsregeln.

Die generische iptables-Regel kann wie folgt geschrieben werden:

# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>

Es könnte wie folgt gelesen werden:

<table>
  -t filter       (the filter table is assumed when omitted)
  -t nat
  -t mangle 

<Add/Insert/Delete>
  -A              (append rule at the end of the chain list)
  -I              (insert rule at the begining of the chain list)
  -D              (Delete rule)

<CHAIN>
  PREROUTING
  INPUT
  FORWARD
  OUTPUT
  POSTROUTING
  USER_DEFINED_CHAIN

<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
  -i [!] <if_name>    or --in-interface [!] <if_name>
          (OUTPUT and POSTROUTING chains cannot match on input  interfaces)
  -o [!] <if_name>    or --out-interface [!] <if_name>
          (INPUT  and PREROUTING  chains cannot match on output interfaces) 
    -mac-source [!] <xx-xx-xx-xx-xx-xx>
            (OUTPUT and POSTROUTING chains cannot match on input  interfaces)

ISO Level-3 matching:
  -s [!] <src_ip>     or --src [!] <src_ip>   or --source [!] <src_ip>
  -d [!] <dst_ip>     or --src [!] <dst_ip>   or --destination [!] <dst_ip>

ISO Level-4 matching:
  -p [!] <prot_name>    or --protocol [!] <prot_name>  (udp|tcp|icmp)

  Also available when ICMP protocol is defined
  --icmp-type [!] <icmp_type>

  Also available when UDP protocol is defined
  --source-port [!] <udp_src_port>      or --sport [!] <udp_src_port>
  --destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>

  Also available when TCP protocol is defined
  --source-port [!] <tcp_src_port>      or --sport [!] <tcp_src_port>
  --destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
  --tcp-flags [!] <tcp_flags>   (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
    --syn
  --tcp-option [!] <tcp_option#>

  --state [!] <state>
  -m <match> [options]

    note: [!] = negation operator

<ACTION>                (also called TARGET)
  -j ACCEPT             (process continues with rules of the next table in map)
  -j DROP               (discard current packet)
  -j REJECT             (discard current packet with ICMP notification)
      option:
      --reject-with <reject_type>
  -j USER_DEFINED_CHAIN   (start traversing USER_DEFINED_CHAIN rules)
  -j RETURN               (return from USER_DEFINED_CHAIN)
  -j LOG                  (log to syslog, then process next rule in table)
      options:
      --log-level <level>
      --log-prefix <prefix>
      --log-tcp-sequence
      --log-tcp-options
      --log-ip-options
      --log-uid

nat table specific
  -j SNAT             (rewrite the source IP address of the packet)
      option:
      --to <ip_address>
  -j SAME             (idem SNAT; used when more than one source address)
      options:
      --nodst 
      --to <a1-a2>
  -j MASQUERADE       (idem SNAT; used when the replace IP is dynamic)
  -j DNAT             (rewrite the destination IP address of the packet)
      option:
      --to <ip_address>
  -j REDIRECT         (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
      option:
      –-to-port <port#>

mangle table specific
  -j ROUTE            (explicitly route packets, valid at PREROUTING)
      options:
      --iface <iface_name>
      --ifindex <iface_idx>
  -j MARK             (set Netfilter mark values)
      options:
      --set-mark <value>
      --and-mark <value>
      --or-mark <value> 
  -j TOS              (set the IP header Type of Service field) 
      option:
      --set-tos <value>
  -j DSCP             (set the IP header Differentiated Services Field)
      options:
      --set-dscp <value>
      --set-dscp-class <class>
  -j TTL              (set the IP header Time To Live field)
      options:
      --ttl-set <value>
      --ttl-dec <value>
      --ttl-inc <value>

#iptables -t <table> -L             
       (Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>     
       (Lists the <table> rules in <CHAIN>)

#iptables -t <table> -N <CHAIN>     
       (Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>  
       (Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)

#iptables -t <table> -X   
       (Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
       (Deletes user-defined <CHAIN> created for holding <table> rules)

#iptables -t <table> -P <CHAIN> <ACTION>     where <ACTION> = ACCEPT|DROP
       (Sets the default policy of <table> rules at <CHAIN> to <ACTION>)

#iptables -t <table> -F             
       (Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
       (Flushes (deletes) all <table> rules in <CHAIN>)

#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
       (Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>

#iptables-save > fileName
      (Save the currently active Netfilter ruleset to fileName)

#iptables-restore < fileName
      (Restore Netfilter ruleset to the one saved in fileName)

iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT

  iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT