Iptables -> einige Fragen

[Thomas Wildgruber]

Hi Group,

ich habe zur Demonstration f�r einen Azubi ein Iptables Skript mit einigen
Regeln geschrieben und im Moment sind mir hier drei Resultate unklar:

---snip---
#!/bin/sh

### BEGIN INIT INFO
# Provides: firewall.sh
# Required-Start: $local_fs $network
# Required-Stop: $local_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Descrition Firewall start script
# Description: Iptables config script
### END INIT INFO

IPTABLES=/sbin/iptables

SPOOFING="0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 /
224.0.0.0/3 255.0.0.0/8"
DNS="192.168.167.2"

case $1 in
start)

echo -n "Starting Firewall..."

# Kernelmodul laden
modprobe ip_conntrack_ftp

# Default Policys setzen
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

# Tabelle flushen
$IPTABLES -F

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

# Spoofing verhindern
for ip in $SPOOFING ;
do
$IPTABLES -A INPUT -s $ip -j LOG --log-prefix "Spoofing detected:"
# $IPTABLES -A INPUT -s $ip -j DROP
done

# Neue TCP Sessions nur mit SYN erlauben
# http://www.smythies.com/~doug/network/iptables_syn/index.html
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG /
--log-prefix "New but SYN-Flag not set:"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# Erlaube Pakete von existierenden Sessions
$IPTABLES -I INPUT 1 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Erlaube abgehende Pings
$IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT

# Erlaube DNS
$IPTABLES -A OUTPUT -p udp --dport 53 -d $DNS -m state --state NEW -j
ACCEPT

# Erlaube NTP
$IPTABLES -A OUTPUT -p udp --dport 123 -m state --state NEW -j ACCEPT

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

# Erlaube HTTP
$IPTABLES -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT

# Erlaube Whois
$IPTABLES -A OUTPUT -p tcp --dport 43 -m state --state NEW -j ACCEPT

# Erlaube FTP (ausgehend)
$IPTABLES -A OUTPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT

echo "Done."

;;
stop)
echo -n "Stopping Firewall ... "
# Policy setzen
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT

# Tabelle flushen
$IPTABLES -F

echo "Done."

;;

*)
echo "Usage {start|stop}"

;;
esac
---snap---

Frage 1) Wobei ich hier die kurze Antwort vermutlich schon kenne... Wenn
ich gegen den Rechner, der das o.g. Regelwerk geladen hat, einen Portscan
fahre, bekomme ich erwartungsgem�� nur den TCP Port 22 als ge�ffnet
angezeigt. Lasse ich den Portscan jedoch auf der lokalen Maschine laufen,
werden mehrere ge�ffnete Ports angezeigt:

---snip---
$ nmap localhost

Starting Nmap 5.00 ( http://nmap.org ) at 2012-09-03 10:46 CEST
Interesting ports on localhost (127.0.0.1):
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
111/tcp open rpcbind

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
---snap---

Ich vermute mal, dass liegt an der Regel, welche den Loopback Adapter
freigibt. Den Mechanismus mit dem Loopbackadapter habe ich auch noch nicht
ganz so verstanden, dachte jedoch, dass die localhost Adresse nichts mit
dem Loopbackadapter zu tun hat. Ist dieses Verhalten von nmap auf dem
lokalen Host mit dem Loopbackadapter erkl�rbar?

2 Frage: Im Skript befindet sich eine Spoofing Log-Regel, die Drop-Regel
dazu ist auskommentiert, weil ich auch dort ein Problem ermittelt habe, von
dem ich jetzt aber nicht wei� woher es kommt. Beim Starten des Skripts wird
ein Log-Eintrag nach /var/log/syslog geschrieben:

---snip---
Spoofing detected:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:c0:00:08:0
8:00 SRC=192.168.167.1 DST=192.168.167.255 LEN=78 TOS=0x00 PREC=0x20 TTL=64
ID=41041 PROTO=UDP SPT=60342 DPT=137 LEN=5
8
---snap---

Woher kommt das, dass die Regel hier anspringt? Meine lokale IP-Adresse
ist: 192.168.167.196/24 und sollte doch nicht von den angelegten Spoofing
Adressen erfasst werden?

Frage 3) Bei meinen ganzen Recherchen bzgl. Iptables bin ich nirgens auf
eine Regel gestossen, welche die initiale DHCP-Prozedur des DHCP-Clients
erfasst. Gewundert habe ich zwar schon, dass der Rechner auch ohne Regel
eine IP-Adresse bekommt aber in diversen Forenbeitr�gen wurde gemutma�t,
dass der ganze DHCP Prozess noch vor dem aktivieren der Firewall
abgewickelt wird. So wird es wohl sein dachte ich mir aber jetzt findet
sich folgender Eintrag (mehrmals) im syslog:

---snip--
Sep 3 10:54:39 debian dhclient: DHCPREQUEST on eth0 to 192.168.167.254
port 67
Sep 3 10:54:39 debian dhclient: send_packet: Operation not permitted
---snap--

Muss man DHCP in seinem Regelsatz doch irgendwie ber�cksichtigen?

Ansonsten bitte ich noch um Hinweise, wenn im Skript Fehler vorhanden sind,
weil ich die nat�rlich ungern weitergegeben m�chte ;-)

Thx & Bye Tom
--
"Manches Gewissen ist nur rein, weil es nie benutzt wurde" (Robert Lembke)

[Thomas Wildgruber]

Servus Heiko,

On 3 Sep 2012 14:01:23 +0200, Heiko Schlenker wrote:

> * Thomas Wildgruber <excp...@web.de> schrieb:
>> [nmap auf localhost -> Loopback Adapter]

>> Ich vermute mal, dass liegt an der Regel, welche den Loopback Adapter
>> freigibt.
>

> Noch ein Grund, der auf der Hand liegt: Die Dienste sind an bestimmte
> Schnittstellen gebunden, deshalb wom�glich nur im LAN verf�gbar und
> nicht �ffentlich zug�nglich. Siehe auch su -c '/bin/netstat -apentu',
> Spalte "Local Address".

Ah okay. Der exim4 (smtp, 25) ist tats�chlich auf die localhost Adresse
gebunden. (BTW: Die doch auch zum Loopback-Interface geh�rt). Der Port 111
jedoch ist auf alle Adressen gebunden (0.0.0.0) und somit vermutlich auch
auf alle Netzwerk-Interfaces...?

>> ---snip---
>> Spoofing detected:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:c0:00:08:0
>> 8:00 SRC=192.168.167.1 DST=192.168.167.255 LEN=78 TOS=0x00 PREC=0x20 TTL=64
>> ID=41041 PROTO=UDP SPT=60342 DPT=137 LEN=5
>> 8
>> ---snap---
>>
>> Woher kommt das, dass die Regel hier anspringt?
>

> Die Skript-Variable "ip" ist nirgends definiert, oder?

Doch, die wird innerhalb der for-Schleife (for ip in ...) definiert.

> Zudem fehlt in der Spoofing-Regel die Angabe der Schnittstelle.

Da drauf bin ich jetzt auch gekommen, nachdem ich stundenlang alle Cent
zusammen gekratzt habe, die ich gefunden habe. Die Regel scheint �berhaupt
nur dann Sinn zu machen, wenn mehrere Netzwerk-Schnittstellen im System
vorhanden sind. Bei einem Router zB m�chte man dann verhindern (bzw.
erkennen und verhindern), dass am externen Interface IP-Adressen aus dem
internen Netz auftauchen, weil das so unter normalen Umst�nden nicht
m�glich sein sollte. Ich denke dann trifft so eine Spoofing-Regel zu.

Bei einem System mit nur einem Interface (Wie hier bei einem simplen
Client) wird man das IP-Spoofing so gar nicht erkennen k�nnen und die Regel
w�re eigentlich in diesem Setup �berfl�ssig ... oder sehe ich das immer
noch nicht richtig?

