iptables skript

[predismo]

danke für die 100%ige erklärung.

habt ihr experten auch n och nen vorschlag für

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 )


???

[captaincrunch]

a. man sollte
$IPTABLES -A INPUT -j LOG
$IPTABLES -A OUTPUT -j LOG
nur mit -limit verwenden

Richtig, da ein böser Mensch wie ich dir sonst deine suaber aufgebauten Logs einfach mal zumülle, und so deine gesamten "sauber" entwickelten Regeln gegen dich verwende ...
Bezüglich des Logging schau dir mal folgenden Thread an : http://www.rootforum.org/forum/viewtopi ... berzeugung
Da habe ich auch mal versucht, Leute hier vom Sinn zu überzeugen (hab's aber danach eingesehen, aber wieder ein anderes Thema )
Grundsätzlich solltest du dich was Paketfilter angeht aber noch ganz massiv einlesen, da dir anscheienend grundlegende Vorkenntnisse (States) dazu fehlen. Das Logging ist dann eher ein Kinderteller ...

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 )

Siehe
a) meine "Ã?berzeugungsarbeit",
b) die Doku und
c) gewisse RFCs, die dich (heffentlich) vom Sinn und Zweck von ICMP-Messages überzeugen werden.
Ich würde das einfach weglassen ... um nicht zu sagen alles, aber das willst du ja nicht hören ...

[dodolin]

Zum limit bei LOG:
http://www.netfilter.org/documentation/ ... WTO-7.html
Der Abschnitt mit "Other Match Extensions".
Ich würde den Default nehmen, das sind 3 Matches pro Stunde, mit einem Burst von 5.

Zum limit bei ICMP Echo:
Ich würde zumindest den Burst deutlich höher setzen, ansonsten bekommst du ja sogut wie immer einen nicht unbeträchtlichen Anteil an Packet Loss, wenn man deinen Rechner anpingt. Der Windows "Ping" sendet per Default z.B. 4 Pakete.

Sobald der Three-Way-Handshake durch ist, steht das ganze als ESTABLISHED in den State-Tables

Faslch.

Mit welcher Regel und wie würde denn dann das SYN+ACK Paket durchkommen?

Ergo: Bereits dieses ist schon ESTABLISHED.
Oder andersherum, alles, was keine neue Verbindung aufbaut, ist ESTABLISHED (vorausgesetzt: es existiert zu dieser Verbindung bereits in Eintrag in der State Table). Neue Verbindungen haben ausschliesslich SYN gesetzt.

Siehe hierzu auch den Abschnitt aus der iptables manpage, den ich hier in diesem Thread irgendwo schonmal zitiert hatte.

Stateful Inspection (oder hat sich CheckPoint diese Bezeichnung gesichert ?).

Jepp, das ist Marketingspeech von CP und es ist nicht dasselbe, wie Statefull Packetfiltering. Letzteres wird von netfilter eingesetzt.

Ã?ber den Unterschied Statefull Inspection <-> Statefull Packetfiltering gab es vor langer Zeit mal einen äusserst ausführlichen Thread in de.comp.security.firewall, den ich losgetreten hatte. Wenn das von Interesse ist, suche ich den Link dazu raus...

[captaincrunch]

Faslch.
Mit welcher Regel und wie würde denn dann das SYN+ACK Paket durchkommen?

Es geht mir nicht darum, zu zeigen, ob das ganze an Rules festzumachen ist, sondern darum, wann eine Verbindung wie in der State-tables steht. Daher zietiere ich mal http://iptables-tutorial.frozentux.net/ ... ATEMACHINE :

The NEW state tells us that the packet is new in the connection. This means that the first packet that the conntrack module sees will be matched. For example, if we see a SYN packet and it is the first packet in a connection that we see, it will match. However, the packet may as well not be a SYN packet and still be considered NEW. This may lead to certain problems in some instances, but it may also be extremely helpful when we need to pick up lost connections from other firewalls, or when a connection has already timed out, but in reality is not closed.

ESTABLISHED ist aber erst nach dem Three-Way-Handschake in den State-Tables :

