iptables skript

Lesenswerte Artikel, Anleitungen und Diskussionen
predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

firewall & dns

Post by predismo » 2003-04-04 19:14

dodolin wrote:

Code: Select all

$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 53 -j ACCEPT
Das letzte sollte wohl eher sport statt dport heissen. Ansonsten sieht es jetzt halbwegs ok aus.
vielen dank. klar sollte das dport heissen. danke!

die states kenne ich. ich beschäftige mich eine weile damit, aber es ist ja auch recht komplex... das hier scheinbar einige fachleute sind (HUT AB!) hier mal dsa ganze firewallscript... bitte macht mich nicht zu sehr nieder, es hat echt genug mühe gekostet. auch mal, um vielleicht für andere noch was feines zu liefern...

Code: Select all

#!/bin/sh
IPTABLES=/usr/sbin/iptables
HIGH_PORTS="1024:65535"

# Benoetigte Module hinzufuegen
/sbin/modprobe ip_conntrack

# Zuruecksetzen aller Regeln
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

# Alle bereits bestehenden Verbindungen erlauben
$IPTABLES -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Erlauben von Loopback-Verbindungen
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

# Erlauben von DNS
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 53 -j ACCEPT

#Erlauben von ident
$IPTABLES -A INPUT -p tcp --dport 113 -j ACCEPT -m limit --limit 2 --limit-burst 4
$IPTABLES -A OUTPUT -p tcp --sport 113 -j ACCEPT -m limit --limit 2 --limit-burst 4

# Erlauben von PING
$IPTABLES -A INPUT -m limit -p ICMP --limit 1 --limit-burst 2 -j ACCEPT
$IPTABLES -A OUTPUT -m limit -p ICMP --limit 1 --limit-burst 2 -j ACCEPT

#Erlauben von HTTP (Server und Client)
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 1024: --dport 80 -j ACCEPT

#Erlauben von HTTPS (Server und Client) - vorbereitung
#$IPTABLES -A INPUT -p tcp --dport 443 -j ACCEPT
#$IPTABLES -A OUTPUT -p tcp --sport 443 -j ACCEPT

#Erlauben von FTP (Client)
$IPTABLES -A INPUT -p tcp --dport 21 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 21 -j ACCEPT

#Erlauben von IMAP (Server und Client)
$IPTABLES -A INPUT -p tcp --dport 143 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 143 -j ACCEPT

#Erlauben von SSH (Server und Client)
$IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 22 -j ACCEPT

#Erlauben von SMTP (Server und Client)
$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 25 -j ACCEPT

#Erlauben von POP (Server und Client)
$IPTABLES -A INPUT -p tcp --dport 110 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 110 -j ACCEPT

# Erlauebn der Zeitsynchonisation
$IPTABLES -A INPUT -p udp --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 123 -j ACCEPT

#Erlauben von MySQL (Server und Clients)
$IPTABLES -A INPUT -p tcp --dport 3306 -j DROP
#ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 3306 -j DROP
## die beiden hier oberhalb sind erstmal mit absicht aus // vorbereitung

#$IPTABLES -A INPUT -p udp --dport 3306 -j ACCEPT
#$IPTABLES -A OUTPUT -p udp --sport 3306 -j ACCEPT

#Erlauben von Webmin (auf port 10000) - vorbereitung
#$IPTABLES -A INPUT -p tcp --dport 10000 -j ACCEPT
#$IPTABLES -A OUTPUT -p tcp --sport 10000 -j ACCEPT

# Erlauben aller hohen Ports fuer passives ftp etc
$IPTABLES -A OUTPUT -p TCP --sport $HIGH_PORTS -j ACCEPT
$IPTABLES -A INPUT -p TCP --dport $HIGH_PORTS -j ACCEPT

#nmap XMAS-Pakete droppen
#dies Pakete sind nicht normal und werden nur von Portscanner verwendet
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

#nmap NULL-Pakete droppen
#dies Pakete sind nicht normal und werden nur von Portscanner verwendet
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# portmap oeffnen
$IPTABLES -A INPUT -p tcp --dport 111 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 111 -j ACCEPT

#ICMP-Fehlermeldungen (Destination unreachable,source quench,TTL exceded,)
#Diese Regeln sollten nicht deaktivert werden, da es sonst Paketverluste gibt
$IPTABLES -A INPUT -p icmp --icmp-type 3 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 4 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 11 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 12 -j ACCEPT

# Schluss und Logging
$IPTABLES -A INPUT -j LOG
$IPTABLES -A OUTPUT -j LOG
$IPTABLES -A INPUT -p tcp --dport auth -j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -j DROP
$IPTABLES -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -p udp -j REJECT
$IPTABLES -A INPUT -j DROP

# final anzeigen was man verbrochen hat
$IPTABLES -L >newtables.asc

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

rootserver-forum-fehler

Post by predismo » 2003-04-04 19:22

Falls die erste Domain per KK-Antrag auf den Rootserver übertragen wurde, erhält man als Ergebnis eines Reverse-Lookups immer pxxxxxxx.pureserver.tld. Die einzige Möglichkeit, dies zu vermeiden, ist also, den Rootserver mit einer "neuen" Domain zu bestellen!
reverse dns auf meine ip (siehe scripte zuvor) ergibt die richtige domain= lockingen.de , die per kk von strato kam... ist also eher out of date....

dodolin
RSAC
Posts: 4009
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: iptables skript

Post by dodolin » 2003-04-05 04:17

[Anmerkung: Ich habe das Thema mal geteilt und hierher verschoben, da es jetzt IMHO mehr zum Thema Security passt.]
bitte macht mich nicht zu sehr nieder, es hat echt genug mühe gekostet.
Das glaube ich dir gerne. Ich habe ja auch mal irgendwann damit angefangen... Wollte dich nicht "niedermachen", aber ich war bereits durch andere Poster etwas gereizt und da ich auch nur ein Mensch bin, musstest du diese Laune dann etwas ausbaden. Sorry!

Ein paar Anmerkungen zu deinem Skript:

Code: Select all

# Alle bereits bestehenden Verbindungen erlauben
$IPTABLES -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
Wenn du das drin hast, dann sind viele deiner Regeln überflüssig, da sie alle als ESTABLISHED bzw. RELATED gelten. Beispiele, was alles überflüssig ist...

Code: Select all

$IPTABLES -A OUTPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 53 -j ACCEPT 
$IPTABLES -A OUTPUT -p tcp --sport 143 -j ACCEPT 
$IPTABLES -A OUTPUT -p tcp --sport 22 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 25 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 110 -j ACCEPT 
#$IPTABLES -A OUTPUT -p udp --sport 3306 -j ACCEPT
#$IPTABLES -A OUTPUT -p tcp --sport 10000 -j ACCEPT 
# Erlauben aller hohen Ports fuer passives ftp etc
$IPTABLES -A OUTPUT -p TCP --sport $HIGH_PORTS -j ACCEPT
$IPTABLES -A INPUT -p TCP --dport $HIGH_PORTS -j ACCEPT 
#ICMP-Fehlermeldungen (Destination unreachable,source quench,TTL exceded,)
#Diese Regeln sollten nicht deaktivert werden, da es sonst Paketverluste gibt
$IPTABLES -A INPUT -p icmp --icmp-type 3 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 4 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 11 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 12 -j ACCEPT
Allgemeine Merkregel: Das Regelskript so kurz wie möglich. Hilft Fehler zu vermeiden. Wie gesagt, obige Regeln sind alle redundant. ICMP ist im Normalfall RELATED, FTP Data Connections ebenso und die Regeln mit --sport sind ESTABLISHED.

Weiters:

Code: Select all

# Erlauben von PING
$IPTABLES -A INPUT -m limit -p ICMP --limit 1 --limit-burst 2 -j ACCEPT
$IPTABLES -A OUTPUT -m limit -p ICMP --limit 1 --limit-burst 2 -j ACCEPT 
Damit erlaubst du nicht "ping", sondern ICMP komplett. Dazu gehören auch unangenehme Dinge, die man eigentlich eher nicht haben will. Zudem dürfte das Limit für ICMP Echo etwas sehr niedrig sein, so rein gefühlsmässig.

