Firewall-Skript (iptables) für vSERVER (s4y)

Elegantly

Registered User
Da ich einiges an Problemen hatte, ein vernünftiges iptables Firewall-Skript für meinen vSERVER (SuSE 9) zu schreiben - einige wichtige Module wie ip_conntrack können nicht verwendet werden :mad: -, poste ich hier mein rudimentäres Skript. Ja, eigentlich ist es nur ein Portfilter. Da hätte auch ipchains gereicht...

Code:
#!/bin/bash
#
# File:         /etc/init.d/firewall.sh
# Author:       Elegantly
#
# Version:      1.0
# Description:  Rudimentary version of a firewall for vSERVER.de;
#               since we cannot load other iptables modules,
#               we can only implement a simple packet filter
#               functionality
#


#### INTERFACE CONFIGURATION
#
#
EXT_IF="venet0:0"


# required binaries
#
IPT=/usr/sbin/iptables
if [ ! -f $IPT -o ! -x $IPT ]; then
  echo "Incorrect iptables binary location: $IPT"
  exit 1
fi

IFCONFIG=/sbin/ifconfig
if [ ! -f $IFCONFIG -o ! -x $IFCONFIG ]; then
  echo "Incorrect iptables binary location: $IFCONFIG"
  exit 1
fi

GREP=/usr/bin/grep
if [ ! -f $GREP -o ! -x $GREP ]; then
  echo "Incorrect iptables binary location: $GREP"
  exit 1
fi

AWK=/usr/bin/awk
if [ ! -f $AWK -o ! -x $AWK ]; then
  echo "Incorrect iptables binary location: $AWK"
  exit 1
fi

SED=/usr/bin/sed
if [ ! -f $SED -o ! -x $SED ]; then
  echo "Incorrect iptables binary location: $SED"
  exit 1
fi

# automatically retrieve our IP address
#
EXT_IP="`$IFCONFIG $EXT_IF | $GREP 'inet addr' | $AWK '{print $2}' | $SED -e 's/.*://'`"


#################################################

# delete any existing custom chains
#
$IPT -X

# Initialize and drop anything per default (in/out)
$IPT -P INPUT   DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT  DROP
$IPT -F
$IPT -X

# Allow communication on localhost (in/out)
$IPT -A INPUT  -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT




#################################################
####
####    INCOMING RULES
####
#################################################

# SSH
$IPT -A INPUT  -d $EXT_IP -p tcp --destination-port 22       -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --source-port 22            -j ACCEPT

# WWW/HTTP
$IPT -A INPUT  -d $EXT_IP -p tcp --destination-port 80     -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --source-port 80          -j ACCEPT

# HTTPS
$IPT -A INPUT  -d $EXT_IP -p tcp --destination-port 443    -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --source-port 443         -j ACCEPT

# SMTP
$IPT -A INPUT  -d $EXT_IP -p tcp --destination-port 25     -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --source-port 25          -j ACCEPT

# POP3
$IPT -A INPUT  -d $EXT_IP -p tcp --destination-port 110    -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --source-port 110         -j ACCEPT

# POP3S
IPT -A INPUT  -d $EXT_IP -p tcp --destination-port 995    -j ACCEPT
IPT -A OUTPUT -s $EXT_IP -p tcp --source-port 995         -j ACCEPT

# ICMP
$IPT -A OUTPUT -s $EXT_IP -p icmp --icmp-type echo-reply   -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p icmp --icmp-type echo-request -j ACCEPT



#################################################
####
####    OUTGOING RULES
####
#################################################

# SMTP
$IPT -A OUTPUT -s $EXT_IP -p tcp --destination-port 25     -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p tcp --source-port 25          -j ACCEPT

# DNS
$IPT -A OUTPUT -s $EXT_IP -p udp --destination-port 53     -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p udp --source-port 53          -j ACCEPT

