IPTABLES Skript

Post by **buddy0815** » 2004-02-16 18:41

Hi,

ich hab mir eine IPTABLES Skript für meinen Server zusammengestellt und wollte mal fragen ob das so in Ordnung ist, oder ob jemand einen Verbesserungsvorschlag hat.

Auf dem Server laufen momentan nur 4 Gameserver, sonst nichts.
Das Skript wir über die Datei boot.local bei jedem Reboot gestartet.

Das Skript soll folgendes können:

Input Regeln:

1. Alle Pakete standardmässig abblocken.
2. SSH erlauben
3. Pakete zu den Gameserverports erlauben

Output Regeln:

1. Nur zugelassene Pakete erlauben
2. Erlaube ausgehende DNS-Anfragen, z.B. um IP's in PROTOKOLLEN aufzuloesen
3. Pakete zum Gamemasterserver erlauben

Forward Regeln

Alle Forwards ablehnen

Hier das Skript:

Code: Select all

#! /bin/bash

# file-id: /xxx/xxx/localfw #

# custom script to start iptables packet filter firewall rules #
# run from /etc/init.d/boot.local #

# last updated 16-02-2004 #

IP_LOCAL=xxx.xxx.xxx.xxx

#------------------------------------------------------#
echo;
echo "=======================================================================";
echo "Running /etc/localfw"
echo " - Initial status of firewall is:"
echo "=======================================================================";
echo;
#------------------------------------------------------#

#------------------------------------------------------#
echo;
echo "=======================================================================";
echo "NAT table initial status"
echo "=======================================================================";
echo;
#------------------------------------------------------#

# list status of NAT table
iptables -t nat -L -v
#------------------------------------------------------#

#------------------------------------------------------#
echo;
echo "=======================================================================";
echo "MANGLE table initial status"
echo "=======================================================================";
echo;
#------------------------------------------------------#

# list status of MANGLE table
iptables -t mangle -L -v
#------------------------------------------------------#

#------------------------------------------------------#
echo;
echo "=======================================================================";
echo "FILTER table initial status"
echo "=======================================================================";
echo;
#------------------------------------------------------#

# list status of FILTER table
iptables -t filter -L -v
#------------------------------------------------------#

#------------------------------------------------------#

# flush ALL rules in ALL tables
iptables -t nat -F
iptables -t mangle -F
iptables -t filter -F

# clear packet & byte counters
iptables -t nat -Z
iptables -t mangle -Z
iptables -t filter -Z

# delete ALL user-defined chains in ALL tables
iptables -t nat -X
iptables -t mangle -X
iptables -t filter -X

#------------------------------------------------------#
echo;
echo "=======================================================================";
echo "Starting up my own custom firewall now!"
echo "=======================================================================";
echo;
#------------------------------------------------------#

#******************************************************#
#                 NAT table rules                      #
#******************************************************#
# NOT USED

#******************************************************#
#                MANGLE table rules                    #
#******************************************************#
# NOT USED

#******************************************************#
#                FILTER table rules                    #
#******************************************************#

# Richte eine Standartdregelung fuer alle drei Standardketten ein, nach der
# Pakete, auf die keine Regel zutrifft, abgelehnt werden.

iptables -P INPUT REJECT
iptables -P FORWARD REJECT
iptables -P OUTPUT REJECT

# Gib Loopback-Interfaces freie Hand, d.h. lokale Prozesse koennen
# sich mit den Listening-Ports anderer Prozesse verbinden.

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Rudimentaere Regeln zum Ablehnen von Paketen wegen IP-Spoofing

iptables -A INPUT -s 255.0.0.0/8 -j LOG --log-prefix 'Gefaelschte Quell-IP!'
iptables -A INPUT -s 255.0.0.0/8 -j DROP
iptables -A INPUT -s 0.0.0.0/8 -j LOG --log-prefix 'Gefaelschte Quell-IP!'
iptables -A INPUT -s 0.0.0.0/8 -j DROP
iptables -A INPUT -s 127.0.0.0/8 -j LOG --log-prefix 'Gefaelschte Quell-IP!'
iptables -A INPUT -s 127.0.0.0/8 -j DROP
iptables -A INPUT -s 192.168.0.0/16 -j LOG --log-prefix 'Gefaelschte Quell-IP!'
iptables -A INPUT -s 192.168.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j LOG --log-prefix 'Gefaelschte Quell-IP!'
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 10.0.0.0/8 -j LOG --log-prefix 'Gefaelschte Quell-IP!'
iptables -A INPUT -s 10.0.0.0/8 -j DROP