Code: Select all

#Erlauben von FTP (Client)
$IPTABLES -A INPUT -p tcp --dport 21 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 21 -j ACCEPT 
Die erste Regel ist nur notwendig, wenn auf deinem Rechner auch ein FTP Server läuft. Du redest allerdings nur von einem FTP Client. Weiss nicht, ob das jetzt Absicht oder versehen ist...?

Code: Select all

# Erlauebn der Zeitsynchonisation
$IPTABLES -A INPUT -p udp --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 123 -j ACCEPT
Damit ist u.U. auch dein NTP Server öffentlich erreichbar. Vermutlich würde folgende Regel zum "Uhrstellen" ausreichen:

Code: Select all

$IPTABLES -A OUTPUT -p udp --dport 123 -j ACCEPT
Müsstest du mal testen, ob er die Antworten dann als RELATED erkennt. Meine Vermutung ist, "ja"... (NTP ist relativ "simpel" in dieser Hinsicht.)

Code: Select all

#Erlauben von MySQL (Server und Clients) 
Wenn nicht unbedingt nötig, sollte man Datenbankzugriff vom Internet aus immer unzugänglich machen (am besten gleich die Datenbank gar nicht erst an IP Interfaces binden) und stattdessen lokal und mit (Unix-)Sockets arbeiten.

Code: Select all

#nmap XMAS-Pakete droppen
#dies Pakete sind nicht normal und werden nur von Portscanner verwendet
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

#nmap NULL-Pakete droppen
#dies Pakete sind nicht normal und werden nur von Portscanner verwendet
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP 
Pseudosicherheit. Aber wer es haben will und wem es ein gutes Gefühl gibt...

Code: Select all

# portmap oeffnen
$IPTABLES -A INPUT -p tcp --dport 111 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 111 -j ACCEPT 
Warum in aller Welt meinst du, du würdest das benötigen und für was benötigst du es? Oben sehe ich jedenfalls keine Dienste, die das benötigen würden. Zudem ist bei RPC Diensten ein Paketfilter sowieso kaum noch zu gebrauchen, da die Ports vom Portmapper ja dynamisch vergeben werden.

Code: Select all

# Schluss und Logging
$IPTABLES -A INPUT -j LOG
$IPTABLES -A OUTPUT -j LOG
$IPTABLES -A INPUT -p tcp --dport auth -j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -j DROP
$IPTABLES -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -p udp -j REJECT
$IPTABLES -A INPUT -j DROP 
Sämtliche LOG Statements sollten mit -m limit versehen werden, um ein Flooding deiner Logs zu verhindern (DoS). Das steht aber u.a. auch im Packet Filtering Howto unter "Advice on paket filter design" oder so ähnlich...

Das Statement mit INPUT -j DROP ist redundant, da ja die Policy bereits DROP ist. IMHO solltest du auch lieber REJECT statt DROP nehmen, siehe dazu http://www.iks-jena.de/mitarb/lutz/usen ... .html#Deny. BTW: Der Autor beschäftigt sich hauptberuflich mit Security und ist eine anerkannte Grösse auf diesem Gebiet (hat u.a. an diversen Security/Crypto RFCs mitgewirkt, den Bundestag in Sachen Security beraten, etc.).

Du siehst, es ist noch viel zu tun...

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

au weia (AUTSCH)

Post by predismo » 2003-04-05 16:56

erstmal tausend dank, aber ich fürchte, da haste einen wunden punkt erwischt... ich war voller hoffnung, endlich mal fertig zu sein...

Habe das Script mal aufgeräumt. Hier die aktuelle Version.. Eines in vorab. Das ganze ist derart komplex, dass ich nen schlechtes Gewissen bekomme, hier derart viel (und so viele Fragen) zu posten. ausserdem habe ich das gefühl, dass ich mich irgendwie noch weiter einlesen müßte... aber schon stunden dabei sass...

das schönste wäre mal von einem experten ein
a. bei dem laufendes script zu sehen zu bekommen oder
b. das jemand mal mein script mit ebenso vielen kommentaren versieht, es versucht zu optimieren bzw meinen kopf zu entwirren...

-tcp verstehe ich ja noch
-udp ok... manchmal brauche ich es, manchmal nicht - lese ich in der services datei nach bzw google ein bischen
aber irgendwie geht mir wohl der zusammenhang zu den realen ports verloren.. HÃ?LFE !!!!

bitte postet nicht sowas wie: mach's selbst... wenn es nach mir geht: es läuft ja so... aber wirklich gut ist es ja scheinbar nicht **SCHNIEF**

ps. danke für den neuen thread :)


Code: Select all

#!/bin/sh
IPTABLES=/usr/sbin/iptables
HIGH_PORTS="1024:65535"

# Benoetigte Module hinzufuegen
/sbin/modprobe ip_conntrack

# Zuruecksetzen aller Regeln
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

# bestehende Verbindungen
$IPTABLES -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
wofinde ich alle bestehenden verbindungen raus?

Code: Select all

# Loopback-Verbindungen
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

# DNS
$IPTABLES -A INPUT -p udp --sport 53 --dport 7531 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 53 --dport 7531 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 1024: --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 1024: --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 53 -j ACCEPT
das monster ist entstanden, da es sonst a. probleme mit meinem nameserver von aussen gab oder b. eine mail an ausserhalb nicht richtrg verschickt werden konnte.

Code: Select all


# ident
$IPTABLES -A INPUT -p tcp --dport 113 -j ACCEPT -m limit --limit 2 --limit-burst 4
$IPTABLES -A OUTPUT -p tcp --sport 113 -j ACCEPT -m limit --limit 2 --limit-burst 4
muss ich ja haben

Code: Select all


# PING
$IPTABLES -A INPUT -m limit -p ICMP --limit 1 --limit-burst 2 -j ACCEPT
$IPTABLES -A OUTPUT -m limit -p ICMP --limit 1 --limit-burst 2 -j ACCEPT
wieso ist das limit zu knappt und : wie lasse ich wirklich nur einen ping, am besten mit nur maximal xy bytes zu?

Code: Select all


# HTTP
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 1024: --dport 80 -j ACCEPT
für die proxies, was ich nicht kapiere ist, warum ich nicht auch nen input von ports >1024 zulassen muss....

Code: Select all


# FTP
$IPTABLES -A INPUT -p tcp --dport 21 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 21 -j ACCEPT

# IMAP
$IPTABLES -A INPUT -p tcp --dport 143 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 143 -j ACCEPT
muss jawohl auch sein

Code: Select all


# SSH
$IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 22 -j ACCEPT

# SMTP
$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 25 -j ACCEPT

# POP
$IPTABLES -A INPUT -p tcp --dport 110 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 110 -j ACCEPT

# Zeitsynchonisation
$IPTABLES -A INPUT -p udp --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 123 -j ACCEPT
ich brauche das doch in beide richtungen, oder? wenn meiner ne zeit abfragt dann per output, aber die antwort ist doch dann wieder nen input, richtig?

Code: Select all


# MySQL -- Vorbereitung (wird dann auf ACCEPT gestellt - so lange soll der Port aber noch blockiert sein)
$IPTABLES -A INPUT -p tcp --dport 3306 -j DROP
$IPTABLES -A OUTPUT -p tcp --sport 3306 -j DROP

# Erlauben aller hohen Ports fuer passives ftp etc
$IPTABLES -A OUTPUT -p TCP --sport $HIGH_PORTS -j ACCEPT
$IPTABLES -A INPUT -p TCP --dport $HIGH_PORTS -j ACCEPT

# nmap XMAS-Pakete droppen
# dies Pakete sind nicht normal und werden nur von Portscanner verwendet
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
ist die vermutung mit den portscanner richtig?

