# README zu SHREKS shreklichen iptables-Skripten # # http://www.buug.de/~aleks/iptables # # $Id: Readme,v 1.22 2003/01/30 20:10:09 aleks Exp $ # $Log: Readme,v $ # Revision 1.22 2003/01/30 20:10:09 aleks # Colins Patches eingespielt # # Revision 1.21 2002/02/25 23:37:01 aleks # Heroes um Ralph ergänzt. # # Revision 1.20 2002/02/21 18:03:49 aleks # - Fiptehler korrigiert, Heldenliste erweitert # # Revision 1.19 2002/02/16 17:41:11 aleks # Fiptehler beseitigt, die Heroes mit richtigen Namen genannt. # # Revision 1.18 2002/01/29 23:27:45 aleks # Umstellung auf CVS-Log-IDs als Versionshistory. Mal sehen, wie das aussieht. # :-) # # So, jetzt isses soweit. Du hälst eine Version von Shrek[]s shreklichen iptables-Skripten[TM] in den Händen. $STANDARD-DISCLAIMER -------------------- Jeder, der diese Skripte benutzt, ist selbst Schuld, wenn ihm dadurch die Kiste geknackt wird - ich übernehme jedenfalls keine Haftung dafür. Bis jetzt funktionieren sie allerdings ziemlich zufriedenstellend. Wie das so ist, gibt es ab und zu - gerade am Anfang - Änderungen, Verbesserungen und Bugfixes. Wer das immer mitbekommen möchte, schreibt eine Mail an shrekskripte@buug.de und wird dann automagisch über Updates und neues informiert. Und nur dann. :-) mail -s "subscribe shrekskripte" shrekskripte-request@buug.de < /dev/null Wenn gewünscht, gibt es auch noch eine Diskussionsliste, ich sehe aber den Bedarf noch nicht. Adressaten ---------- Diese Skripte sind eindeutig für den Hausgebrauch - nicht für den professionellen Einsatz. Die Regeln sind zwar in der Grundkonfiguration von außen dicht (bei SSH konfigurierbar), erlauben aber lokalen Usern allerhand, was man im professionellen Umfeld nicht möchte. Ein weiteres Kriterium ist der Einsatzzweck an einer Leitung mit dynamischer IP - für den professionellen Einsatz will man das wohl eher nicht, weil man so nur schwer selbst Dienste anbieten kann. Diese Skripte sind zwar für Leute gedacht, die sich noch nicht ernsthaft mit iptables beschäftigt haben, eine gewisse Routine in Bezug auf Linux und Shellskripte sollte aber beim Einsatz der Skripte vorhanden sein - die Chance, sich mit sicherheitsrelevanten Dingen wie zum Beispiel Paketfiltern gewaltig in den Fuß zu schiessen, ist vorhanden. Wem sich beim ersten Überfliegen der Skripte die Nackenhaare aufstellen, sollte lieber einen professionellen Dienstleister bemühen. Zum Einsatz der Skripte: ------------------------ Auf einem Linux-System gehören packetfilter und restorefilter für root ausführbar nach /usr/local/sbin/ chmod 700 /usr/local/sbin/packetfilter chmod 700 /usr/local/sbin/restorefilter Die Konfigurartionsdatei gehört nach /etc/firewall/fw-config Dieses Verzeichnis wird in aller Regeln noch nicht vorhanden sein. fw-config benötigt die Rechte 600. Zum Starten und Stoppen des Filters: ------------------------------------ Bei Debian werden alle Dateien, die in /etc/ppp/ip-up.d/ liegen, nach einen Verbindungsaufbau automagisch ausgeführt. Bei anderen Distributionen gibt es entsprechendes, bei der Windows NE (Nürnberg Edition) z.B. das wundervolle /etc/ppp/ip-up-Skript. Dabei nicht die cases verwexeln, der case muß dem Namen des externen Devices entsprechen, also ppp*) für ppp0. Dorthin gehört also ein entsprechender Link auf die beiden Skripte rein oder aber ein Startskript, z.B. in der Art: ,---- | nightmare:/etc/ppp/ip-up.d# ls -al | insgesamt 9 | drwxr-xr-x 2 root root 1024 Nov 14 13:57 . | drwxr-x--- 6 root dip 1024 Nov 14 20:24 .. | -rwxr-xr-x 1 root root 1299 Apr 18 2000 00-isdnutils | -rwxr-xr-x 1 root root 141 Mär 12 2001 1firewall_start | -rwxr-xr-x 1 root root 1668 Mär 11 2001 4dns-up | -rwxr-xr-x 1 root root 86 Feb 25 2001 fetchmail | -rwxr-xr-x 1 root root 330 Mai 24 2000 postfix | nightmare:/etc/ppp/ip-up.d# more 1firewall_start | #!/bin/bash | test -f /usr/local/sbin/packetfilter || exit 0 | | /usr/local/sbin/packetfilter | echo "Die Firewall wurde gestartet." | logger >> /var/log/messages | exit 0 | | nightmare:/etc/ppp/ip-up.d# cd ../ip-down.d/ | nightmare:/etc/ppp/ip-down.d# ls -la | insgesamt 8 | drwxr-xr-x 2 root root 1024 Mai 14 2001 . | drwxr-x--- 6 root dip 1024 Nov 14 20:24 .. | -rwxr-xr-x 1 root root 427 Mär 11 2001 0dns-down | -rwxr-xr-x 1 root root 48 Mär 12 2001 0firewall_stop | -rwxr-xr-x 1 root root 1191 Apr 18 2000 99-isdnutils | -rwxr-xr-x 1 root root 235 Feb 23 2000 leafnode | -rwxr-xr-x 1 root root 162 Mai 24 2000 postfix | nightmare:/etc/ppp/ip-down.d# more 0firewall_stop | #!/bin/bash | /usr/local/sbin/restorefilter `---- Als Alternative gibt es auch die Möglichkeit, die Firewall über ein gewöhnliches Init-Skript zu starten, wenn man zum Beispiel eine feste IP hat. Das dafür verwendbare Skript heißt firewall-init und wird für den Haupteinsatzweck (Paketfilter für Dialup-Leitung) NICHT BENÖTIGT. DEBUGGING --------- Zum Testen bitte immer erst das Restore-Skript laufen lassen, dann das Filterskript starten, nach dem die Konfigurationsdatei gespeichert wurde: /usr/local/sbin/restorefilter && /usr/local/sbin/packetfilter Wenn was nicht klappt, bitte ausführlich in das Syslog sehen. Die letzten Regeln loggen alle Pakete, die verworfen werden, mit dem Log-Tag FINAL nach /var/log/messages. Anhand eines Auszuges dieser Datei kann man in der Regel schnell sehen, was ein Paket will, und warum es nicht zu den vorhandenen Regeln paßt. Ein ausführlicheres Logging erreicht man durch das Setzen der Variablen DEBUG auf "1". Im Normalbetrieb laufen nur die Logs der Regeln, die rejecten, weil man sonst /var/log vollgemüllt bekommt. Und auch diese loggen jeweils nur die jeweils ersten Treffer. Eine weitere sehr brauchbare Analysemöglichkeit (vor allem, wenn das obige Skript auf eigene Faust erweitert wurde) ist der folgende Aufruf: sh -x /usr/local/sbin/packetfilter &> /tmp/test Damit wird die Ausgabe jeder Zeile im Skript (egal ob Erfolgsmeldung oder Fehlermeldung) nach /tmp/test geschrieben. In einen Editor geladen sieht man schnell, wo ein Problem durch eine z.B. nicht definierte Variable auftritt. Rückfragen an mich OHNE Logauszug und OHNE Screendump der versuchten Aktion sind wirklich sinnlos - wenn ich hellsehen könnte, würde ich hier jetzt schon reinschreiben, was dein Problem ist und wie Du es löst. Live-Support: In der Regel bin ich und ein paar andere kompetente Kaputte im IRC auf irc.buug.de im Channel #buug zu erreichen. REGELBETRIEB ------------ Zwei Dinge, auf die ich aufmerksam gemacht wurde: - Bei eine Portscan entstehen sehr schnell sehr große (über 50 MB) Logdateien. Es gibt ab sofort eine Debug-Option in zwei Schritten, die eingeschaltet ein relativ unbegrenztes Logging (zur Fehlersuche) erlaubt, und ausgeschaltet nur DENYs loggt (und da nur die ersten einer Verbindung). - Im Regelbetrieb sollten die Policies bei ausgeschaltetem Paketfilter nicht auf ACCEPT, sondern auf DENY stehen. Man kommt dann allerdings nur noch lokal an das System ran, wenn keine Leitung nach draußen offen ist. Deshalb gibt es jetzt die Variable TESTING, damit wird die Defaultpolicy von DENY auf ACCEPT gestellt. Dies ist sinnvoll für Dialupsysteme, die mit Dialondemand arbeiten (nicht permanent online sind) und ein lokales Netz versorgen. Hilfe, ich werde gehackt! ------------------------- Durch den Einsatz dieser Regeln kommt es vor, das es bemerkt wird, wenn sich fremde Rechner im Syslog verewigen. DIES IST NICHT PER SE GEFÄHRLICH! Das Internet dient der Kommunikation. Think about it. Es gibt genug irrtümliche Verbindungen, gerade im Dialup-Bereich, wenn die zugewiesene IP gerade noch jemand anderem gehört hat, der Napster oder sonstwas betrieben hat. Bis das die ehemaligen Partner bemerken, kann es dauern. Sowas ist kein Angriff! Also bitte nervt nicht mich mit irgendwelchen Logfile-Auszügen, weil Ihr 'gehackt' werdet. 1. Wird das in 98% aller Fälle nicht der Fall sein, 2. werdet Ihr es in den restlichen 2% der Fälle wahrscheinlich nicht bemerken, und 3. kann ich nix dafür, daß Ihr plötzlich seht, wer an eurer Tür rüttelt. Bitte nervt auch nicht die Provider mit Lapalien. Die Ressourcen, die Ihr dort durch Kindereien bindet, können anders sinnvoller für Sicherheit aller investiert werden. Um im Zweifel herauszubekommen, wer das ist, der da rüttelt, helfen die Kommandozeilentools host, traceroute, whois und so weiter weiter. Im IRC-Channel #buug auf irc.buug.de steht gern mit Rat und Tat :o) zur Seite, wenn es tatsächlich ernst wird oder Fragen auftauchen. Wer mehr will: -------------- Es gibt keine Generalregel, was man haben muß. Es gibt aber folgende (einfache) Möglichkeiten, die Sicherheit etwas zu erhöhen: - Die vorhandenen Regeln dichter ziehen. Nicht alles, was geht, wird wirklich gebraucht. Outgoing ist praktisch ungefiltert. - Einsatz von ssh in der Protokollversion 2 und ssh-keys (PasswordAuthentification=no in der sshd) sind DRINGEND angeraten. - Regelmäßiger Check der Systemlogs. - Überprüfen des Systems anhand des folgenden HOWTOs (zwar Debian, aber zu 98% unabhängig von der Distribution): http://www.debian.org/doc/manuals/securing-debian-howto/ - Regelmäßiger Check auf bekannte Sicherheitslücken der benutzten Software, Abo der Security-Liste der eigenen Distribution und evtl. Security-Focus/bugtraq. - Überlegen, ob der Einsatz von tripwire, libsafe, chkrootkit, snort usw. sinnvoll ist. Dies ist *nur* *dann* der Fall, wenn man sich damit etwas intensiver auseinander setzt - und taugt sonst nicht mal als Fuchsschwanz, weil die Schnitten nicht wissen, was das sein soll. Ressourcen: ---------- - Die deutsche Übersetzung des Packet-Filtering-HOWTO http://www.netfilter.org/documentation/HOWTO/de/packet-filtering-HOWTO.txt - Die deutsche Übersetzung des NAT-HOWTO http://www.netfilter.org/documentation/HOWTO/de/NAT-HOWTO.txt - Die FAQ der Usenetgroup de.comp.security.firewall http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html - Die Security-Seiten der Distributionen (tbc): - http://www.debian.org/security/ - http://www.suse.de/de/support/security/ - http://www.redhat.com/apps/support/errata/ - http://www.linux-mandrake.com/en/security/ - Eine unabhängige Security-Seite für Linux: - http://www.linux-secure.de - Das folgende Howto ist zwar für Debian gedacht, 98% ist aber für jede Linux-Distribution geeignet http://www.debian.org/doc/manuals/securing-debian-howto/ - BUGTRAQ http://www.securityfocus.com Credits&Heroes: --------------- - Robin Socha, der sich den ersten Alphatest des umgestrickten Skriptes gegeben hat. Sowohl er, als auch das Skript haben ihn gut überstanden. - Rusty Russel. Weil er so schön undeutlich spricht, dafür aber brauchbare HOWTOs schreibt. - Matthias Kranz. Einfach, weil er ein Held ist und mir so wundervolle Sachen wie zum Beispiel: ppp=`ifconfig eth1 2>/dev/null`; if [ "$ppp" != "" -a $? -eq 0 \ ] ; then echo "richtig" ; else echo "flasch"; fi; gezeigt hat. Ja, ich gehe jetzt ins Bett. Bestimmt. - Karl-Heinz Haag. Für den Tip mit dem 50 MB-Logfile. Wer macht denn auch sowas? :-) - Christoph Biedl für einige Rechtschraibkorrekturen. - Gunnar Hahn für den Tip mit tcpmms. - Christoph Mieschel für das Entwanzen der Texte und behaarliches Nachfragen über die Sinnhaftigkeit einiger Regeln. - Ralph Angenendt, der auch auf meine -m unclean-Regel reingefallen ist. TODO ---- - Das ganze ist alles bis auf das Paketfilter-Skript selbst noch ziemlich unterdokumentiert, aber das kommt im Laufe der Zeit. - Squid-Config für transparentes Proxing - Weiterführenden Schutz ausweiten. - Ressourcen-Liste - murmel. Mich dünkt, das ganze doch auf init-Skript umzubauen. Mal sehen. Anregungen, Flames, Kommentare und so weiter bitte an mich. Alexander Stielau , 01-12-30.