# ICMP
$IPT -A OUTPUT -s $EXT_IP -p icmp --icmp-type echo-request -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p icmp --icmp-type echo-reply   -j ACCEPT

# WWW
$IPT -A OUTPUT -s $EXT_IP -p tcp --destination-port 80     -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p tcp --source-port 80          -j ACCEPT

# SSH
$IPT -A OUTPUT -s $EXT_IP -p tcp --destination-port 22     -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p tcp --source-port 22          -j ACCEPT

Das o.g. Skript erlaubt erkennt bei angegebenem Netzwerk-Interface die eigene IP automatisch, und erlaubt rudimentären Zugriff auf den eigenen Host (SSH, WWW, WWW mit SSL, SMTP, POP3, POP mit SSL, ICMP), und schränkt ausgehende Verbindungen ebenfalls auf die wichtigsten Dienste (SMTP, DNS, WWW, SSH, ICMP).

Wichtiger Hinweis: FTP funktioniert NICHT mit diesem Setup. Da wir keine Kernelmodule nachladen können, die Stateful Inspection etc. für FTP erlauben, ist es auf meinem Server komplett deaktiviert. Wer also z.B. mit wget ein RPM von einem FTP-Server laden will, muss anders vorgehen (z.B. einen HTTP-Mirror auswählen). NOTFALLS kann man auch die Firewall vorübergehend deaktivieren...

Hier noch ein Skript, um die Firewallfunktionalität zu deaktivieren (= ALLOW ALL). Da im o.g. Skript die Standard-Policies auf DROP gesetzt werden, reicht ein intuitivies Löschen aller definierten Regeln nämlich nicht aus.

Code:
#!/bin/bash
#
# File:         /root/firewall_disable.sh
# Author:       Elegantly
#
# Version:      1.0
# Description:  Make our firewall go into ALLOW ALL state;
#

################################################

# required binaries
#
IPT=/usr/sbin/iptables
if [ ! -f $IPT -o ! -x $IPT ]; then
  echo "Incorrect iptables binary location: $IPT"
  exit 1
fi


#################################################
$IPT -X

# Set default policies to allow all
#
$IPT -P INPUT   ACCEPT
$IPT -P FORWARD ACCEPT
$IPT -P OUTPUT  ACCEPT
$IPT -F
$IPT -X

# Allow any communication
#
$IPT -A INPUT  -j ACCEPT
$IPT -A OUTPUT -j ACCEPT
 
Good Job

Cool,

es gibt halt Leude die nicht nur an sich denken.

Auch wenn ich Suse nicht benutzte, war mir in Einnerung, als ob Suse nicht schon ein eigenes Firewallskript besitzt.
Egal, ich denke mal es läßt sich so wunderbar auf jede Distri anwenden. Werd ich nachher mal gegen mein *in3minreingehämertscript* ersetzen.

thx dOcX
 
Das Skript an sich ist distributionsunabhängig. Höchstens die Pfade zu den erforderlichen Binaries müssen evtl. geändert werden.

Ich habe die mitgelieferte SuSE Firewall gar nicht erst ausprobiert, da IIRC einige der benötigten iptables-Module bei vSERVER nicht nachgeladen werden können.
 
@Elegantly

Danke für Deinen Beitrag zu iptables. Auch wenn Huschi immer abwiegelt, halte ich die Portfilter auch auf auf einem vserver durchaus für wichtig.

Man kann zwar mühsam von Programm zu Programm die Configurationen durchgehen und nur den lokalen Zugriff erlauben (natürlich ausser den Diensten, die man anbieten will), aber iptables ist viel eleganter und man vergisst nichts.
 
Abgeändert für Debian:

Code:
#!/bin/bash
#
# File:         /etc/init.d/firewall.sh
# Author:       Elegantly
#              -Darkantares for Debian
# Version:      1.0
# Description:  Rudimentary version of a firewall for vSERVER.de;
#               since we cannot load other iptables modules,
#               we can only implement a simple packet filter
#               functionality
#


#### INTERFACE CONFIGURATION
#
#
EXT_IF="venet0:0"


# required binaries
#
IPT=/sbin/iptables
if [ ! -f $IPT -o ! -x $IPT ]; then
  echo "Incorrect iptables binary location: $IPT"
  exit 1
fi

IFCONFIG=/sbin/ifconfig
if [ ! -f $IFCONFIG -o ! -x $IFCONFIG ]; then
  echo "Incorrect iptables binary location: $IFCONFIG"
  exit 1
fi

GREP=/bin/grep
if [ ! -f $GREP -o ! -x $GREP ]; then
  echo "Incorrect iptables binary location: $GREP"
  exit 1
fi

AWK=/usr/bin/awk
if [ ! -f $AWK -o ! -x $AWK ]; then
  echo "Incorrect iptables binary location: $AWK"
  exit 1
fi

SED=/bin/sed
if [ ! -f $SED -o ! -x $SED ]; then
  echo "Incorrect iptables binary location: $SED"
  exit 1
fi

# automatically retrieve our IP address
#
EXT_IP="`$IFCONFIG $EXT_IF | $GREP 'inet addr' | $AWK '{print $2}' | $SED -e 's/.*://'`"


#################################################

# delete any existing custom chains
#
$IPT -X

# Initialize and drop anything per default (in/out)
$IPT -P INPUT   DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT  DROP
$IPT -F
$IPT -X

# Allow communication on localhost (in/out)
$IPT -A INPUT  -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT




#################################################
####
####    INCOMING RULES
####
#################################################

# SSH
$IPT -A INPUT  -d $EXT_IP -p tcp --dport 22       -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --sport 22            -j ACCEPT

# WWW/HTTP
$IPT -A INPUT  -d $EXT_IP -p tcp --dport 80     -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --sport 80          -j ACCEPT

# HTTPS
$IPT -A INPUT  -d $EXT_IP -p tcp --dport 443    -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --sport 443         -j ACCEPT

# SMTP
$IPT -A INPUT  -d $EXT_IP -p tcp --dport 25     -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --sport 25          -j ACCEPT

# POP3
$IPT -A INPUT  -d $EXT_IP -p tcp --dport 110    -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --sport 110         -j ACCEPT

# POP3S
$IPT -A INPUT  -d $EXT_IP -p tcp --dport 995    -j ACCEPT
$IPT -A OUTPUT -s $EXT_IP -p tcp --sport 995         -j ACCEPT

# ICMP
$IPT -A OUTPUT -s $EXT_IP -p icmp --icmp-type echo-reply   -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p icmp --icmp-type echo-request -j ACCEPT



#################################################
####
####    OUTGOING RULES
####
#################################################

# SMTP
$IPT -A OUTPUT -s $EXT_IP -p tcp --dport 25     -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p tcp --sport 25          -j ACCEPT

# DNS
$IPT -A OUTPUT -s $EXT_IP -p udp --dport 53     -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p udp --sport 53          -j ACCEPT

# ICMP
$IPT -A OUTPUT -s $EXT_IP -p icmp --icmp-type echo-request -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p icmp --icmp-type echo-reply   -j ACCEPT

# WWW
$IPT -A OUTPUT -s $EXT_IP -p tcp --dport 80     -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p tcp --sport 80          -j ACCEPT

# SSH
$IPT -A OUTPUT -s $EXT_IP -p tcp --dport 22     -j ACCEPT
$IPT -A INPUT  -d $EXT_IP -p tcp --sport 22          -j ACCEPT
 
Last edited by a moderator:
Was genau muss ich nun tun um das Firewallscript zu aktivieren und gibt es einen test um die Funktionalität zu testen?.
Bin halt grad am lernen :confused:

System: Suse 9.3

Gruss und Danke.
 
