Sascha Andres wrote: [...snip...]

sourceport 80 dpt = high ist - fuer mich - etwas merk- wuerdig.

vielleicht versucht da jemand ueber eine hintertuer offene tueren zu finden (port 80 generell offen hab ich schon haeufiger gesehen).

http oeffnet AFAIK keinen rueckport vom server. der client (browser) oeffnet fuer jede verbindung einen highport und verbindet sich zu port 80.

ciao sascha

-- Sascha Andres linux@programmers-world.com http://www.programmers-world.com

Hallo, der Webserver muß aber seine Antwort zurücksenden, und dazu benutzt er nun einmal den Port 80 als Src und sendet an den Port, von dem aus die Verbindung aufgebaut wurde. Die Frage geht also noch raus, nur die Antwort bleibt stecken. Der Request geht ja auch von einem high port weg... Gruß, Jens

Sascha Andres wrote at Monday, December 31, 2001 7:41 PM Hallo

hi, On Mon, Dec 31, 2001 at 07:21:11PM +0100, Jens Falke wrote:

...

der Webserver muß aber seine Antwort zurücksenden, und dazu benutzt er nun einmal den Port 80 als Src und sendet an den Port, von dem stimmt. den rueckweg hab ich glatt unterschlagen. aber die antwart ist enweder related oder established, im fall von http established. also ganz oben in der input chain einfuegen: iptables --append INPUT --match state --state RELATED,ESTABLISHED --jump ACCEPT

ich habe iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT drinstehen und als default DROP, d. h. ich habe nirgends eine DROP Regel, dann kann der Aufruf doch gar nicht zu spät sein, oder doch?

dann sollten also alle daten korrekt ankommen.

ciao sascha

Sascha Andres wrote at Monday, December 31, 2001 10:59 PM Hallo

hi, On Mon, Dec 31, 2001 at 10:50:53PM +0100, Alexander Sommer wrote:

...

ich habe iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT drinstehen und als default DROP, d. h. ich habe nirgends eine DROP Regel, dann kann der Aufruf doch gar nicht zu spät sein, oder doch? hast du irgendwelche aufrufe der form iptables --append INPUT --jump LOG --log-prefix "INPUT Packet DENY :" drinstehen. die wuerden loggen aber kein drop taetigen.

ja, iptables -A INPUT -d 255.255.255.255 -j DROP iptables -A INPUT -j -j LOG --log-prefix "INPUT Packet DENY :" als letzte Zeilen in Skript mit dem ich meine iptables aufrufe. Das sollte doch funktionieren, oder? Gruß Alex PS * * * * * Gutes Neues Jahr * * * * *

Sascha Andres wrote at Tuesday, January 01, 2002 1:18 AM Hallo

hi, On Tue, Jan 01, 2002 at 12:25:00AM +0100, Alexander Sommer wrote:

...

ja, iptables -A INPUT -d 255.255.255.255 -j DROP iptables -A INPUT -j -j LOG --log-prefix "INPUT Packet DENY :" okay. so wies aussieht scheint das script den vorletzten schritt einer http verbindung zu blocken. dabei kommt es auf die tcp flags an (ACK SYN FIN PSH).

bei einer http verbindung die geloggt sieht das so aus:

aufbau state NEW antwort ACK SYN datentransfer ACK datenende ACK FIN PSH bestaetigung ACK bestaetigung ACK

datenende wird bei dir geblockt.

wenn das nicht weiterhilft, kannst du mir gerne mal per pm dein script zuschicken. ich schau's mir dann mal an.

Leider bin ich soweit noch nicht eingestiegen, da? ich mit den Flags gro?artig umgehen kann und deshalb verstehe ich leider auch Deine Erklarung nicht. Aus diesem Grund hange ich das Skript einfach mal an. Besten Dank im fur Deine Hilfe Gru? Alex Firewall Skript: #! /bin/sh # # Masquerading Firewall Version 0.02 # # # Iptables / Netfilter Paketfilter # # fuer Kernel-Version 2.4.x # # einzelne Verbindungen vom internen Netzwerk zulassen # # Absichern und Logging # # Dynamische Paket Filterung internal_device="eth0" internal_netaddress="192.168.1.0/24" internal_netaddress1="192.168.10.0/24" external_device="ppp0" . /etc/rc.config # Wie wurde ich aufgrufen, direkt oder aus einem Runlevel-Link # # 1. kompletter Filename # 2. fuehrendes S/K 00-99 entfernen base=${0#*/} link=${base#*[SK][0-9][0-9]} # Wenn ich direkt aufgerufen wurde dann starte mich immer, # ansonsten check erst die Start-Variable /etc/rc.config/ START_MSQ_FIREWALL # test $link = $base && START_MSQ_FIREWALL="yes" test "$START_MSQ_FIREWALL" = yes || exit 0 case "$1" in start) echo -n "Starteng Firewall Services." echo # regeln flushen iptables -F # benutzerdefinierte Regeln entfernen iptables -X iptables -t nat -F # default policy iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP # Schutzmasnahmen # siehe dazu auch: /usr/src/linux/Documentation/networking/ip-sysctl.txt # Schutz gegen IP-Spoofing if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i done fi # SYN-FLOOD-Protection if [ -e /proc/sys/net/ipv4/tcp_syncookies ]; then echo 1 > /proc/sys/net/ipv4/tcp_syncookies fi # Source Route Quench Protection for i in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $i done # IP_Forwarding einschalten echo "1" > /proc/sys/net/ipv4/ip_forward # DYN_IP fuer ppp und dhcp clients echo "1" > /proc/sys/net/ipv4/ip_dynaddr # Loopback-Device freischalten iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Proxy, HTTP, POP, SMTP und Ping fur's Lan (192.168.1.x) freischalten iptables -A INPUT -p tcp --dport 3128 -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT iptables -A INPUT -p tcp --dport 110 -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT iptables -A INPUT -p tcp --dport 25 -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT iptables -A INPUT -p udp --dport 37 -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT iptables -A INPUT -p tcp --dport 22 -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT iptables -A INPUT -p icmp -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT # Proxy, POP, SMTP und Ping fur's Lan (192.168.10.x) freischalten iptables -A INPUT -p icmp -i $internal_device -s $internal_netaddress1 -m state --state NEW -j ACCEPT iptables -A INPUT -p tcp --dport 25 -i $internal_device -s $internal_netaddress1 -m state --state NEW -j ACCEPT iptables -A INPUT -p tcp --dport 110 -i $internal_device -s $internal_netaddress1 -m state --state NEW -j ACCEPT iptables -A INPUT -p tcp --dport 3128 -i $internal_device -s $internal_netaddress1 -m state --state NEW -j ACCEPT # FTP freischalten iptables -A INPUT -p tcp --dport 113 -j REJECT iptables -A INPUT -p tcp --sport 20 -j ACCEPT # Ping, HTTP, DNS, FTP, POP3, SMTP, SSL, SSH nach au?en lassen iptables -A OUTPUT -p icmp -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport 110 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p udp --dport 37 -m state --state NEW -j ACCEPT # Vorhandene Verbindungen zulassen iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # Forward-Chain zur Vorselektierung # ICMP iptables -A FORWARD -p icmp -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT # DNS iptables -A FORWARD -p udp --dport 53 -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT # HTTP iptables -A FORWARD -p tcp --dport 80 -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT # FTP-Command iptables -A FORWARD -p tcp --dport 21 -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT # FTP-Data passiv iptables -A FORWARD -p tcp --dport 1024 -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT # SSH iptables -A FORWARD -p tcp --dport 22 -i $internal_device -s $internal_netaddress -m state --state NEW -j ACCEPT # Forwarding Rules definieren # alle bestehenden Verbindungen zulassen iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # nicht zugelassene Verbindungen protokollieren iptables -A FORWARD -d 255.255.255.255 -j DROP iptables -A FORWARD -j LOG --log-prefix "FORWARD Packet DENY :" # Postrouting und Maskieren iptables -t nat -A POSTROUTING -o $external_device -j MASQUERADE # Logging von externen Verbindungsversuchen iptables -A INPUT -d 255.255.255.255 -j DROP iptables -A INPUT -j LOG --log-prefix "INPUT Packet DENY :" ;; stop) echo -n "Shutting down Masquerding Services." echo # regeln flushen iptables -F # IP_Forwarding ausschalten echo "0" > /proc/sys/net/ipv4/ip_forward ;; *) echo "Usage: $0 {start|stop}" esac

On Tue, Jan 01, 2002 at 01:17:50AM +0100, Sascha Andres wrote:

so wies aussieht scheint das script den vorletzten schritt einer http verbindung zu blocken. dabei kommt es auf die tcp flags an (ACK SYN FIN PSH).

bei einer http verbindung die geloggt sieht das so aus:

aufbau state NEW antwort ACK SYN datentransfer ACK datenende ACK FIN PSH bestaetigung ACK bestaetigung ACK

datenende wird bei dir geblockt.

Eine kleine Frage: Sind die states nur Abkürzungen für die Flags? Es gibt ja die Flags: SYN, ACK, FIN, RST, URG, PSH (ALL und NONE) Wäre dann z. B. --tcp-flags SYN,ACK,FIN SYN (= --syn) dasselbe wie: --state NEW? Was ist der Unterschied zwischen --tcp-flags SYN,ACK,FIN SYN und --tcp-flags ALL SYN? Und welche Kombinationen sind überhaupt möglich bzw. kann ein Hacker alle Flags individuell setzen? -- mfg Martin Neuditschko

On Fri, Jan 04, 2002 at 12:28:09PM +0100, Sascha Andres wrote:

hi, On Thu, Jan 03, 2002 at 08:09:16AM +0100, Yosuke Tomoe wrote:

...

Eine kleine Frage: Sind die states nur Abkürzungen für die Flags? Es gibt ja die Flags: SYN, ACK, FIN, RST, URG, PSH (ALL und NONE)

Wäre dann z. B. --tcp-flags SYN,ACK,FIN SYN (= --syn) dasselbe wie: --state NEW? nein. NEW bezieht sich auf den verbindungsaufbau. bei tcp (=Transmission Control Protocol) geschieht der verbindungaufbau durch einen 3 wege handshake. wenn 'ich' eine verbindung oeffnen moechte, so wuerde ich einpacket mit gesetztem SYN flag schicken. dieses bekomme ich durch ein ACK bestaetigt. zueltzt erhalte ich noch ein packet mit gesetztem SYN flag.

D.h. wenn ich bei meiner FW statt --syn ein --state NEW nehme bin ich sicherer, weil dann gleich der ganze Datenaufbau geblockt wird, oder? (Ach ja das state NEW funzt ja auch bei UDP und ICMP. Ist also sowieso besser)

aufbau state NEW ^^^ du meinst SYN, nicht? antwort ACK SYN datentransfer ACK datenende ACK FIN PSH bestaetigung ACK

Kann ich das so machen: iptables -F iptables -A FORWARD -i ppp0 --state NEW -j DENY iptables -A FORWARD --state INVALID -j DENY iptables -A FORWARD -p tcp --tcp-flags ALL SYN -j filter iptables -A FORWARD -p tcp --tcp-flags ALL ACK,SYN -j filter iptables -A FORWARD -p tcp --tcp-flags ALL ACK -j filter iptables -A FORWARD -p tcp --tcp-flags ALL ACK,FIN,PSH -j filter iptables -A FORWARD -p tcp -j DROP (in -A filter sind die jetzigen Regeln für tcp) Oder kann man das so sowieso nicht machen?

...

Was ist der Unterschied zwischen --tcp-flags SYN,ACK,FIN SYN und --tcp-flags ALL SYN? ALL matched auf xmas (s.u.) ersteres nicht. Und welche Kombinationen sind überhaupt möglich bzw. kann ein Hacker alle Flags individuell setzen? es gibt durchaus tools, mit denen sich ein eigenes tcpip packet zusammengebauen laesst. so zb auch ein xmas packet. ein xmas packet heisst so, weil alle flags an sind.

Und was bewirkt das? Ich nehme an einen Verbindungsaufbau, oder?

...

Martin Neuditschko heisst du nun Yosuke Tomoe oder Martin Neuditschko ?

Ersteres ist nur ein Nick. Habe ich jetzt geändert. -- mfg Martin Neuditschko

On Fri, Jan 04, 2002 at 03:58:21PM +0100, Sascha Andres wrote:

hi, On Fri, Jan 04, 2002 at 01:10:19PM +0100, Martin Neuditschko wrote:

...

iptables -F iptables -A FORWARD -i ppp0 --state NEW -j DENY keiner sollte mehr eine verbindung von ueber ppp0 aufmachen koennen. Nein. Es darf keiner von außen eine Verbindung öffnen.

...

iptables -A FORWARD --state INVALID -j DENY

iptables -A FORWARD -p tcp --tcp-flags ALL SYN -j filter iptables -A FORWARD -p tcp --tcp-flags ALL ACK,SYN -j filter iptables -A FORWARD -p tcp --tcp-flags ALL ACK -j filter iptables -A FORWARD -p tcp --tcp-flags ALL ACK,FIN,PSH -j filter nimm doch einfach: iptables -A FORWARD -p tcp -j filter da du fuer alle flags matchen moechtest. Will ich ja nicht. Ich will nur solche Pakete durchlassen die es auch wirklich gibt. Was ist wenn ein Hacker z. B. ein Paket mit ACK, PSH oder RST oder FIN,SYN,... schickt? Mit den obigen Regeln werden nur Pakete die die Flags so gesetzt haben, wie sie normal verwendet werden, durchgelassen werden. Alles was nicht "normal" aussieht wird gleich geblockt.

...

Und was bewirkt das? Ich nehme an einen Verbindungsaufbau, oder? dabei erhofft man sich informationen um was fuer ein system es sich beim zielrechner handelt. teilweise gab es da in den tcpip stacks einige fehler. im moment wuesste ich aber nicht genau welche. Dann ist es ja noch wichtiger Pakete mit abnormal gesetzten Flags zu terminieren, oder?

-- mfg Martin Neuditschko

On Sat, Jan 05, 2002 at 11:25:52AM +0100, Sascha Andres wrote:

hi, On Fri, Jan 04, 2002 at 06:05:49PM +0100, Martin Neuditschko wrote:

...

Will ich ja nicht. Ich will nur solche Pakete durchlassen die es auch wirklich gibt. Was ist wenn ein Hacker z. B. ein Paket mit ACK, PSH oder RST oder FIN,SYN,... schickt? Mit den obigen Regeln werden nur Pakete die die Flags so gesetzt haben, wie sie normal verwendet werden, durchgelassen werden. Alles was nicht "normal" aussieht wird gleich geblockt. [...] Dann ist es ja noch wichtiger Pakete mit abnormal gesetzten Flags zu terminieren, oder? dafuer ist der state INVALID zustaendig:

iptables --append FORWARD --match state --state INVALID --jump DROP

alle ungueltigen packete werden gedropt.

D. h. die Überprüfungsmöglichkeit der TCP-Flags ist sowieso überfüssig? -- mfg Martin Neuditschko

Hallo Allerseits, * 05.01.2002 19:34 Uhr, Sascha Andres linux@programmers-world.com:

hi, On Sat, Jan 05, 2002 at 05:14:25PM +0100, Martin Neuditschko wrote:

...

D. h. die Überprüfungsmöglichkeit der TCP-Flags ist sowieso überfüssig?

nicht unbedingt. haengt unter umstaenden von der anwendung ab. aber um einen relativ guten schutz fuer einen rechner zuhause zu realisieren, muss man sich nicht unbedingt mit den tcp flags auseinander setzen. je sicherheitskritischer das scheutzende netzwerk ist desto eher muss ich mich damit beschaeftigen...

ciao sascha

Ich muß Sascha an dieser Stelle beipflichten. Ich realisiere bei mir alleine mit einer Logging Rule so eine Art Pseudo IDS. Alleine mit richtig gesetzten TCP FLAGS ist es möglich auf rudimentäre Art und Weise Portscans zu erkennen (siehe -m limit). Mit diesen Regeln kann ich dann relativ zuverlässig auswerten um was für einen Scan (SYN-Scan, FIN-SCAN, NULL-SCAN, XMAS-Scan etc: - siehe nmap) es sich gehandelt hat. Klappt eigentlich ziemlich gut, kann ich nur empfehlen. Grüße Martin