Comme la plupart des systèmes d'exploitation, un système FreeBSD peut être identifié par son "empreinte réseau", c'est-à-dire le comportement de sa pile TCP/IP sur réception de paquets atypiques.
Ce paper propose des solutions pour empecher cette detection.
Système FreeBSD contre Nmap (1/2)
Le problème
Comme la plupart des systèmes d'exploitation, un système FreeBSD peut être
identifié par son "empreinte réseau", c'est-à-dire le comportement de sa pile
TCP/IP sur réception de paquets atypiques.
Si l'on prend l'exemple d'un système FreeBSD 4.6-RELEASE (fonctionnant sous
noyau GENERIC, avec une installation de base et application des rustines de
sécurité jusqu'à SA-02:38), on observe déjà plusieurs services réseau actifs
par défaut :
# netstat -a -f inet
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 *.submission *.* LISTEN
tcp4 0 0 *.smtp *.* LISTEN
tcp4 0 0 *.ssh *.* LISTEN
tcp46 0 0 *.ssh *.* LISTEN
udp4 0 0 *.syslog *.*
# sockstat -l4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sendmail 89 3 tcp4 *:25 *:*
root sendmail 89 5 tcp4 *:587 *:*
root sshd 84 4 tcp4 *:22 *:*
root syslogd 73 5 udp4 *:514 *:*
Une application telle que nmap n'a aucune difficulté à identifier un tel
système :
# nmap -sS -PT -PI -O -vv -T 3 machine_cible
Starting nmap V. 3.00 ( www.insecure.org/nmap )
Host (machine_cible) appears to be up ... good.
Initiating SYN Stealth Scan against (machine_cible)
Adding open port 587/tcp
Adding open port 22/tcp
Adding open port 25/tcp
The SYN Stealth Scan took 8 seconds to scan 1601 ports.
For OSScan assuming that port 22 is open and port 1 is closed and neither are
firewalled
Interesting ports on (machine_cible):
(The 1598 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
587/tcp open submission
Remote operating system guess: FreeBSD 4.6-RELEASE or -STABLE (July 2002) (X86)
OS Fingerprint:
TSeq(Class=TR%IPID=I%TS=100HZ)
T1(Resp=Y%DF=N%W=E000%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=N)
T3(Resp=Y%DF=N%W=E000%ACK=S++%Flags=AS%Ops=MNWNNT)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=0%ULEN=134%DAT=E)
Uptime 0.011 days (since Tue Aug 20 11:29:41 2002)
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
TCP ISN Seq. Numbers: 5FE43222 E67FA720 960B9F23 7AC6EF2F E55EFFA8 A9776596
IPID Sequence Generation: Incremental
Nmap run completed -- 1 IP address (1 host up) scanned in 18 seconds
...même si cela laisse quelques traces sur la console, du type :
Limiting closed port RST response from XXX to 200 packets per second
Les solutions
L'identification du système peut-être empêchée de plusieurs façons, mais
aucune de celles traditionnellement proposées n'est totalement satisfaisante.
La première solution passe par le recours à une option du noyau absente de la
configuration par défaut et aurait l'inconvénient de rompre certaines
fonctionnalités d'applications réseau (quoique personnellement je n'aie jamais
identifié de problème provoqué par cette option) :
# more /sys/i386/conf/LINT
# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This
# prevents nmap et al. from identifying the TCP/IP stack, but breaks support
# for RFC1644 extensions and is not recommended for web servers.
# man rc.conf
tcp_drop_synfin
(bool) Set to "NO" by default. Setting to YES will cause
the kernel to ignore TCP frames that have both the SYN and
FIN flags set. This prevents OS fingerprinting, but may
break some legitimate applications. This option is only
available if the kernel was built with the TCP_DROP_SYNFIN
option.
Concrètement cela se met en place de la façon suivante :
# cd /sys/i386/conf
# cp GENERIC GENERIC2
# echo "options TCP_DROP_SYNFIN" >> GENERIC2
# config GENERIC2
# cd ../../compile/GENERIC2
# make depend
# make
# cp kernel /
# echo 'tcp_drop_synfin="YES"' >> /etc/rc.conf
# reboot
Et cette fois, effectivement, nmap ne parvient pas à identifier le système :
# nmap -sS -PT -PI -O -vv -T 3 machine_cible
Starting nmap V. 3.00 ( www.insecure.org/nmap )
Host (machine_cible) appears to be up ... good.
Initiating SYN Stealth Scan against (machine_cible)
Adding open port 22/tcp
Adding open port 25/tcp
Adding open port 587/tcp
The SYN Stealth Scan took 8 seconds to scan 1601 ports.
For OSScan assuming that port 22 is open and port 1 is closed and neither are
firewalled
For OSScan assuming that port 22 is open and port 1 is closed and neither are
firewalled
For OSScan assuming that port 22 is open and port 1 is closed and neither are
firewalled
Interesting ports on (machine_cible):
(The 1598 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
587/tcp open submission
No exact OS matches for host (If you know what OS is running on it,
see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.00%P=i686-pc-windows-windows%D=8/20%Time=3D621986%O=22%C=1)
TSeq(Class=TR%IPID=I%TS=100HZ)
T1(Resp=Y%DF=N%W=E000%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=N)
T3(Resp=N)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=0%ULEN=134%DAT=E)
Uptime 0.006 days (since Tue Aug 20 12:19:18 2002)
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
TCP ISN Seq. Numbers: 4BCA9A2F 54EDB2A 17DFF624 1F257A1 EB062221 7DCEA324
IPID Sequence Generation: Incremental
Nmap run completed -- 1 IP address (1 host up) scanned in 28 seconds
Enfin, a priori seulement, puisqu'une option non documentée de nmap permet
d'obtenir une estimation avec un fort degré de confiance (97% !), ce qui
limite fortement l'intérêt de cette option TCP_DROP_SYNFIN :
# nmap -sS -PT -PI -O --osscan_guess -vv -T 3 machine_cible
Starting nmap V. 3.00 ( www.insecure.org/nmap )
Host (machine_cible) appears to be up ... good.
Initiating SYN Stealth Scan against (machine_cible)
Adding open port 587/tcp
Adding open port 25/tcp
Adding open port 22/tcp
The SYN Stealth Scan took 11 seconds to scan 1601 ports.
For OSScan assuming that port 22 is open and port 1 is closed and neither are
firewalled
For OSScan assuming that port 22 is open and port 1 is closed and neither are
firewalled
For OSScan assuming that port 22 is open and port 1 is closed and neither are
firewalled
Interesting ports on (machine_cible):
(The 1598 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
587/tcp open submission
Aggressive OS guesses: FreeBSD 4.6-RELEASE or -STABLE (July 2002) (X86) (97%),
FreeBSD 4.5-RELEASE (or -STABLE) (X86) (94%), FreeBSD 4.6 (94%), AIX v4.2
(94%),
FreeBSD 4.3 - 4.4PRERELEASE (92%), IBM AIX v3.2.5 - 4 (91%),
FreeBSD 4.4 for i386 (IA-32) (91%), Linux 1.3.20 (X86) (91%)
No exact OS matches for host (If you know what OS is running on it,
see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.00%P=i686-pc-windows-windows%D=11/12%Time=3DD16827%O=22%C=1)
TSeq(Class=TR%IPID=I%TS=100HZ)
T1(Resp=Y%DF=N%W=E000%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=N)
T3(Resp=N)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=0%ULEN=134%DAT=E)
Uptime 0.001 days (since Tue Nov 12 21:42:51 2002)
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
TCP ISN Seq. Numbers: 447C2AD9 F9E5955A BABCB5A4 533E7E23 8399C3AF 4AE172A4
IPID Sequence Generation: Incremental
Nmap run completed -- 1 IP address (1 host up) scanned in 34 seconds
Une deuxième solution passe par la fermeture de tous les ports... ce qui,
excepté pour un pare-feu ou une station de travail, est un peu le comble pour
un système d'exploitation réseau tel que FreeBSD !
Le test est cependant assez simple à réaliser :
# killall inetd
# killall sshd
# killall sendmail
# killall syslogd
# sockstat -l4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
# nmap -sS -PT -PI -n -O -vv -T 3 machine_cible
Starting nmap V. 3.00 ( www.insecure.org/nmap )
Host (machine_cible) appears to be up ... good.
Initiating SYN Stealth Scan against (machine_cible)
The SYN Stealth Scan took 9 seconds to scan 1601 ports.
Warning: OS detection will be MUCH less reliable because we did not find
at least 1 open and 1 closed TCP port
All 1601 scanned ports on (machine_cible) are: closed
Too many fingerprints match this host for me to give an accurate OS guess
TCP/IP fingerprint:
SInfo(V=3.00%P=i686-pc-windows-windows%D=8/20%Time=3D62110A%O=-1%C=1)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=0%ULEN=134%DAT=E)
Nmap run completed -- 1 IP address (1 host up) scanned in 22 seconds
Au delà de ces premières solutions, il est également possible de contrer les
applications telles que Nmap, en filtrant les paquets atypiques qu'elles
emploient avec des pare-feu (tels qu'IPFW ou IP Filter), ou bien en les
perturbant avec des systèmes de détection d'intrusions (tels que Snort) ou des
applications spécifiques (telles que BSD FingerPrint***** ou Antimap).
Ces solutions "avancées" sont abordées dans la suite de cette article.
Quelques notes complémentaires
Malgré ce que l'on entend parfois, la fonctionnalité de "blackhole" n'empêche
pas l'identification du système :
# sysctl net.inet.tcp.blackhole=2
net.inet.tcp.blackhole: 0 -> 2
# sysctl net.inet.udp.blackhole=1
net.inet.udp.blackhole: 0 -> 1
# nmap -sS -PT -PI -n -O -vv -T 3 machine_cible
Starting nmap V. 3.00 ( www.insecure.org/nmap )
Host (machine_cible) appears to be up ... good.
Initiating SYN Stealth Scan against (machine_cible)
Adding open port 587/tcp
Adding open port 25/tcp
Adding open port 22/tcp
The SYN Stealth Scan took 283 seconds to scan 1601 ports.
Warning: OS detection will be MUCH less reliable because we did not find
at least 1 open and 1 closed TCP port
For OSScan assuming that port 22 is open and port 36269 is closed and neither
are firewalled
Interesting ports on (machine_cible):
(The 1598 ports scanned but not shown below are in state: filtered)
Port State Service
22/tcp open ssh
25/tcp open smtp
587/tcp open submission
Remote operating system guess: FreeBSD 4.6-RELEASE or -STABLE (July 2002) (X86)
OS Fingerprint:
TSeq(Class=TR%IPID=I%TS=100HZ)
T1(Resp=Y%DF=N%W=E000%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=N)
T3(Resp=Y%DF=N%W=E000%ACK=S++%Flags=AS%Ops=MNWNNT)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=N)
T6(Resp=N)
T7(Resp=N)
PU(Resp=N)
Uptime 0.005 days (since Tue Aug 20 11:53:06 2002)
TCP Sequence Prediction: Class=truly random
Difficulty=99
99999 (Good luck!)
TCP ISN Seq. Numbers: ACDEC804 4DF36401 D230BF81 32ED5104 DFB258BB 6DD033F
IPID Sequence Generation: Incremental
Nmap run completed -- 1 IP address (1 host up) scanned in 307 seconds
Elle ralentit cependant le balayage de ports d'un facteur 15 ou 16, comme
l'indique très justement le manuel :
BLACKHOLE(4) FreeBSD Kernel Interfaces Manual BLACKHOLE(4)
NAME
blackhole - a sysctl(8) MIB for manipulating behaviour in respect of
refused TCP or UDP connection attempts
[...]
DESCRIPTION
The blackhole sysctl(8) MIB is used to control system behaviour when con-
nection requests are received on TCP or UDP ports where there is no
socket listening.
Normal behaviour, when a TCP SYN segment is received on a port where
there is no socket accepting connections, is for the system to return a
RST segment, and drop the connection. The connecting system will see
this as a "Connection reset by peer". By setting the TCP blackhole MIB
to a numeric value of one, the incoming SYN segment is merely dropped,
and no RST is sent, making the system appear as a blackhole. By setting
the MIB value to two, any segment arriving on a closed port is dropped
without returning a RST. This provides some degree of protection against
stealth port scans.
In the UDP instance, enabling blackhole behaviour turns off the sending
of an ICMP port unreachable message in response to a UDP datagram which
arrives on a port where there is no socket listening.
[...]
The blackhole behaviour is useful to slow down anyone who is port scan-
ning a system, attempting to detect vulnerable services on a system.
|