# Das folgende wird den lokalen Interprozess-Verkehr, dessen Pakete die
# Quell-IP des lokalen Loopback-Interfaces (z.B. 127.0.0.1) haben, nicht behindern

iptables -A INPUT -s 192.168.0.100 -j LOG --log-prefix 'Falscher GFW!'
iptables -A INPUT -s 192.168.0.100 -j DROP

# Sage netfilter, dass alle TCP-Sessions tatsaechlich mit SYN beginnen muessen.
# (Es koennte Anwendungen geben, die mit dem RFC nicht verträglich sind
# und ihre Transaktionen anders beginnen, aber mir sind sie noch nicht begegnet.)

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix 'Stealth Scan Angriff?'
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j REJECT

# Schliesslich das Kernstueck unserer Paketfilter-Strategie:

# INBOUND-Strategie
# (Bezieht sich auf Pakete, die aus dem Netzwerk auf unserem Interface
# eingehen und an diesen Rechner asresiert sind)

# Akzeptiere eingehende Pakete, die Teil von zuvor zugelassenen Sessions sind.
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED

# Akzeptiere eingehende Pakete, die SSH-Sessions einleiten.
iptables -A INPUT -p tcp -j ACCEPT --dport 22 -m state --state NEW

# Akzeptiere eingehende Pakete, die FTP-Sessions einleiten.
#iptables -A INPUT -p tcp -j ACCEPT --dport 21 -m state --state NEW

# Akzeptiere eingehende Pakete, die HTTP-Sessions einleiten.
#iptables -A INPUT -p tcp -j ACCEPT --dport 80 -m state --state NEW

# Akzeptiere eingehende Pakete, die eine Gameserver-Sessions einleiten.
iptables -A INPUT -p udp -j ACCEPT --dport 29070 -m state --state NEW
iptables -A INPUT -p udp -j ACCEPT --dport 29080 -m state --state NEW
iptables -A INPUT -p udp -j ACCEPT --dport 29090 -m state --state NEW
iptables -A INPUT -p udp -j ACCEPT --dport 29100 -m state --state NEW

# Protokolliere alles, was laut den obigen Regeln nicht akzeptiert wird
# (Wir wollen jedes Paket, das auf keine ACCEPT-Regel passt, aus Sicherheitsgruenden
# und zur Fehlerbehebung protokollieren. Beachten Sie die Redundanz der letzten "DROP"-Regel,
# wenn die Default-Strategie bereits DROP ist. Redundante Sicherheit ist aber immer gut.)

iptables -A INPUT -j LOG --log-prefix 'Abgelehnt (INPUT):'
iptables -A INPUT -j REJECT

# OUTBOUND-Strategie
# (Bezieht sich auf Pakete, die von lokalen Prozessen an das Netzwerk-Interface
# (NICHT das Loopback) gesendet werden).

# Lasse es zu, wenn es Teil einer genehmigten Verbindung ist.
iptables -I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Erlaube ausgehendes ping
# (Nur fuer Testzwecke! Wenn jemand in Ihr System eindringt, koennte er mit ping
# versuchen, andere aktive IP-Adressen in Ihrem DMZ zu identifizieren.
# Kommentieren Sie diese Regel aus, wenn Sie sie nicht benoetigen!)

iptables -A OUTPUT -p icmp -j ACCEPT --icmp-type echo-request

# Erlaube ausgehende DNS-Anfragen, z.B. um IP's in PROTOKOLLEN aufzuloesen
# (Viele Netzwerkanwendungen versagen oder laufen viel langsamer, wenn Ihnen
# kein DNS zur Verfügung steht. DNS-Anfragen verwenden normalerweise UDP 53
# manchmal auch TCP 53. Obwohl TCP 53 normalerweise fuer Zonen-Transfers
# eingesetzt wird, wird es auch von DNS-Anfragen mit groesseren Antworten als
# 512 Byte verwendet, also erlauben wir hier TCP und UDP 53.)

iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT

# Erlaube ausgehende Pakete an Masterserver für Gameserver:
iptables -A OUTPUT -p udp --dport 29060 -m state --state NEW -j ACCEPT

# Protokolliere  alles, was laut der obigen Regeln nicht erlaubt ist;

