PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Könnt ihr euch mal dieses iptables-Skript anschauen?



Qeldroma
30.04.03, 19:52
Folgendes möchte ich auf einem Firmen-Server (über DSL ins Netz, zwei NIC's in's LAN) einsetzen. Sollte ich noch irgendetwas verbessern?



#!/bin/bash
NET2SERVER=""
LAN2SERVER="22 210 3306"
SERVER2LAN="80 8080 443 22 10000"
SERVER2NET="20 21 80 8080 443"
NET2LAN=""
LAN2NET="20 21 80 8080 110 119 443 995"
NIC2NET="ppp0"
NICs2LAN="eth1 eth2"
allowedICMP="echo-request destination-unreachable source-quench time-exceeded parameter-problem"
#############################################
## Module laden ##
#############################################

depmod -a
modprobe ip_tables
modprobe ip_conntrack
modprobe iptable_filter
modprobe iptable_mangle
modprobe iptable_nat
modprobe ipt_LOG
modprobe ipt_limit
modprobe ipt_state
modprobe ipt_owner
modprobe ipt_REJECT
modprobe ipt_MASQUERADE
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

#############################################
## Kernelparameter setzen ##
#############################################

# accept_source_route: Dies würde erlauben, das fremde Rechner den Weg definieren dürfen, den Packete nehmen. Weg.
# accept_redirects: Dies würde fremden Rechnern das Manipulieren der Routing-Tabelle erlauben. Weg.
# *_redirects: Dies würde fremden Rechnern das Manipulieren der Routing-Tabelle erlauben. Weg.
for i in /proc/sys/net/ipv4/conf/*/{accept_source_route,accept_redirects,send_redirec ts}
do
echo 0 >$i
done

# Pakete sollen auch weitergeleitet werden "(--> LAN)"
echo 1 >/proc/sys/net/ipv4/ip_forward

# SynCookie-Schutz aktivieren
echo 1 >/proc/sys/net/ipv4/tcp_syncookies

#############################################
## alle Regeln zurücksetzen ##
#############################################

# Folgende Tabellen gibt es unter Linux, jede enthält chains, welche die eigentlichen Regeln sind:
# filter: Enthält alle filternden Regeln
# nat: Enthält Regeln, welche Ziele verdeckt weiterleiten (Server im LAN von außen erreichen)
# mangle: Hier können Pakete gemangled werden, also manipuliert.

# Zuallererst wir alles zurückgesetzt, das heißt alle Regeln gelöscht und ale Tabellen auf drop gesetzt.
# -F steht für flush, also leeren. -X steht für erase, also löschen.
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

#############################################
## neue Regeln ##
#############################################

# INPUT kommt von draußen, OUTPUT geht rauswärts. Da viele Sachen über höhere Ports (>=1024 - 1024:) abgehandelt
# werden, nachdem auf einem Standard-port die Verbindung verhandelt wurde, lassen wir alle eingehenden
# TCP-Verbindungen zu, die NICHT das erste Paket einer Übertragung sind. ESTABLISHED steht für verbunden, d.h.
# zugehörig zu einer bestehenden Verbindung. RELATED sind Verbindungen, welche vermutlicht ebenfalls zu einer
# bestehenden dazugehören.
iptables -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p ALL -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# Lokale (-i[nterface] lo) Kommunikation soll natürlich frei verlaufen.
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Nun lasse ich den Kontakt zu meinem Server zu. Ähnlich verfährt man mit allen anderen Servern. dport steht für
# d[estination]port und sport für s[ource]port.
for port in $SERVER2NET; do
iptables -A OUTPUT -p tcp --sport $port -j ACCEPT
iptables -A OUTPUT -p udp --sport $port -j ACCEPT
done
for port in $NET2SERVER; do
iptables -A INPUT -p tcp --dport $port -j ACCEPT
iptables -A INPUT -p udp --dport $port -j ACCEPT
done

# Nun den Kontakt zwischen LAN und SERVER
for port in $SERVER2LAN; do
for NIC in $NICs2LAN; do
iptables -A OUTPUT -i $NIC -p tcp --sport $port -j ACCEPT
iptables -A OUTPUT -i $NIC -p udp --sport $port -j ACCEPT
done
done
for port in $LAN2SERVER; do
for NIC in $NICs2LAN; do
iptables -A INPUT -i $NIC -p tcp --dport $port -j ACCEPT
iptables -A INPUT -i $NIC -p udp --dport $port -j ACCEPT
done
done

# Nun folgen Regeln um das LAN ins internet zu bringen. Dies geschiet AUSSCHLIEßLICH über die FORWARD-chain.
# -o Gerät definiert, ob es rauswärts oder reinwärts geht.
iptables -A FORWARD -o $NIC2NET -p ALL -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
for NIC in $NICs2LAN; do
iptables -A FORWARD -o $NICs2LAN -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT
done
for port in $SERVER2NET; do
iptables -A OUTPUT -p tcp --sport $port -j ACCEPT
iptables -A OUTPUT -p udp --sport $port -j ACCEPT
done
for port in $SERVER2LAN; do
for NIC in $NICs2LAN; do
iptables -A OUTPUT -i $NIC -p tcp --sport $port -j ACCEPT
iptables -A OUTPUT -i $NIC -p udp --sport $port -j ACCEPT
done
done

# Zuletzt aktivieren wir die NAT, somit werden die LAN-Clients auf die Internetseitige IP gefälscht, um von außen
# den Eindruck eines einzigen Rechners zu erzeugen.
iptables -t nat -A POSTROUTING -o $NIC2NET -j MASQUERADE

# Nun öffnen wir die Kommunikation zur Namensauflösung "(DNS: port 53)". Zuerst die ANfrage an einen DNS. Dieses läuft
# erst über UDP, wenns nicht klappt über TCP. Die Antwort ist schwieriger, da die Antwort über UDP läuft und die
# firewall somit nicht erkennen kann, ob es eine bestehende oder neue Verbindung sein soll. Daher geben wir explizit
# den DNS-Server an.
iptables -A OUTPUT -p udp --sport 1024: --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024: --dport 53 -j ACCEPT
for DNS in $(cut -d ' ' -f 2 /etc/resolv.conf)
do
iptables -A INPUT -p udp -s $DNS --sport 53 -j ACCEPT
iptables -A INPUT -p tcp -s $DNS --sport 53 -j ACCEPT
done

# Jetzt kümmern wir uns, um bestimmte ICMP-Packete, welche nicht Port, sondern Inhalt-abhängig sind (Fehlermeldungen).
# Da wir zur Fehlersuche nicht auf PING in jede Richtung verzichten möchten, lassen wir alles durch.
for type in $allowedICMP; do
for NIC in $NICs2LAN; do
iptables -A INPUT -i $NIC -p icmp --icmp-type $type -j ACCEPT
iptables -A OUTPUT -o $NIC -p icmp --icmp-type $type -j ACCEPT
done
done

#############################################
## Logging ##
#############################################

# NETBIOS und CUPS droppen wir Kommentarlos, alles andere zeichnen wir auf.
iptables -A INPUT -p tcp --dport netbios-ns -j DROP
iptables -A INPUT -p tcp --dport netbios-dgm -j DROP
iptables -A INPUT -p tcp --dport netbios-ssn -j DROP
iptables -A INPUT -p udp --dport netbios-ns -j DROP
iptables -A INPUT -p udp --dport netbios-dgm -j DROP
iptables -A INPUT -p udp --dport netbios-ssn -j DROP
iptables -A INPUT -p tcp --dport 631 -j DROP
iptables -A INPUT -p udp --dport 631 -j DROP
iptables -A INPUT -j LOG
iptables -A OUTPUT -j LOG

# Wir lassen die restlichen Pakete durchlaufen, aber ignorieren sie, denn wir wollen es einem Eindringling nicht
# gönnen, herauszufinden, was wir so blocken. Einzig FTP-Authorizierung blocken wir offen, um zu verhindern, das
# der FTP ewig auf Antworten wartet.
iptables -A INPUT -p tcp --dport auth -j REJECT --reject-with tcp-reset
iptables -A INPUT -j DROP

# Außerdem wollen wir die Welt um uns nicht mit ungewollten Paketen belästigen, daher werden diese zurückgewiesen.
iptables -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A OUTPUT -p udp -j REJECT
iptables -A OUTPUT -j DROP



Ist das so ausreichend??

RapidMax
01.05.03, 12:41
So auf den ersten Blick sieht es sauber ausgebaut auf. Es ist jedoch schwierig es zu beurteilen, wenn die Netzwerkstruktur nicht bekannt ist.

Teste es doch mit den gängigen Sicherheits-Tools wie nessus oder zumindest nmap.

Gruss, Andy

Qeldroma
01.05.03, 15:24
Naja, ein server als Router/Firewall/LAMP zwischen DSL und LAN mit zwei NIC's in zwei LAN's, beide gleich geschützt.

Also relativ einfach.
Komischerweise bekomme ich laut online-scan einen offenen Port 113 (auth)?! Wüßte mal gerne wo der herkommt...

RapidMax
01.05.03, 15:27
Original geschrieben von Qeldroma
Naja, ein server als Router/Firewall/LAMP zwischen DSL und LAN mit zwei NIC's in zwei LAN's, beide gleich geschützt.

Also relativ einfach.
Komischerweise bekomme ich laut online-scan einen offenen Port 113 (auth)?! Wüßte mal gerne wo der herkommt...

:confused: den hast du doch absichtlich mit tcp-reset rejected?


iptables -A INPUT -p tcp --dport auth -j REJECT --reject-with tcp-reset
Das ist auch üblich, da gewisse Server (ftp, irc) beim Connection zuerst versuchen auf diesen Port zu connecten, was ohne tcp-reset eine Weile dauert, da dann der Timeout abgewartet wird, ohne Rückmeldung.

Gruss, Andy

Qeldroma
01.05.03, 18:25
:D OBERpeinlich :D

....sollte wohl nächstes Mal, wenn ich so etwas entdecke, mein EIGENES Skript auch bis zu ende zu lesen.