# [SOLVED] Netzwerk mit iptables sehr langsam

## revargne

Hallo,

ich habe mir mit iptables einige Firewall Regeln erstellt:

```

iptables -A INPUT -s localhost -j ACCEPT

iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -s 192.168.x.x/24 -p tcp --dport 137:139 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

iptables -A INPUT -s 192.168.x.x/24 -p udp --dport 137:139 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

iptables -A INPUT -p tcp --dport x -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

```

Der letzte Eintrag ist für einen Bouncer gedacht.

So weit so gut. Bringt so erstmal noch nichts, da die Policy für INPUT noch auf ACCEPT steht. Wenn ich nun die Policy auf DROP setze, ist erstens ein Login über SSH sehr langsam (ca. 1 min bis zur Passworteingabe), zweitens dauert die Ausgabe von iptables -L mindestens 3 min und ein Login auf meinem Bouncer läuft sich tot (nachdem der IRC Client sich schon zu dem Bouncer verbunden hat und sogar den, hier jetzt auch sehr langsamen, Login hinter sich gebracht hat).

Habe ich irgendwo einen Denkfehler oder habe ich etwas vergessen? Woran kann das liegen?Last edited by revargne on Tue Feb 19, 2008 6:52 am; edited 1 time in total

----------

## 69719

 *revargne wrote:*   

> 
> 
> ```
> 
> iptables -A INPUT -s localhost -j ACCEPT
> ...

 

192.168.x.x/24? Müßte das nicht 192.168.0.0/24 heißen?

Wenn ein -L 3 Minuten dauert, so rate ich dir dein DNS zu überprüfen bzw denn Input für das device lo durchzulassen.

----------

## schachti

Hört sich so an, als ob es Probleme mit der Namensauflösung gibt. DNS läuft teilweise auch über UDP, versuch mal, die entsprechenden Ports freizugeben.

Zum Testen:

* iptables mal mit -n, mal ohne diese Option ausführen

* in der Konfigurationsdatei des sshd UseDNS auf no setzen (default ist yes).

----------

## revargne

 *Quote:*   

> 192.168.x.x/24? Müßte das nicht 192.168.0.0/24 heißen?

 

Hihi, klar muss es das.... bzw. ist die erste 0 keine 0 bei mir. Ich habe nur x verwendet um meine interne IP Range hier nicht explizit anzugeben.

 *Quote:*   

> Wenn ein -L 3 Minuten dauert, so rate ich dir dein DNS zu überprüfen bzw denn Input für das device lo durchzulassen.

 

Hat leider nicht geholfen  :Sad: 

----------

## toralf

Wieso nutzt Du nicht einfach das LOG target ? Dann siehst Du sofort, was die Firewall abblockt:

```
n22 ~ # zgrep TARGET_LOG /proc/config.gz

CONFIG_IP_NF_TARGET_LOG=m

n22 ~ # grep LOG /etc/kmyfirewall/kmyfirewall.sh

        $MOD ipt_LOG

        $IPT -t filter -A INPUT -m limit --limit 1/second --limit-burst 5 -j LOG --log-prefix "FW_IN: "

        $IPT -t filter -A OUTPUT -m limit --limit 1/second --limit-burst 5 -j LOG --log-prefix "FW_OUT: "

        $IPT -t filter -A FORWARD -m limit --limit 1/second --limit-burst 5 -j LOG --log-prefix "FW_FWD: "