The ESTABLISHED state has seen traffic in both directions and will then continuously match those packets. ESTABLISHED connections are fairly easy to understand. The only requirement to get into an ESTABLISHED state is that one host sends a packet, and that it later on gets a reply from the other host. The NEW state will upon receipt of the reply packet to or through the firewall change to the ESTABLISHED state. ICMP error messages and redirects etc can also be considered as ESTABLISHED, if we have generated a packet that in turn generated the ICMP message.

Ã?ber den Unterschied Statefull Inspection <-> Statefull Packetfiltering gab es vor langer Zeit mal einen äusserst ausführlichen Thread in de.comp.security.firewall, den ich losgetreten hatte. Wenn das von Interesse ist, suche ich den Link dazu raus...

Auf jeden Fall. Aber so lange das jetzt nicht auch Smart-Irgendwas heißt, soll mir das egal sein ...

[dodolin]

Zum 1. Zitat: Jo, klar. NEW ist auch, wenn bei z.B. bei TCP was anderes als nur SYN gesetzt ist, aber kein Eintrag in der State Table vorhanden ist. Das kann sein, weil uns jemand mit "seltsamen" Paketen beglückt oder weil der Eintrag in der State Table in den Timeout gelaufen ist und deshalb nicht mehr vorhanden ist.

Zum 2. Zitat:
Das bezieht sich auf das "Userland" (in dem iptables ja arbeitet).

Hierzu sollte man aber auch folgenden Abschnitt beachten, wodurch sich unser vermeintlich Widerspruch in den Aussagen aufklären lässt:

All connection tracking is handled in the PREROUTING chain, except locally generated packets which are handled in the OUTPUT chain. What this means is that iptables will do all recalculation of states and so on within the PREROUTING chain. If we send the initial packet in a stream, the state gets set to NEW within the OUTPUT chain, and when we receive a return packet, the state gets changed in the PREROUTING chain to ESTABLISHED, and so on. If the first packet is not originated by ourself, the NEW state is set within the PREROUTING chain of course. So, all state changes and calculations are done within the PREROUTING and OUTPUT chains of the nat table.

d.h. also, wenn man das TCP SYN+ACK Paket in INPUT sieht, wird es schon als ESTABLISHED gematched, weil es bereits in PREROUTING von NEW in ESTABLISHED verändert wurde.

Siehe hierzu ebenso http://iptables-tutorial.frozentux.net/ ... ONNECTIONS:

As you can see, the connection tracking code does not really follow the flow of the TCP connection, from the users viewpoint. Once it has seen one packet(the SYN), it considers the connection as NEW. Once it sees the return packet(SYN/ACK), it considers the connection as ESTABLISHED. If you think about this a second, you will understand why. With this particular implementation, you can allow NEW and ESTABLISHED packets to leave your local network, only allow ESTABLISHED connections back, and that will work perfectly. Conversely, if the connection tracking machine were to consider the whole connection establishment as NEW, we would never really be able to stop outside connections to our local network, since we would have to allow NEW packets back in again.

d.h. also, dass in der Tat nicht der gesamte Verbindungsaufbau (TCP 3-way-handshake) NEW ist, sondern bereits das 2. Paket in diesem 3-way-step ESTABLISHED ist.

Google:
http://groups.google.de/groups?as_q=sta ... inik%20ruf
Das war übrigens mein allererster Beitrag in dcsf. Und ich bin nicht - wie so viele andere - gleich geköpft worden.

Aber es macht schon Sinn, sämtliche der über 60 Beiträge zu lesen, um die gesamte Diskussion und die verschiedenen Ansichten mitzukriegen. Bei mir ist nämlich in diesem Thread erst nach und nach das Verständnis gekommen...

[captaincrunch]

Wie war das doch gleich : "die Sprache ist der Quell aller Missverständnisse" ?!?

Auch wenn wir predismo jetzt wahrscheinlich komplett durcheinandergebrahct haben , danke ich dir für diese Diskussion und vor allem für den Link auf die Newsgroup. War (mal wieder) echt aufschlussreich).

[predismo]