Frage mich gerade, was obiges Firewallscript eigentlich bewirken soll?
Wenn ein Angreifer über einen der zahlreichen Systemdienste in den Rechner eindringt, wird er einfach einen Backdoor installieren und eine ipfilter-Regel einfügen die nur ihn auf besagtem Port reinlässt.
Ne FW macht für mich nur Sinn, wenn hinter dem FW-Rechner noch weitere Rechner im Netz hängen und auf der Firewall keine kritischen Systemdienste laufen :)

Bevor ihr eure Bemühungen in solche FW Scripte investiert, solltet ihr lieber die Dienste auf non-standard Ports verlegen und sie aktuelle halten.
 
Cyberchriss said:
Ne FW macht für mich nur Sinn, wenn hinter dem FW-Rechner noch weitere Rechner im Netz hängen und auf der Firewall keine kritischen Systemdienste laufen :)
Absolut richtig denn
Definition said:
Eine Firewall schützt Netzwerk A vor Netzwerk B
Wenn der Traffic schon am System ankommt und von diesem verarbeitet wird ist's viel zu spät für alles.
Cybercriss said:
Bevor ihr eure Bemühungen in solche FW Scripte investiert, solltet ihr lieber die Dienste auf non-standard Ports verlegen und sie aktuelle halten.
Nein: security by obscurity -> kein Mehr an Sicherheit
Ja: weniger Logmeldungen, sonst nichts.

Aktuelle Patches einzuspielen gehört zu den laufenden Tätigkeiten, aber auch dies entbindet nicht von einer peniblen Konfiguration jedes einzelnen Dienstes der auf dem Server läuft.

Firewalls wie in den vorherigen Postings erörtert sind ein Versuch Desktop-"Firewalls" nachzubauen, auf einem Linuxhost erstens völlig sinnfrei da es keine unbenötigten offenen Ports gibt und zweitens am Sinn vorbei da eine Firewall irgendwoanders in Hardwareform im Rechenzentrum zu stehen hat.

iptables sind ein gutes Mittel für Logging und Analyse, vielleicht auch für Low-Budget-Eigenbau-Router, aber auf einem Applicationserver in freier Wildbahn ist jedes Script nur eine weitere Fehlerquelle.

0,02 EUR ;)

Cheers

tcs
 
Wo du Recht hast hast du Recht Herr Kollege.

Was bringt das Script, wenn dadurch kein Port geschlossen wird? Oder ist das die neue Form von Dienst abschalten?

[Edit]War zu langsam - Frage schon beantwortet[/Edit]
 
Zitat:
Zitat von Cybercriss
Bevor ihr eure Bemühungen in solche FW Scripte investiert, solltet ihr lieber die Dienste auf non-standard Ports verlegen und sie aktuelle halten.
Nein: security by obscurity -> kein Mehr an Sicherheit
Ja: weniger Logmeldungen, sonst nichts.

Grundsätzlich hast Du vollkommen Recht, dass bei gezielten Angriffen auf einen host logischerweise kein Sicherheitsgewinn vorhanden ist :)
Wenn ich allerdings an die Portscans der ganzen Scriptkiddies denke, die sich teilweise auf sshd oder ftpd Standardports beschränken, kann man deren Aufmerksamkeit doch ein wenig vom eigenen Server ablenken ;)

Ansonsten bleibt vielleicht noch anzumerken, dass rooties grundsätzlich als unsicher einzustufen sind und man regelmässig Backups machen sollte sowie genügend Zeit um sich um die Konfiguration sowie aktualität des Systems zu kümmern. Ebeneso sollte man von Zeit zu Zeit mal seine Logfiles parsen.
 
Cyberchriss said:
Wenn ein Angreifer über einen der zahlreichen Systemdienste in den Rechner eindringt, wird er einfach einen Backdoor installieren und eine ipfilter-Regel einfügen die nur ihn auf besagtem Port reinlässt.
Die Abänderung der Firewall-Policy (= das iptables-Regelwerk) kann nur durch root durchgeführt werden. Du setzt also bei deiner Argumentation voraus, dass der Angreifer root-Rechte erhalten hat.