```

Last edited by toralf on Mon Feb 18, 2008 4:28 pm; edited 1 time in total

----------

## mv

 *revargne wrote:*   

> Hihi, klar muss es das.... bzw. ist die erste 0 keine 0 bei mir. Ich habe nur x verwendet um meine interne IP Range hier nicht explizit anzugeben.

 

Dein interner IP-Range ist automatisch 192.* - da gibt es nichts zu verstecken. Und gegenüber IP-Spoofing solltest Du Dich sowieso schützen: Security by obscurity funktioniert bekanntlich nicht.

Zu Deinem eigentlichen Problem: Du willst sicherlich nicht allen ICMP Traffic blockieren. Das wird Dir später noch mehr Ärger einhandeln. (Außerdem ist REJECT gegenüber DROP i.d.R. vorzuziehen). Schau Dir z.B. mal dieses firewall script hier an.

----------

## think4urs11

 *mv wrote:*   

> Dein interner IP-Range ist automatisch 192.* 

 

Nur zur Klarstellung - das in keineswegs in Stein gemeißelt (und wenn überhaupt dann 192.168.*  :Wink:  ). Man _sollte_ in einem privaten Netzwerk einen Adressbereich aus RFC1918 benutzen weil diese garantiert im Internet nicht geroutet werden, aber letztlich dazu gezwungen ist man nicht. Man kann genausogut 12.34.56.80/28 benutzen wenn es einem gefällt.

Es kann aber nicht schaden den exakten Range trotzdem geheim zu halten, erschwert z.B. die diversen Angriffe auf Router wie sie in letzter Zeit durch die Medien gingen.

----------

## mv

 *Think4UrS11 wrote:*   

>  *mv wrote:*   Dein interner IP-Range ist automatisch 192.*  
> 
> Nur zur Klarstellung - das in keineswegs in Stein gemeißelt (und wenn überhaupt dann 192.168.*  ).

 

Das war wohl missverständlich. Erst mit der Angabe 192.168.x.x/24 wird es in Stein gemeißelt (und strenggenommen ist es dann weder 192.* noch 192.168.*, aber ich bin jetzt zu bequem, das Korrekte als regulären Ausdruck anzugeben).

 *Quote:*   

> Es kann aber nicht schaden den exakten Range trotzdem geheim zu halten, erschwert z.B. die diversen Angriffe auf Router wie sie in letzter Zeit durch die Medien gingen.

 

Wie gesagt: Lieber vernünftige Maßnahmen gegen Adress-Spoofing treffen (statt sich auf "security by obscurity" zu verlassen). Ein nicht vertrauenswürdiger Router (und in diese Klasse gehören die meisten Geräte) ist keine solche Maßnahme.

Edit: Ich hatte mich oben vertan: 192.* ist für /24 schon korrekt.Last edited by mv on Mon Feb 18, 2008 8:13 pm; edited 1 time in total

----------

## think4urs11

 *mv wrote:*   

> Lieber vernünftige Maßnahmen gegen Adress-Spoofing treffen (statt sich auf "security by obscurity" zu verlassen). Ein nicht vertrauenswürdiger Router (und in diese Klasse gehören die meisten Geräte) ist keine solche Maßnahme.

 

Die Angriffe die ich meine haben nichts mit Spoofing zu tun, viel mehr mit der Tatsache das viele Router via Webinterface konfiguriert werden und man ggf. mit geeignet manipulierten Links die $Dau anklickt die Konfig umschreiben kann.

Ansonsten gebe ich dir recht, die meisten der bezahlbaren Router für dein Heimgebrauch haben mehr oder weniger große Lücken und/oder fehlende Funktionalitäten.

(aktuelles Beispiel aus eigener Erfahrung - Fritzbox kann nur DHCP-Server für 192.168.178.x spielen auch wenn sie selbst in einem ganz anderen Netz hängt, seeeehr sinnvoll   :Evil or Very Mad: )

----------

## revargne

 *Quote:*   

> Edit: Ich hatte mich oben vertan: 192.* ist für /24 schon korrekt.

 

Da widerspreche ich jetzt einfach mal. Alle Informationen, die ich darüber finde sagen mir, dass mit /24 nur noch 8 Bit frei sind also 192.168.x.0/24 gibt mir den Adressbereich 192.168.x.0-192.168.x.254 und nicht umgekehrt. Ist insgesamt auch logisch, es sind ja 24 von 32 Bit maskiert und damit bleiben nur 8 Bit übrig. Das heißt außerdem, dass /24 einer Subnetzmaske von 255.255.255.0 entspricht. BTW würde sonst ja 0.0.0.0/0 auch nicht für _alle_ Adressen sondern für _gar keine_ Adresse stehen....

Bevor das jetzt in einer Grundsatzdiskussion ausufert: Ich suche immer noch eine Lösung für mein Problem ^^

 :Smile: 

Edit:  *Quote:*   

> Außerdem ist REJECT gegenüber DROP i.d.R. vorzuziehen

  Warum das? Mit REJECT antwortet mein Rechner auch auf den gesperrten Ports, zwar nur mit einer Ablehnung aber er anwortet. Für mich macht das mehr Sinn, wenn er wirklich nur da ein Lebenszeichen von sich gibt, wo er es auch soll. Im Übrigen sind mir keine Firewalls bekannt, die REJECT anstatt DROP benutzen.Last edited by revargne on Tue Feb 19, 2008 6:20 am; edited 1 time in total

----------

## schachti

Du hast noch nicht geschrieben,

* ob iptables -n -L schneller geht als iptables -L,

* ob das Problem mit ssh verschwindet, wenn Du UseDNS no in /etc/ssh/sshd_config setzt und sshd neu startest,

* ob das Problem verschwindet, wenn Du DNS in der Firewall erlaubst,

* was im Log erscheint, wenn Du - anstatt die Policy auf DROP zu setzen - am Ende eine Regel einfügst, die alles loggt, was übrig ist.

Das sind doch erstmal ein Haufen Ansatzpunkte...

----------

## revargne

 *schachti wrote:*   

> Du hast noch nicht geschrieben,
> 
> * ob iptables -n -L schneller geht als iptables -L,
> 
> * ob das Problem mit ssh verschwindet, wenn Du UseDNS no in /etc/ssh/sshd_config setzt und sshd neu startest,
> ...

 

Sorry, hatte den Beitrag erst nicht genau gelesen weil ich mich mit der Netzwerkmaske beschäftigt hatte....

Und ja, ein Haufen Ansatzpunkte  :Smile:  Einer davon reichte: Es war der DNS   :Embarassed: 

Wenn ich jetzt noch herausfinde warum ich nicht daran gedacht habe....  :Very Happy: 

Danke auf jeden Fall!

----------

## mv

 *revargne wrote:*   

>  *Quote:*   Edit: Ich hatte mich oben vertan: 192.* ist für /24 schon korrekt. 
> 
> Da widerspreche ich jetzt einfach mal. Alle Informationen, die ich darüber finde sagen mir, dass mit /24 nur noch 8 Bit frei sind

 

Nach kurzer Recherche stelle ich erstaunt fest: Du hast recht.   :Confused:   Ich hatte die Zahl immer für die Anzahl der freien Bits gehalten. Gut, dass ich das vorhin so klugscheißerisch geschrieben habe, sonst wäre mir lange nicht aufgefallen, dass ich da einer Fehlinformation aufgesessen war.   :Embarassed: 

 *Quote:*   

>  *Quote:*   Außerdem ist REJECT gegenüber DROP i.d.R. vorzuziehen  Warum das? Mit REJECT antwortet mein Rechner auch auf den gesperrten Ports, zwar nur mit einer Ablehnung aber er anwortet. Für mich macht das mehr Sinn, wenn er wirklich nur da ein Lebenszeichen von sich gibt, wo er es auch soll. Im Übrigen sind mir keine Firewalls bekannt, die REJECT anstatt DROP benutzen.

 

I.d.R. benötigt es weniger Traffic, wenn man ein ordentliches Reject sendet statt einfach nicht zu antworten (was übrigens auch irgendwelchen RFC-Standards widerspricht): Vernünftige Programme senden dann die Anfrage nicht erneut. Für genauere Details verweise ich mal auf die Firewall FAQ

Das heißt natürlich nicht, dass man zur DOS-Vermeidung nicht ein Ratelimit auf die Rejects setzen sollte. Und gewisse Ports (z.B. 135, 137-139, 445), die gerne von verwirrten Windows-Programmen oder Viren unter Ignorierung des Reject belästigt werden, sollte man vielleicht in jedem Fall auf DROP setzen. Bei letzterem gehen die Meinungen oft auseinander.

Die kommerziellen sog. "private Firewalls" sind kein Qualitäts-Kriterium, wie Du ebenfalls in obiger Firewall FAQ nachlesen kannst.

----------

## think4urs11

 *revargne wrote:*   

> Warum das? Mit REJECT antwortet mein Rechner auch auf den gesperrten Ports, zwar nur mit einer Ablehnung aber er anwortet. Für mich macht das mehr Sinn, wenn er wirklich nur da ein Lebenszeichen von sich gibt, wo er es auch soll. Im Übrigen sind mir keine Firewalls bekannt, die REJECT anstatt DROP benutzen.

 

Es ist schlicht die 'nettere' Variante einem Anfragenden zu sagen 'nee du, haben wir nicht' (REJECT) als ihn einfach zu ignorieren (DROP) und einen Sicherheitsgewinn hast du durch DROP auch nicht - die 'Stealth-Firewall'-Features die an allen Ecken angepriesen werden sind schlicht Mumpitz.

Abgesehen davon sollte man mindestens für ident explizit REJECT statt DROP nutzen, bei allem anderen kann man es i.d.R. aber handhaben wie man will (RFCs mal außen vor). Und speziell bei 'Windows-Geplapper' ist wie mv schon schreibt ein DROP vorzuziehen.

----------

## revargne

Ok, dann danke für die Erklärungen  :Smile:  Ich werde mich wohl noch ein bisschen mit der Materie befassen und weiter an der Firewall rumbasteln bis ich 'die Perfekte' habe. Zumindest ist der betroffene Rechner auch ohne eigene Firewall recht sicher und ich bin nicht auf den sofortigen und fehlerfreien Einsatz einer Fw angewiesen  :Very Happy: 

----------

## think4urs11

je nachdem was exakt and Daemons läuft braucht es ggf. gar keine Firewall.

Viel essentieller ist eine jeweils sichere Konfiguration der Services (z.B. kein root-login, nur pubkey bei sshd)

----------

## revargne

 *Think4UrS11 wrote:*   

> je nachdem was exakt and Daemons läuft braucht es ggf. gar keine Firewall.
> 
> Viel essentieller ist eine jeweils sichere Konfiguration der Services (z.B. kein root-login, nur pubkey bei sshd)

 

_Gebraucht_ wird auf diesem Rechner mit großer Sicherheit keine Firewall  :Smile:  Ich baue die Firewall hauptsächlich auf um mich damit zu beschäftigen. Trotz großer Unwissenheit administriere ich mit anderen Leuten zusammen einen Benutzerserver und um die Firewall konnte ich mich bisher nicht kümmern bzw. wollte ich nicht, da ich davon zu wenig Ahnung habe ^^

Es dient also lediglich der Fortbildung.

----------