ok. aber das betrifft ja im prinzip "nur" die differenzierung zwischen established new und related. da muss man sich nen genaueren kopf machen, wenn man output-rules haben will; mit denen ich mir ja nur selbst nen bein stelle :) [bin ja lernfähig grien]

mein letzter stand vom skript läßt ja alles raus, also sollte mir die tiefergehende unterscheidung der states doch egal sein können. hauptsache ich lasse rein, was rein soll...

aber, da es inzwischen schon fast zu meinem signum gehört: *GRIEN*

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 ACCEPT

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

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

# DNS
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --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

# POP
$IPTABLES -A INPUT -p tcp --dport 110 -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

# ICMP aufs noetigste Begrenzen (echo request und time exceeded)
$IPTABLES -A INPUT -m limit -p ICMP -s 0/0 --limit 1 --limit-burst 2 --icmp-type 8 -j ACCEPT
$IPTABLES -A INPUT -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

# Boese Pakete werden direkt "aussortiert"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP

# Logging
$IPTABLES -A INPUT -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

nun sei noch angemerkt, dass der abschnitt

# Boese Pakete werden direkt "aussortiert"

natürlich kopiert und ohne hirn und verstand im einsatz ist. ich bin gerade mit standard-scannern am ausprobieren, sehe aber nicht wirklich einen unterschied, also würde ich mal sagen, kann der abschnitt im prinzip evtl bisauf die ersten beiden zeilen wieder weg.

diskutiert ruhig weiter. ich lese auch schon auf... man kann ja nur lernen :)


PS: Heute Werbund bekommen für SUSE 8.2. Updatepreis weiterhin 49 EUR - soll jetzt aber keine Schleichwerbung sein. Mal schauen, was diesmal wieder verändert wurde. Evtl läuft ja die 8.2 ohne ein Online Update vernünftig auf Anhieb grien

[captaincrunch]

Ein paar Sachen stoßen mir immer noch bitter auf :

a) du definierst ganz oben schon Standardregeln, und setzt alles auf "DROP". Ganz unten sortierst du alles, was übrig bleibt (reduntanterweise) noch mal mit einem REJECT aus.
Wieso ? Mal ganz davon abgesehen, dass es besser ist, zu REJECTen, statt zu DROPpen (kannst du auch in den von dodolin geposteten Links finden).

b) Das Logging hast du immer noch nicht mit --limit versehen. Damit schaufelst du dir selbst u.U. dein Grab (bzw. das des Servers).

Ansonsten :

natürlich kopiert und ohne hirn und verstand im einsatz ist. ich bin gerade mit standard-scannern am ausprobieren, sehe aber nicht wirklich einen unterschied, also würde ich mal sagen, kann der abschnitt im prinzip evtl bisauf die ersten beiden zeilen wieder weg.

Was verstehst du unter "Standard-Scanner" ? Mir ist nur ein vernünftiger Scanner bekannt, und zwar nmap. Da kannst du diese lustigen "Flag-Spielchen" machen, daran wirst du dann auch was merken.

[dodolin]

a) du definierst ganz oben schon Standardregeln, und setzt alles auf "DROP". Ganz unten sortierst du alles, was übrig bleibt (reduntanterweise) noch mal mit einem REJECT aus.
Wieso ? Mal ganz davon abgesehen, dass es besser ist, zu REJECTen, statt zu DROPpen (kannst du auch in den von dodolin geposteten Links finden).

Die beiden Zeilen:

Code: Select all

# 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

Sind IMHO genau richtig und machen auch Sinn. Der Kommentar allerdings weniger, denn TCP wird durch die erste Regel ja gerade nicht mit einem ICMP Port unreachable, sondern mit einem TCP RST beantwortet.

Das Problem ist folgendes: Bei iptables gibt es keine Policy REJECT. D.h. man muss als Policy DROP nehmen, dann aber als letzte Regel eine Catch-All Regel mit REJECT nehmen, damit die Pakete kurz bevor sie durch die Policy geDROPt würden, noch korrekt abgelehnt werden. Da aber das Target REJECT immer nur ICMP Port unreachable sendet, benötigt man kurz vor dieser Regel noch eine weitere Regel, die nur TCP matched und dieses mit einem TCP RST beantwortet, was der zu bevorzugende Weg ist.