Oft schafft es ein Angreifer aber nur, einen x-beliebigen Benutzeraccount zu hacken bzw. Systembenutzer ("www", "apache", "mysql" und wie sie alle heißen mögen). Eine Backdoor, z.b. mit Verbindung ins IRC-Netz, kann dann aber noch lange nicht verwendet werden (installiert ja, benutzt nein), da bis auf die weniger in der Firewall Rulebase explizit erlaubten Verbindungen - wie z.B. eingehende Verbindungen für den http-Dienst - alle anderen eingehenden und ausgehenden Verbindungen gesperrt sind.

Dann kann ein hochgeladenes und kompiliertes server.rat.c nämlich nicht mehr nach Hause telefonieren - weder selbständig vom VSERVER nach außen noch durch den ursprünglichen Hacker von außen auf den VSERVER (wenn ich jetzt ganz korrekt bin, muss ich hinzufügen, dass in meinem Beispiel von server.rat.c dieses ohnehin nur letzteres kann, d.h. eine simple Art von Backdoor ähnlich eines telnetd zu öffnen; IIRC wurde server.rat.c im Phrack Magazine erstmals vorgestellt, dort gibt es auch den Source Code für Interessierte).

Aus diesem Grund halte ich es daher auch für notwendig, nicht nur eingehende, sondern auch ausgehende Verbindungen zu filtern.

Cyberchriss said:
Ne FW macht für mich nur Sinn, wenn hinter dem FW-Rechner noch weitere Rechner im Netz hängen und auf der Firewall keine kritischen Systemdienste laufen :)
Ich stimme dir zu, dass eine Firewall idealerweise selber keine Dienste zur Verfügung stellt, um selbst weniger angreifbar zu sein (extremere Varianten sind z.B. transparent bridges, die ich mit OpenBSD aufgesetzt habe - diese Maschinen filtern Netzwerkverbindungen, obwohl sie selber keine IP haben - die große Masse an "Crackern" wird nicht einmal herausfinden können, wo und was sich da im Netzwerk befindet).

Cyberchriss said:
Bevor ihr eure Bemühungen in solche FW Scripte investiert, solltet ihr lieber die Dienste auf non-standard Ports verlegen und sie aktuelle halten.
Zum Punkt "Software aktuell halten" stimme ich dir vollkommen zu. Das ist bei vSERVERN von S4Y aber leider mitunter ein Problem. Erst einmal will YOU manchmal nicht so richtig mit den S4Y-eigenen RPMs oder auch Confixx zusammenspielen; und zweitens...naja, wie alt ist nochmal SUSE 9.0? Nach zwei Jahren gibt es IIRC keine Patches mehr für SUSE-Releases (bei SUSE gibt es alle 6 Monate ein neues Release).

Andererseits muss ich zu deinem Statement aber auch anmerken, dass man mit Security through Obscurity nur sehr wenig erreichen kann. Neben der offensichtlichen Thematik hinsichtlich Obscurity muss ich auch fragen: Was nützt mir ein Webserver für die Allgemeinheit, der auf Port 39261 lauscht?

Ich glaube nicht, dass Google diesen Web-Server findet oder dass sich Kunden die Adresse merken können - oder Freunde, die von Internettechnik keine Ahnung haben.

Sind Firewalls auf einem Applikationsserver sinnvoll?
Das darf gerne jeder selbst für sich entscheiden. Ich entscheide mich je nach Fall für oder gegen den Einsatz einer Firewall auf einem Applikationsserver.

Eine andere Fragestellung ist aber, ob eine Firewall auf einem VSERVER Sinn macht.

