# Iptables - alles abdichten?

## chilla

Hallo, 

vorneweg: bitte verzeiht mir etwaige Fehler, ich bin gerade dabei, mich in das Thema einzuarbeiten und mein Wissen darüber ist noch nicht sehr groß.  Aber um einige Sachen für mich verständlicher zu machen, möchte ich euch gerne ein paar Fragen dazu stellen, die mir unklar sind. 

Es geht um folgendes: Ich möchte vorerst nur meinen Arbeitsplatz sichern, und später auch den Router, der für meinen Internetzugang zuständig ist absichern. 

Bei der Lektüre stoße ich auf sehr viele iptables-skripte, die folgendermaßen vorgehen: Ich erstelle die Ketten, flushe sie nochmal, damit sie leer sind. Nun blockiere ich manche Ports und bestimmte eingehende tcp-verbindungsversuche mit bestimmten tcp-flags. Was mich daran stört ist die übersichtlichkeit. Ich bin von meinem wissen noch nicht soweit, dass ich wirklich sagen kann, was ich blocken muss, damit mein system sicher ist. Ich traue mir das nicht zu. 

Für mich als "noob" erscheint es wesentlich sinnvoller, ersteinmal _alles_ zu blockieren und dann nach und nach schritt für schritt die dinge zuzulassen, bei denen ich mir sicher bin, dass ich sie öffnen kann/muss, wie beispielsweise der 22er port für ssh. 

Wenn ich mir /etc/services anschaue, kann das ja eientlich kein Problem sein, da dort steht, welchen port ich zu verwenden habe, und welchen nicht. Doch hierzu meine erste frage: 

In /etc/services stehen für die meisten Anwendungen nützliche Infos zu den verwendeten Ports, wie beispielweise: 

```
cat /etc/services | grep ssh

ssh             22/tcp                          # SSH Remote Login Protocol

ssh             22/udp

```

Doch wieso steht dort auch UDP? Ebenso für fast alle anderen Anwendungen werden die Ports sowohl für tcp, als auch für udp angegeben - auch wenn die Anwengungen garnicht beide Protokolle verwerden. Wo bekomme ich evtl. brauchbarere infos über die Ports und Protokolle der Anwendungen? 