natürlich kopiert und ohne hirn und verstand im einsatz ist.

Genau DAS hatte ich bereits beim Lesen der Regeln gedacht.

Es bringt dir absolut nix. Wenn du sowas in der Art haben willst, versehe alle deine INPUT Regeln noch mit -m --state NEW und alles wird gut (tm). Zumal ich nicht checke, warum du z.B. die TCP Flags URG und PSH aussortierst...

[captaincrunch]

Das Problem ist folgendes: Bei iptables gibt es keine Policy REJECT

OK, hab's mittlerweile auch gemerkt ... war heute morgen echt zu früh für mich ...

[predismo]

ok. die vorgeschlagenen änderungen sind gemacht worden (1. state überall --new)

2. die beiden unnötigen zeilen (psh, urg)

3. limit fürs log... oem. ist so eine frage.... was brignt mir nen limit von 100/s zu setzen oder so... bin am überlegen, was da so sinnvoll ist... letztendlich möchte ich möglichst viel doku haben.
irgendwelche vorschläge?


danke danke danke



hier das aktuelle script

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 ACCEPT

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

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

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

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

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

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

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

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

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

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

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

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

# ICMP aufs noetigste Begrenzen (echo request und time exceeded)
$IPTABLES -A INPUT -m state --state NEW -m limit -p ICMP -s 0/0 --limit 1 --limit-burst 2 --icmp-type 8 -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

# Boese Pakete werden direkt "aussortiert"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
$IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags ACK,FIN FIN -j DROP
### $IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags ACK,PSH PSH -j DROP
### $IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags ACK,URG URG -j DROP

# Logging
$IPTABLES -A INPUT -j LOG

# Alles andere REJECTEN - policy ist ja drop
$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

[dodolin]

Zu 3.)

Das hatte ich schonmal weiter oben geschrieben:

Zum limit bei LOG:
http://www.netfilter.org/documentation/ ... WTO-7.html
Der Abschnitt mit "Other Match Extensions".
Ich würde den Default nehmen, das sind 3 Matches pro Stunde, mit einem Burst von 5.

Zum limit bei ICMP Echo:
Ich würde zumindest den Burst deutlich höher setzen, ansonsten bekommst du ja sogut wie immer einen nicht unbeträchtlichen Anteil an Packet Loss, wenn man deinen Rechner anpingt. Der Windows "Ping" sendet per Default z.B. 4 Pakete.

Zu 2.)

Ich würde den kompletten Abschnitt rausnehmen, wie gesagt. Was soll das denn bringen? Meinst du nicht, dein OS würde von ganz alleine schon wissen, was zu tun ist und mit diesen "ungewöhnlichen" Paketen zurecht kommen?

[predismo]

Code: Select all

# ICMP aufs noetigste Begrenzen (echo request und time exceeded)
$IPTABLES -A INPUT -m state --state NEW -m limit -p ICMP -s 0/0 --limit 3/s --limit-burst 8 --icmp-type 8 -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -m limit -p ICMP -s 0/0 --limit 3/s --limit-burst 8 --icmp-type 11 -j ACCEPT

burst von 8. wenn ich das richtig interpretiere, greift die regel also erst nach 8 paketen... dann gehen noch zwei durch (limit) und ab dem 3. wird dann abgelehnt. das scheint auch zu funktionieren.
wenn mir jetzt aber einer nen ping mit 64k datenlast schickt, ist ja mein transfervolumen auch recht schnell weg... evtl sollte man das doch so niedrig lassen, damit (bei täglicher kontrolle) man überhaupt ne chance hat.

Code: Select all

# Logging
$IPTABLES -A INPUT -j LOG -m limit --limit 20/s

im moment möchte ich erstmal möglichst viel info... das läßt sich ja noch redizieren :)

die im weiter oben stehenden link gen. regeln:

Code: Select all

# Boese Pakete werden direkt "aussortiert"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
$IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags ACK,FIN FIN -j DROP

muss ich mir nochmal anschauen. könnte ja ganz gut zum verschaukeln sein, aber prinzipiell sollten sie wohl eher raus...


erstmal nochmals vielen dank für die hilfe!


ps: ihr scheint ja relativ erfahren zu sein und habt best. auch die optische korrektur im mta gemacht, fällt euch nicht nochw as zu
http://www.rootforum.de/forum/viewtopic.php?t=9591 ein?

[dodolin]

burst von 8. wenn ich das richtig interpretiere, greift die regel also erst nach 8 paketen...

Das ist schon falsch oder zumindest unkorrekt ausgedrückt.
Die Regel matched die ersten 8 Pakete, danach gerade nicht mehr und nicht umgekehrt.

Nach dem 8. Paket matched die Regel nicht mehr und wird einfach übergangen, wie jede andere Regel auch, die nicht matched.

dann gehen noch zwei durch (limit)

Nein, auch das ist falsch. Nach 8 Paketen ist erst mal Schluss.

wenn mir jetzt aber einer nen ping mit 64k datenlast schickt, ist ja mein transfervolumen auch recht schnell weg... evtl sollte man das doch so niedrig lassen, damit (bei täglicher kontrolle) man überhaupt ne chance hat.

Sorry, das ist totaler Quark. Mit solchen Regeln kannst du genau gar nicht verhindern, wie viele Daten ich oder jemand anderes dir schickt. Die Daten kommen so oder so bei dir an und zählen zu deinem Traffic, egal, was du damit jetzt machst (DROP, REJECT, whatever). Hint: Der Traffic wird auf dem Gateway vor deinem Rechner gezählt.

Code: Select all

$IPTABLES -A INPUT -j LOG -m limit --limit 20/s 

Sorry, aber das ist echt krank!

20/s, das sind 1200/min oder 72.000/h. Wieviele Logmeldungen das pro Tag fabriziert, will ich gar nicht wissen...

muss ich mir nochmal anschauen. könnte ja ganz gut zum verschaukeln sein, aber prinzipiell sollten sie wohl eher raus...

Jo. Sollten sie.

Zum Thema "vergaukeln": Security through Obscurity funktioniert nicht. Das ist nicht von mir, sondern von Leuten, die sich damit auskennen.

Es könnte übrigens durchaus sein, dass solche Pakete durch den State INVALID gematched werden. Aber da bin ich mir nicht hundertpro sicher.

Zum Thema mit MTA fällt mir nix ein, da ich kein Confixx einsetze.

[predismo]

Die Daten kommen so oder so bei dir an und zählen zu deinem Traffic

ist natürlich richtig und von mir völlig falsch....

Sorry, aber das ist echt krank!

korrekt, das setze ich runter, wenn es mir zuviel wird....

Security through Obscurity funktioniert nicht

oemmm.... da haste eigentlich ebenfalls recht *HUT ZIEH* gerade in kombination mit dem traffic-punkt...


man beachte das # :)
die erste beiden zeilen auch raus?

danke danke danke !

Code: Select all

# Boese Pakete werden direkt "aussortiert"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
## $IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
## $IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
## $IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
## $IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags ACK,FIN FIN -j DROP
### $IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags ACK,PSH PSH -j DROP
### $IPTABLES -A INPUT -m state --state NEW -p tcp --tcp-flags ACK,URG URG -j DROP

[dodolin]

korrekt, das setze ich runter, wenn es mir zuviel wird....

Das klitzekleine Problemchen an der Sache ist, wenn es dir zuviel wird, wird es schon zu spät sein. :P

die erste beiden zeilen auch raus?

Geschmacksache. Ich persönlich würde sie rausnehmen, weil das keine zusätzliche Sicherheit bringt. Ob das jetzt geDROPt oder REJECTed wird, ist wurscht. BTW: DROP ist genau dieses "Security through Obscurity"...

Wow! Wir werden doch nicht etwa diesen Monsterthread zu einem Ende bringen?

[predismo]

1. man brauchst absolut keine firewall. man kann die dienste, die ein scriptkiddie nicht direkt beim scannen sehen soll auch direkt deaktivieren (sofern man sie nicht selbst braucht).