iptables -A OUTPUT -j LOG --log-prefix 'Abgelehnt (OUTPUT):'
iptables -A OUTPUT -j REJECT

# Protokolliere und verwerfe ALLE eingehenden Pakete, die einen anderen Bestimmungsort
# haben. (Wir haben bereits die Default-FORWARD-Strategie auf Drop gesetzt. Dies ist aber
# eine weitere Redundanz zur Absicherung, warum sollten wir sie also nicht einsetzen?)
iptables -A FORWARD -j LOG --log-prefix 'FORWARD? Abgelehnt:'
iptables -A FORWARD -j REJECT

#------------------------------------------------------#
echo;
echo "=======================================================================";
echo "New status of firewall using my own custom rules is:"
echo "=======================================================================";
echo;
#------------------------------------------------------#

#------------------------------------------------------#
echo;
echo "=======================================================================";
echo "NAT table - new status"
echo "=======================================================================";
echo;
#------------------------------------------------------#

# list current status of NAT table
iptables -t nat -L -v
#------------------------------------------------------#

#------------------------------------------------------#
echo;
echo "=======================================================================";
echo "MANGLE table - new status"
echo "=======================================================================";
echo;
#------------------------------------------------------#

# list current status of MANGLE table
iptables -t mangle -L -v
#------------------------------------------------------#

#------------------------------------------------------#
echo;
echo "=======================================================================";
echo "FILTER table - new rules"
echo "=======================================================================";
echo;
#------------------------------------------------------#

# list current status of FILTER table
iptables -L -v
#------------------------------------------------------#

# exit with a valid code

 exit 0

#------------------------------------------------------#

# end of firewall #

Für Verbesserungsvorschläge bin ich sehr dankbar.

Danke schon mal im voraus

Buddy0815

Post by **dodolin** » 2004-02-17 09:49

a) Gibt es eine _Policy_ REJECT? Meines Wissens nicht...
b) Alle (!) -j LOG Regeln sollten unbedingt mit -m limit versehen werden.
c) Die Anti-Spoofing-Regeln sind redundant und lassen sich mit einer einzigen Zeile ersetzen: Hier lesen -> http://www.iptables.org/documentation/H ... TO-11.html

Post by **buddy0815** » 2004-02-18 08:52

Danke,

werd ich überarbeiten.

Post by **buddy0815** » 2004-02-18 09:46

Laut man iptables existiert aber die policy REJECT.
Und sie wird auch ohne Fehlermeldung übernommen.

Post by **dodolin** » 2004-02-18 12:31

Laut meiner manpage gibts das nicht. Wenn ich mich recht entsinne, musste man das extra mit einkompilieren...

Post by **standbye** » 2004-02-18 13:56

-> musst du beim kernel kompilieren einsttellen (auf jedenfall hab ich vorhin so ne option gesehen) ;)

Post by **buddy0815** » 2004-02-19 16:27

Also ich hab 2 Server mit SuSe 9.0 mit Kernel 2.4.21-192.

Bei mir steht folgendes in den Manuals:

REJECT
This is used to send back an error packet in response to the matched packet: otherwise it is equivalent to DROP so it is a terminating TARGET, ending rule traversal. This target is only valid in the INPUT, FORWARD and OUTPUT chains, and user-defined chains which are only called from those chains. The following option controls the nature of the error packet returned:
...

Also gibt es diese Policy.
Und es kommt auch keinerlei Fehlermeldung wenn ich das Skript ausführe.

Buddy0815

Post by **flolein** » 2004-02-19 17:53

jop. steht in der manpage unter target extensions, nicht unter target.

Post by **dodolin** » 2004-02-21 00:57

Also gibt es diese Policy.

Nochmal für die Langsameren: Das kommt auf den Kernel drauf an. Bei mir gibts das eben nicht. BTW: Und früher gabs das AFAIK auch grundsätzlich nicht, das REJECT Target wurde erst später irgendwann dazugemacht. Lässt sich z.B. in de.comp.security.firewall auch nachgooglen, war dort früher auch mal Thema.

Post by **torben** » 2004-02-21 04:52

Finde deine Firewall ganz brauchbar, gute Sache.

Post by **captaincrunch** » 2004-02-21 08:03

Ã?hm...ganz doofe Frage: was genau findest du denn daran so toll?

Post by **oxygen** » 2004-02-21 10:54

Lustig, besonders das meine Lachmuskeln ordentlich gefordert:

