Brauche mal Hilfe für meine Firewall

[schnebeck]

Aloa

Ich habe per iptable-Generator über "Harris Linux Seite" mir einen Regelsatz für eine Firewall eines Webservers generieren lassen.

Mir fällt auf, dass wenn ich ein Telnet auf Port 11 oder 15 für den Rechner mache, die Pakete nicht verworfen werden. Stattdessen gibt es ein Timeout und keinen Log-Eintrag.

Woran liegt das? Eigentlich sollten nur Port 22,80 und Port 8080 offen sein:

iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere           state INVALID limit: avg 2/sec burst 5 LOG level warning prefix `INPUT INVALID '
DROP       all  --  anywhere             anywhere           state INVALID
MY_DROP    tcp  --  anywhere             anywhere           tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE
MY_DROP    tcp  --  anywhere             anywhere           tcp flags:FIN,SYN/FIN,SYN
MY_DROP    tcp  --  anywhere             anywhere           tcp flags:SYN,RST/SYN,RST
MY_DROP    tcp  --  anywhere             anywhere           tcp flags:FIN,RST/FIN,RST
MY_DROP    tcp  --  anywhere             anywhere           tcp flags:FIN,ACK/FIN
MY_DROP    tcp  --  anywhere             anywhere           tcp flags:PSH,ACK/PSH
MY_DROP    tcp  --  anywhere             anywhere           tcp flags:ACK,URG/URG
ACCEPT     all  --  anywhere             anywhere <--- an Localhost gebunden!
ACCEPT     all  --  anywhere             anywhere           state RELATED,ESTABLISHED <--- was macht diese Regel?
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:www
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:webcache
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:ssh
MY_REJECT  all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy DROP)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere           state INVALID limit: avg 2/sec burst 5 LOG level warning prefix `OUTPUT INVALID '
DROP       all  --  anywhere             anywhere           state INVALID
ACCEPT     all  --  anywhere             anywhere <--- an Localhost gebunden
ACCEPT     all  --  anywhere             anywhere           state NEW,RELATED,ESTABLISHED
MY_REJECT  all  --  anywhere             anywhere

