Michael Karges wrote:
Am Freitag, 24. Oktober 2003 21:13 schrieb Matthias Hentges:
[snip]
Wird der Port von der Firewall gedropt nennt nmap ihn "filtered", wird er rejected (wie bei 113) nennt nmap ihn closed (eben weil er rejected wird und nicht gedropt) ob da nun was läuft auf dem Port oder nicht. Das "closed" wird von der Firewall verursacht und nicht von einem Dienst auf dem Rechner.
Kann nicht ganz stimmen: # cat /var/log/messages | grep DPT=113
liefert unter anderem:
Oct 24 20:13:34 (none) kernel: SuSE-FW-DROP-DEFAULT IN=eth1 OUT= MAC=xx DST=xx.xx.xx.xx LEN=328 TOS=0x00 PREC=0x00 TTL=48 ID=31557 PROTO=UDP SPT=44104 DPT=113 LEN=308
D.h., die Firewall "dropped" das Paket, genau das gleiche tut sie aber mit Port 110 beispielsweise, und dieses bezeichnet nmap als "filtered":
"Interesting ports on (81.5.192.18): (The 1599 ports scanned but not shown below are in state: filtered)"
Auch meint nmap: "For OSScan assuming that port 22 is open and port 113 is closed and neither are firewalled" -> wird also auch von nmap als niht von einer Firewall gefiltert angenommen.
Für 113/tcp ist in der Suse-FW expliziet ein REJECT eingebaut, auch wenn die Policy default auf Drop gesetzt wurde. Das "port 113 is closed and neither are firewalled" bezieht sich möglicherweise auf den tcp-scan seitens nmap. Im obigen Log-Auszug greift aber DROP, weil udp. Die anderen Ports werden als filtered bezeichnet, eben weil sie nur gedropped werden. Such mal in diese Richtung. Ich habe keine Lust, mich durch das SuSE-Geraffel durchzuquälen. :-b Auszug aus /sbin/SuSEfirewall2: # If port 113 (auth/identd) was not allowed above, outgoing mail # would # be delayed most of the time. Hence we put a hardcoded reject line # in. for CHAIN in input_ext input_dmz input_int; do $LDA $IPTABLES -A $CHAIN -j LOG ${LOG}"-REJECT " -p tcp --dport 113 --syn $IPTABLES -A $CHAIN -j "$REJECT" -p tcp --dport 113 --syn 2> /dev/null MfG Benn