Code: Select all


# nmap NULL-Pakete droppen
# dies Pakete sind nicht normal und werden nur von Portscanner verwendet
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
dito ?????

Code: Select all


# portmap oeffnen
$IPTABLES -A INPUT -p tcp --dport 111 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 111 -j ACCEPT
brauche ich doch nicht wirklich oder wird darüber uach eine verbindung aufgebaut?

Code: Select all


# ICMP-Fehlermeldungen (Destination unreachable,source quench,TTL exceded,)
# Diese Regeln sollten nicht deaktivert werden, da es sonst Paketverluste gibt
$IPTABLES -A INPUT -p icmp --icmp-type 3 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 4 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 11 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 12 -j ACCEPT
die sollten laut einem kollegen explizit so rein...

Code: Select all


# Schluss und Logging
$IPTABLES -A INPUT -j LOG
$IPTABLES -A OUTPUT -j LOG
$IPTABLES -A INPUT -p tcp --dport auth -j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -j DROP
$IPTABLES -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -p udp -j REJECT
$IPTABLES -A INPUT -j DROP

# final anzeigen was man verbrochen hat
$IPTABLES -L

dodolin
RSAC
Posts: 4009
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: iptables skript

Post by dodolin » 2003-04-05 18:01

Das ganze ist derart komplex, dass ich nen schlechtes Gewissen bekomme, hier derart viel (und so viele Fragen) zu posten.
Schön, dass du das einsiehst. Deshalb sagte ich ja, dass man sowas nur einsetzen sollte, wenn man wirklich Ahnung hat, was man da tut, da man sonst mehr Schaden (für sich UND für das Netz) anrichtet, als dass es nutzt.

Um einen Paketfilter zu betreiben, ist es unerlässlich, dass man die Grundlagen von TCP/IP wirklich verstanden und intus hat. Ebenso sollte man die Protokolle (HTTP, DNS, FTP, ...) verstehen, um sie sinnvoll in Verbindung mit Paketfiltern einzusetzen.

Siehe auch hier:
http://www.iks-jena.de/mitarb/lutz/usen ... tml#Lernen

Es wird dir recht wenig nutzen, fertige Skripten zu sehen, denn sowas kommt doch immer ganz auf das Szenario und auf die Policy drauf an, die umgesetzt werden soll.

Wenn du dir die obige FAQ der Newsgruppe de.comp.security.firewall mal komplett durchliest, wirst du vielleicht einsehen, dass ein eine Firewall (z.B. in Form eines Paketfilters) ohne Konzept absolut sinnlos ist. Zuerst sollte man sich überlegen:

- Was will ich erreichen?
- Welche Bedrohungen habe ich und wie könnte ich mich dagegen schützen?
- Was ist erlaubt, was ist verboten?
- usw.

Wenn man sich das für einen Rootserver mal überlegt, kommt man einfach zu dem Schluss, dass ein Paketfilter absolut sinnfrei ist, weil:

- Eingehender Traffic:
Wo kein Dienst lauscht, da wird eine Anfrage sowieso schon vom Betriebssystem zurückgewiesen und wo ein Dienst lauscht, dann soll er ja gerade öffentlich erreichbar sein und muss auch erlaubt sein. Diese Dienste abzusichern, ist sowieso unerlässlich.

- Ausgehender Traffic:
Den zu filtern ist entweder damit gleichzusetzen, dass man sich selbst ins Bein schiesst, wenn man nicht checkt, was man tut und gegen Angriffe ebenso sinnlos. Denn: Wurde der Rechner erst mal gerootet, dann kann der Cracker auch problemlos deinen Paketfilter ausser Gefecht setzen.

Unter diesen Voraussetzungen habe ich ehrlich gesagt, keine grosse Lust, dir da gross weiterzuhelfen, weil ich das Vorhaben einfach für sinnfrei halte (s.o.).

Wenn du mehr lernen willst, kann ich dir z.B. obige Newsgruppe empfehlen, einfach mal nur mitzulesen.

Deinem Skript entnehme ich, dass du das Konzept mit dem Connection Tracking und dem State immer noch absolut nicht verstanden hast.
wofinde ich alle bestehenden verbindungen raus?
Du könntest vor die Regel mit ACCEPT eine genau gleichlautende Regel mit LOG einführen. Aber Vorsicht: Sowas macht man nicht auf öffentlichen Rechnern! Sowas testet man zuhause.
das monster ist entstanden, da es sonst a. probleme mit meinem nameserver von aussen gab oder b. eine mail an ausserhalb nicht richtrg verschickt werden konnte.
Du hast ja das mit dem dport 7531 immer noch drin! Sagte ich nicht bereits, dass dort wahrscheinlich kein DNS Server bei dir laufen wird? Wozu soll diese Regel denn gut sein, wenn ich mal ganz dumm fragen darf? Oder schreibst du einfach irgendwelche Regeln irgendwo ab, deren Sinn du nicht verstanden hast? Sowas ist wirklich gefährlich! Gerade in diesem Bereich.
muss ich ja haben
Nein, musst du nicht, wenn du oben RELATED und ESTABLISHED drin hast. Aber das sagte ich bereits. Und wie gesagt: Ich habe den Eindruck, dass du dieses Konzept nicht verstanden hast.
wieso ist das limit zu knappt und : wie lasse ich wirklich nur einen ping, am besten mit nur maximal xy bytes zu?
Weil 1 Paket pro Sekunde nunmal nicht wirklich tauglich ist. Die Bytes kannst du nicht beschränken, AFAIK. Und du lässt keinen "ping" zu, sondern wenn schon, dann ICMP Type 8 (Echo Request). Wenn du das also auf ICMP Type 8 einschränken möchtest, dann solltest du das tun und nicht komplett alles erlauben, was ICMP ist.

Ich komme auf meine obigen Ausführungen zurück: Es ist unerlässlich, dass man die Protokolle TCP/IP (dazu gehört auch ICMP) verstanden hat. Und zwar nicht nur so ein bisschen, sondern richtig. Literatur siehe obiger Link. Sowas lernt man nunmal nicht in ein paar Tagen.
für die proxies, was ich nicht kapiere ist, warum ich nicht auch nen input von ports >1024 zulassen muss....
Was an einem DPORT 80 mit Proxies zu tun hat, ist mir noch nicht ganz klar. SPORTS > 1024 musst du nicht explizit zulassen, wenn du zu SPORT überhaupt keine Angaben machst. Denn dann sind einfach alle SPORTS erlaubt.
ch brauche das doch in beide richtungen, oder? wenn meiner ne zeit abfragt dann per output, aber die antwort ist doch dann wieder nen input, richtig?
Siehe oben: Ã?berlege dir zuerst, was du überhaupt erreichen willst. Willst du einen öffentlichen NTP Server betreiben oder willst du lediglich per NTP die Uhr auf deinem eigenen Rechner stellen? Wenn letzteres, dann hatte ich doch oben dazu bereits etwas gesagt. Ist da was unklar? Ich fürchte, dir ist alles unklar, weil dir einfach die nötigen Grundlagen fehlen, um die Zusammenhänge zu verstehen...
ist die vermutung mit den portscanner richtig?
AFAIK (und ohne Gewehr) ja. TCP Pakete, in denen alle oder gar keine TCP Flags gesetzt sind, kommen in "normaler" Kommunikation nicht vor. Wenn du dich mit TCP auseinandergesetzt hättest (s.o.), dann wüsstest du das selbst.
brauche ich doch nicht wirklich oder wird darüber uach eine verbindung aufgebaut?
Siehst du, du hast Regeln, von denen du gar nicht weisst, was sie tun. Solange das der Fall ist, solltest du die Finger von Paketfiltern lassen. Woher soll ich wissen, ob du die Regeln brauchst? Weiss ich, was du für Dienste betreiben möchtest, wie dein Konzept aussieht, etc.?
die sollten laut einem kollegen explizit so rein...
Dann hat auch dieser "Kollege" das Konzept mit RELATED nicht verstanden.