# Erlaube ausgehendes ping
# (Nur fuer Testzwecke! Wenn jemand in Ihr System eindringt, koennte er mit ping
# versuchen, andere aktive IP-Adressen in Ihrem DMZ zu identifizieren.
# Kommentieren Sie diese Regel aus, wenn Sie sie nicht benoetigen!)

iptables -A OUTPUT -p icmp -j ACCEPT --icmp-type echo-request

Post by **torben** » 2004-02-21 14:54

CaptainCrunch wrote:Ã?hm...ganz doofe Frage: was genau findest du denn daran so toll?

Das die Leute die mittlerweile dieses Forum fast überfluten endlich mal eine Firewall haben damit ihr schrei nach Sicherheit etwas gemildert wird.

Post by **dodolin** » 2004-02-21 15:01

Das die Leute die mittlerweile dieses Forum fast überfluten endlich mal eine Firewall haben damit ihr schrei nach Sicherheit etwas gemildert wird.

LOL. Traurig, aber wahr.

BTW: Ich sehe hier ein riesiges Marktpotenzial.
Man nehme:
- Eine Webseite, überschreibe sie mit "Sicherheits-Howto für Rootserver"
- Schreibt rein (so oder ähnlich):

Hier ein supergutes Profiskript speziell für Rootserver, einfach ausführen und euer Rechner ist absolut sicher und zuverlässig gegen jegliche Hacker, Spamversender, "Pub-Uploader" und Co. geschützt.

Das ganze dann einfach kostenpflichtig machen oder mit Bannern überfluten und nicht vergessen: Die gelben Packungen! Dann klappts ganz bestimmt...

SCNR.

Post by **captaincrunch** » 2004-02-21 16:03

YMMD... :lol:

Post by **checker** » 2004-02-21 17:52

Hallo,

ach macht euch darüber doch nicht lustig, :roll: okay auch im BGB steht "Unwissenheit schützt nicht vor Strafe" Aber die Leute haben einfach noch nicht viel Ahnung! (naja denken aber das Sie sie haben)

Auf der anderen Seite:
Klar kann man euch verstehen wenn die Leute sich nicht bemühen, mal was lesen und sich genauer mit solchen Dingen auseinandersetzen!

Aber Sicherheit ist wohl eines der schwierigsten aber auch intressantesten Themen im Bezug auf Rootserver! Und da müsste es eigentlich jedem schnell klar werden, das nichts sicher ist!

Naja das war mal ein kurzes Statement zu dem Thema, zum Thread:

Man sollte den Threadnamen ändern, das ist schon echt gefährlich weil manche Leute hier denken, dass wäre ein Non Plus Ultra Script :roll:

Naja...

MfG checker

Post by **elfrico** » 2004-03-05 19:13

Ha, das Skript kenne ich,
steht das nicht im O'reilly-Buch "Sichere Server mit Linux".
Dor werden die Pakete allerdings geDROPt, nicht REJECTed. Find ich auch besser, denn man will ja keine Information an den Angreifer geben, bei einem REJECT weiss er bescheid, dass es den Host gibt.

Soweit sogut, finde das Script so ganz ok. Wo ist das Problem, wenn man sich hier in einem solchen Forum austauscht und gemeinsam erörter, was gute Security-Strategien sind?

Post by **captaincrunch** » 2004-03-05 21:40

Find ich auch besser, denn man will ja keine Information an den Angreifer geben, bei einem REJECT weiss er bescheid, dass es den Host gibt.

Ich kann mir ehrlich gesagt nicht vorstellen, dass das so in einem O'Reilly-Buch beschrieben wurde. Du scheinst etwas komplett falsch verstanden zu haben. Etwas "Hintergrundlektüre" würde dir sicherlich gut tun:

http://www.iks-jena.de/mitarb/lutz/usen ... .html#Deny
http://www.iks-jena.de/mitarb/lutz/usen ... Verstecken

...sowie günstigstenfalls diverse RFCs zum Thema.

Wo ist das Problem, wenn man sich hier in einem solchen Forum austauscht und gemeinsam erörter, was gute Security-Strategien sind?

Genau das tun wir ja hier...und geben Gründe dafür, warum es eben keine "gute" Strategie ist.

Post by **dea** » 2004-03-05 22:04

elfrico wrote:Wo ist das Problem, wenn man sich hier in einem solchen Forum austauscht und gemeinsam erörter, was gute Security-Strategien sind?