Ich setze ein iptables-Skript ein, da ich keinerlei Informationen darüber habe, ob und wie S4Y in ihren Rechenzentren Kunden-VSERVER absichern. Ich kann mir z.B. auf meinem VSERVER ziemlich sicher sein, dass meine Anwendungen keine IP-Pakete mit Absenderadressen aus privaten Netzwerken oder sogar der VSERVER-IP von außen erhalten (spoofing) - um nur einen der Vorteile zu nennen. Leider kann man mit den Bordmitteln der S4Y VSERVER nicht allzu viel in dieser Hinsicht machen. Natürlich gibt es auch andere Arten von Sicherheitsprogrammen wie AIDE oder Tripwire, die beim Absichern eines VSERVERs helfen. Um diese ging es aber in diesem Thread nicht.

Wenn ich wüßte, dass direkt vor meinem VSERVER eine gut von S4Y gewartete Firewall stünde, würde ich vielleicht anders darüber denken. Dennoch stellte sich mir dann die Frage, was meinen VSERVER eigentlich vor Kunden anderer VSERVER schützt, die sich im gleichen Netzwerk wie mein eigener Server hinter der Firewall befinden. Eine bekannte Weisheit im Sicherheitsbereich sagt: "Die meisten Angriffe kommen von innen". :D

tcs said:
Definition: Eine Firewall schützt Netzwerk A vor Netzwerk B.
Da musste ich schmunzeln, denn ich könnte dir ein Dutzend anderer Definitionen von Firewalls vorlegen, deren Unterschiede von tief technisch bis hoch philosophisch reichen.

Um es vorwegzunehmen: In meinem ersten Posting in diesem Thread habe ich den Begriff "Firewall" verwendet, damit man den Thread halbwegs gut über die Board-Suche finden kann. :)

Manche meiner Kollegen würden z.B. sagen, dass das o.g. Skript keine Firewall realisiert/ist, sondern lediglich ein Packet Filter ist - für sie ist das Feature "Stateful Inspection" erforderlich, damit eine Firewall sich heutzutage Firewall nennen kann (auf einem VSERVER kann man mangels Kernelmodulen leider kein iptables mit Stateful Inspection verwenden).

Man kann sich darüber hinaus auch fragen, bis zu welchem Layer eine Firewall filtern muss oder filtern kann. Bis zum Transport Layer (TCP/UDP)? Oder auch Application Layer (HTTP, STMP)? Wenn man nämlich auch Application Layer einbezieht, ist die Frage nach dem Sinn einer Firewall auf einem Applikationsserver vielleicht eine ganz andere. Wenn man sich heute die Fachbroschüren und Whitepapers der entsprechenden Hersteller durchliest, findet man bestimmt vieles, aber definitiv keine allgemein akzeptierte Antwort.

--

Wie gesagt, die Diskussion über Sinn und Unsinn kann recht schnell ins Philosophische abgleiten.

Jedenfalls bin ich erfreut, dass interessierte VSERVER-Kunden beim Durchlesen dieses Threads auch Argumente gegen den Einsatz einer Firewall auf einem VSERVER sehen! Das ist sehr viel besser, als wenn die hier geposteten Firewall-Skripte auf Grund technischer Fehler in der Luft zerrissen worden wären. ;)

Edited:
P.S.: Hehe, diese Post ist länger geworden als gedacht. Vielleicht regt sie ja zum Nachdenken an.:p
 
Last edited by a moderator:
Ich habe einen Verbesserungsvorschlag für das Script:

Code:
$IPT -A INPUT -s 255.0.0.0/8 -j DROP
$IPT -A INPUT -s 0.0.0.0/8 -j DROP
$IPT -A INPUT -s 192.168.0.0/16 -j DROP
$IPT -A INPUT -s 172.16.0.0/12 -j DROP
$IPT -A INPUT -s 10.0.0.0/8 -j DROP

Ich musste Feststellen das Leute die gerne Ihre IP-Adresse fälschen gerne diese Bereiche verwenden.
 
Back
Top