Nächstes Problem: Da ich wie oben beschrieben eine "default-policy" -P DROP für die Ketten INPUT und OUTPUT setzen möchte, habe ich das Problem, dass noch immer keine Verbindungen zustandekommen, auch wenn ich beispielsweise dport 22 bei tcp auf ACCEPT stelle. Liegt das vielleicht daran, dass ich erstnoch bestimmte tcp Flags erlauben muss? Ich habe mich bisher an die Anleitung von Selflinux.org (http://selflinux.org/selflinux/html/iptables.html) gehalten. Wahrscheinlich habe ich nur zu schlecht gelesen, oder mir fehlt einfach das Vorwissen. Muss ich trotz der Porterlaubnis für tcp 22 trotzdem noch extra SYN Flags (und vielleicht noch andere) für tcp zulassen, damit etwas durchkommt? 

Lezte Frage: Wenn ich für INPUT und OUTPUT jeweils eine defaultpolicy DROP verwende, bin ich dann gegen Attacken geschüzt? Mit Attacken meine ich Dinge wie "Ping of death" und "DOS" oder weiss der Geier, was es alles gibt - sorry für meine Unkenntnis.  "Geschüzt" bedeutet für mich, dass nichts reinkommt, was ich nicht will. 

Bitte nich anmaulen, weil ich angeblich zu wenig nachgelesen habe - es scheitert bei mir am verständnis, und wenn ihr mir konkretere Anhaltspunkte sagen könnt, über die ich mich informieren sollte, dann werde ich es auch gerne tun. Leider sind die meiste Dokumentationen über iptables auf einem meines Erachtens nach sehr hohen Niveau gehalten und somit relativ unbrauchbar für einen Netzwerkneuling wie mich.

----------

## amne

Also deinen Post nach zu urteilen hast du dir ja durchaus schon etwas durchgelesen und dir Gedanken dazu gemacht.

Wie dir schon aufgefallen ist, gibt es verschiedene Philosophien was Firewalling angeht: Entweder per default nix reinlassen und explizit freischalten - oder umgekehrt. Für was man sich entscheidet ist eine Frage der Paranoia und des Komforts.

Es gibt auch durchaus Leute, die der Ansicht sind, ein gut aufgesetzter Rechner braucht gar keine Firewall - weil keine unnötigen Services laufen, die angegriffen werden können.

Wegen tcp/udp: Richtig, ssh läuft nur auf tcp. Meistens wird der bekannte Port aber trotzdem für tcp und udp eingetragen, um zu vermeiden, dass jemand anderer dann diesen auf udp belegt und irgendwann ein Chaos herauskommt (weil z.b. jemand auch ssh über udp implementiert).

----------

## chilla

 *amne wrote:*   

> [...]
> 
> Wie dir schon aufgefallen ist, gibt es verschiedene Philosophien was Firewalling angeht: Entweder per default nix reinlassen und explizit freischalten - oder umgekehrt. Für was man sich entscheidet ist eine Frage der Paranoia und des Komforts.
> 
> Es gibt auch durchaus Leute, die der Ansicht sind, ein gut aufgesetzter Rechner braucht gar keine Firewall - weil keine unnötigen Services laufen, die angegriffen werden können.[...]

 

In der Tat, das ist mir aufgefallen. Jedoch halte ich es für für sinnvoll, die Sicherheit an der Stelle anzusetzen, wo man am effektivsten und am einfachsten Arbeiten kann. Afu dem Recner laufen sehr viele Prozesse von denen ich garnicht weiss, was sie eigentlich tun - und ich verlasse mich bei einem emerge darauf, dass das, was ich mir da installiere auc nur das tut, was es soll: xmms soll audiodateien abspielen, und nicht anderen leuten zugang zu meinem Rechner gewähren. 

Ich denke, es ist unmöglich, die gesamte Software zu kontrollieren, und immer zu schauen, was andere Benutzer auf dem Rechner machen. Das Feld, welches man kontrollieren muss, ist für jemanden wie mich einfach zu groß. 

Ich denke, eine der wenigen möglichkeiten für mich, das System sicher zu halten, ist an der Schnittstelle zur Ausßenwelt, da diese für mich per Iptables am einfachsten zu kontrollieren ist. Und um das so einfach wie möglich zu gestalten, möchte ich erstmal rein garnichts erlauben. Und dann ganz langsam mich an die öffnung von ports wagen  :Smile: 

Ziel für mich ist es, eine Firewallgrudkonfiguration zu erlangen, bei der ales geblockt wird, und ich letztendlich nurnoch maximal 2-3 Zeilen schreiben muss, um einen Dienst (beispielweise das surfen mittels eines Browsers, oder das nutzen von ssh) auf diesem Rechner zuzulassen. <- Das ist die grenze dessen, wo jemand wie ich noch durchblickt  :Razz: 

----------

## SinoTech

Also zu deinem ssh Problem.

1. Du musst auch DNS zulassen (Domain name system), da du ansonsten keinen Namen ind die entsprechende IP umwandeln kannst:

```

#!/bin/bash

IPTABLES='/sbin/iptables'

# Set interface values

INTIF1='eth0'

[...]

$IPTABLES -A INPUT -i $INTIF1 -p udp --sport 53 --dport 1024: -j ACCEPT

$IPTABLES -A OUTPUT -o $INTIF1 -p udp --sport 1024: --dport 53  -j ACCEPT

```

Und wie du wohl gemerkt hast, wird das ganze zweimal eingetragen. Nämlich einmal für ausgehende Datenpackete (Die Anfrage) und einmal für die eingehende Datenpackete (Die Antwort).

Und genauso musst du es auch für ssh machen:

```

$IPTABLES -A OUTPUT -o $INTIF1 -p tcp --sport 1024: --dport 22 -j ACCEPT

$IPTABLES -A INPUT -i $INTIF1 -p tcp --sport 22    --dport 1024: -j ACCEPT

```

Wobei du dir den zweiten Eintrag schenken kannst, wenn du IPTABLES sagst, das eingehende Datenpackete erlaubt sind wenn die Verbindung bereits besteht:

```

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

```

Mfg

Sino

----------

## chilla

@sinotech:  wieso gibst du in deinem Beispiel immernoch den 1024er Port an? Hat das eine bestimmte Bedeutung? 

Okay, ich habe nun mal angefangen, von der Theorie zur Praxis zu gehen. Hier mein erster Gehversuch: 

```

IPTABLES='/sbin/iptables'

INTIF='eth0'

echo

echo Beginn der firewallkonfiguration fuer $INTIF:

echo - Die Ketten INPUT, OUTPUT und FORWARD werden geleert.

$IPTABLES -F INPUT

$IPTABLES -F FORWARD

$IPTABLES -F OUTPUT

echo - Alle Ketten bekommen DROP als defaultpolicy

$IPTABLES -P INPUT DROP

$IPTABLES -P OUTPUT DROP

$IPTABLES -P FORWARD DROP

echo

echo

 

echo - DNS Anfragen werden zugelassen

$IPTABLES -A INPUT -p udp -s 192.168.0.2 --sport 53 -j ACCEPT

$IPTABLES -A OUTPUT -p udp -d 192.168.0.2 --dport 53 -j ACCEPT

echo - Pings werden zugelassen

$IPTABLES -A INPUT -p icmp -s 192.168.0.0/24 -j ACCEPT

$IPTABLES -A OUTPUT -p icmp -j ACCEPT

echo - SSH wird zugelassen

$IPTABLES -A INPUT -p tcp -s 192.168.0.0/24 --sport 22 -j ACCEPT

$IPTABLES -A OUTPUT -p tcp --dport 22 -j ACCEPT

echo - www wird zugelassen

$IPTABLES -A INPUT -p tcp --sport 80 -j ACCEPT

$IPTABLES -A OUTPUT -p tcp --dport 80 -j ACCEPT

echo

echo --------------------------------------

# letzte Ausgabe der aktuellen iptables:

echo Konfiguration beendet: 

echo --------------------------------------

$IPTABLES -L

echo --------------------------------------

```

meine iptablessehen schliesslich so aus: 

```

--------------------------------------

Konfiguration beendet:

--------------------------------------

Chain INPUT (policy DROP)

target     prot opt source               destination         

ACCEPT     udp  --  server.lan           anywhere            udp spt:domain 

ACCEPT     icmp --  192.168.0.0/24       anywhere            

ACCEPT     tcp  --  192.168.0.0/24       anywhere            tcp spt:ssh 

ACCEPT     tcp  --  anywhere             anywhere            tcp spt:http 

Chain FORWARD (policy DROP)

target     prot opt source               destination         

Chain OUTPUT (policy DROP)

target     prot opt source               destination         

ACCEPT     udp  --  anywhere             server.lan          udp dpt:domain 

ACCEPT     icmp --  anywhere             anywhere            

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh 

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http 

--------------------------------------

```

Problem1: ping server.lan <- funktioniert. ping heise.de funktioniert nicht. Soll aber. 

Die Antworten von meinen Pings, die ich nach außen gesendet habe, sollen reinkommen. Wenn jemand mich von außen anpingt, und ich rein zufällig hinter einem routersitze, der icmps an meine ip weiterleitet, dann sollen diese jedoch nicht beantwortet werden. 

Soll heissen: icmps werden nur dann erlaubt, wenn sie vom internetn netzwerk kommen (192.168.0.0/24), ODER wenn sie eine ANTWORT auf eine von MIR gestellte pingabfrage sind. 

Wie formuliere ich das auf "iptäblisch", dass er nur Antworten reinlassen soll?

unter iptables -p icmp -h gibt er mir folgende möglichkeiten für icmp: 

 *Quote:*   

> 
> 
> ICMP v1.2.11 options:
> 
>  --icmp-type [!] typename       match icmp type
> ...

 

Mein gefühl sagt mir, ich muss einfach nur "echo-reply" in der INPUT-Kette zulassen. Alles andere wird ja geblockt, und in der OUTPUT-Kette darf ja icmp ungehindert raus. Aber erreiche ich damit auch das, was ich möchte? Bin ich damit auch vor möglichen Ping- attacken geschützt? Oder ist das ein Denkfehler von mir? 

```
$IPTABLES -A INPUT -p icmp --icmp-type echo-reply  -j ACCEPT

$IPTABLES -A OUTPUT -p icmp -j ACCEPT
```

----------

## STiGMaTa_ch

 *chilla wrote:*   

> @sinotech:  wieso gibst du in deinem Beispiel immernoch den 1024er Port an? Hat das eine bestimmte Bedeutung? 

 

Beachte den Doppelpunkt hinter 1024. Damit gibt er nicht den Port 1024 sondern alle Ports von 1024-65535 frei.

Und ja, das hat einen Grund warum man die freigibt  :Laughing: 

Port 22 ist Standardässig für SSH vorgesehen. Das heisst, dies ist der Port auf dem der SSHD Daemon lauschen soll. Wenn du nun eine ssh Verbindung aufbauen willst, dann wählt dein Rechner einen Port oberhalb 1024 für deine Lokale Verbindung.

Falls du dich nun fragst, WARUM man nicht einfach auch Port 22 oder einen anderen FIXEN Port benutzt, hier die simple Antwort:

- Wenn du bei dir ebenfalls einen SSH Daemon laufen hast, der auf deinem Port 22 horcht, dann könntest du ja keine Verbindung mehr zu einem anderen Rechner aufbauen, weil der Port 22 für die Verbindung bereits blockiert ist. Du müsstest also den Daemon killen, eine Verbindung aufbauen, und nach beendigung der Verbindung wieder den Daemon starten.

- würde man nun definieren, dass z.B. Port 2222 für ausgehende Verbindungen nutzbar wären, dann hättest du das Problem, dass du ja nur eine Verbindung aufbauen kannst. Wenn du dann zusätzlich eine Verbindung zu einem anderen Rechner aufbauen wolltest, wäre der Port ebenfalls blockiert.

Aus diesen Gründen werden automatisch Ports oberhalb 1024 für ausgehende Verbindungen genutzt.

 *Quote:*   

> Okay, ich habe nun mal angefangen, von der Theorie zur Praxis zu gehen. Hier mein erster Gehversuch: 
> 
> ```
> 
>  
> ...

 

Hast du einen eigenen DNS Server am laufen? Sprich: Sollen Leute deinen Rechner als DNS Server angeben? Wenn nein, dann braucht es diese Regel nicht! Auch hier gilt: Wenn du eine DNS Anfrage ausführst, dann wird auf 192.168.0.2 irgend ein Port grösser als 1024 zur Verbindung gebraucht.

 *Quote:*   

> 
> 
> ```
> echo - www wird zugelassen
> 
> ...

 

Hier das selbe. Hast du einen eigenen Webserver am laufen, welcher von anderen besucht werden soll? Wenn nein, raus mit der Input Regel.

Lieber Gruss

STiGMaTa

----------

## chilla

 *Quote:*   

> Port 22 ist Standardässig für SSH vorgesehen. Das heisst, dies ist der Port auf dem der SSHD Daemon lauschen soll. Wenn du nun eine ssh Verbindung aufbauen willst, dann wählt dein Rechner einen Port oberhalb 1024 für deine Lokale Verbindung. 

  Uff.. das bedeutet, ich die komplette Portrange für ausgehende Verbindungen freigeben? Das ist eigentlich genau das Gegenteil von dem, was ich mir vorgenommen habe: einzelne Ports freigeben und die Übersicht behalen  :Sad: 

Sino hat geschrieben:

```
$IPTABLES -A INPUT -i $INTIF1 -p udp --sport 53 --dport 1024: -j ACCEPT 
```

 Müsste es dann aber nicht grade umgekehrt sein? Wenn etwas an meinem Rechner ankommt (INPUT-Kette), und ich darauf hören soll, dann "höre" ich doch mit einem bestimmten port. Nur senden tu ich mit "irgendeinem" oberhalb von 1024, der halt gerade frei ist, oder? Der Port, mit dem ich höre, der an meinem Rechner ist, ist dann doch der --dport? Destination heist meines Wissens nach "Ankunft". Also müsste mein "lauschen" auf der Input-kette doch der -dport 53 sein, und beim senden der --sport 1024:. Irgendetwas scheine ich falsch zu verstehen. 

 *Quote:*   

> Hast du einen eigenen DNS Server am laufen? Sprich: Sollen Leute deinen Rechner als DNS Server angeben? Wenn nein, dann braucht es diese Regel nicht! Auch hier gilt: Wenn du eine DNS Anfrage ausführst, dann wird auf 192.168.0.2 irgend ein Port grösser als 1024 zur Verbindung gebraucht. 

 

Jap, auf dieser IP läuft ein Bind, der interne domains (tld: lan) und externe domains verwaltet. Nameserveranfragen sollen ausschliesslich an diese Maschine gehen. Daher die restriktion auf diese IP.

//Edit: 

 *Quote:*   

> Hier das selbe. Hast du einen eigenen Webserver am laufen, welcher von anderen besucht werden soll? Wenn nein, raus mit der Input Regel.

  Nein, auf meinem Rechner läuft kein Webserver. Aber ich will doch die Antworten von meinen Anfragen an andere Webserver auch bekommen. Sollte ich dann nicht die Input-regel stehen lassen, und nur aus -dport  ein -sport machen?

----------

## Freiburg

 *STiGMaTa_ch wrote:*   

>  *chilla wrote:*   @sinotech:  wieso gibst du in deinem Beispiel immernoch den 1024er Port an? Hat das eine bestimmte Bedeutung?  
> 
> Beachte den Doppelpunkt hinter 1024. Damit gibt er nicht den Port 1024 sondern alle Ports von 1024-65535 frei.
> 
> Und ja, das hat einen Grund warum man die freigibt 
> ...

 

Mit verlaub das ist qautsch, ich hab hier auf nem Gateway für an die 200 Leute nicht alle Ports oberhalb von 1024 offen, es gibt welche folgendermaßen bei mir aussieht

```
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
```

Wenn man nun von intern eine Verbindung nach außen aufmacht, von mir aus auch zum ssh, dann wir erkannt das das Antwortpacket RELATED ist und die Verbindung funktioniert ohne Probleme, ohne das man ein Scheunentor offen läßt

----------

## chilla

juhuu  :Smile:  Jetzt kommt die totale Verwirrung  :Very Happy:  Habt ihr noch ne Alternative, nac der ich mein Zauberkugel befragen kann?  :Smile: 

Aber ich muss ehrlich sagen, dass mit dem "related" hört sich sinnvoll an.

----------

## Anarcho

Das halte ich auch für das beste.

In die INPUT Chain nur ports rein, hinter denen auch ein Daemon steht auf den von aussen zugegriffen werden soll (Port 80 für Webserver z.b.).

Alles andere über statefull firewalling regeln.

----------

## toskala

als kleiner tip:

es gibt privilegierte ports und unprivilegierte ports. die unprivilegierten sollte man auflassen ausser mit wenigen ausnahmen, diese sind jedoch streng fallbezogen.

privilegiert sind alle ports unter 1024 (port 22 für ssh, 80 für http usw.)

unprivilegiert sind alle ab 1023 bis 65535 (da haste dann die ganze kommunikation drauf, die keine ports blockieren soll, wie schon im thread gesagt.

am besten verschaffst du dir erstmal einen überblick welche dienste laufen und welche im netzwerk horchen. 

starte dazu

"netstat -alpn | head -n 50"

damit siehst du die ersten 50 zeilen von netstat

sieht bei mir hier grade so aus:

```
nemesis ~ # netstat -alpn | head -n 50

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   

tcp        0      0 0.0.0.0:32769           0.0.0.0:*               LISTEN      11439/licq          

tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      7095/mysqld         

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      7244/apache2        

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      7100/sshd           

tcp        0      0 0.0.0.0:631             0.0.0.0:*               LISTEN      10481/cupsd         
```

da steht noch mehr kram, aber fürs beispiel wirds reichen.

so, nun siehste da z.b. mysqld apache2 und sshd. du willst z.b. nur den sshd von aussen erreichbar haben, also machst du alle ports dicht und lässt selektiv port 22 rein.

sinnvoller ist es jedoch, die dienste so zu konfigurieren, als dass sie gar nicht erst an kritischen interfaces lauschen. also binde den mysqld z.b. nur an localhost 127.0.0.1 dann brauchst du ihn auch nicht explizit mit der firewall auszusperren.

naja, jedenfalls findest du fein heraus was wo lauscht, danach kannst du dann entscheiden was du wie absperren willst.

cheerios,

toskala

----------

## chilla

 *Anarcho wrote:*   

> Das halte ich auch für das beste.
> 
> In die INPUT Chain nur ports rein, hinter denen auch ein Daemon steht auf den von aussen zugegriffen werden soll (Port 80 für Webserver z.b.).
> 
> Alles andere über statefull firewalling regeln.

 

Ich nehme an, du meinst mit "statefull firewalling" soetwas: 

```
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
```

Nach alles, was ich bisher verstanden habe, meine ich aber, dass udp ein "verbindungsloses" protokoll ist. Wenn es aber keine Verbindung gibt, kann auch keine Verbindung hergestellt (ESTABLISHED) sein. Wenn ich also eine anfrage per udp sende, und per udp eine Antwort bekomme, dürfte --state RELATED,ESTABLISHED doch eigentlich nicht matchen, oder? 

Wenn keine Verbindung existiert, endet eine Überprüfung nach bestehender Verbindug nach meiner Logik in einem negativen Ergebnis - ergo, es wird bis ans Ende der Kette gearbeitet, und dort steht die Policy DROP. Oder wird das etwas durch das "RELATED" geregelt?

----------

## Freiburg

Established bezieht sich auf die Packete bislang bestehender Verbindungen, ich würde auf keinen Fall irgendwelche Ports offen lassen die nicht benötigt werden, dafür gibt es das statefull firewalling wei schon richtig gesagt wurde, ansonsten sind wir wieder bei dummen Firewalls die sich nur einzelne Packete ansehen

----------

## SinoTech

 *Freiburg wrote:*   

> 
> 
> [...]
> 
> Mit verlaub das ist qautsch, ich hab hier auf nem Gateway für an die 200 Leute nicht alle Ports oberhalb von 1024 offen, es gibt welche folgendermaßen bei mir aussieht
> ...

 

OK, mein Beispiel war eigentlich nur um zu zeigen das man die eingehenden Packete auch irgendwie durch schleusen muss. Habe aber auch geschrieben das man dem "REALATED" Zeug das ganze etwas übersichtlicher und einfacher gestalten kann.

Mfg

SinoLast edited by SinoTech on Thu Jul 28, 2005 3:39 pm; edited 2 times in total

----------

## SinoTech

 *chilla wrote:*   

> 
> 
> Nach alles, was ich bisher verstanden habe, meine ich aber, dass udp ein "verbindungsloses" protokoll ist. Wenn es aber keine Verbindung gibt, kann auch keine Verbindung hergestellt (ESTABLISHED) sein. Wenn ich also eine anfrage per udp sende, und per udp eine Antwort bekomme, dürfte --state RELATED,ESTABLISHED doch eigentlich nicht matchen, oder? 
> 
> Wenn keine Verbindung existiert, endet eine Überprüfung nach bestehender Verbindug nach meiner Logik in einem negativen Ergebnis - ergo, es wird bis ans Ende der Kette gearbeitet, und dort steht die Policy DROP. Oder wird das etwas durch das "RELATED" geregelt?

 

Also UDP ist zwar ist zwar verbindungslos, aber normal kannst du schon erkennen zu welcher "Verbindung" ein Packet gehört. Bei einer DNS Anfrage beispielsweise wird im UDP Packet auch immer ein Identifier mitgeschickt (16 Bit Zahl) die dann auch in der Antwort zu finden ist.

Davon abgesehen wird auch bei UDP als Sourceport immer ein Port >1024 gewählt, bzw. in der Antwort ist dies dann der Destination port. Auch damit ist eine Idendifikation des Paketes möglich.

Mfg

Sino

----------

## STiGMaTa_ch

 *chilla wrote:*   

>  *Quote:*   Port 22 ist Standardässig für SSH vorgesehen. Das heisst, dies ist der Port auf dem der SSHD Daemon lauschen soll. Wenn du nun eine ssh Verbindung aufbauen willst, dann wählt dein Rechner einen Port oberhalb 1024 für deine Lokale Verbindung.   Uff.. das bedeutet, ich die komplette Portrange für ausgehende Verbindungen freigeben? Das ist eigentlich genau das Gegenteil von dem, was ich mir vorgenommen habe: einzelne Ports freigeben und die Übersicht behalen  

 

Ganz und gar nicht!

Ein

```
$IPTABLES -A OUTPUT -i $INTIF1 -p udp --sport 1024: --dport 22 -j ACCEPT
```

Lässt nur eine Verbindung eines Portes Oberhalb 1024 auf einen anderen Port 22 zu. Wenn du nun einen "bösen Trojaner" hättest, welcher mittels dem Sourceport 10000 eine Verbindung zu einem entfernten Trojaner Server auf Port 1234 aufbauen wollte, dann würde das nicht gehen. Nur, wenn auf dem entfernten Trojaner Server das Ding auf Port 22 laufen würde, dann könnte sich der Trojaner auch damit verbinden.

Natürlich ist das etwas mühsam, da du so für jeden Dienst die Ports oberhalb 1024 freigeben müsstest. Deshalb hast du die Möglichkeit die Firewall mit statefull Regeln zu versehen, die diesbezüglich flexibler sind. Aber ich dachte, ich verschone dich mal für den Anfang damit.  :Wink: 

 *Quote:*   

> Sino hat geschrieben: 
> 
> ```
> $IPTABLES -A INPUT -i $INTIF1 -p udp --sport 53 --dport 1024: -j ACCEPT 
> ```
> ...

 

Nein, Denn wenn du die IP von www.google.de wissen willst, dann baust du eine Verbindung zu deinem DNS Server auf, welcher seinerseits auf Port 53 Horcht. Er selber muss ja keine Verbindung mehr für die Antwort zu dir aufbauen, denn die besteht ja schon.

Hier ein Beispiel aus dem Gentoo Security Handbuch:

```

DNS1=1.1.1.1 # IP des ersten DNS Servers

DNS2=2.2.2.2 # IP des zweiten DNS Servers

 einfo "Erstelle Kette für ausgehenden DNS-Verkehr"

  $IPTABLES -N allow-dns-traffic-out

  $IPTABLES -F allow-dns-traffic-out

  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS1 --dport domain \ 

      -j ACCEPT

  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS2 --dport domain \ 

     -j ACCEPT
```

Wenn du nun aber den Rechner selber als DNS Server betreibst, dann willst du ja zum einen, dass andere Mitglieder in deinem Netz eine Anfrage an dich stellen (diese kommen über die INPUT Chain) und du selber willst bei nichtwissen den DNS deines Providers anfrage (OUTPUT Chain).

Um nun sicherzustellen, dass nur DNS Anfragen von Clients aus deinem Netz kommen und du gleichzeitig DNS Anfragen an DNS1 oder DNS2 senden kannst müsstest du folgende Regeln erstellen:

```
$IPTABLES -A OUTPUT -i $EXTINTF -p udp --sport 1024: -d $DNS1 --dport 53 -j ACCEPT

$IPTABLES -A OUTPUT -i $EXTINTF -p udp --sport 1024: -d $DNS2 --dport 53 -j ACCEPT

$IPTABLES -A INPUT -i $INTINTF -p udp -s 192.168.0.0/24 --dport 53 -j ACCEPT
```

Lieber Gruss

STiGMaTa

----------

## think4urs11

 *chilla wrote:*   

> Die Antworten von meinen Pings, die ich nach außen gesendet habe, sollen reinkommen. Wenn jemand mich von außen anpingt, und ich rein zufällig hinter einem routersitze, der icmps an meine ip weiterleitet, dann sollen diese jedoch nicht beantwortet werden. 
> 
> Soll heissen: icmps werden nur dann erlaubt, wenn sie vom internen netzwerk kommen (192.168.0.0/24), ODER wenn sie eine ANTWORT auf eine von MIR gestellte pingabfrage sind. 
> 
> Mein gefühl sagt mir, ich muss einfach nur "echo-reply" in der INPUT-Kette zulassen. Alles andere wird ja geblockt, und in der OUTPUT-Kette darf ja icmp ungehindert raus. Aber erreiche ich damit auch das, was ich möchte? Bin ich damit auch vor möglichen Ping- attacken geschützt? Oder ist das ein Denkfehler von mir?

 

Normalerweise gibt man neben replys auch unreachables zurück sowie frag needed+time exceeded.

Die sonstigen Typen kannst und solltest du wegfiltern weil die einem potentiellen Angreifer sonst ggf. unnötig viele Details über deine Maschine und/oder das Netzwerk in dem sie steht geben können.

Nur - was soll das bringen nicht auf Ping zu antworten? Außer der vor Urzeiten mal funktionierenden ping of death Geschichte fällt mir kein Grund ein. Jedenfalls kannst du damit keinen ICMP-flood/DoS verhindern, denn die echo Anfragen kommen ja trotzdem bis zu deinem IP-Stack bzw. zur entsprechenden drop rule und belegen damit Bandbreite.

Jaa, ich weiß Microsoft macht das neuerdings mit XP genauso, deswegen ist es aber noch lange nicht sinnvoll oder richtig -> 'security by obsurity'

----------