Werd' Dir zunächst bitte über den Begriff "Strategie" klar, bevor Du hier noch weiter Unsinn erzählst.

plz - close

Post by **buddy0815** » 2004-03-06 09:26

CaptainCrunch wrote: Ich kann mir ehrlich gesagt nicht vorstellen, dass das so in einem O'Reilly-Buch beschrieben wurde. Du scheinst etwas komplett falsch verstanden zu haben. Etwas "Hintergrundlektüre" würde dir sicherlich gut tun:

Die policy's hab ich aus besagtem Buch übernommen und für meine Zwecke etwas umgeschrieben. Auch hab ich die DROP Regel durch die REJECT Regel ersetzt.

CaptainCrunch wrote:
Wo ist das Problem, wenn man sich hier in einem solchen Forum austauscht und gemeinsam erörter, was gute Security-Strategien sind?
Genau das tun wir ja hier...und geben Gründe dafür, warum es eben keine "gute" Strategie ist.

Wenn ich dich jetzt richtig verstanden habe, sind die Regeln nach deiner Meinung nach "Scheisse". Oder bezieht sich das nur auf die Drop Regel?

Wenn nicht, dann sag mir doch explizit was du anders machen würdest.

Es ist mir klar, dass es keine absolute Sicherheit im Netz gibt!

Post by **captaincrunch** » 2004-03-06 10:54

Auch hab ich die DROP Regel durch die REJECT Regel ersetzt.

OK, dann wird der einzige Grund für die DROP-Policy in einer etwas älteren iptables-Version zu suchen sein, die vermutlich beim Autor im Einsatz war.

Du willst wissen, was ich anders machen würde? Meine Zeit nicht mit einer Personal Firewall verschwenden, sondern lieber überlegen, wie ich die angebotenen Dienste so sicher konfiguriere, dass ich nachts halbwegs ruhig schlafen kann.

Post by **elfrico** » 2004-03-06 14:28

Folgendes steht bei mir in man iptables:

Code: Select all

   REJECT
       This is used to send back an error packet in response to the matched packet: otherwise it is equivalent  to
       DROP so it is a terminating TARGET, ending rule traversal.  This target is only valid in the INPUT, FORWARD
       and OUTPUT chains, and user-defined chains which are only called from those chains.  The  following  option
       controls the nature of the error packet returned:

Warum sollte ich dem Angreifer darüber informieren, dass sein Angriff fehlgeschlagen ist. Ich gebe ihm doch lieber keine Information als diese Infomation.

Oder denk ich da total falsch?

Post by **wirsing** » 2004-03-06 14:36

Bei dir ist also jeder, der auf deinen Server zugreifen will, ein Angreifer?

Post by **elfrico** » 2004-03-06 14:36

dea wrote: Werd' Dir zunächst bitte über den Begriff "Strategie" klar, bevor Du hier noch weiter Unsinn erzählst.

Nur zur Info...

StraÂ·te'gie, die; -,-n 1.längerfristiger Plan zur Erreichung eines Zieles, der versucht, äußere Faktoren und Reaktionen zu berücksichtigen und das weitere Vorgehen darauf einzurichten 2. MILITÃ?R für bestimmte Kriegssituationen festgelegte militärische Vorgehensweise 3. langfristig angelegte Vorgehensweise, Ã?berlegung zur mittel- und längerfristigen Entwicklung

Post by **elfrico** » 2004-03-06 14:50

wirsing wrote:Bei dir ist also jeder, der auf deinen Server zugreifen will, ein Angreifer?

Das geht schon etwas in die Richtung, aber leider ein Stückchen zu weit.

Es gibt Leute, die auf bestimmte Dienste des Server zugreifen dürfen. (ja, die ganze Welt darf HTTP nutzen). Das muss natürlich gestattet werden.
Aber was interssiert es mich, wenn jemand z.B. auf Port 4711 ein Paket schickt? Da gibt es nämlich keinen Service, den ich anbiete. Daraus folgt, dass ich auch nicht anworten muss (natürlich kann ich, aber will nicht).

Die Frage REJECT oder DROP ist also fast schon 'ne philosophische Frage.

Aber mal ganz im Ernst: ist doch eigentlich egal ob REJECT oder DROP. Wer rein will lässt sich von sowas nicht beeindrucken.

Also meine Frage: Gibt es Vorteile von REJECT gegenüber DROP?

RootForum Community

IPTABLES Skript

IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript

Re: IPTABLES Skript