2. jede form von verarschung in firewall-scripten ist absolut dämlich und verwirrt einen eher selbst, als den angreifer, der meistens sowieso irgendwelche standard-lücken abscannt. die angreifer, die es geschafft haben, tauchen im log eh nicht mehr auf ;)

3. dieser thread sollte allen dienen, die in zukunft eine firewall aufziehen wollen (aus welchen gründen auch immer). ich poste gleich noch das bei mir final entstandene script.

4. ein ganz grossen dankeschön an alle beteiligten! nicht jeder würde diese geduld aufweisen. herzlichen dank dafür!
inbesondere dank an dodolin und CaptainCrunch!

5. bevor hier irgendwer was postet: alle links + diesen ges. thread lesen!

6. ein script sollte möglichst kurz und knackig bleiben.

bei diesem hier wird der output nicht beschränkt (weils beschränkt wäre sich selbst zu drosseln - antworten können ja eh nur die gewollten dienste). der input wird vollständig gefiltert. jede form von forwarding macht nur auf privaten kisten sinn (dsl-router und konsorten, dazu könnte ich bei bedarf nochmals ein script mit NAT posten, allerdings gibt es diese schon sehr oft, ausserdem ist es immer die frage: welche dienste laufen denn)... das unten stehende script richtet sich an alle personen mit frischen rootserver (L) von puretec. anpassen sollte es jeder selbst. evtl auch mit hilfe dieses forums (das eine sehr gute hilfe bietet!).

evtl könnte man nochmals wie in der faq erwähnt das trasnfervolumen loggen lassen. aber das ist was für die zukunft.

zum mysql-part... dieser ist auskommentiert... wer man eine wartung durchs netz bruacht (z.b. mit mysqlfront) der kann das dann deaktiveren. es ist aber eher davon abzuraten (siehe auch: http://server.1und1.com/root_server/confixx2/6.html) .


hier das script:

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 ACCEPT

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

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

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

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

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

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

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

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

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

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

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

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

# ICMP aufs noetigste Begrenzen (echo request und time exceeded)
$IPTABLES -A INPUT -m state --state NEW -m limit -p ICMP -s 0/0 --limit 3/s --limit-burst 8 --icmp-type 8 -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -m limit -p ICMP -s 0/0 --limit 3/s --limit-burst 8 --icmp-type 11 -j ACCEPT

# Boese Pakete werden direkt "aussortiert"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"

# Logging
$IPTABLES -A INPUT -j LOG -m limit --limit 20/s
## sollte unbedingt anpasst werden. zu debugzwecken. danach sollte 3/s und ein burstwert eingestellt werden!

# Alles andere REJECTEN - policy ist ja drop
$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

es ist sehr zu empfehlen ein fax zu puretec zu schicken, um das transfervolumen zu limitieren !

[dodolin]

Eine kleine Anmerkung hätte ich noch: :)

Code: Select all

$IPTABLES -A INPUT -m state --state NEW -m limit -p ICMP -s 0/0 --limit 3/s --limit-burst 8 --icmp-type 11 -j ACCEPT 

Ist überflüssig, da ICMP Time Exceeded nicht state NEW hat, sondern RELATED ist und damit bereits oben erlaubt wird. Die Regel wird also keine "normalen" Pakete matchen, sondern höchstens, wenn dir jemand "gefälschte" Time Exceeded unterjubeln will. Und in diesem Fall will man das auch nicht limitiert erlauben, sondern gar nicht. Ergo: Regel entfernen.

Zum Loggen: Auch 3/s finde ich noch zuviel, aber das soll jeder selbst entscheiden.

Ansonsten bin ich jetzt zufrieden mit deiner Arbeit...! *Lob*

[predismo]

ok, aber dann sollte schleunigst einfach nur das state new raus, damit ich zumindest den limit (und burst) setzen kann; einverstanden? :)


also zeile bitte ändern in:

Code: Select all

$IPTABLES -A INPUT -m limit -p ICMP -s 0/0 --limit 3/s --limit-burst 8 --icmp-type 11 -j ACCEPT