Sorry, wenn ich schon wieder so deutliche Worte wähle, aber man kann das nicht oft genug sagen. Das ist nicht gegen dich persönlich gerichtet und es wäre mir auch zuviel Nachdenken, wenn ich mir erst noch Gedanken machen sollte, wie ich das jetzt nett verpacke. Siehe dazu den Link in meiner Signatur, vielleicht wird es dann klarer, dass es meist nicht so gemeint ist.
Dealing with rudeness

Much of what looks like rudeness in hacker circles is not intended to give offence. Rather, it's the product of the direct, cut-through-the-bullshit communications style that is natural to people who are more concerned about solving problems than making others feel warm and fuzzy.

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

moerderiche laenge :) aber erstmal danke an alle dies lesen

Post by predismo » 2003-04-05 22:16

nimms bitte nicht persönlich, aber einer von uns beiden erzählt naja -- nicht das richtige... ich habe jetzt nochmal sorgfälig geprüft und lasse mich natürlich gerne eine besseren belehren....

eines aber in vorab:
sinn oder unsinn einer firewall moechte ich nicht diskutieren - ich will eben etwas "besseres" als nur die hosts.allow bzw hosts.deny zu nutzen, die eigentlich eine sehr gute möglichkeit darstellen, um dienste, die man nicht abschalten kann - aber auch nicht haben will, nicht für die öffentlichlichkeit sichtbar zu machen.
abgesehen davon scannen genug leute (mit genug zeit und geld) auf lücken, so dass der sicherheitsaspekt der wichtigste ist. da hilft nur learning by doing and reading...



die anfangsbuchstaben dienen nur zum späteren besseren zuteilen

a.
nachdem ich den ("""unnötigen""") udp-teil aus dem dns-bereich rausgenommen hatte, konnte mein mailserver kein relaying mehr, weil die ip des empfängers nicht mehr ausgewertet werden konnte.
daher kam es, das ich erstmal wieder ein backup zurück gegangen bin...

b.
weshalb port 7531 wieder da war -- ist natürlich reinrassiger schwachsinn (war mal nen test)

c.
die hohen ports für ftp (ein ftp-server läuft) usw (was ich da geschrieben hatte) MÃ?SSEN ebenfalls bleiben, sonst funktioniert der passive ftp nicht mehr

d.
icmp-type müssen auch bleiben, nachdem ich den "ping" - teil auf type 8 beschrängt habe (davor hattest du natürlich rehct, aber: nichts ist, wie es bleiben soll grins). icmp-type 3,4,8,11,12 werden nun erlaubt...

e.
zeitsyncho -> output auf udp sollte deiner meinung nach reichen.
evtl ist das ja dann related - aber ich (noch) null ahnung (bisher keien fehlermeldung) - warten wird ab. :)
kommt die antwort (die differenz) dann nicht im input an?!?!?

f.
portmap : reinrassigster blödsin, ist raus (nfs)

g.
-m limit wegen flooding der logs -> paket filtering howto "advice on paket filter design"

gute adressen dazu:
http://www.netfilter.org/documentation/ ... html#ss3.3
http://www.pl-berichte.de/work/snort/index.html
http://www.iptables.org/documentation/H ... TO-11.html

bin noch am lesen

h.
> redundates -A input -j drop
ist goldrichtig und entfernt.

i.
> reject statt drop
ist jetzt so (ausser bei portscannereien)

j.
[ident] -> muss ich ja haben -> nein, musst du nicht wg related und est

bei smtp brauche ich das, es wird empfohlen diesen port offen zu halten.
ident wird zwischen smtp-servern zur verifikation der emailadresse benötigt.
frage ich nur, ob dsa nich doch lieber gedropt werden sollte, da es scheinbar nen beliebtes angriffsziel (für scanproleten) ist...

k.
1 paket pro sekunden. doch, finde ich gut :)
überlege ich mich aber nochmal mit g :) gibt ja schönere möglichkeiten...

l.
proxy http -- haste recht - ist geändert
im http war natürlich der output-teil überflüssig...

m.
> kollegen (icmp)
-> das war ne komisch entwicklung - jetzt stimmt es ja wieder
mein fehler

n.
imap brauche ich nicht. (nur pop von den clients, wenn es jmd braucht gebe ich dsa lieber wieder frei)



Und als Ã?bersicht hier der nun aktuelle Code:

Code: Select all

#!/bin/sh
IPTABLES=/usr/sbin/iptables
HIGH_PORTS="1024:65535"

# Benoetigte Module hinzufuegen
/sbin/modprobe ip_conntrack

# Zuruecksetzen aller Regeln
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

# bestehende Verbindungen
$IPTABLES -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Loopback-Verbindungen
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

# DNS
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 53 -j ACCEPT

# ident
$IPTABLES -A INPUT -p tcp --dport 113 -j ACCEPT -m limit --limit 2 --limit-burst 4
$IPTABLES -A OUTPUT -p tcp --sport 113 -j ACCEPT -m limit --limit 2 --limit-burst 4

# HTTP
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT

# FTP
$IPTABLES -A INPUT -p tcp --dport 21 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 21 -j ACCEPT

# IMAP
$IPTABLES -A INPUT -p tcp --dport 143 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 143 -j ACCEPT

# SSH
$IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 22 -j ACCEPT

# SMTP
$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 25 -j ACCEPT

# POP
$IPTABLES -A INPUT -p tcp --dport 110 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 110 -j ACCEPT

# Zeitsynchonisation - output sollte angeblich reichen
# mal abwarten $IPTABLES -A INPUT -p udp --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 123 -j ACCEPT

# MySQL -- Vorbereitung (wird dann auf ACCEPT gestellt - so lange soll der Port aber noch blockiert sein)
$IPTABLES -A INPUT -p tcp --dport 3306 -j REJECT
$IPTABLES -A OUTPUT -p tcp --sport 3306 -j REJECT

# Erlauben aller hohen Ports fuer passives ftp etc
$IPTABLES -A OUTPUT -p TCP --sport $HIGH_PORTS -j ACCEPT
$IPTABLES -A INPUT -p TCP --dport $HIGH_PORTS -j ACCEPT
$IPTABLES -A OUTPUT -p UDP --sport $HIGH_PORTS -j ACCEPT
$IPTABLES -A INPUT -p UDP --dport $HIGH_PORTS -j ACCEPT

# nmap XMAS-Pakete droppen - Postscanner
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# nmap NULL-Pakete droppen - Portscanner
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# PING
$IPTABLES -A INPUT -m limit -p ICMP --limit 1 --limit-burst 2 --icmp-type 8 -j ACCEPT
$IPTABLES -A OUTPUT -m limit -p ICMP --limit 1 --limit-burst 2 --icmp-type 8 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 3 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 4 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 11 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 12 -j ACCEPT

# Schluss und Logging
$IPTABLES -A INPUT -j LOG
$IPTABLES -A OUTPUT -j LOG
$IPTABLES -A INPUT -p tcp --dport auth -j REJECT --reject-with tcp-reset
$IPTABLES -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -p udp -j REJECT
$IPTABLES -A INPUT -j DROP
# drop gefaellt mir hier auch irgendwie besser

# final anzeigen was man verbrochen hat
$IPTABLES -L >/root/iptables.new
tail -f /var/log/messages /var/log/mail

Vielen Dank für jede Hilfe - es kann ja nur besser werden ;)

captaincrunch
Userprojekt
Userprojekt
Posts: 7225
Joined: 2002-10-09 14:30
Location: Dorsten

Re: iptables skript

Post by captaincrunch » 2003-04-06 00:04

Du weißt aber schon, das du Passive FTP auch ganz einfach über RELATED-states hinbekommen kannst, und dass (wie dodlin schon sagte) die Highports komplett überflüssig sind ?