> Au�erdem sollte die
> Spoofing-Erkennung (zus�tzlich) per sysctl aktiviert werden
> (/proc/sys/net/ipv4/conf/*/rp_filter).

Ist bereits aktiviert.

>> Muss man DHCP in seinem Regelsatz doch irgendwie ber�cksichtigen?
>

> Durchaus m�glich:
> "-A <chain> -i <interface> -p udp --dport 67:68 --sport 67:68 -j ACCEPT"

Okay ich habe jetzt schon mal testweise folgende Regel eingebaut gehabt
aber die Fehlermeldung im Syslog habe ich immer noch:

---snip---
$IPTABLES -A INPUT -p UDP --sport 68 -j ACCEPT
$IPTABLES -A OUTPUT -p UDP --sport 67 -j ACCEPT
---snap---

Ich probier es mal mit sport 67:68 und dport 67:68 in jeder Regel. Aber so
wie ich den Ablauf der DHCP Kommunikation verstanden habe, m�ssten meine
Regeln eigentlich passen ... Anyway, passt jedenfalls nicht ;-)

http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

> Generell sollten Regeln wie
> "-A <chain> -m state --state ESTABLISHED,RELATED -j ACCEPT"
> ziemlich zum Schluss spezifiziert werden. Es werden n�mlich nicht alle
> Regeln abgearbeitet. Vielmehr stoppt die Firewall die Verarbeitung bei
> der ersten passenden Regel. Die Reihenfolge der Regeln kann nicht
> beliebig variiert werden.

Ja der Ablauf der Regelauswertung ist mir bekannt. Bei der Position dieser
Regel ziemlich weit oben im Regelwerk soll halt vermieden werden, dass
jedes Paket, welches bereits zu einer bestehenden Verbindung geh�rt, nicht
das gesamte Regelwerk durchgearbeitet werden muss. Schont Ressourcen.
Welchen Zweck verfolgst du damit, die Regel ziemlich weit unten zu
platzieren?

[Thomas Wildgruber]

On Mon, 3 Sep 2012 15:13:03 +0200, Thomas Wildgruber wrote:

>>> Muss man DHCP in seinem Regelsatz doch irgendwie ber嚙箱ksichtigen?
>>
>> Durchaus m嚙篇lich:

>> "-A <chain> -i <interface> -p udp --dport 67:68 --sport 67:68 -j ACCEPT"
>
> Okay ich habe jetzt schon mal testweise folgende Regel eingebaut gehabt
> aber die Fehlermeldung im Syslog habe ich immer noch:
>
> ---snip---
> $IPTABLES -A INPUT -p UDP --sport 68 -j ACCEPT
> $IPTABLES -A OUTPUT -p UDP --sport 67 -j ACCEPT
> ---snap---
>
> Ich probier es mal mit sport 67:68 und dport 67:68 in jeder Regel. Aber so

> wie ich den Ablauf der DHCP Kommunikation verstanden habe, m嚙編sten meine

> Regeln eigentlich passen ... Anyway, passt jedenfalls nicht ;-)
>
> http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

Ah jetzt habe ich hier doch noch einen Fehler gefunden, die zweite Regel
sollte einen --dport beinhalten keinen --sport. Die Regeln demnach
abge嚙緯dert wie folgt:

---snip---
$IPTABLES -A INPUT -p UDP --sport 68 -j ACCEPT

$IPTABLES -A OUTPUT -p UDP --dport 67 -j ACCEPT
---snap---

Die Regel scharf gemacht und sofort zeigt sich folgendes im Syslog:

---snip---
Sep 3 15:30:16 debian dhclient: DHCPREQUEST on eth0 to 192.168.167.254
port 67
Sep 3 15:30:16 debian dhclient: DHCPACK from 192.168.167.254
Sep 3 15:30:16 debian dhclient: bound to 192.168.167.196 -- renewal in 752
seconds.
---snap---

Demnach scheint das Thema jetzt abgehakt zu sein.

Mich wundert nur, dass DHCP so gut wie in keinem Beispiel Skript
angesprochen wird. DHCP ist ja jetzt kein exotisches Protokoll. Die
initiale DHCP Vergabe bei booten scheint sich zwar noch vor dem aktivieren
des Paketfilters abzuspielen, denn es funktioniert ja auch ohne diese
Regeln aber ich denke sp嚙緣estens wenn das Lease des Clients abgelaufen ist,
k嚙緯nten ohne diese Regeln Probleme mit der Erneuerung auftauchen...

Thx & Bye Tom
--

"One good Whiskey a day, keeps the doctor away"

[Andreas Kohlbach]

Thomas Wildgruber wrote on 03. September 2012:
>
> Servus Heiko,
>
> On 3 Sep 2012 14:01:23 +0200, Heiko Schlenker wrote:
>
>> * Thomas Wildgruber <excp...@web.de> schrieb:
>>> [nmap auf localhost -> Loopback Adapter]
>>> Ich vermute mal, dass liegt an der Regel, welche den Loopback Adapter
>>> freigibt.
>>
>> Noch ein Grund, der auf der Hand liegt: Die Dienste sind an bestimmte

>> Schnittstellen gebunden, deshalb womöglich nur im LAN verfügbar und
>> nicht öffentlich zugänglich. Siehe auch su -c '/bin/netstat -apentu',
>> Spalte "Local Address".
>
> Ah okay. Der exim4 (smtp, 25) ist tatsächlich auf die localhost Adresse
> gebunden. (BTW: Die doch auch zum Loopback-Interface gehört). Der Port 111

> jedoch ist auf alle Adressen gebunden (0.0.0.0) und somit vermutlich auch
> auf alle Netzwerk-Interfaces...?

Den Portmap (111) habe ich laut Prozessliste per

/sbin/portmap -i 127.0.0.1

laufen. Aus "man portmap":

-i address
bind portmap to address. If you specify 127.0.0.1 it will
bind to the loopback interface only.

Ich versuche auch, mit "Bordmitteln" zu arbeiten, um die Erstellung von
iptables Regeln zu vermeiden. Also mit dem Programm selbst an Interfaces
binden.

So lauscht mein Samba nur am (verschlüsselten) WLAN, während das Internet
über PPPOE (eth0) rein kommt. Was ich über die smb.conf mal einstellte,
ohne iptables nutzen zu müssen.
--
Andreas
Linux: The choice of a GNU generation.

[Thomas Wildgruber]

Servus Oliver,

On Tue, 04 Sep 2012 01:18:35 +0200, Oliver Sch@d wrote:

> Thomas Wildgruber wrote:
>
>> Ich vermute mal, dass liegt an der Regel, welche den Loopback Adapter
>> freigibt. Den Mechanismus mit dem Loopbackadapter habe ich auch noch
>> nicht ganz so verstanden, dachte jedoch, dass die localhost Adresse
>> nichts mit dem Loopbackadapter zu tun hat. Ist dieses Verhalten von
>> nmap auf dem lokalen Host mit dem Loopbackadapter erkl�rbar?
>

> Du kannst mit Iptables Netzwerkadapter und IP-Adressen getrennt als
> Kriterium konfigurieren. Die Adresse 127.0.0.1 bzw. ::1 ist f�r
> gew�hnlich an den Netzwerkadapter "lo" gebunden.
>
> Mit der Regel "iptables -i lo -j ACCEPT" willst du ausdr�cken, dass
> lokal erzeugter Datenverkehr zu deiner eigenen Maschine wieder hin in
> Ordnung ist und daher immer zugreifen darf. Wenn du das nun um�nderst
> auf die IP-Adresse hast du das Problem, dass du nicht sicher sein
> kannst, dass das Paket von au�en kommt mit gef�lschter Adresse. Zudem
> kann so ein Adapter auch eine andere Adresse als 127.0.0.1 haben, z.B.
> 127.0.0.2.
>
> Adressen sind letztlich Schall und Rauch, auf Adapternamen kannst du
> dich dagegen verlassen.

Jupp, dass habe ich mittlerweile auch schon gelesen. Da war eine nette
Anekdote dabei, wo man Skript-Kiddies anhand einer localhost Adresse (zB
127.12.102.2) diverse Angriffs-Taktiken erkl�rte. Die f�hren dann den
Angriff gegen ihre eigene Maschine durch. Localhost Adresse sind demnach
ganze IP-Adressbereiche. Wusste ich auch nicht...

>> 2 Frage: Im Skript befindet sich eine Spoofing Log-Regel, die
>> Drop-Regel dazu ist auskommentiert, weil ich auch dort ein Problem
>> ermittelt habe, von dem ich jetzt aber nicht wei� woher es kommt. Beim
>> Starten des Skripts wird ein Log-Eintrag nach /var/log/syslog
>> geschrieben:
>>
>> ---snip---
>> Spoofing detected:IN=eth0 OUT=
>> MAC=ff:ff:ff:ff:ff:ff:00:50:56:c0:00:08:0 8:00 SRC=192.168.167.1
>> DST=192.168.167.255 LEN=78 TOS=0x00 PREC=0x20 TTL=64 ID=41041
>> PROTO=UDP SPT=60342 DPT=137 LEN=5 8
>> ---snap---
>

> Du sperrst einfach allen Datenverkehr im LAN mit diesem Spoofing-Kram,
> was sicher nicht deine Intention ist.

Nein war es nicht. Ich bin mittlerweile soweit, dass ich diese Regel
eigentlich nur bei einem Rechner mit mehr als einem Netzwerk-Interface
einsetzen w�rde, um zu verhindern, dass Pakete an einem Interface
angenommen werden, welche eigentlich auf dem anderen zu erwarten w�ren. (zB
Router).

> Damit man nicht Datenverkehr auf
> der falschen Schnittstelle reinbekommt, kann man besser rp_filter setzen
> auf �ffentlich erreichbaren Schnittstellen:
>
> sysctl -w net.ipv4.conf.eth1.rp_filter=1
>
> bzw. in der /etc/sysctl.conf fest eintragen.

Habe ich gemacht. Aber ist diese Einstellung auch ohne netfilter wirksam
gegen Spoofing?

>> Woher kommt das, dass die Regel hier anspringt? Meine lokale
>> IP-Adresse ist: 192.168.167.196/24 und sollte doch nicht von den
>> angelegten Spoofing Adressen erfasst werden?
>

> Doch, du hast ja keinen Netzwerkadapter angegeben, wof�r die Regel nicht
> gelten sollte bzw. f�r den die Spoofing-Regeln explizit gelten w�rden.

Wobei ich doch aber das IP-Netz 192.168.0.0/24 nicht explizit als
Spoofing-Bereich angegeben habe. Das mit dem fehlenden Interface okay, das
habe ich mittlerweile mitgbekommen, dass das so nicht wirklich sinnvoll ist
aber wieso wird eine Adresse aus einem C-Netz geblockt, wenn nur �hnliche
Adressen aus einem B-Netz angegeben werden? Respektiert der Filter die
Subnetzmaske nicht?

>> [...]

>> Muss man DHCP in seinem Regelsatz doch irgendwie ber�cksichtigen?
>

> Selbstverst�ndlich, DHCP beruht auf UDP und wird ganz normal von
> Iptables/Netfilter gefiltert. Man sollte sich aber bewusst sein, dass 2
> UDP-Ports im Spiel sind, der Server wird auf UDP-Port 67 angesprochen,
> der Client auf UDP-Port 68.

Ja die Regeln habe ich mittlerweile eingetragen und die Fehlermeldungen im
Syslog sind verschwunden. Vielleicht kannst du noch ein paar Worte
verlieren, warum der Client aber noch eine IP-Adresse von einem DHC Server
bekommt, auch wenn keine Regel daf�r definiert wurde? Sicherlich muss es so
sein, dass der ganze DHCP Dialog noch vor dem Inkrafttreten der Iptables
regeln stattfindet aber wei� man das genauer? Also wann der DHCP Dialog
stattfindet in Bezig auf das Abarbeiten der init-Skripte? Das Interface und
das Netzwerksubsystem sind ja schon gestartet, dann w�rde man das doch
eigentlich von Netfilter auch erwarten.

>> Ansonsten bitte ich noch um Hinweise, wenn im Skript Fehler vorhanden
>> sind, weil ich die nat�rlich ungern weitergegeben m�chte ;-)

> [...]
> Aber das h�ngt ganz an deinen Anforderungen, wie man das ganze angeht,
> von denen du noch nicht erz�hlt hast.

Na, stand doch im ersten Absatz des OPs: "ich habe zur Demonstration f�r
einen Azubi ein Iptables Skript mit einigen Regeln geschrieben..." Okay,
das erkl�rt aber auch nur eine H�lfte des Skripts aber irgendwo muss man ja
mal anfangen... ;-)

> Achso, ich sehe noch, dass du alle Pakete sonst wegschmei�t, was eher
> uncool ist zum Debuggen und ebenso ICMP wegschmei�t - auch uncool. Mach
> den Leuten auf dieser Welt einschlie�lich dir selbst das Leben doch
> nicht unn�tig schwer.

Jupp, diesen Hinweis habe ich nicht vers�umt und explizit darauf
hingewiesen, dass ICMP g�nzlich abzustellen eine dumme Idee ist. Kenne ich
noch von fr�her in den Anf�ngen von DSL wo MTU Angaben irgendwo auf der
Strecke blieben usw...

> Zudem vermisse ich die IPv6-Regeln, wo sind die eigentlich?

Gute Frage, n�chste Frage ;-) Ja es wird Zeit sich damit zu besch�ftigen.
zZ lasse ich mir das von den Azubis erkl�ren, die das in der Schule lernen
aber die Zeit wird kommen, ich wei�. Warum konnten die nicht einfach zwei
Oketts an die bestehenden Adresse dran h�ngen und den Rest so lassen wie er
war?

> Ich lese gerade nochmal die Regeln - �rks, moment mal, hier noch ein
> paar Kommentare:

>
>>
>> # Neue TCP Sessions nur mit SYN erlauben
>> # http://www.smythies.com/~doug/network/iptables_syn/index.html
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG /
>> --log-prefix "New but SYN-Flag not set:"
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
>

> Das kann man sich sparen mit dem Syn-Flag.

Warum? Ich dachte das war ne gute Idee?

>> # Erlaube Pakete von existierenden Sessions
>> $IPTABLES -I INPUT 1 -m state --state ESTABLISHED,RELATED -j
>> ACCEPT
>

> Wieso steht die Regel irgendwo, wird aber am Anfang eingef�gt?

Das war zur Demonstration, wie Regeln im Skript abgearneitet werden
(n�mlich der reihe nach) und welche M�glichkeiten man hat, hier noch
Einfluss darauf zu nehmen.

>> # Erlaube DNS
>> $IPTABLES -A OUTPUT -p udp --dport 53 -d $DNS -m state --state NEW
>> -j
>> ACCEPT
>

> TCP fehlt bei DNS, immer UDP *und* TCP auf Port 53 freigeben.

Ah okay. Kann ich in einer Regel beide Protokolle angeben oder brauche ich
den Regelsatz zweimal? Ich hab mal was von Multiports gelesen, gibts das
auch f�r Protokolle.

>> # Erlaube FTP (ausgehend)
>> $IPTABLES -A OUTPUT -p tcp --dport 21 -m state --state NEW -j
>> ACCEPT
>

> Ohne FTP-Modul wird das so nix.

Steht auch im Skript:

---snip---

# Kernelmodul laden
modprobe ip_conntrack_ftp

---snap---

...oder hast du ein anderes gemeint? Anyway, FTP funktioniert wie erwartet.

Vielen Dank f�r deine ausf�hlichen �usserungen... :-)

[Thomas Wildgruber]

On Mon, 03 Sep 2012 20:37:40 -0400, Andreas Kohlbach wrote:

>> Ah okay. Der exim4 (smtp, 25) ist tats�chlich auf die localhost Adresse
>> gebunden. (BTW: Die doch auch zum Loopback-Interface geh�rt). Der Port 111

>> jedoch ist auf alle Adressen gebunden (0.0.0.0) und somit vermutlich auch
>> auf alle Netzwerk-Interfaces...?
>
> Den Portmap (111) habe ich laut Prozessliste per
>
> /sbin/portmap -i 127.0.0.1
>
> laufen. Aus "man portmap":
>
> -i address
> bind portmap to address. If you specify 127.0.0.1 it will
> bind to the loopback interface only.
>
> Ich versuche auch, mit "Bordmitteln" zu arbeiten, um die Erstellung von
> iptables Regeln zu vermeiden. Also mit dem Programm selbst an Interfaces
> binden.

Interessanter Aspekt, auf den ich so nie gekommen w�re. Danke hierf�r. In
diesem Zusammenhang habe ich jetzt auch erfahren, dass die f�r mich erstmal
sinnfrei Defaultinstallation von Exim4 auf Debian erstmal kein Risiko
darstellt. Den MTA will Debian vermutlich wegen dem Versenden von (Status-
oder Notification-) E-Mails an root haben aber wenn er nur an der
localhost-Adresse gebunden ist, sollte das erstmal kein Sicherheitsriskio
darstellen (solange wohl die Implementierung selbst keinen Bug hat)

> So lauscht mein Samba nur am (verschl�sselten) WLAN, w�hrend das Internet
> �ber PPPOE (eth0) rein kommt. Was ich �ber die smb.conf mal einstellte,
> ohne iptables nutzen zu m�ssen.

Okay, macht auch Sinn. Dann brauchst du wohl zumindest auch daf�r mal keine
eigene Filter-Regel, zumindest solange, wie du das interne Netzt nicht auch
noch reglementieren m�chtest.

Thx & Bye Tom
--

"Sie wissen, wir leben im Zeitalter der Abk�rzungen. Ehe ist die Kurzform
f�r lateinische "errare humanum est" ("Irren ist menschlich")." (Robert
Lembke)

[Juergen P. Meier]

Thomas Wildgruber <excp...@web.de>:
> ich habe zur Demonstration fï¿œr einen Azubi ein Iptables Skript mit einigen

> Regeln geschrieben und im Moment sind mir hier drei Resultate unklar:
>

> SPOOFING="0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 /
> 224.0.0.0/3 255.0.0.0/8"
> DNS="192.168.167.2"

Dein DNS-Server steht innen?

> # Loopback Interface freigeben
> $IPTABLES -A INPUT -i lo -j ACCEPT
> $IPTABLES -A OUTPUT -o lo -j ACCEPT
> # Spoofing verhindern
> for ip in $SPOOFING ;
> do
> $IPTABLES -A INPUT -s $ip -j LOG --log-prefix "Spoofing detected:"
> # $IPTABLES -A INPUT -s $ip -j DROP
> done

Sofern du RFC1918-Addressen verwendest, hast du dir gerade die Fuesse
weggeschossen.
Kannst du das nicht auf das Interface einschraenken, dass "aussen"
anliegt? (-i ppp* o.ae.)

> # Neue TCP Sessions nur mit SYN erlauben
> # http://www.smythies.com/~doug/network/iptables_syn/index.html
> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG /
> --log-prefix "New but SYN-Flag not set:"
> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Hae? Ich will dir ja nicht zu nahe treten, aber das ist ueberfluessig.

Entweder du verwendest das conntrack_tcp state modul, oder du filterst
auf Flags. Beides ist jedoch sinnfrei (--staet NEW limitiert bereits
auf SYN-only flag - genauer auf den 3-way handshake, den du mit
billigen Flags garnicht so abbilden kannst).

Ausserdem erlaubt das *alles* was TCP ist.

> # Erlaube Pakete von existierenden Sessions
> $IPTABLES -I INPUT 1 -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT

Das ist wiederum sinnvoll, und erlaubt auch die ueblichen UDP
"Rueckkanaele" (sic).

> # Erlaube abgehende Pings
> $IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT

Du solltest das in jede Richtung erlauben. Deine Fuesse haben schon
Loecher, ICMP Echo (und die fuer IP notwendigen anderen 4 Typen) zu
erlauben gehoert genauso dazu wie Stahlkappen beim Heben schwerer
Lasten).

> # Erlaube DNS
> $IPTABLES -A OUTPUT -p udp --dport 53 -d $DNS -m state --state NEW -j
> ACCEPT

Zu Spaet. Dein Spoofing-filter filtert dir deinen DNS-server bereits weg.

> # Erlaube NTP
> $IPTABLES -A OUTPUT -p udp --dport 123 -m state --state NEW -j ACCEPT

Kannst du das nicht auf deine NTP peers einschraenken? NTP besticht
jetzt nicht gerade durch extreme Stabilitaet der Implementierungen
bezueglich Bufferoverflows und anderer Fuzzing-Methoden. Und zu
erraten, wer deine NTP-Server sind, ist nur dann trivial, wenn du die
ueblichen (ntp-pool, PTB, Microsoft) verwendest.

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

Von aussen. Nur von Aussen (s.O.). Und auch noch auf dem standard
Port. (SSH sollte man aussenseitig nicht auf dem Standardport
betreiben - schon um sich dem DoS-Angriff gegen die Authentication Logs
zu entziehen. [damit meine ich die myriaden von Fehlversuchen die
deine Auth-logs vollmuellen])

> # Erlaube HTTP
> $IPTABLES -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
> $IPTABLES -A OUTPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT

HTTP wird im Internet auf vielen verschiedenen Ports betrieben. Wenn
du diese per Whitelist freigeben willst, wirst du nicht froh (oder
deine Anwender). Ueblich ist es, alle Ports bis auf eine Blackliste
freizugeben (z.B. 1-79, 81-442, 444-1023, 2094, 3128, 6666-6670, ...)

> # Erlaube Whois
> $IPTABLES -A OUTPUT -p tcp --dport 43 -m state --state NEW -j ACCEPT

Okay, nicht dass es nicht Webfrontends dafuer gaebe.

> # Erlaube FTP (ausgehend)
> $IPTABLES -A OUTPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT

Den FTP Steuerkanal freizugeben wird nicht reichen (solange du nicht
die grobe Sicherheitsluecke namens "conntrack_ftp" als modul nachlaedst
- was in der Praxis eine nicht besonders kluge Idee ist)

> Frage 1) Wobei ich hier die kurze Antwort vermutlich schon kenne... Wenn
> ich gegen den Rechner, der das o.g. Regelwerk geladen hat, einen Portscan

> fahre, bekomme ich erwartungsgemￜￜ nur den TCP Port 22 als geￜffnet

> angezeigt. Lasse ich den Portscan jedoch auf der lokalen Maschine laufen,

> werden mehrere geï¿œffnete Ports angezeigt:
>
> ---snip---
> $ nmap localhost

> Interesting ports on localhost (127.0.0.1):
> Not shown: 997 closed ports
> PORT STATE SERVICE
> 22/tcp open ssh
> 25/tcp open smtp
> 111/tcp open rpcbind

> ---snap---
>
> Ich vermute mal, dass liegt an der Regel, welche den Loopback Adapter
> freigibt. Den Mechanismus mit dem Loopbackadapter habe ich auch noch nicht

Korrekt.

> ganz so verstanden, dachte jedoch, dass die localhost Adresse nichts mit

Das loopback interface ist im prinzip ein Netzwerkinterface wie jedes
andere auch. Der Hauptunterschied zu einem Ethernet-Interface (oder
auch Dummy-interface) ist der, dass bei loopback jede Kommunikation
zwischen zwei (nur lokalen) Prozessen per Mem-copy direkt zwischen den
Pufferspeichern beider Prozesse ablaeuft. Das war insbsondere frueher
bei Systemen mit langsamen I/O-Subsystemen von entscheidendem
GEschwindigkeitsvorteil.

Dass die Loopback-IP Addresse ueberall die selbe ist, ist konvention,
damit man diese in Applikationen, die nur lokal aber trotzdem ueber
TCP/IP-Methoden kommunizieren sollen, Hardcoden kann.

Deer entscheidende Vorteil von TCP/IP Interprozesskommunikation (fuer
die Loopback erfunden wurde) geenueber allen anderen (lokalen)
Interprozesskommunikationsmethoden (wie z.B. IPC, Pipes, Semaphores,
Streams etc.) ist die Portabilitaet. TCP/IP ist Systemunabhaengig.

> dem Loopbackadapter zu tun hat. Ist dieses Verhalten von nmap auf dem

> lokalen Host mit dem Loopbackadapter erklï¿œrbar?

Loopback ist bei Linux z.B. so hoch optimiert, dass praktisch gar kein
Netzwerkspezifischer Code mehr abgearbeitet wird - Daten werden direkt
vom Puffer eines Prozesses in den des anderen kopiert, auch findet
keinerlei Layer-2 bis 3 Code statt (du konntest zeitweise sogar
beliebige IP-Addressen setzen, solange der Loopback-Adapter verwendet
wird wurde der Code, der sonst IP-Addressen verifiziert einfach
ausgelassen - der PErformance zu Liebe). Es findet auch nur ein
Bruchteil der Bearbeitung auf Schicht-4 statt, wenn du Loopback statt
eines "richtigen" Interfaces verwendest. (alles, was Flowcontrol und
Error-correction/detection ist wird uebersprungen weil da unnoetig und
nur eine Performancebremse).

Um zum Testen und debugging ein lokales Interface zu haben, dass diese
TCP/IP Codeteile dennoch (wnen auch nur virtuell) durchlaeuft, wurde
unter Linux das dummy-interface erfunden. Das ist ein loopback ohne
die Optimierungen.

> 2 Frage: Im Skript befindet sich eine Spoofing Log-Regel, die Drop-Regel
> dazu ist auskommentiert, weil ich auch dort ein Problem ermittelt habe, von

Ach.

> dem ich jetzt aber nicht weiￜ woher es kommt. Beim Starten des Skripts wird

> ein Log-Eintrag nach /var/log/syslog geschrieben:

Du filterst dein eigenes Netz per Anti-spoofing.

> ---snip---
> Spoofing detected:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:c0:00:08:0
> 8:00 SRC=192.168.167.1 DST=192.168.167.255 LEN=78 TOS=0x00 PREC=0x20 TTL=64
> ID=41041 PROTO=UDP SPT=60342 DPT=137 LEN=5
> 8
> ---snap---
>
> Woher kommt das, dass die Regel hier anspringt? Meine lokale IP-Adresse
> ist: 192.168.167.196/24 und sollte doch nicht von den angelegten Spoofing
> Adressen erfasst werden?

Doch. Die Anti-spoofing Regeln setzt man idR. nur auf Interfaecs, die
zu oeffentlichen oder fremden Datennetzen zeigen.

> Frage 3) Bei meinen ganzen Recherchen bzgl. Iptables bin ich nirgens auf
> eine Regel gestossen, welche die initiale DHCP-Prozedur des DHCP-Clients

DHCP ist UDP.

> erfasst. Gewundert habe ich zwar schon, dass der Rechner auch ohne Regel

> eine IP-Adresse bekommt aber in diversen Forenbeitrï¿œgen wurde gemutmaï¿œt,

> dass der ganze DHCP Prozess noch vor dem aktivieren der Firewall

Kaffeesatzleser... Nein. Das ist falsch. DHCP muss natuelrich auch
durch die Netfilter-Regeln hindurch.

DHCP verwendet UDP. Und UDP ausgehend ist bei dir erlaubt (DHCP
Request), und du erlaubst die "Antworten" auf UDP, also die DHCP
offers. DA du antispoofing erst danach machst, sabotiert dir das
nicht auch diese Kommunikation.

> Muss man DHCP in seinem Regelsatz doch irgendwie berï¿œcksichtigen?

Ja, natuerlich. Aber das wird bei dir schon gemacht, auch wenn du
nicht weist wo.

> Ansonsten bitte ich noch um Hinweise, wenn im Skript Fehler vorhanden sind,

> weil ich die natï¿œrlich ungern weitergegeben mï¿œchte ;-)

Das ganze Script sieht danach aus, als ob du aus verschiedenen Quellen
jewiels Schnippsel von Beispielen herausgezogen und zusammengeklebt
hast.

Das funktioniert nur zufaellig (meistens nicht), birgt mangels des
gesamtheitlichen VErstaendnisses aber immer die Gefahr, dass es nicht
das umsetzt, was du eigentlich erreichen willst.

Sinnvoller ist es, sich erst mal aufzumalen, was fuer
Kommunikationsbeziehungen ueberhaupt bestehen (inkl. so elemntare oder
auch fluechtige Dinge wie DHCP, DNS oder auch ident). Sowas nennt man
dann auch "Kommunikationsmatrix", aus der ein Regelwerk fuer eine
Firewall wie iptables/netfilter fast von alleine rausfaellt.

Fuer die Grundfunktion von TCP/IP sind auch ein paar basis-regeln die
unabhaengig davon universell gelten notwendig, einen Teil davon hast
du bereits verwendet - wenn auch ungeschickt kombiniert.

Auch solltest du dir genau ueberlegen, ob du ausgehenden Verkehr
einschraenken moechtest, und ob du dafuer einen White-list oder einen
Blacklist-Approach waehlst.

Wenn du einen DHCP-Server auf deinem netfilter-rechner betreiben
willst, musst du die BOOTP/DHCP-DISCOVER Pakete explizit erlauben.

Tip:

loopback-Regel zu oberst.
Antispoofing (nur) auf Interfaces zu fremden Netzen beschraenkt ganz
oben direkt danach.
Dann die ESTABLISHED,RELATED-State-Accept regeln um bestehende
Verbindungen zu erlauben.
Dann fuer die Funktion von IP notwendige ICMP typen erlauben

Bei whitelisting dann die whiteliste, danach REJECTs. Wer DROP
verwendet, macht sich unnoetig auffaellig.

Bei blacklisting die Blackliste, danach ACCEPT.

Zum Troubleshooten die counter (iptables-save -c) beachten.

HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Thomas Wildgruber]

Serrvus,

On Tue, 04 Sep 2012 04:30:50 +0000 (UTC), Juergen P. Meier wrote:

>> [...]

>> DNS="192.168.167.2"
>
> Dein DNS-Server steht innen?

Jupp, zumindest als Weiterleitung. In diesem Fall sogar auf meiner
Maschine. Das Linux l�uft in einer VM und die IP des VM-Hosts wird per DHCP
als GW- und DNS-Adresse dem Gast �bergeben.

Das Setup hier dient lediglich als Testinstallation. Ich arbeite mit einem
Azubi daran aber nat�rlich sollen die Regeln stimmen, der Sinn ist manchmal
zweifelhaft, sollte hier und dort lediglich zur Demonstration dienen.

>> # Spoofing verhindern
>> for ip in $SPOOFING ;
>> do
>> $IPTABLES -A INPUT -s $ip -j LOG --log-prefix "Spoofing detected:"
>> # $IPTABLES -A INPUT -s $ip -j DROP
>> done
>
> Sofern du RFC1918-Addressen verwendest, hast du dir gerade die Fuesse
> weggeschossen.

Ja verwende ich aber ich verstehe nicht warum. Ist im adressbereich
192.168.0.0/16 der Bereich 192.168.0.0/24 includiert? Denn im
192.168.0.0/24 befindet sich die IP des Systems.

> Kannst du das nicht auf das Interface einschraenken, dass "aussen"
> anliegt? (-i ppp* o.ae.)

Im Moment nicht, da ich nur ein Interface (eth0) habe. Da ist sie schon
mal, die Geschichte mit dem Demosystem in einer VM. Ich muss zugeben, dass
ich das aber so nicht gewusst habe (sonst h�tte ich es ja hier nicht als
Frage gestellt ;) und bin jetzt mal so verblieben, dass die ganze Spoofing
Geschichte erst dann Sinn macht, wenn ich mehrere Interfaces habe und wei�
welche Art Pakete an welchem Interface zu erwarten sind.

>> # Neue TCP Sessions nur mit SYN erlauben
>> # http://www.smythies.com/~doug/network/iptables_syn/index.html
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG /
>> --log-prefix "New but SYN-Flag not set:"
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
>
> Hae? Ich will dir ja nicht zu nahe treten, aber das ist ueberfluessig.
>
> Entweder du verwendest das conntrack_tcp state modul, oder du filterst
> auf Flags. Beides ist jedoch sinnfrei (--staet NEW limitiert bereits
> auf SYN-only flag - genauer auf den 3-way handshake, den du mit
> billigen Flags garnicht so abbilden kannst).

Ich habe mich an dieses Konzept noch aus den Tagen erinnert, wo man mit
Ipchains gearbeitet hat (Das war mein letzter unixoider Paketfilter den ich
gebaut habe <urgs>) auch wenn die Umsetzung etwas anders gewesen ist. Hier
wurde AFAIR zu jeder Verbindung explizit der Hin- und R�ckkanal und der
Hin-Kanal mit dem -y Flag f�r SYN-only konfiguriert.

> Ausserdem erlaubt das *alles* was TCP ist.

Warum? Die Pakete werden ja geLOGgt und geDROPt.

>> # Erlaube abgehende Pings
>> $IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
>
> Du solltest das in jede Richtung erlauben. Deine Fuesse haben schon
> Loecher, ICMP Echo (und die fuer IP notwendigen anderen 4 Typen) zu
> erlauben gehoert genauso dazu wie Stahlkappen beim Heben schwerer
> Lasten).

Jupp, an anderer Stelle im Thread habe ich schon mal darauf hingewiesen,
dass ich mir hier der Konsequenzen schon bewusst war und auch noch so
einige Probleme in Erinnerung habe, die Serveradmins mit g�nzlich
abgeschalteten ICMP verursacht haben (oder es immer noch tun)

Ich wollte hier im Beispiel nur den vielen Beispielkonfiguration aus dem
Internet, welche Ping mit ICMP verwechseln, den Wind aus den Segeln nehmen.
Hier an dieser Stelle wollte ich zum Ausdruck bringen, dass es
verschiednene ICMP Typen gibt und manche davon sinnvoll andere sogar
wichtig sein k�nnen. Das h�tte ich vielleicht erw�hnen sollen.

>> # Erlaube DNS
>> $IPTABLES -A OUTPUT -p udp --dport 53 -d $DNS -m state --state NEW -j
>> ACCEPT
>
> Zu Spaet. Dein Spoofing-filter filtert dir deinen DNS-server bereits weg.

Hm, schon wieder. Mit der Spoofing Regel ging wirklich gar nichts mehr,
deshalb habe ich die DROP Regel dann in eine LOG Regel umgewandelt, um zu
schauen was davon erfasst wird (sp�ter habe ich dann beides kombiniert).
Aber die og Frage mit den Subnetzmasken /16 /24 bleibt noch offen. Kann
aber nur daran liegen, denn ohne dem Netz 192.168.0.0/16 hat die
Spoofingregel keinen Totalzusammenbruch der Verbindung verursacht.

>> # Erlaube NTP
>> $IPTABLES -A OUTPUT -p udp --dport 123 -m state --state NEW -j ACCEPT
>
> Kannst du das nicht auf deine NTP peers einschraenken? NTP besticht
> jetzt nicht gerade durch extreme Stabilitaet der Implementierungen
> bezueglich Bufferoverflows und anderer Fuzzing-Methoden. Und zu
> erraten, wer deine NTP-Server sind, ist nur dann trivial, wenn du die
> ueblichen (ntp-pool, PTB, Microsoft) verwendest.

Gute Idee, nat�rlich k�nnte ich das. Auch hier haben wir interne.

>> # Allow incoming SSH
>> $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
>
> Von aussen. Nur von Aussen (s.O.). Und auch noch auf dem standard
> Port. (SSH sollte man aussenseitig nicht auf dem Standardport
> betreiben - schon um sich dem DoS-Angriff gegen die Authentication Logs
> zu entziehen. [damit meine ich die myriaden von Fehlversuchen die
> deine Auth-logs vollmuellen])

Ja die Regel ist bislang nur von aussen, anders rum sollte der Azubi
mittlerweile in der Lage sein, den fehler zu erkennen und wissen, wo er was
einstellen muss, damit es auch vom Testsystem aus funktioniert.

Das mit dem Standardport ist ein Gedanke den man aufgreifen k�nnte, in der
Tat. Wobei ich gerade an dieser Stelle (zu gegebener Zeit) fail2ban ins
Spiel bringen wollte, was ebenfalls auf das Auth-Logfile zur�ckgreift und
Iptables verwendet. Aber das eine schlie�t das andere ja nicht aus, wir
werden an dieser Stelle dann (Brute-Force und gegenma�nahmen) eh eine Weile
verbringen. Da gibts dann auch noch Blockhosts, was aber erstmal nichts mit
Iptables zu tun hat.

>> # Erlaube HTTP
>> $IPTABLES -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
>> $IPTABLES -A OUTPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
>
> HTTP wird im Internet auf vielen verschiedenen Ports betrieben. Wenn
> du diese per Whitelist freigeben willst, wirst du nicht froh (oder
> deine Anwender). Ueblich ist es, alle Ports bis auf eine Blackliste
> freizugeben (z.B. 1-79, 81-442, 444-1023, 2094, 3128, 6666-6670, ...)

Jupp, da bin auch hier und da mal �ber Multiport-Regeln gesto�en. Diese
Regel hier ist sicherlich f�r den Praxisbetrieb deutlich zu erweitern.

>> # Erlaube Whois
>> $IPTABLES -A OUTPUT -p tcp --dport 43 -m state --state NEW -j ACCEPT
>
> Okay, nicht dass es nicht Webfrontends dafuer gaebe.

Testsystem hat kein X ;-)

>> # Erlaube FTP (ausgehend)
>> $IPTABLES -A OUTPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
>
> Den FTP Steuerkanal freizugeben wird nicht reichen (solange du nicht
> die grobe Sicherheitsluecke namens "conntrack_ftp" als modul nachlaedst
> - was in der Praxis eine nicht besonders kluge Idee ist)

Aha, das ist mir neu, wobei mir auch das Kdernelmodul erst seit gestern
bekannt ist. Ich habs *mit* dem Kernel-Modul eingerichtet (steht irgendwo
weit oben im Skript). Gibt es zu den Problemen mit dem Modul was zum
nachlesen?

Ohne den Modul m�sste ich den Port 20 dann auch noch konfigurieren und mich
vermutlich auf passives FTP beschr�nken, wobei aktives FTP in den meisten
F�llen wegen fehlendem Portforwarding auf den meisten SOHO Routern eh nicht
mehr funktioniert wird. Aber villeicht haben die sogar auch noch ein
Stafeul-Inspection Modul, was das dann wieder m�glich machen k�nnte.

>> [...]

>> ganz so verstanden, dachte jedoch, dass die localhost Adresse nichts mit
>
> Das loopback interface ist im prinzip ein Netzwerkinterface wie jedes
> andere auch. Der Hauptunterschied zu einem Ethernet-Interface (oder
> auch Dummy-interface) ist der, dass bei loopback jede Kommunikation
> zwischen zwei (nur lokalen) Prozessen per Mem-copy direkt zwischen den
> Pufferspeichern beider Prozesse ablaeuft. Das war insbsondere frueher
> bei Systemen mit langsamen I/O-Subsystemen von entscheidendem
> GEschwindigkeitsvorteil.
>
> Dass die Loopback-IP Addresse ueberall die selbe ist, ist konvention,
> damit man diese in Applikationen, die nur lokal aber trotzdem ueber
> TCP/IP-Methoden kommunizieren sollen, Hardcoden kann.
>
> Deer entscheidende Vorteil von TCP/IP Interprozesskommunikation (fuer
> die Loopback erfunden wurde) geenueber allen anderen (lokalen)
> Interprozesskommunikationsmethoden (wie z.B. IPC, Pipes, Semaphores,
> Streams etc.) ist die Portabilitaet. TCP/IP ist Systemunabhaengig.
>
>> dem Loopbackadapter zu tun hat. Ist dieses Verhalten von nmap auf dem

>> lokalen Host mit dem Loopbackadapter erkl�rbar?

>
> Loopback ist bei Linux z.B. so hoch optimiert, dass praktisch gar kein
> Netzwerkspezifischer Code mehr abgearbeitet wird - Daten werden direkt
> vom Puffer eines Prozesses in den des anderen kopiert, auch findet
> keinerlei Layer-2 bis 3 Code statt (du konntest zeitweise sogar
> beliebige IP-Addressen setzen, solange der Loopback-Adapter verwendet
> wird wurde der Code, der sonst IP-Addressen verifiziert einfach
> ausgelassen - der PErformance zu Liebe). Es findet auch nur ein
> Bruchteil der Bearbeitung auf Schicht-4 statt, wenn du Loopback statt
> eines "richtigen" Interfaces verwendest. (alles, was Flowcontrol und
> Error-correction/detection ist wird uebersprungen weil da unnoetig und
> nur eine Performancebremse).
>
> Um zum Testen und debugging ein lokales Interface zu haben, dass diese
> TCP/IP Codeteile dennoch (wnen auch nur virtuell) durchlaeuft, wurde
> unter Linux das dummy-interface erfunden. Das ist ein loopback ohne
> die Optimierungen.

Okay, auch wenn ich jetzt nach ein-, zwei-maligem lesen nicht alles
verstanden habe, wei� ich worauf du hinaus m�chtest. Diese Art Erkl�rung
habe ich so jetzt nicht gefunden, bei meiner Recherche. Danke hierf�r, ich
nehme das als Grundlage weiter nachzuforschen, scheint nicht uninteressant
und auch nicht ganz unwichtig zu sein...

>> 2 Frage: Im Skript befindet sich eine Spoofing Log-Regel, die Drop-Regel
>> dazu ist auskommentiert, weil ich auch dort ein Problem ermittelt habe, von
>
> Ach.

Tja... ;-)

>> dem ich jetzt aber nicht wei� woher es kommt. Beim Starten des Skripts wird

>> ein Log-Eintrag nach /var/log/syslog geschrieben:
>
> Du filterst dein eigenes Netz per Anti-spoofing.

Siehe oben...

BTW: Ich h�tte vielleicht das Posting erst ganz lesen sollen bevor ich
schon mit dem kommentieren angefangen habe, dann h�tte ich an dieser Stelle
mit meinem Problem mit Klasse B und Klasse C Netzen anbringen k�nnen ;-)

>> [...]

>> Frage 3) Bei meinen ganzen Recherchen bzgl. Iptables bin ich nirgens auf
>> eine Regel gestossen, welche die initiale DHCP-Prozedur des DHCP-Clients
>
> DHCP ist UDP.
>
>> erfasst. Gewundert habe ich zwar schon, dass der Rechner auch ohne Regel

>> eine IP-Adresse bekommt aber in diversen Forenbeitr�gen wurde gemutma�t,

>> dass der ganze DHCP Prozess noch vor dem aktivieren der Firewall
>
> Kaffeesatzleser... Nein. Das ist falsch. DHCP muss natuelrich auch
> durch die Netfilter-Regeln hindurch.
>
> DHCP verwendet UDP. Und UDP ausgehend ist bei dir erlaubt (DHCP
> Request), und du erlaubst die "Antworten" auf UDP, also die DHCP
> offers. DA du antispoofing erst danach machst, sabotiert dir das
> nicht auch diese Kommunikation.
>

>> Muss man DHCP in seinem Regelsatz doch irgendwie ber�cksichtigen?

>
> Ja, natuerlich. Aber das wird bei dir schon gemacht, auch wenn du
> nicht weist wo.

Nein wei� ich wirklich, wo?

Wobei ich aber gerade alle meinen Regeln geflusht habe, also gar keine
Regel mehr in den Tabellen habe, jedoch immer noch die Default DROP Policy
aktiv ist und ich nach einem Neustart immer noch eine DHCP Adresse bekomme,
kann es doch eigentlich nicht an den Regeln gelegen haben, dass zumindest
die initialie DHCP Kommunkikation immer noch funktioniert. Von den sp�teren
Lease-Erneuerungen mal abgsehen, die jetzt vermutlich gegen die Wand
fahren.

H�tte ich in meinem Regelwerk jetzt zuf�llig DHCP erlaubt ohne es zu
wissen, dann sollte es ohne Regeln doch jetzt nicht mehr gehen, isn,t it?

>> Ansonsten bitte ich noch um Hinweise, wenn im Skript Fehler vorhanden sind,

>> weil ich die nat�rlich ungern weitergegeben m�chte ;-)

>
> Das ganze Script sieht danach aus, als ob du aus verschiedenen Quellen
> jewiels Schnippsel von Beispielen herausgezogen und zusammengeklebt
> hast.

Jetzt sei nicht so streng, ich fand das Skript gut, mift ;-)

> Das funktioniert nur zufaellig (meistens nicht), birgt mangels des
> gesamtheitlichen VErstaendnisses aber immer die Gefahr, dass es nicht
> das umsetzt, was du eigentlich erreichen willst.

Die Gefahr besteht nat�rlich, wobei ich aber schon dachte zu wissen, was
die regeln da tun. Gut die DHCP Geschichte ist nat�rlich noch ein R�tsel,
l�ftest du es...? ;-)

> Sinnvoller ist es, sich erst mal aufzumalen, was fuer
> Kommunikationsbeziehungen ueberhaupt bestehen (inkl. so elemntare oder
> auch fluechtige Dinge wie DHCP, DNS oder auch ident). Sowas nennt man
> dann auch "Kommunikationsmatrix", aus der ein Regelwerk fuer eine
> Firewall wie iptables/netfilter fast von alleine rausfaellt.

Okay...

> [...]

> Auch solltest du dir genau ueberlegen, ob du ausgehenden Verkehr
> einschraenken moechtest, und ob du dafuer einen White-list oder einen
> Blacklist-Approach waehlst.

Ausgehenden Verkehr zu filtern halte nach wie vor f�r sinnvoll, wenn auch
nicht unbedingt auf einem Client System, wie hier demonstriert aber wie
gesagt, ist nur eine Demonstration...

Anyway, hier im Haus wird die Philosophie vertreten, dass wenn wir einen
Mailserver haben, nur dieser SMTP ins Internet darf, die Clients d�rfen das
nicht. Selbes gilt zB f�r NTP und DNS. Wobei diese Regeln dann am
Perimetergateway greifen.

Ist die Default Policy "Verbiete erst mal alles" dann muss man eben
hergehen und St�ck f�r St�ck die notwendigen Dienste wieder �ffnen. Ich
halte das zumindest am Perimeter weiterhin f�r eine sinnvolle Einstellung.

> Wenn du einen DHCP-Server auf deinem netfilter-rechner betreiben
> willst, musst du die BOOTP/DHCP-DISCOVER Pakete explizit erlauben.

Im LAN ist keiner vorhanden (Nur die lokalen VMs haben einen) aber wir
werden das sicherlich auch noch behandeln und da kommt das dann ins Spiel.

> loopback-Regel zu oberst.

Ist der Fall, naja nicht ganz die ESTABLISHED,RELATED Geschichte mogelt
sich noch davor...

> Antispoofing (nur) auf Interfaces zu fremden Netzen beschraenkt ganz
> oben direkt danach.

Okay, die lasse ich mangels zweiten Interface jetzt mal ganz weg.

> Dann die ESTABLISHED,RELATED-State-Accept regeln um bestehende
> Verbindungen zu erlauben.
> Dann fuer die Funktion von IP notwendige ICMP typen erlauben

Dann w�re hier ein '-I <CHAIN> 2' besser.

> Bei whitelisting dann die whiteliste, danach REJECTs. Wer DROP
> verwendet, macht sich unnoetig auffaellig.
>
> Bei blacklisting die Blackliste, danach ACCEPT.

Die letzten zwei habe ich jetzt nicht ganz verstanden. Die Whitelist soll
GeDROPt (bzw. REJECTed) werden bzw eine Blacklist ACCEPTed? Warum nicht
anders herum?

> Zum Troubleshooten die counter (iptables-save -c) beachten.
>
> HTH,
> Juergen

Ja sehr und Danke f�r deine Geduld. Ich hoffe du findest noch die Geduld,
die noch offenen Fragen zu beantworten.

Thx & Bye Tom
--

[Juergen P. Meier]

Thomas Wildgruber <excp...@web.de>:

> On Tue, 04 Sep 2012 04:30:50 +0000 (UTC), Juergen P. Meier wrote:
>>> DNS="192.168.167.2"
>>
>> Dein DNS-Server steht innen?
>

> Das Setup hier dient lediglich als Testinstallation. Ich arbeite mit einem

> Azubi daran aber natï¿œrlich sollen die Regeln stimmen, der Sinn ist manchmal

> zweifelhaft, sollte hier und dort lediglich zur Demonstration dienen.

Ein Problem bei sowas ist, dass der vereinfachte Testaufbau die
Struktur des Regelwerks beeinflusst.

>> Sofern du RFC1918-Addressen verwendest, hast du dir gerade die Fuesse
>> weggeschossen.
>
> Ja verwende ich aber ich verstehe nicht warum. Ist im adressbereich
> 192.168.0.0/16 der Bereich 192.168.0.0/24 includiert? Denn im

Ja. Die Zahl hinter dem / gibt die Prefix-Laenge an, also die Anzahl
der Netz-Bits in der Netzmaske. Je niedriger, desto umfangreicher das
Netz. Jedes 192.168.*.0/24 (fuer *=0 bis 255) ist ein Subnetz von
192.168.0.0/16.

> 192.168.0.0/24 befindet sich die IP des Systems.

Wenn dein DNS-Server die obige IP hat, verwendest du 192.168.167.0/24.
Oder verwendest du mehrere Netze aus dem 192.168.0.0/16 Bereich?

Anyway, beide /24 waeren bestandteil des 192.168.0.0/16 und werden von
der Antispoofing-Regel erschlagen.

>> Kannst du das nicht auf das Interface einschraenken, dass "aussen"
>> anliegt? (-i ppp* o.ae.)
>
> Im Moment nicht, da ich nur ein Interface (eth0) habe. Da ist sie schon

Dann kannst du auch kein Antispoofing betreiben. Antispoofing der
hier verwendeten Geschmacksrichtung "Path Verification", also alle
Quelladdressen die unmoeglich hinter einem bestimmten (externen)
Interface liegen koennen, auf diesem Interface wegzufiltern, kannst du
bei einem "Router am Stiel" nicht verwenden, weil dein einziges
Interface nunmal sowohl deine privaten als auch alle anderen Netze
voellig legitm erreichbar macht.

> mal, die Geschichte mit dem Demosystem in einer VM. Ich muss zugeben, dass

> ich das aber so nicht gewusst habe (sonst hï¿œtte ich es ja hier nicht als

> Frage gestellt ;) und bin jetzt mal so verblieben, dass die ganze Spoofing

> Geschichte erst dann Sinn macht, wenn ich mehrere Interfaces habe und weiￜ

> welche Art Pakete an welchem Interface zu erwarten sind.

Korrekt. Du kannst immerhin die RFC1918 Addressbereiche wegfiltern,
die du intern nirgends verwendest.

> Ich habe mich an dieses Konzept noch aus den Tagen erinnert, wo man mit
> Ipchains gearbeitet hat (Das war mein letzter unixoider Paketfilter den ich
> gebaut habe <urgs>) auch wenn die Umsetzung etwas anders gewesen ist. Hier

> wurde AFAIR zu jeder Verbindung explizit der Hin- und Rï¿œckkanal und der
> Hin-Kanal mit dem -y Flag fï¿œr SYN-only konfiguriert.

Ja, damals war das kein "stateful" Filter. Bei netfilter mit Conntrack
(modul "state") sieht das anders aus.

>> Ausserdem erlaubt das *alles* was TCP ist.
>
> Warum? Die Pakete werden ja geLOGgt und geDROPt.

Ah stimmt, das Target hatte ich in der Eile genau verwechselt.

> Hm, schon wieder. Mit der Spoofing Regel ging wirklich gar nichts mehr,
> deshalb habe ich die DROP Regel dann in eine LOG Regel umgewandelt, um zu

> schauen was davon erfasst wird (spï¿œter habe ich dann beides kombiniert).

> Aber die og Frage mit den Subnetzmasken /16 /24 bleibt noch offen. Kann
> aber nur daran liegen, denn ohne dem Netz 192.168.0.0/16 hat die
> Spoofingregel keinen Totalzusammenbruch der Verbindung verursacht.

Das problem an dieser Stelle ist: Du koenntest hoechstens die
Spoofing-regel so umbauen, dass alle Subnetze von 192.168.0.0/16
ausser 192.168.0.0/24 (bzw. 192.168.167.0/24 wenn die DNS-IP stimmt)
auflistet, das waeren dann aber mehr als ein halbes dutzend gestueckelter
Netzangaben (z.B.: 192.168.1.0/24, 192.168.2.0/23, 192.168.4/22,
192.168.8.0/21,, 192.168.16.0,20, 192.168.32.9/19, 192.168.64.0/18,
192.168.128.0/17 - das waere 192.168.0.0/16 ohne 192.168.0.0/24)

> Das mit dem Standardport ist ein Gedanke den man aufgreifen kï¿œnnte, in der

> Tat. Wobei ich gerade an dieser Stelle (zu gegebener Zeit) fail2ban ins

> Spiel bringen wollte, was ebenfalls auf das Auth-Logfile zurï¿œckgreift und

fail2ban ist potentiell gefaehrlich weil es einen DoS gegen den
Service ermnoeglicht, der dich selbst aussperren kann. Sowas immer mit
Bedacht einsetzen.

>> HTTP wird im Internet auf vielen verschiedenen Ports betrieben. Wenn
>> du diese per Whitelist freigeben willst, wirst du nicht froh (oder
>> deine Anwender). Ueblich ist es, alle Ports bis auf eine Blackliste
>> freizugeben (z.B. 1-79, 81-442, 444-1023, 2094, 3128, 6666-6670, ...)
>

> Jupp, da bin auch hier und da mal ï¿œber Multiport-Regeln gestoï¿œen. Diese
> Regel hier ist sicherlich fï¿œr den Praxisbetrieb deutlich zu erweitern.

>
>>> # Erlaube Whois
>>> $IPTABLES -A OUTPUT -p tcp --dport 43 -m state --state NEW -j ACCEPT
>>
>> Okay, nicht dass es nicht Webfrontends dafuer gaebe.
>
> Testsystem hat kein X ;-)

X ist keine Notwendigkeit fuer Webzugriff, lync, linx oder w3m sind
Terminalbasierte Text-browser ;)

>> Den FTP Steuerkanal freizugeben wird nicht reichen (solange du nicht
>> die grobe Sicherheitsluecke namens "conntrack_ftp" als modul nachlaedst
>> - was in der Praxis eine nicht besonders kluge Idee ist)
>
> Aha, das ist mir neu, wobei mir auch das Kdernelmodul erst seit gestern
> bekannt ist. Ich habs *mit* dem Kernel-Modul eingerichtet (steht irgendwo
> weit oben im Skript). Gibt es zu den Problemen mit dem Modul was zum
> nachlesen?

Das FTP Conntrack modul "liest" den FTP-Kanal mit und alles, was nach
einem PORT oder PASV oder aehnlichem Kommando aussieht wird als
Portfreischaltungsauffforderung interpretiert und fuehrt zu einem
entsprechenden dynamischen Loch in den Filterregeln.

In den 1990er Jahren - als die ersten STateful-Firewalls auftauchten
mit FTP-Helpern - war es ein beliebtes Spiel im / Verzeichnis eines
FTP-Servers bei Connect eine Datei die z.B. die Zeichenkette
"PORT 192,168,1,1,0,80" an passender Stelle im langen Namen des
einzigen Unterverzeichnisses (bzw. verschiedene Kombinationen
haeufig verwendeter IP Addressen in Heim-Netzen) anzubieten, die dann
vom Client wegen der Laenge des Namens in zwei TCP-Pakete zerlegt
werden mussten und im zweiten Paket dann als PORT-Kommando
fehlinterpretiert wurde. Der Angreifer konnte sich dann z.B. auf das
*interne* webinterface eines NAT-Routers verbinden und so diesen
Fernsteuern (o.ae.).

> Ohne den Modul mï¿œsste ich den Port 20 dann auch noch konfigurieren und mich

Das ist schon lange Geschichte. Kaum eine moderne FTP-Implementierung
verwendet noch Port 20 mit aktivem FTP.

FTP ist firewalltechnisch eine Katastrophe, denn man braucht einen
Robusten Protokollparser mit groesseren Puffern (der solche Angriffe
erkennt und zuverlaessig von echten PORT-Kommandos unterscheiden
kann) um Passives wie Aktives* FTP mit zufaelligen high-Ports, wie es
seit vielen Jahren ueblich ist, zu ermoeglichen.

* Aktives FTP wenn der Paketfilter auf Client-Seite steht, PAssives
dann entsprechend wenn der Paketfilter auf SErver-Seite steht.

> vermutlich auf passives FTP beschrï¿œnken, wobei aktives FTP in den meisten
> Fï¿œllen wegen fehlendem Portforwarding auf den meisten SOHO Routern eh nicht

> mehr funktioniert wird. Aber villeicht haben die sogar auch noch ein

Genau. Nur den Port kannst du in der Praxis nicht einschraenken, weil
viele FTP-SErver nicht die noetigen Recht ehaben, einen Datenkanal auf
Port 20 aufzumachen, und daher High-ports verwenden. Dummerweise idR.
aus dem gesammten Bereich zwischen 1024 und 64k.

Damit wird auch Passives FTP ohne FTP-Protokollerkennung zu einer
.... -d any --ports 1024-65536 -j ACCEPT.

> Stafeul-Inspection Modul, was das dann wieder mï¿œglich machen kï¿œnnte.

Ja, allerdings lassen sich diese immernoch austricksen, weil FTP
konzepttionell ein verwundbares Protokoll ist (keine von einem
MitM-Paketleser erkennbare Differenzierung zwischen Kommandos und
Benuterdaten).

>> Ja, natuerlich. Aber das wird bei dir schon gemacht, auch wenn du
>> nicht weist wo.
>

> Nein weiￜ ich wirklich, wo?

Das wollte ich weiter unten ausfuehren: Deine state-regel erlaubt das.
Weil ausgehend erlaubtst du dein DHCP DISCOVER, und das DHCP REPLY Paket
vom DHCP server faellt in state=ESTABLISHED.

> Jetzt sei nicht so streng, ich fand das Skript gut, mift ;-)

Heh, es dauert ein wenig bis man das alles raushat.

> Ist der Fall, naja nicht ganz die ESTABLISHED,RELATED Geschichte mogelt
> sich noch davor...

Schadet zumindest nicht.

>> Antispoofing (nur) auf Interfaces zu fremden Netzen beschraenkt ganz
>> oben direkt danach.
>
> Okay, die lasse ich mangels zweiten Interface jetzt mal ganz weg.

Du koenntest immerhin die Netze wegfiltern, die nirgends in deinem LAN
irgendwo verwendet werden, und das 192er halt aus der Liste rausnehmen.

>> Bei whitelisting dann die whiteliste, danach REJECTs. Wer DROP
>> verwendet, macht sich unnoetig auffaellig.
>>
>> Bei blacklisting die Blackliste, danach ACCEPT.
>
> Die letzten zwei habe ich jetzt nicht ganz verstanden. Die Whitelist soll
> GeDROPt (bzw. REJECTed) werden bzw eine Blacklist ACCEPTed? Warum nicht
> anders herum?

Ich meinte: Whiteliste (impliziert ACCEPT) oben, am Ende derselben
eine generische -s any -d any -j REJECT Regel. Ich hatte mich wohl ein
wenig zu kurz gefasst.
(bzw. Blacklist impliziert -J REJECT in den einzelnen Listen-Zeilen,
gefolgt von einer any-any -j ACCEPT REgel).

Ich wuerde auch der Uebersicht immer (nicht nur bei Netfilter) dazu
raten, am Ende der Chain eine Explizite -j REJECT oder -j ACCEPT (je
nach Gusto) Regel zu platzieren, und nicht auf die Default-Targets
zu gehen. Das erleichtert die UEbersichtlichkeit und man sieht auf den
Ersten Blick, was sache ist und muss nicht erst nachschauen, was ganz
oben zur Chain steht. Das erleichtert auch die Lesbarkeit fuer Dritte.

(Gleiches gilt fuer alle Paketfilter mit Default-Targets, seien es
Cisco ACLs, Check Pointe Firewalls, Windows Host-Firewalls oder BSD
Paketfilter).

[Thomas Wildgruber]

Servus,

On Wed, 05 Sep 2012 00:28:22 +0200, Oliver Sch@d wrote:

> Thomas Wildgruber wrote:

>>>> [...]

>>> sysctl -w net.ipv4.conf.eth1.rp_filter=1
>>>
>>> bzw. in der /etc/sysctl.conf fest eintragen.
>>
>> Habe ich gemacht. Aber ist diese Einstellung auch ohne netfilter
>> wirksam gegen Spoofing?
>

> Ja.
> http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

Interessanter Link, ich hab mich schwer getan etwas Genaueres dar�ber zu
finden. Danke.

>>>> [...]
> So, nach diesem Exkurs kann ich noch sagen, dass 192.168.0.0/16
> nat�rlich alle IP-Adressen umfasst, die 192.168.167.0/24 umfasst. Wenn
> du also den gr��eren Bereich sperrst, ist nat�rlich der kleinere Bereich
> inbegriffen.

Das ist mir jetzt fast ein wenig peinlich, dass h�tte ich eigentlich wissen
*m�ssen*. Aber okay, ich schiebs mal auf das Alter... ;-)

>> Ja die Regeln habe ich mittlerweile eingetragen und die
>> Fehlermeldungen im Syslog sind verschwunden. Vielleicht kannst du noch
>> ein paar Worte verlieren, warum der Client aber noch eine IP-Adresse
>> von einem DHC Server bekommt, auch wenn keine Regel daf�r definiert
>> wurde?
>

> Im Grundsatz kann ich das nicht best�tigen, gucke ich mir demn�chst
> nochmal an deinen Fall.

>
>> Sicherlich muss es so sein, dass der ganze DHCP Dialog noch vor
>> dem Inkrafttreten der Iptables regeln stattfindet aber wei� man das
>> genauer?
>

> �h, eigentlich ist DHCP einfach UDP und UDP wird ganz normal gefiltert
> mit Iptables.

Wir sind gestern sogar hergegangen und haben alle Regeln geflusht und nur
die Default DROP Policy in der INPUT, FORWARD und OUTPUT Chain stehen
lassen, den Rechner gebootet und er bekam ohne Probleme eine IP-Adresse.
Wir sind sogar hergegangen und haben vorher noch das Lease mit dhclient
versucht zu erneuern, (was ohne Regeln dann nat�rlich nicht gegangen ist)
um auch sicher zu sein, dass der Client kein g�ltiges Lease mehr hat.

Aber ich habe einen anderen Verdacht, warum das beim Booten auch ohne Regel
klappen k�nnte. An meiner Maschine hier initilaisiere ich den Netfilter
�ber ein Init-Skript und dieses hat folgenden LSB-Header:

### BEGIN INIT INFO
# Provides: firewall.sh
# Required-Start: $local_fs $network
# Required-Stop: $local_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Descrition Firewall start script
# Description: Iptables config script
### END INIT INFO

Das boot_facility $network in Required-Start k�nnte das Aufrufen des
Skripts uU so lange hinausz�gern, dass der initiale DHCP Dialog bereits
abgeschlossen ist.

Auf einem anderen Rechner haben wir das Skript �ber die if-up.d Startskript
Methode in /etc/network ausf�hren lassen, was sicherlich auch so lange
warten wird bis das Netzwerksubsystem initialisiert ist und damit k�nnte
der DHCP Dialog auch dort schon abgeschlossen sein.

Einen Haken hat die Sache allerdings und das w�re die Default DROP Policy.
Das Ganze spielt sich ja im Kernel ab und somit ... stop, ich habs gerade
getestet -> Auch die Default DROP Policy ist nicht persistent und �berlebt
einen Reboot ohne erneute Initialisierung nicht.

Anyway, ich bin jetzt mal hergegangen und habe den Neustart des DHCP
Clients mit Wireshark mitgesnifft und festgestellt, dass der initiale DHCP
Request weit vor dem Booten des OS kommt. Das Paket war schon da, noch
bevor man den Kernel zum Booten ausw�hlen konnte. Das DHCP Offer und das
finale DHCP ACK jedoch kam erst zum Zeitpunkt wo das Betriebssystem schon
gestartet war, kurz vor dem Login. Das Problem hier ist aber, dass die
Linux VM auf einer SSD l�uft und fast mit Warp-Geschwindigkeit bootet...

Okay, da der Netfilter ja keine Regel hat, welche Pakete von ESTABLISHED
Verbindungen zulassen (im Moment hat der Filter gar keine Regel ausser die
Default DROP Policy) stelle ich mir hier die Frage, ob es auch ein
Stateful-Inspection Kernel Modul gibt, was die Antwort des DHCP Servers
zul�sst (ohne als Regel konfiguriert zu sein, wohlbemerkt)?

Linux-Netfilter kann doch stateful-inspection, braucht es da zwingend auch
eine Regel dazu?

>> [...]

>>> Zudem vermisse ich die IPv6-Regeln, wo sind die eigentlich?
>>
>> Gute Frage, n�chste Frage ;-) Ja es wird Zeit sich damit zu
>> besch�ftigen. zZ lasse ich mir das von den Azubis erkl�ren, die das in
>> der Schule lernen aber die Zeit wird kommen, ich wei�. Warum konnten
>> die nicht einfach zwei Oketts an die bestehenden Adresse dran h�ngen
>> und den Rest so lassen wie er war?
>

> Na ja, man hat bei den Features schon ordentlich draufgepackt, obwohl
> nat�rlich das nicht so gut sichtbar ist, weil z.T. wieder r�ckportiert
> wurde. Na ja, ich bin mir auch nicht sicher, ob IPv6 nur toll ist, aber
> es ist eine Verbesserung nach meiner Meinung und was anderes haben wir
> nicht.

Jupp, da muss ich durch. Ich bin noch nicht so alt, dass ich das aussitzen
k�nnte. Da werd ich nicht drumrum kommen, es sei denn ich schul noch mal um
zum Landschaftsg�rtner oder so ... manchmal w�r mir echt danach... ;-)

>>>> # Neue TCP Sessions nur mit SYN erlauben
>>>> # http://www.smythies.com/~doug/network/iptables_syn/index.html
>>>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG /
>>>> --log-prefix "New but SYN-Flag not set:"
>>>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
>>>
>>> Das kann man sich sparen mit dem Syn-Flag.
>>
>> Warum? Ich dachte das war ne gute Idee?
>

> Na ja, der State-Filter von Iptables ist da eigentlich ausreichend
> zusammen mit deinem TCP-Stack, der ja auch nicht ganz bl�d ist.

Okay, wir hatten hier beim Testen aber auch den Fall, dass die Regel sogar
mal angesprungen ist. Wir waren mit SSH auf dem Rechner und beim Ausf�hren
des Firewall Skripts (um es neu einzulesen) ist die SSH Verbindung
abgest�rzt oder h�ngen geblieben. Jetzt hat es der SSH Client
offensichtlich noch eine Weile versucht und hat dann mit einer Broken Pipe
Meldung die Verbindung g�nzlich terminiert.

Aber in dieser Zeit wurden auf dem SSH Server (was auch der Rechner ist auf
dem wir Iptables testen) eben eine ganze Reihe dieser LOGs erzeugt.
Offensichtlich hat der SSH Server die Verbindung schon aufgegeben, was der
Client nicht wusste und so kam es wohl zu einer Reihe dieser verwaisten
Pakete, die zu keiner Verbindung mehr geh�rten.

>>> [...]

>> Vielen Dank f�r deine ausf�hlichen �usserungen... :-)
>

> Wof�r hat man Usenet-Freunde.

Fehlt nur noch der Like-Button ;-)

Thx & Bye Tom
--

"Der Retter der Welt ist ein Pinguin und Linus Torvalds ist sein Prophet "

[Thomas Wildgruber]

Servus,

On Wed, 05 Sep 2012 05:17:22 +0000 (UTC), Juergen P. Meier wrote:

> Thomas Wildgruber <excp...@web.de>:

>
>> 192.168.0.0/24 befindet sich die IP des Systems.
>
> Wenn dein DNS-Server die obige IP hat, verwendest du 192.168.167.0/24.
> Oder verwendest du mehrere Netze aus dem 192.168.0.0/16 Bereich?

Nein, die Netzadresse wurde von mir falsch angegeben, ich befinde mich im
netz 192.168.167.0/24, sorry...

> Anyway, beide /24 waeren bestandteil des 192.168.0.0/16 und werden von
> der Antispoofing-Regel erschlagen.

Okay, obwohl ich eigentlich h�tte wissen m�ssen, danke ich f�r die
Aufkl�rung, ich hab es n�mlich nicht gewusst... ;-)

>>> [...]
>> Das mit dem Standardport ist ein Gedanke den man aufgreifen k�nnte, in der

>> Tat. Wobei ich gerade an dieser Stelle (zu gegebener Zeit) fail2ban ins

>> Spiel bringen wollte, was ebenfalls auf das Auth-Logfile zur�ckgreift und

>
> fail2ban ist potentiell gefaehrlich weil es einen DoS gegen den
> Service ermnoeglicht, der dich selbst aussperren kann. Sowas immer mit
> Bedacht einsetzen.

Wie das? Da m�ssten wir dann doch wieder in die Spoofing Thematik zur�ck
oder nicht? Der Angreifer greift meinen (SSH) Service an und verwendet
dabei zB unsere externe IP und sperrt somit uns anstatt sich selbst. Das
meinst du wohl damit?

Ja auf die Gefahr bin ich damals hingewiesen worden, als mir das gelernt
wurde, ich erinnere mich, wobei wir damals Blockhosts als
Diskussionsgrundlage hatten. Dieses Skript parst auch ein Logfile und parkt
f�r eine gewisse Zeit (wenn die Bedingungen zutreffen) die Angreifer IP in
der /etc/hosts.allow mit dem deny Flag. Die Standardeinstellung des Skripts
verwendet hier in der Syntax ALL: <IP>: deny, was jeden Dienst f�r den
Angreifer sperrt, obwohl dieser das ganze �ber (in unserem Fall) FTP
ausgel�st hat. An dieser Stelle wurde ich auf die Gefahr des ALL:
hingewiesen, dass der Angreiferuns so auch f�r SSH ausperren k�nnte.

Oder hattest du mit dem Hinweis etwas anderes im Sinn?

BTW: Wie spooft man eigentlich eine andere IP-Adresse? Ich k�nnte mir das
gut als Demonstration f�r den Azubi vorstellen. Klingt spannend und w�rde
die Motivation f�r diese Thematik hoch halten.

>>> [...]

>>> Den FTP Steuerkanal freizugeben wird nicht reichen (solange du nicht
>>> die grobe Sicherheitsluecke namens "conntrack_ftp" als modul nachlaedst
>>> - was in der Praxis eine nicht besonders kluge Idee ist)
>>
>> Aha, das ist mir neu, wobei mir auch das Kdernelmodul erst seit gestern
>> bekannt ist. Ich habs *mit* dem Kernel-Modul eingerichtet (steht irgendwo
>> weit oben im Skript). Gibt es zu den Problemen mit dem Modul was zum
>> nachlesen?
>
> Das FTP Conntrack modul "liest" den FTP-Kanal mit und alles, was nach
> einem PORT oder PASV oder aehnlichem Kommando aussieht wird als
> Portfreischaltungsauffforderung interpretiert und fuehrt zu einem
> entsprechenden dynamischen Loch in den Filterregeln.

Ja das h�rt sich so an, als ob es eine Einladung w�re, f�r jemanden der
damit umzugehen versteht.

> In den 1990er Jahren - als die ersten STateful-Firewalls auftauchten
> mit FTP-Helpern - war es ein beliebtes Spiel im / Verzeichnis eines
> FTP-Servers bei Connect eine Datei die z.B. die Zeichenkette
> "PORT 192,168,1,1,0,80" an passender Stelle im langen Namen des
> einzigen Unterverzeichnisses (bzw. verschiedene Kombinationen
> haeufig verwendeter IP Addressen in Heim-Netzen) anzubieten, die dann
> vom Client wegen der Laenge des Namens in zwei TCP-Pakete zerlegt
> werden mussten und im zweiten Paket dann als PORT-Kommando
> fehlinterpretiert wurde. Der Angreifer konnte sich dann z.B. auf das
> *interne* webinterface eines NAT-Routers verbinden und so diesen
> Fernsteuern (o.ae.).

Aha, klingt auch spannend und da f�llt mir ein, dass ich davon schon mal in
einem Buch gelesen habe, welches ich Zuhause habe. Ich werde mir das
nochmal zur Brust nehmen.

>>> [...]

> Damit wird auch Passives FTP ohne FTP-Protokollerkennung zu einer
> .... -d any --ports 1024-65536 -j ACCEPT.

Jupp, und das war das Problem, welches wir damals mit Ipchains hatten. Ein
Scheunentorgro�es Loch, das keiner wirklich haben wollte. Wobei wir damals
einen FTP Server hinter einem Paketfilter betrieben haben und idR nicht die
Clients gewesen sind. In unserem FTP Server konnte (oder kann man immer
noch...) einen Port-Range festlegen, welche f�r den R�ckweg verwendet
werden d�rfen. Das machen die Com-Partner ja im Handshake aus. Somit
konnten wird die offenen High-Ports auf ein paar wenige beschr�nken aber
mehr wie ein Pflaster war das nat�rlich auch nicht.

>> [DHCP Dialog]

>>> Ja, natuerlich. Aber das wird bei dir schon gemacht, auch wenn du
>>> nicht weist wo.
>>

>> Nein wei� ich wirklich, wo?

>
> Das wollte ich weiter unten ausfuehren: Deine state-regel erlaubt das.
> Weil ausgehend erlaubtst du dein DHCP DISCOVER, und das DHCP REPLY Paket
> vom DHCP server faellt in state=ESTABLISHED.

Ich widerspreche dir nur ungern aber an dieser Stelle habe ich meine
Zweifel, zumindest was den initalen DHCP Dialog beim Booten betrifft. Ich
habe das im anderen Posting an Oliver schon ausf�hrlich kommentiert, ich
erlaube mir deshalb das ganze zT aus dem Kontext gerissen hier zu kopieren:

---snip---

> �h, eigentlich ist DHCP einfach UDP und UDP wird ganz normal gefiltert
> mit Iptables.

Wir sind gestern sogar hergegangen und haben alle Regeln geflusht und nur
die Default DROP Policy in der INPUT, FORWARD und OUTPUT Chain stehen
lassen, den Rechner gebootet und er bekam ohne Probleme eine IP-Adresse.
Wir sind sogar hergegangen und haben vorher noch das Lease mit dhclient
versucht zu erneuern, (was ohne Regeln dann nat�rlich nicht gegangen ist)
um auch sicher zu sein, dass der Client kein g�ltiges Lease mehr hat.

Aber ich habe einen anderen Verdacht, warum das beim Booten auch ohne Regel
klappen k�nnte. An meiner Maschine hier initilaisiere ich den Netfilter
�ber ein Init-Skript und dieses hat folgenden LSB-Header:

### BEGIN INIT INFO
# Provides: firewall.sh
# Required-Start: $local_fs $network
# Required-Stop: $local_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Descrition Firewall start script
# Description: Iptables config script
### END INIT INFO

---snap---

>> Jetzt sei nicht so streng, ich fand das Skript gut, mift ;-)
>
> Heh, es dauert ein wenig bis man das alles raushat.

Definitiv ;-)

>>> [...]

>> Die letzten zwei habe ich jetzt nicht ganz verstanden. Die Whitelist soll
>> GeDROPt (bzw. REJECTed) werden bzw eine Blacklist ACCEPTed? Warum nicht
>> anders herum?
>
> Ich meinte: Whiteliste (impliziert ACCEPT) oben, am Ende derselben
> eine generische -s any -d any -j REJECT Regel. Ich hatte mich wohl ein
> wenig zu kurz gefasst.
> (bzw. Blacklist impliziert -J REJECT in den einzelnen Listen-Zeilen,
> gefolgt von einer any-any -j ACCEPT REgel).
>
> Ich wuerde auch der Uebersicht immer (nicht nur bei Netfilter) dazu
> raten, am Ende der Chain eine Explizite -j REJECT oder -j ACCEPT (je
> nach Gusto) Regel zu platzieren, und nicht auf die Default-Targets
> zu gehen. Das erleichtert die UEbersichtlichkeit und man sieht auf den
> Ersten Blick, was sache ist und muss nicht erst nachschauen, was ganz
> oben zur Chain steht. Das erleichtert auch die Lesbarkeit fuer Dritte.

Jupp das haben wir mit einer LOG/REJECT Regel jetzt so gemacht. Zum einen
weil wir wissen wollten, was den alles durch das Regelwerk trudelt ohne
erfasst zu werden (LOG) und zum anderen um nicht sinnlos Resourcen zu
verschwenden (REJECT).

Wir konnten n�mlich bei Testen festellen, dass zB ein Versuch sich mit
Telnet mit dem Rechner zu verbinden (was im Regelwerk nicht erlaubt ist)
der Client bei einer DROP-Regel es eine ganze Weile lang mehrfach versucht
den Dienst zu erreichen. Das waren nicht wenige Versuche in einer nicht zu
vernachlosen Zeitspanne. Gleiches Prozedere mit REJECT, stellt sofort nach
Erhalt des Port-Unreachable Pakets seine Bem�hungen ein. Fazit: Das REJECT
f�r den ganzen Rest am Ende des Regelwerks ist definitiv die bessere
Variante und haben wir so jetzt auch in unser Skript eingebaut. Danke
hierf�r.

So, Danke nochmal f�r deine ausf�hrlichen Kommentare.

Thx & Bye Tom
--

[Oliver Sch@d]

Thomas Wildgruber wrote:

> Das boot_facility $network in Required-Start könnte das Aufrufen des
> Skripts uU so lange hinauszögern, dass der initiale DHCP Dialog bereits
> abgeschlossen ist.

Mit großer Sicherheit wird das so sein. Kannst du leicht testen, indem du
lokal an der Maschine sitzend (oder KVM) den DHCP-Client weghaust und
diesen dann direkt auf der Kommandozeile mal erneut startest ohne Init-
Skript.

Deine Fehlermeldungen im Iptables-Log deuten auch genau auf dein
vermutetes Verhalten hin, denn wenn DHCP inital mal gemacht wurde, läuft
das Init-Skript für Iptables und ab da ist DHCP gesperrt. Das sollte dann
aber auch bedeuten, dass dann irgendwann der Client die IP-Adresse
verliert, wenn die maximale Lease-Zeit abgelaufen ist und der erneute
DHCP-Aufruf nicht klappt.

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen