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)

Servus Heiko,

On 3 Sep 2012 14:01:23 +0200, Heiko Schlenker 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...?

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

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?

Ist bereits aktiviert.

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

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?

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

Ah jetzt habe ich hier doch noch einen Fehler gefunden, die zweite Regel
sollte einen --dport beinhalten keinen --sport. Die Regeln demnach
abge ndert 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 testens wenn das Lease des Clients abgelaufen ist,
k nnten ohne diese Regeln Probleme mit der Erneuerung auftauchen...

Thx & Bye Tom
--
"One good Whiskey a day, keeps the doctor away"

Thomas Wildgruber wrote on 03. September 2012:

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.

Servus Oliver,

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...

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).

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

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?

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.

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... ;-)

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...

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?

Warum? Ich dachte das war ne gute Idee?

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.

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.

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... :-)

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

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)

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)

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

Dein DNS-Server steht innen?

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.)

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.

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

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).

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

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.

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])

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, ...)

Okay, nicht dass es nicht Webfrontends dafuer gaebe.

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)

Korrekt.

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.

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.

Ach.

Du filterst dein eigenes Netz per Anti-spoofing.

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

DHCP ist UDP.

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.

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

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 ...

read more »

Serrvus,

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.

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.

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.

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.

Warum? Die Pakete werden ja geLOGgt und geDROPt.

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.

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.

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

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.

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.

Testsystem hat kein X ;-)

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.

Okay, auch wenn ich jetzt nach ein-, zwei-maligem lesen nicht alles
verstanden habe, wei ich worauf du hinaus m chtest. ...

read more »

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

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

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.

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.

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.

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

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

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

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)

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

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

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.).

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.

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.

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).

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.

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

Schadet zumindest nicht.

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

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 ...

read more »

Servus,

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

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

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?  

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... ;-)

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.

Fehlt nur noch der Like-Button ;-)

Thx & Bye Tom
--
"Der Retter der Welt ist ein Pinguin und Linus Torvalds ist sein Prophet "

Servus,

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

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

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.

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

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.

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.

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---

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?  
---snap---

Definitiv ;-)

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 ...

read more »

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