Desweiteren :
1. Du schreibst, dass du die Deafult-Policy wieder auf REJECT gesetzt hast. In deinem Code-Snippet kann ich aber dafür nur weiterhin DROP erkennen.

2. Wozu machst du dir mit den Output-Regeln das Leben schwerer ? Auch das hatte dodolin schon geschreiben. Sobald jemand mit genügend Verstand (durch eine Lücke in einem deiner Dienste) auf dem Server ist, ist das erste was er macht, deine sauber ausgetüftelten Regeln außer Kraft zu setzen ...

3. Ich dachte, du bräuchtest kein IMAP. Wozu hast du es dann immer noch drin ?

4. Du brauchst definitiv nicht sämtliche ICMP-Typen zu erlauben. Wichtige Typen sind 8 und 11

5. Zu guter Letzt veruchst du noch, weitere "Standardregeln" zu definieren, die du ganz oben aber schon ganz anders (durch -P) drin hast.

Sorry, also insgesamt sieht es mir eher danach aus, als würdest du die Thematik nicht wirklich durchblicken (wobei ich von dodolin weiß, dass er es blickt ...). Nicht persönlich gemeint ...
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

dodolin
RSAC
Posts: 4009
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: iptables skript

Post by dodolin » 2003-04-06 03:34

nimms bitte nicht persönlich, aber einer von uns beiden erzählt naja -- nicht das richtige... ich habe jetzt nochmal sorgfälig geprüft und lasse mich natürlich gerne eine besseren belehren....
Nuja, ich hatte dir jetzt bereits zweimal versucht, das zu erklären, aber scheinbar ist dir da noch was unklar, vorsichtig ausgedrückt.
dienste, die man nicht abschalten kann - aber auch nicht haben will
Hast du dafür mal ein konkretes Beispiel?
abgesehen davon scannen genug leute (mit genug zeit und geld) auf lücken, so dass der sicherheitsaspekt der wichtigste ist.
Du hast dadurch keine höhere Sicherheit. Und wenn du vor ein bisschen Portscannen schon Angst hast... hm, dann kann man dir wohl auch nicht helfen.
http://www.iks-jena.de/mitarb/lutz/usen ... l#Portscan
Das, was du betreibst, nennt man Personal Firewall. Ein Paketfilter, der auf dem selben System läuft, das er schützen soll. Lies dazu mal: http://www.iks-jena.de/mitarb/lutz/usen ... ll.html#PF. Aber das hatte ich ja schonmal oben geschrieben. Ich scheine mich zu wiederholen.

Lies ebenso mal http://www.iks-jena.de/mitarb/lutz/usen ... mpensation. Das trifft wohl auch auf dich zu.
nachdem ich den ("""unnötigen""") udp-teil aus dem dns-bereich rausgenommen hatte, konnte mein mailserver kein relaying mehr, weil die ip des empfängers nicht mehr ausgewertet werden konnte.
Nuja, das passiert halt, wenn man Leuten wie RobertW glaubt, ohne sich selbst schlau zu machen und sich selbst eine Meinung zu bilden. Ich hatte bestimmt nie behauptet, dass UDP für DNS unnötig ist.
die hohen ports für ftp (ein ftp-server läuft) usw (was ich da geschrieben hatte) MÃ?SSEN ebenfalls bleiben, sonst funktioniert der passive ftp nicht mehr
Nein, müssen sie nicht. Und ich werde das jetzt nicht noch weitere 3mal wiederholen.
icmp-type müssen auch bleiben, nachdem ich den "ping" - teil auf type 8 beschrängt habe (davor hattest du natürlich rehct, aber: nichts ist, wie es bleiben soll grins). icmp-type 3,4,8,11,12 werden nun erlaubt...
Nein, müssen sie nicht, weil das alles RELATED ist. Sag mal, hast du eigentlich schonmal nen Blick in die manpage geworfen?
state
This module, when combined with connection tracking,
allows access to the connection tracking state for this
packet.

--state state
Where state is a comma separated list of the con­
nection states to match. Possible states are
INVALID meaning that the packet is associated with
no known connection, ESTABLISHED meaning that the
packet is associated with a connection which has
seen packets in both directions, NEW meaning that
the packet has started a new connection, or other­
wise associated with a connection which has not
seen packets in both directions, and RELATED mean­
ing that the packet is starting a new connection,
but is associated with an existing connection, such
as an FTP data transfer, or an ICMP error.
> reject statt drop
ist jetzt so (ausser bei portscannereien)
Nein, hast du bisher nur für UDP, nicht aber für TCP.
> redundates -A input -j drop
ist goldrichtig und entfernt.
Nein, ist immer noch drin. Sag mal...?!
[ident] -> muss ich ja haben -> nein, musst du nicht wg related und est

bei smtp brauche ich das, es wird empfohlen diesen port offen zu halten.
ident wird zwischen smtp-servern zur verifikation der emailadresse benötigt.
frage ich nur, ob dsa nich doch lieber gedropt werden sollte, da es scheinbar nen beliebtes angriffsziel (für scanproleten) ist...
Wie ich bereits vorher schon sagte: Mache dich doch erst mal schlau, was ident überhaupt ist.

Lesetipps: http://www.fefe.de/docs/ident.txt
http://www.rfc-editor.org/rfc/rfc1413.txt

Nochmal: Würdest du sinnigerweise alles sauber rejecten, bräuchtest du keine extra Regel für ident. Du bräuchtest sowieso überhaupt keine Regel, denn hättest du einen identd laufen, würde er antworten, hättest du keinen laufen, würde es sowieso rejected.
1 paket pro sekunden. doch, finde ich gut
Nuja, dann machst du halt genauso das Internet kaputt, wie es z.B. die unfähigen Firewall Admins von GMX und zahlreichen anderen Sites tun. Aber bitte schön... Ich wiederholfe mich ungerne, deshalb sage ich dazu jetzt nichts mehr. Wer nicht lernen will, der hat schon...
überlege ich mich aber nochmal mit g gibt ja schönere möglichkeiten...
Welche denn? Das würde mich jetzt mal interessieren...
> kollegen (icmp)
-> das war ne komisch entwicklung - jetzt stimmt es ja wieder
mein fehler
Nein, es ist immer noch viel zu viel redundantes Zeug drin.

Code: Select all

# DNS
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 53 -j ACCEPT 
Die letzten 2 Regeln machen ausschliesslich dann Sinn, wenn du einen lokalen DNS als Resolver laufen hast und dieser mit query-source-port 53 konfiguriert ist. Ansonsten sollte das nämlich nicht --sport 53, sondern --dport 53 heissen.

Aber ich sagte ja bereits, dass man sich nur selbst das Leben schwer macht, wenn man auch noch in OUTPUT filtern will...

Code: Select all

# Zeitsynchonisation - output sollte angeblich reichen
# mal abwarten $IPTABLES -A INPUT -p udp --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 123 -j ACCEPT 
Das ist zwar nicht das, was ich dir oben dafür genannt hatte, aber wenn du Glück hast, dann funktioniert es auch so. Ich bin mir aber nicht sicher, ob NTPD immer den Sourceport 123 benutzt... Jedenfalls kann sich so schonmal kein normaler User die Zeit eines externen NTP Servers anzeigen lassen.

Nuja, ich hatte dir ja bereits vorher schonmal geschrieben, welche Regeln du alle ersatzlos streichen könntest, weil sie redundant sind. Wenn du meinst, du weisst es besser, ok... aber ich werde das jetzt kein drittes Mal wiederholen.
CaptainCrunch wrote:4. Du brauchst definitiv nicht sämtliche ICMP-Typen zu erlauben. Wichtige Typen sind 8 und 11
Man braucht eigentlich gar nichts explizit erlauben, wenn man alles RELATED erlaubt. Denn das, was man von ICMP haben will, sind Fehlermeldungen aller Art. Diese gibt es logischerweise nur, wenn vorher bereits eine Verbindung bestand oder man eine neue Verbindung aufbauen möchte. Somit ist das, was man haben will alles RELATED, siehe auch der Abschnitt der manpage oben.

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