Chain MY_DROP (7 references)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere           limit: avg 2/sec burst 5 LOG level warning prefix `PORTSCAN DROP '
DROP       all  --  anywhere             anywhere

Chain MY_REJECT (2 references)
target     prot opt source               destination
LOG        tcp  --  anywhere             anywhere           limit: avg 2/sec burst 5 LOG level warning prefix `REJECT TCP '
REJECT     tcp  --  anywhere             anywhere           reject-with tcp-reset
LOG        udp  --  anywhere             anywhere           limit: avg 2/sec burst 5 LOG level warning prefix `REJECT UDP '
REJECT     udp  --  anywhere             anywhere           reject-with icmp-port-unreachable
LOG        icmp --  anywhere             anywhere           limit: avg 2/sec burst 5 LOG level warning prefix `DROP ICMP '
DROP       icmp --  anywhere             anywhere
LOG        all  --  anywhere             anywhere           limit: avg 2/sec burst 5 LOG level warning prefix `REJECT OTHER '
REJECT     all  --  anywhere             anywhere           reject-with icmp-proto-unreachable

Bye

Thorsten

[HangLoose]

moin moin

warum die pakete nicht verworfen werden, weiß ich jetzt auf anhieb auch nicht. aber zumindest eine frage kann ich dir beantworten.

ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED <--- was macht diese Regel?

diese regel sorgt dafür, das pakete die zu einer bestehenden verbindung gehören, passieren dürfen. stichwort connection tracking.


Gruß HL

[HangLoose]

sag mal, diese telnet anfragen laufen die über localhost? wenn ja, das ist ja erlaubt mit deinen regeln.


Gruß HL

[schnebeck]

Neee, die mache ich von außen über das Internet, normal mit
telnet IP Port

[schnebeck]

So, ich habe jetzt mal nmap drauf los gelassen:
nmap -p '0-1024' -TPolite -v -sS serverip
WARNING: Scanning "port 0" is supported, but unusual.

Starting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-07-06 23:15 CEST
Host serverip appears to be up ... good.
Initiating SYN Stealth Scan against serverip at 23:15
Adding open port 80/tcp
Adding open port 22/tcp
The SYN Stealth Scan took 481 seconds to scan 1025 ports.
Interesting ports on serverip:
(The 996 ports scanned but not shown below are in state: closed)
Port State Service
11/tcp filtered systat
15/tcp filtered netstat
22/tcp open ssh
25/tcp filtered smtp
57/tcp filtered priv-term
67/tcp filtered dhcpserver
68/tcp filtered dhcpclient
80/tcp open http
87/tcp filtered priv-term-l
95/tcp filtered supdup
98/tcp filtered linuxconf
111/tcp filtered sunrpc
135/tcp filtered loc-srv
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
161/tcp filtered snmp
162/tcp filtered snmptrap
179/tcp filtered bgp
199/tcp filtered smux
391/tcp filtered synotics-relay
445/tcp filtered microsoft-ds
512/tcp filtered exec
513/tcp filtered login
514/tcp filtered shell
515/tcp filtered printer
540/tcp filtered uucp
705/tcp filtered unknown

Nmap run completed -- 1 IP address (1 host up) scanned in 481.295 seconds


Was bedeutet denn nun "filtered"??

Nachtrag UDP:
==========
nmap -p '0-1024' -TNormal -v -sU serverip
WARNING: Scanning "port 0" is supported, but unusual.

Starting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-07-06 23:30 CEST
Host serverip appears to be up ... good.
Initiating UDP Scan against serverip at 23:30
send_udp_raw: One or more of your parameters suck!
send_udp_raw: One or more of your parameters suck!
Too many drops ... increasing senddelay to 50000
Too many drops ... increasing senddelay to 100000
Too many drops ... increasing senddelay to 200000
Too many drops ... increasing senddelay to 400000
Too many drops ... increasing senddelay to 800000
send_udp_raw: One or more of your parameters suck!
send_udp_raw: One or more of your parameters suck!
send_udp_raw: One or more of your parameters suck!
send_udp_raw: One or more of your parameters suck!
The UDP Scan took 1042 seconds to scan 1025 ports.
Adding open port 135/udp
Adding open port 111/udp
Adding open port 137/udp
Adding open port 162/udp
Adding open port 391/udp
Adding open port 67/udp
Adding open port 514/udp
Adding open port 139/udp
Adding open port 88/udp
Adding open port 68/udp
Adding open port 199/udp
Adding open port 69/udp
Adding open port 161/udp
Adding open port 445/udp
Adding open port 136/udp
Adding open port 0/udp
Adding open port 138/udp
Interesting ports on serverip:
(The 1008 ports scanned but not shown below are in state: closed)
Port State Service
0/udp open unknown
67/udp open dhcpserver
68/udp open dhcpclient
69/udp open tftp
88/udp open kerberos-sec
111/udp open sunrpc
135/udp open loc-srv
136/udp open profile
137/udp open netbios-ns
138/udp open netbios-dgm
139/udp open netbios-ssn
161/udp open snmp
162/udp open snmptrap
199/udp open smux
391/udp open synotics-relay
445/udp open microsoft-ds
514/udp open syslog

Nmap run completed -- 1 IP address (1 host up) scanned in 1041.776
susi root #

Ist das Teil offen wie ein Scheunentor - oder verstehe ich da was nicht?!

Verwirrt

Thorsten

[HangLoose]

hi

Was bedeutet denn nun "filtered"??

das filtered bedeutet, das eine firewall/paketfilter aktiv ist. dein paketfilter schickt in dem fall ein tcp-reset, was auch ok ist.

dein udp scan verwirrt mich auch etwas, muss ich sagen. da sollte auch eigentlich auch ein filtered auftauchen.

hast du eigentlich den inetd oder xinetd laufen?


Gruß HL

[HangLoose]

hi



-sU UDP-Scans: Diese Methode wird stets dann herangezo_
gen, wenn es um das Identifizieren der offenen UDP-
Ports (siehe RFC 768) eines Systems geht. Diese
Technik basiert darauf, dass ein UDP-Datagramm mit
0 Byte an Nutzdaten an jeden Port des Zielsystems
geschickt wird. Erhalten wir eine ICMP port
unreachable-Nachricht, so ist der Zielport
geschlossen. Andererseits handelt es sich um einen
offenen Port.

harry verwendet in seinem script ein port unreachable

REJECT udp -- anywhere anywhere reject-with icmp-port-unreachable

es hätte also eigentlich ein filtered auftauchen müssen.


ps: ich muss erstmal in die koje


Gruß HL

[schnebeck]

Ich auch, überschlafen hilft ja vielleicht ;-)

ich haben weder inetd noch xinetd am laufen:

netstat -e -a -p
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name
tcp        0      0 *:mysql                 *:*                     LISTEN      root       2024       813/
tcp        0      0 *:webcache              *:*                     LISTEN      root       4646       991/
tcp        0      0 *:www                   *:*                     LISTEN      root       2073       825/apache2
tcp        0      0 *:8021                  *:*                     LISTEN      root       4649       991/
tcp        0      0 *:ssh                   *:*                     LISTEN      root       2157       910/sshd
tcp        0    304 web-pzh.ita.uni-han:ssh pD9E3449E.dip.t-d:45666 ESTABLISHED root       4746       1056/s0
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path
unix  4      [ ]         DGRAM                    2022   808/syslogd         /dev/log
unix  2      [ ACC ]     STREAM     LISTENING     2026   813/                /var/run/mysqld/mysqld.sock
unix  2      [ ACC ]     STREAM     LISTENING     2205   933/                /var/run/cgisock
unix  2      [ ]         DGRAM                    2223   939/cron
unix  2      [ ]         DGRAM                    2067   817/klogd

der 991 ist ein Zope-Server

Gute Nacht!

[schnebeck]

Ah! nmap ist bei den UDP vielleicht etwas optimistisch:

nmap -p '162' -v -sU serverip

Starting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-07-07 00:37 CEST
Host serverip appears to be up ... good.
Initiating UDP Scan against serverip at 00:37
The UDP Scan took 1 second to scan 1 ports.
Adding open port 162/udp
Interesting ports on serverip:
Port State Service
162/udp open snmptrap

Nmap run completed

Das hat zu einem DROP ICMP im Syslog geführt - Sollte es besser Rejected werden?
Jul 7 00:37:33 web-pzh kernel: DROP ICMP IN=eth0 OUT= MAC=00:08:74:c9:c4:4a:00:b0:8e:87:0f:40:08:00 SRC=217.227.68.158 DST=serverip LEN=28 TOS=0x00 PREC=0x00 TTL=39 ID=22258 PROTO=ICMP TYPE=8 CODE=0 ID=21952 SEQ=18313

Bleibt wohl eher die Frage, warum ein Scan auf TCP-filtered-Port nicht im Syslog erscheint?
Warum schickt der Paketfilter genau bei jenen Ports ein reset? Wie wird das in den Regeln deutlich?

Bye

Thorsten

[Jinto]

ala gut, sag ich halt auchmal was: Hallo

Original geschrieben von schnebeck
Mir fällt auf, dass wenn ich ein Telnet auf Port 11 oder 15 für den Rechner mache, die Pakete nicht verworfen werden. Stattdessen gibt es ein Timeout und keinen Log-Eintrag.

zuerst mal so die ein oder andere Anmerkung, diese Ausgabe ist relativ schlecht. Wenn du direkt das Script oder iptables-save ausgabe gepostet hättest wäre dir ein bischen Arbeit erspart und das ein oder andere wäre bestimmt deutlicher rausgekommen.

Wie und von wo hast du denn telnet aufgerufen?

Woran liegt das? Eigentlich sollten nur Port 22,80 und Port 8080 offen sein:

Das ist auch so.

So wie du nmap aufgerufen hast, würde ich auf einen lokalen Portscan tippen, leider ist der jedoch nicht aussagekräftig und taucht auch nicht in deinen logs auf, da es sich um einen lokalen Scan handelt.

Wenn du einen Portscan durchführen willst, dann musst du schon von "extern" auf diese Schnittstelle zugreifen => internetpostscanner verwenden such mal hier im Forum danach.

PS: nmap -p '162' -v -sU serverip und dein Logfileauszug haben ncihts miteinander zu tun.


@HL
nein, es hätte geschlossen auftauchen müssen, siehe dein Zitat.

[schnebeck]

Erstmal ein Dankeschön an die Helfenden :-)

Wie oben schon mal geschrieben: Sowohl telnet als auch nmap wurde über das Internet von einem entfernten Rechner ausgeführt. _Kein_ lokaler Scan! Wie telnet bzw. nmap abgesetzt wurden steht oben.

Hier nochmal die iptables-Befehle:
echo "Starte IP-Paketfilter"

# iptables-Modul
modprobe ip_tables
# Connection-Tracking-Module
modprobe ip_conntrack
# Das Modul ip_conntrack_irc ist erst bei Kerneln >= 2.4.19 verfuegbar
modprobe ip_conntrack_irc
modprobe ip_conntrack_ftp
# Tabelle flushen
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X
# Default-Policies setzen
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# MY_REJECT-Chain
iptables -N MY_REJECT
# MY_REJECT fuellen
iptables -A MY_REJECT -p tcp -m limit --limit 7200/h -j LOG --log-prefix "REJECT TCP "
iptables -A MY_REJECT -p tcp -j REJECT --reject-with tcp-reset
iptables -A MY_REJECT -p udp -m limit --limit 7200/h -j LOG --log-prefix "REJECT UDP "
iptables -A MY_REJECT -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A MY_REJECT -p icmp -m limit --limit 7200/h -j LOG --log-prefix "DROP ICMP "
iptables -A MY_REJECT -p icmp -j DROP
iptables -A MY_REJECT -m limit --limit 7200/h -j LOG --log-prefix "REJECT OTHER "
iptables -A MY_REJECT -j REJECT --reject-with icmp-proto-unreachable
# MY_DROP-Chain
iptables -N MY_DROP
iptables -A MY_DROP -m limit --limit 7200/h -j LOG --log-prefix "PORTSCAN DROP "
iptables -A MY_DROP -j DROP
# Alle verworfenen Pakete protokollieren
iptables -A INPUT -m state --state INVALID -m limit --limit 7200/h -j LOG --log-prefix "INPUT INVALID "
iptables -A OUTPUT -m state --state INVALID -m limit --limit 7200/h -j LOG --log-prefix "OUTPUT INVALID "
# Korrupte Pakete zurueckweisen
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP
# Stealth Scans etc. DROPpen
# Keine Flags gesetzt
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j MY_DROP
# SYN und FIN gesetzt
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j MY_DROP
# SYN und RST gleichzeitig gesetzt
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j MY_DROP

# FIN und RST gleichzeitig gesetzt
iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j MY_DROP

# FIN ohne ACK
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j MY_DROP

# PSH ohne ACK
iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j MY_DROP

# URG ohne ACK
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j MY_DROP

# Loopback-Netzwerk-Kommunikation zulassen
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Connection-Tracking aktivieren
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# HTTP
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 8080 -j ACCEPT
# SSH
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 22 -j ACCEPT
# Default-Policies mit REJECT
iptables -A INPUT -j MY_REJECT
iptables -A OUTPUT -j MY_REJECT

# Max. 500/Sekunde (5/Jiffie) senden
echo 5 > /proc/sys/net/ipv4/icmp_ratelimit

# Speicherallozierung und -timing fr IP-De/-Fragmentierung
echo 262144 > /proc/sys/net/ipv4/ipfrag_high_thresh
echo 196608 > /proc/sys/net/ipv4/ipfrag_low_thresh
echo 30 > /proc/sys/net/ipv4/ipfrag_time

# TCP-FIN-Timeout zum Schutz vor DoS-Attacken setzen
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

# Maximal 3 Antworten auf ein TCP-SYN
echo 3 > /proc/sys/net/ipv4/tcp_retries1

# TCP-Pakete maximal 15x wiederholen
echo 15 > /proc/sys/net/ipv4/tcp_retries2


Bye

Thorsten

[Jinto]

ein Internetportscan find ich halt in der Weise komisch, da nmap serverip zumindest bei mir nicht gehen würde.

Das Skript sieht soweit in Ordnung aus.

Was hälst du davon wenn ich mal einen Scan absetze? Schick deine ip einfach mal per pn bzw. handeln zuvor ne Zeit aus.

[schnebeck]

Jinto hat das Problem in privater Mail geklärt:
Im B-Netz gibt es eine weitere FW, die aktiv wird, wenn man von außen das Netzwerk scannt. Diese hat die Tests somit beeinflusst. Meine lokale FW scheint i.O. zu sein, wie ein Scan innerhalb des B-Netzes ergab.

Bye

Thorsten

[HangLoose]

@Jinto

nein, es hätte geschlossen auftauchen müssen, siehe dein Zitat.

stimmt da steht geschlossen, hatte ich auch gelesen . ich bin nur von ausgegangen, das ähnlich wie beim tcp-scan ein filtered kommt, wenn nmap merkt das da ein paketfilter vorhängt.


Gruß HL