danke für die geduld

Post by predismo » 2003-04-06 14:15

danke danke danke -das nur erstmal in vorab...

1.
ident: habe ich nicht verstanden, sorry. ich lasse es erstmal an, bevor ich irgendwas kaputt mache.

2.
wenn ich

Code: Select all

$IPTABLES -A INPUT -p TCP --dport $HIGH_PORTS -j ACCEPT
rausnehme, dann klappt passive ftp nicht mehr.

3.
wenn ich

Code: Select all

$IPTABLES -A INPUT -m limit -p ICMP --limit 1 --limit-burst 2 --icmp-type 8 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 3,4,11,12 -j ACCEPT
rausnehme kommt nichts mehr zurück.

4.
es war zu lesen, das icmp immer mit limit vergeben werden sollte... nun sagst du mir aber das ein einsekündliches limit schwachsinn ist (und ich eigentlich auch nur weniger durchlassen muss). ganz blöde frage. wie hast du es denn?

5.
das ende habe ich umgebaut in

Code: Select all

$IPTABLES -A INPUT -j REJECT
wäre es evtl sinnvoller daraus ein

Code: Select all

$IPTABLES -A INPUT -p udp -j REJECT
$IPTABLES -A INPUT -p tcp -j REJECT
$IPTABLES -A INPUT -j DROp
zu machen?



hier das ganze script (NEU) :)

Code: Select all

#!/bin/sh
IPTABLES=/usr/sbin/iptables
HIGH_PORTS="1024:65535"

# Benoetigte Module hinzufuegen
/sbin/modprobe ip_conntrack

# Zuruecksetzen aller Regeln
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

# bestehende Verbindungen
$IPTABLES -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Loopback-Verbindungen
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

# DNS
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT

# ident
$IPTABLES -A INPUT -p tcp --dport 113 -j ACCEPT -m limit --limit 2 --limit-burst 4
$IPTABLES -A OUTPUT -p tcp --sport 113 -j ACCEPT -m limit --limit 2 --limit-burst 4

# HTTP
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT

# FTP
$IPTABLES -A INPUT -p tcp --dport 21 -j ACCEPT

# IMAP
$IPTABLES -A INPUT -p tcp --dport 143 -j ACCEPT

# SSH
$IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT

# SMTP
$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT

# POP
$IPTABLES -A INPUT -p tcp --dport 110 -j ACCEPT

# Zeitsynchonisation
$IPTABLES -A OUTPUT -p udp --dport 123 -j ACCEPT

# MySQL -- Vorbereitung (wird spaeter auf ACCEPT gestellt)
$IPTABLES -A INPUT -p tcp --dport 3306 -j REJECT

# Erlauben aller hohen Ports fuer passives ftp etc
$IPTABLES -A INPUT -p TCP --dport $HIGH_PORTS -j ACCEPT
$IPTABLES -A OUTPUT -p UDP --sport $HIGH_PORTS -j ACCEPT
$IPTABLES -A INPUT -p UDP --dport $HIGH_PORTS -j ACCEPT

# nmap XMAS-Pakete droppen - Postscanner
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j REJECT

# nmap NULL-Pakete droppen - Portscanner
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j REJECT

# PING
$IPTABLES -A INPUT -m limit -p ICMP --limit 1 --limit-burst 2 --icmp-type 8 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 3,4,11,12 -j ACCEPT

# Schluss und Logging
$IPTABLES -A INPUT -j LOG
$IPTABLES -A OUTPUT -j LOG
$IPTABLES -A INPUT -p tcp --dport auth -j REJECT --reject-with tcp-reset
$IPTABLES -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset

#$IPTABLES -A INPUT -p udp -j REJECT
#$IPTABLES -A INPUT -p tcp -j REJECT
$IPTABLES -A INPUT -j REJECT

# final anzeigen was man verbrochen hat
$IPTABLES -L >/root/iptables.new
tail -f /var/log/messages /var/log/mail

in der argen hoffnung nun dem ende endlich ein sattes stück näher gekommen zu sein.

captaincrunch
Userprojekt
Userprojekt
Posts: 7225
Joined: 2002-10-09 14:30
Location: Dorsten

Re: iptables skript

Post by captaincrunch » 2003-04-06 14:21

in der argen hoffnung nun dem ende endlich ein sattes stück näher gekommen zu sein.
Was die Sicherheit in vernetzten Systemen angeht, ist man nie "fertig" oder "am Ende". Ein Satz, den ich hier schon mal geschrieben hatte :
"Security ist kein Zustand, sondern ein ständiger Prozess"
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

mail

Post by predismo » 2003-04-06 14:23

musste leider feststellen, dass nun keine mail mehr an weitere smtp-server weitergeleitet werden. lösung? bin am basteln

Code: Select all

==> /var/log/messages <==
Apr  6 14:25:35 p15122592 kernel: IN= OUT=eth0 SRC=217.160.177.210 DST=192.67.198.32 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=32872 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Apr  6 14:25:35 p15122592 kernel: IN= OUT=eth0 SRC=217.160.177.210 DST=192.67.198.48 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=25956 DF PROTO=TCP SPT=32873 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Apr  6 14:25:35 p15122592 kernel: IN= OUT=eth0 SRC=217.160.177.210 DST=192.67.198.37 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=25956 DF PROTO=TCP SPT=32874 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0

==> /var/log/mail <==
Apr  6 14:25:35 p15122592 postfix/smtp[23776]: connect to mailin.webmailer.de[192.67.198.32]: Connection refused (port 25)
Apr  6 14:25:35 p15122592 postfix/smtp[23776]: connect to mailin.webmailer.de[192.67.198.48]: Connection refused (port 25)
Apr  6 14:25:35 p15122592 postfix/smtp[23776]: connect to mailin.webmailer.de[192.67.198.37]: Connection refused (port 25)

$IPTABLES -A OUTPUT -p UDP --sport $HIGH_PORTS -j ACCEPT

kann theoretisch auch raus.?!

eigentlich sollte der

$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT

doch eine nachricht akzeptieren?

wieso tut das nun wieder nicht. hat das nun wieder was mit dns zu tun?

dodolin
RSAC
Posts: 4009
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: iptables skript

Post by dodolin » 2003-04-06 14:41

1. ident: Hast du die 2 Links von mir gelesen?
Wenn deine Reject Regeln am Ende passen, dann brauchst du das oben für ident nicht noch mal extra zu machen. Das ist alles, was ich dir sagen wollte.

Weiters: Ich weiss nicht, wo du das mit dem identd/unsicher/cracken her hast, aber ich persönlich habe auf allen meinen Rechnern identd laufen...

2. HighPorts und Passive FTP:
Du musst das Modul ip_conntrack_ftp laden, dann funzt das.

3. Die erste der beiden Regeln sollte genügen. Die zweite ist überflüssig, da RELATED. Wenn du die erste Regel rausnimmst, geht dein "ping" nicht mehr, das ist klar.

4. ICMP und limit:
Wo war das zu lesen, dass ICMP immer mit limit benutzt werden sollte? Ich sagte lediglich, dass LOG immer mit limit benutzt werden sollte. Wie ich es habe, fragst du? Ich habe keinen Paketfilter. Somit ist alles unbegrenzt und ohne limit. Ist absolut krass sicher! :lol:

5. REJECT Regeln am Ende:
Am sinnigsten wäre IMHO sowas:

Code: Select all

iptables -A INPUT -p TCP -j REJECT --reject-with tcp-reset
iptables -A INPUT -j REJECT
Sonst wird nämlich auch TCP mit einem ICMP Port unreachable beantwortet. Das ist zwar laut RFC nicht falsch, aber trotzdem gibt es viele Clients draussen im Einsatz, die das nicht korrekt auswerten.

Zum Skript:
* Dir fehlt jetzt der OUTPUT für DNS. Somit kannst du selbst nichts mehr resolven.

* Wenn du auch Mails verschicken möchtest, dann fehlt dir natürlich auch der OUTPUT für SMTP.

* Zu MySQL hatte ich schonmal was gesagt. Brauchst du denn den Zugriff auf die DB übers Internet wirklich zwingend?

* Wenn du deine "Portscanner" Pakete jetzt REJECTest, dann kannst du dir das auch sparen, da du das am Ende ja sowieso machst.

* Du willst nie etwas per HTTP oder FTP auf deinen Rootie laden? Spielst du keine Security Updates ein, oder wie machst du das? Per SCP?

Anmerkung zu deiner Ergänzung mit SMTP:
Ich habe die Vermutung, dass du noch nicht mal richtig zwischen eingehenden und ausgehenden Verbindungen unterscheiden kannst.

Ich sagte ja bereits, dass es äusserst sinnig wäre, wenn du dich erst mal in Ruhe hinsetzt und dir überlegst:

* Welche Dienste du öffentlich anbieten möchtest.
* Welche Dienste du selbst von deinem Rootie aus nutzen möchtest.

Und danach:
* Welche Regeln du dafür brauchst, um das alles zu ermöglichen.

Nochmal EDIT: Wenn du es dann NOCH besser machen möchtest, solltest du dir mal die Kernel-Doc im Verzeichnis networking ansehen, insbesondere ip-sysctl.txt.
Last edited by dodolin on 2003-04-06 14:55, edited 1 time in total.

Anonymous

Re: mail

Post by Anonymous » 2003-04-06 14:54

predismo wrote:musste leider feststellen, dass nun keine mail mehr an weitere smtp-server weitergeleitet werden. lösung? bin am basteln
[...]
wieso tut das nun wieder nicht. hat das nun wieder was mit dns zu tun?
Du bist wirklich niedlich. Fast jede Anwendung, die sich mit einem fremden Rechner unterhalten will, braucht DNS, um erst mal dessen IP rauszukriegen. Und da der eigene DNS nur die eigenen Domains kennt, muß der sich zwangsläufig und möglichst ungestört mit seinen Kollegen unterhalten können.

Nachdem Dir hier schon einige kompetende Köppe mitgeteilt haben, daß es sinnfrei ist, auf einem Sigle-Rechner eine Firewall einzusetzen, die wild und zu allem entschlossen mit irgendwelchen zusammengeklaubten Paketfilter-Regeln das System mehr oder weniger lahmegt, und Dir nahegelegt haben, Dir vorher die für TCP/IP Manipulationen erforderlichen Kenntnisse anzulesen, frage ich mich wirklich, was Du da treibst.

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

dodolin, my hero

Post by predismo » 2003-04-06 21:17

wow... hut ab für die geduld grins

1.
eigentlich sollte doch
$IPTABLES -A OUTPUT -p udp --dport 123 -j ACCEPT
raus können, da der output via udp ja sowieso nicht eingeschränkt ist.

2.
mysql habe ich rausgenommen, wird sowieso rejected; wenn ich es doch mal brauche, brauche ich nur auszukommentieren.

3.
mit ident hast du natürlich recht, ist raus :)

4.
smtp out und dns out -regeln habe ich erstellt.

5.
wieso muss
$IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT
sein... wie gesagt. der output für udp ist doch wirklich nicht eingeschränkt.


dns-part

Code: Select all

# DNS
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT
[/quote]

dodolin
RSAC
Posts: 4009
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: iptables skript

Post by dodolin » 2003-04-07 01:02

In der Tat. Das war mir irgendwie durch die Lappen gegangen, dass du UDP in OUTPUT nicht REJECTest. Das ist ja jetzt aber vollkommen inkonsistent. Warum REJECTest du TCP in OUTPUT, UDP aber nicht? Steckt da irgendeine tiefere Logik dahinter?

Entweder habe ich eine DENY ALL Policy oder nicht. Nu ja, ist halt wie immer nur meine Meinung...

Dann kannst du natürlich alle Regeln für UDP in OUTPUT streichen.

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

brauch ich eben doch - warum ist mir unklar

Post by predismo » 2003-04-07 08:21

ich brauche eben doch die regeln für udp im output:

1.
ohne ein
$IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT
klappt z.b. ping von lokal an extern nicht mehr.
warum nicht? udp-output ist doch nicht eingeschränkt.

2.
wieso brauche ich
$IPTABLES -A OUTPUT -p tcp --dport 25 -j ACCEPT
?
der tcp output ist doch eigentlich auch uneingeschränkt möglich.

liegt das evtl daran, dass diese noch nicht related sind und der rest (ftp, ssh) bereits related vorhanden ist - fänd ich aber auch irgendwie nicht wirklich logisch.

3.
es läuft so, wie es ist.. die inkonsistenz mit udp muss natürlich noch raus; ich hoffe dsa alleine zu schaffen. laut services müßte ich doch sehen können, welcher port udp/tcp benötigt. unklar ist mir nur wirklich noch immer
wenn eine verbindung per ssh aufgebaut werden soll ist der input-part gefragt. aber er server antwortet doch auch - und das sollte doch output sein - und solch eine regel muss nicht erstellt werden; ist das wieder related?



herzlichen dank bereits in vorab

Code: Select all

#!/bin/sh
IPTABLES=/usr/sbin/iptables
HIGH_PORTS="1024:65535"

# Benoetigte Module hinzufuegen
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp

# Zuruecksetzen aller Regeln
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

# bestehende Verbindungen
$IPTABLES -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Loopback-Verbindungen
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

# DNS
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT

# HTTP
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT

# FTP
$IPTABLES -A INPUT -p tcp --dport 21 -j ACCEPT

# IMAP
$IPTABLES -A INPUT -p tcp --dport 143 -j ACCEPT

# SSH
$IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT

# SMTP
$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 25 -j ACCEPT

# POP
$IPTABLES -A INPUT -p tcp --dport 110 -j ACCEPT

# Zeitsynchonisation
# $IPTABLES -A OUTPUT -p udp --dport 123 -j ACCEPT

# MySQL -- Vorbereitung
# $IPTABLES -A INPUT -p tcp --dport 3306 -j ACCEPT

# nmap XMAS-Pakete droppen - Postscanner
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# nmap NULL-Pakete droppen - Portscanner
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# PING
$IPTABLES -A INPUT -m limit -p ICMP --limit 1 --limit-burst 2 --icmp-type 8 -j ACCEPT
$IPTABLES -A OUTPUT -p ICMP --icmp-type 8 -j ACCEPT

# Logging
$IPTABLES -A INPUT -j LOG
$IPTABLES -A OUTPUT -j LOG

# Alles andere REJECTEN (TCP mit einem ICMP Port unreachable)
$IPTABLES -A INPUT -p TCP -j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -j REJECT

# Anzeige
$IPTABLES -L >/root/iptables.new
tail -f /var/log/messages /var/log/mail

captaincrunch
Userprojekt
Userprojekt
Posts: 7225
Joined: 2002-10-09 14:30
Location: Dorsten

Re: iptables skript

Post by captaincrunch » 2003-04-07 09:20

ich brauche eben doch die regeln für udp im output:
Die Frage, die sich mir ganz grundsätzlich stellt ist, warum du deine Energien überhaupt so sehr auf die Output-Rules verschwendest ?!?
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

genau

Post by predismo » 2003-04-07 09:30

@captaincrunch

genau das ist es ja.. ich möcjhte den output eigentlich unangetastet lassen. aber aus irgendwelchen gründen brauhce ich die output-regeln ja, da sonst z.b. der dns bzw smtp nicht mehr läuft...

nun frage ich eigentlich nur: warum? :)

tausend dank!

captaincrunch
Userprojekt
Userprojekt
Posts: 7225
Joined: 2002-10-09 14:30
Location: Dorsten

Re: iptables skript

Post by captaincrunch » 2003-04-07 09:32

genau das ist es ja.. ich möcjhte den output eigentlich unangetastet lassen. aber aus irgendwelchen gründen brauhce ich die output-regeln ja, da sonst z.b. der dns bzw smtp nicht mehr läuft...
Wenn du OUTPUT nicht einschränkst, brauchst du dir um die von dir afgestellten Regeln erst gar keinen Kopf machen. Lass OUTPUT per default raus, und du hast damit schon keine Sorgen mehr.
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

korrigiert mich, wenn ich mich irre

Post by predismo » 2003-04-07 09:38

$IPTABLES -P OUTPUT DROP
sorgt doch dafür, dass die default policy doppen ist.

die sollte ich mir sparen. ok

schau mal bitte ein paar mails höher. die 3 fragen. kannst du die irgendwie beantworten...

mal brauche ich ne output regel - mal nicht...
wann brauche ich eine -wann nicht...

ssh antwortet doch z.b. auch... und das muss ja scheinbar per udp sein?!?! sonst bräuchte ichja ne output-regel... wieso brauche ich aber explizit eine output-regel für dns auf tcp... da ist doch normalerweilse nicht eingeschränkt...

wenn die default policy wirklich drop ist, dann müßte ich doch für http auch ne output-regel definieren --- oder ist wieder related und dadurch schon accepted!?!?!

captaincrunch
Userprojekt
Userprojekt
Posts: 7225
Joined: 2002-10-09 14:30
Location: Dorsten

Re: iptables skript

Post by captaincrunch » 2003-04-07 09:44

mal brauche ich ne output regel - mal nicht...
wann brauche ich eine -wann nicht...
Wenn du OUTPUT keine Beschränkungen auferlegst (was ohnehin noch eine sinnfreie Sache dabei ist, aber das ist ein anderes Thema), brauchst du gar keine Regeln für ausgehenden Traffic definieren.
Mach ein $IPTABLES -P OUTPUT ACCEPT, und alles wird in dem Punkt schon mal gut :wink: ...
ssh antwortet doch z.b. auch... und das muss ja scheinbar per udp sein?!?! sonst bräuchte ichja ne output-regel... wieso brauche ich aber explizit eine output-regel für dns auf tcp... da ist doch normalerweilse nicht eingeschränkt...
SSH läuft definitiv nicht per UDP. Dir scheint immer noch nicht ganz klar zu sein, was du eigentlich bezwecken möchtest, udn auch dodlin hat dich schon mehrmals nach deinem Konzept gefragt (was man für ein solches Vorhaben grundsätzlich vorab aufgestellt haben sollte).

Falls du dich wirklich fragst, warum SSH antwortet, obwohl du es nicht extra im OUTPUT freigeschaltet hast :
Du erlaubst, dass man sich von außen per SSH auf deinen Rechner connecten kann. Dadurch ist (durch die State-Tables, sobald die Verbindung establisht ist) auch der Antworttraffic gestattet. Extra freigeben brauchst du den nicht.

Also entweder verstehe ich dich, oder du uns nicht so wirklich ...
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

dodolin
RSAC
Posts: 4009
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: iptables skript

Post by dodolin » 2003-04-07 09:57

Ja, sorry. In meinem letzten Post hatte ich Bullshit geschrieben. Das ist mir dann später auch aufgefallen.

Du hast keine Catch-All ACCEPT Regel für UDP oder TCP in OUTPUT und deine Policy ist DROP. Also ist alles verboten. Wie der CaptainCrunch schon sagte: Wenn du alles in OUTPUT erlauben willst, stelle die Policy auf ACCEPT und lösche dann alle Regeln, die sich auf OUTPUT beziehen.

Es ist zu mühsam, dir das mit ESTABLISHED zu erklären, solange du nicht verstehst, wie TCP funktioniert.

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

ok aber wieso

Post by predismo » 2003-04-07 09:59

ok... output generell zu akzeptieren finde ich gut.
stelle das nachher auch um.
CaptainCrunch wrote: Falls du dich wirklich fragst, warum SSH antwortet, obwohl du es nicht extra im OUTPUT freigeschaltet hast :
Du erlaubst, dass man sich von außen per SSH auf deinen Rechner connecten kann. Dadurch ist (durch die State-Tables, sobald die Verbindung establisht ist) auch der Antworttraffic gestattet. Extra freigeben brauchst du den nicht.
Das war GOLD wert... DANKE

nur zur bildung. wieso brauche ich denn explizit ein
$IPTABLES -A OUTPUT -p tcp --dport 53 -j ACCEPT

weil ich im moment output als default droppe und keine verbindung beim input established wird, richtig? selbiges gilt für smtp, richtig?

$IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT
brauche ich, weil eben das droppen als default policy auch für udp eingestellt ist und der rest des outputs eigentlich eben nur durch die established sache funktioniert...

ich glaube das hat mir wirklich gefehlt, danke danke...

das sieht aber doch dsa script mit eingebautem
$IPTABLES -P OUTPUT ACCEPT
und ausgebauten sonstigen output statemens für meine zwekce eigentlich gut aus...


zwei sahcen sind noch offen:
a. man sollte
$IPTABLES -A INPUT -j LOG
$IPTABLES -A OUTPUT -j LOG
nur mit -limit verwenden

muss ich n och nachlesen. oder gibt es da was pauschales?

b.
hiess es
$IPTABLES -A INPUT -m limit -p ICMP --limit 1 --limit-burst 2 --icmp-type 8 -j ACCEPT
wäre nicht gut...
was wäre denn die empfehlen (bitte nicht wieder = keine firewall :) )


das bei input eine established-regel für output zieht hatte ich nicht begriffen....
Last edited by predismo on 2003-04-07 10:19, edited 1 time in total.

predismo
Posts: 47
Joined: 2003-03-31 00:42
Location: Niedersachsen

verstehen

Post by predismo » 2003-04-07 10:01

ich versuche es ja zu verstehen :)
aber es ist eben auch recht komplex...

in jedem fall nochmals TAUSEND DANK für die mühe die sich hier alle machen. es hilft ungemein weiter

ps: selbst wenn ich der meine war, ich hätte das verstanden - es kommt immer wieder was neues... :?

captaincrunch
Userprojekt
Userprojekt
Posts: 7225
Joined: 2002-10-09 14:30
Location: Dorsten

Re: iptables skript

Post by captaincrunch » 2003-04-07 10:06

nur zur bildung. wieso brauche ich denn explizit ein
$IPTABLES -A OUTPUT -p tcp --dport 53 -j ACCEPT
OK, also noch mal ganz langsam :
Weil du momentan ausgehende Verbindungen dropst.

Die Chain "OUTPUT" bezieht sich auf Verbidnungen, die dein Rechner von sich aus zu anderen Rechner aufbaut. Da dur OUTPUT also beschränkst, brauchst du für sämtliche Verbindungen, die dein Rechner nach außen aufbaut eine eigene Regel, da es jeweils eine neue Verbindung ist.

Im Fall einer INPUT-Regel sieht das ganze wieder anders aus :
Du erlaubst die Verbindung auf Port 22. Sobald der Three-Way-Handshake durch ist, steht das ganze als ESTABLISHED in den State-Tables, udn auch der Antworttraffic ist erlaubt, weshalb du den ausgehenden Traffic nicht extra freigeben musst.
Genau das ist das schöne an der Stateful Inspection (oder hat sich CheckPoint diese Bezeichnung gesichert ?).

Mach dir folgendes klar : für neue Verbindungen (die also erst noch den Three-Way-Handshake durchlaufen müssen) bruachst du genau eine Regel. Sobald die Verbindung aufgebaut ist (SYN / SYN-ACK / ACK) ist die Verbindung ESTABLISHED.
Das gilt für jede Richtug, die der Traffic nimmt, sowohl rein, als auch raus, als auch für geforwardete Pakete (in diesem Fall eher weniger).

Ist aber auch egal, setz OUTPUT auf ACCEPT, und alles wird (hoffentlich) gut ... :wink:
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc