I tried SinFP today. It's a host fingerprinting tool by Patrice Auffret, owner of the cat. The SinFP feature I find interesting is its lack of using odd packets (a la Nmap) to discover remote operating systems.
I tried installing SinFP using CPAN on FreeBSD 6.0, but I got the following errors.
cpan> install Net::SinFP
CPAN: Storable loaded ok
LWP not available
Fetching with Net::FTP:
ftp://archive.progeny.com/CPAN/authors/01mailrc.txt.gz
Going to read /usr/local/cpan/sources/authors/01mailrc.txt.gz
LWP not available
Fetching with Net::FTP:
ftp://archive.progeny.com/CPAN/modules/02packages.details.txt.gz
Going to read /usr/local/cpan/sources/modules/02packages.details.txt.gz
Database was generated on Sun, 21 May 2006 09:26:33 GMT
HTTP::Date not available
There's a new CPAN.pm version (v1.87) available!
[Current version is v1.7602]
You might want to try
install Bundle::CPAN
reload cpan
without quitting the current session. It should be a seamless upgrade
while we are running...
LWP not available
...edited...
Running install for module Net::SinFP
Running make for G/GO/GOMOR/Net-SinFP-1.01.tar.gz
LWP not available
Fetching with Net::FTP:
ftp://archive.progeny.com/CPAN/authors/id/G/GO/GOMOR/Net-SinFP-1.01.tar.gz
CPAN: Digest::MD5 loaded ok
LWP not available
Fetching with Net::FTP:
ftp://archive.progeny.com/CPAN/authors/id/G/GO/GOMOR/CHECKSUMS
Checksum for /usr/local/cpan/sources/authors/id/G/GO/GOMOR/Net-SinFP-1.01.tar.gz ok
Scanning cache /usr/local/cpan/build for sizes
x Net-SinFP-1.01/
x Net-SinFP-1.01/lib/
x Net-SinFP-1.01/lib/Net/
x Net-SinFP-1.01/lib/Net/SinFP/
x Net-SinFP-1.01/lib/Net/SinFP/DB/
x Net-SinFP-1.01/lib/Net/SinFP/DB/SystemClass.pm
...edited...
t/01-use....Can't locate DBIx/SQLite/Simple.pm in @INC (@INC contains:
/usr/local/cpan/build/Net-SinFP-1.01/blib/lib /usr/local/cpan/build/Net-SinFP-1.01/blib/arch
/usr/local/lib/perl5/5.8.8/BSDPAN /usr/local/lib/perl5/site_perl/5.8.8/mach
/usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/5.8.8/mach /usr/local/lib/perl5/5.8.8 .) at
/usr/local/cpan/build/Net-SinFP-1.01/blib/lib/Net/SinFP.pm line 72.
Compilation failed in require at t/01-use.t line 4.
BEGIN failed--compilation aborted at t/01-use.t line 4.
t/01-use....dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/01-use.t 2 512 1 2 200.00% 1
Failed 1/1 test scripts, 0.00% okay. 1/1 subtests failed, 0.00% okay.
*** Error code 2
Stop in /usr/local/cpan/build/Net-SinFP-1.01.
/usr/bin/make test -- NOT OK
Running make install
make test had returned bad status, won't install without force
That's no good. Next I tried downloading the tar.gz archive, which did work.
orr:/usr/local/src# fetch http://umn.dl.sourceforge.net/sourceforge/sinfp/SinFP-1.01-6.tar.gz
SinFP-1.01-6.tar.gz 100% of 2524 kB 470 kBps
orr:/usr/local/src# tar -xzvf SinFP-1.01-6.tar.gz
x SinFP-1.01-6/
x SinFP-1.01-6/LICENSE
x SinFP-1.01-6/LICENSE.Artistic
x SinFP-1.01-6/Makefile
x SinFP-1.01-6/dbi/
x SinFP-1.01-6/dbi/DBI-1.50/
x SinFP-1.01-6/dbi/DBI-1.50/Changes
...edited...
orr:/usr/local/src# cd SinFP-1.01-6
orr:/usr/local/src/SinFP-1.01-6# make
cd dbi && GOMOR_PATH=/usr/local/sinfp perl Makefile.PL && make install
...edited...
Manifying ../blib/man3/Net::Write.3
Manifying ../blib/man3/Net::Write::Layer4.3
orr:/usr/local/src/SinFP-1.01-6# make install
cd dbd-sqlite && GOMOR_PATH=/usr/local/sinfp make install
...edited...
Installing /usr/local/sinfp/bin/sinfp.pl
Installing /usr/local/sinfp/bin/np-anon-pcap.pl
Writing /usr/local/sinfp/lib/auto/gomor/.packlist
FreeBSD: Registering installation in the package database
Appending installation info to /usr/local/lib/perl5/5.8.8/mach/perllocal.pod
if [ ! -d /usr/local/sinfp/bin ]; then mkdir /usr/local/sinfp/bin; fi
if [ ! -d /usr/local/sinfp/db ]; then mkdir /usr/local/sinfp/db ; fi
rm -rf /usr/local/sinfp/bin/*
cp gomor/Net-SinFP-*/sinfp.pl /usr/local/sinfp/bin/
cp gomor/Net-SinFP-*/np-anon-pcap.pl /usr/local/sinfp/bin/
cp gomor/Net-SinFP-*/sinfp.db /usr/local/sinfp/db/
That worked. Now I had a few new programs to try:
orr:/usr/local/src/SinFP-1.01-6# cd /usr/local/sinfp/bin/
orr:/usr/local/sinfp/bin# ls
np-anon-pcap.pl sinfp.pl
orr:/usr/local/sinfp/bin# ./sinfp.pl
-- SinFP - 1.01 --
Usage: sinfp.pl -i targetIp [-p openTcpPort] [-d device] [-f pcapFile]
[-I sourceIp] [-r retryNumber] [-t timeout] [-v]
[-m targetMac (for IPv6)] [-M sourceMac (for IPv6)]
[-s signatureFile]
[-4 | -6]
[-P] [-F filter]
[-H]
[-O]
-4: default, use IPv4 fingerprinting
-6: use IPv6 fingerprinting
-k: keep generated pcap file. Not by default.
-P: passive fingerprinting
-F: pcap filter for passive fingerprinting
-H: use HEURISTIC2 mode to match signatures
(mostly used as a human helper, or for passive OSFP)
-O: print only operating system
Let's try profiling a nearby Win XP SP2 box:
orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.3 -p 445
T1: B11111 F0x12 W16616 O0204ffff M1460
T2: B11111 F0x12 W17520 O0204ffff010303000101080a000000000000000001010402 M1460
T3: B11011 F0x04 W0 O0 M0
IPv4: EXACT/FULL: Windows: Microsoft: Windows: 2000 (2000 srv SP2)
IPv4: EXACT/FULL: Windows: Microsoft: Windows: XP (XP pro SP2)
Here is the traffic:
1. 16:04:36.260439 IP 192.168.2.5.52221 > 192.168.2.3.445: S 1284670681:1284670681(0) win 5840
2. 16:04:36.261074 IP 192.168.2.5.52221 > 192.168.2.3.445: S 1284670681:1284670681(0) win 5840
3. 16:04:36.261321 IP 192.168.2.3.445 > 192.168.2.5.52221: S 3314059019:3314059019(0) ack 1284670682
win 16616 mss 1460
4. 16:04:36.261385 IP 192.168.2.5.52221 > 192.168.2.3.445: R 1284670682:1284670682(0) win 0
5. 16:04:36.261439 IP 192.168.2.5.52222 > 192.168.2.3.445: S 1284670682:1284670682(0) win 5840
mss 1460,timestamp 1145389380 0,wscale 1,sackOK,eol
6. 16:04:36.261828 IP 192.168.2.5.52223 > 192.168.2.3.445: S 1284670683:1284670683(0) ack 1457354825
win 5840
7. 16:04:36.262164 IP 192.168.2.3.445 > 192.168.2.5.52221: S 3314059019:3314059019(0) ack 1284670682
win 16616 mss 1460
8. 16:04:36.262207 IP 192.168.2.5.52221 > 192.168.2.3.445: R 1284670682:1284670682(0) win 0
9. 16:04:36.262357 IP 192.168.2.5.52221 > 192.168.2.3.445: R 1284670682:1284670682(0) win 0
10. 16:04:36.269336 IP 192.168.2.5.52222 > 192.168.2.3.445: S 1284670682:1284670682(0) win 5840
mss 1460,timestamp 1145389380 0,wscale 1,sackOK,eol
11. 16:04:36.270075 IP 192.168.2.5.52223 > 192.168.2.3.445: S 1284670683:1284670683(0) ack 1457354825
win 5840
12. 16:04:36.275180 IP 192.168.2.3.445 > 192.168.2.5.52222: S 574001478:574001478(0) ack 1284670683
win 17520 mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK
13. 16:04:36.275252 IP 192.168.2.5.52222 > 192.168.2.3.445: R 1284670683:1284670683(0) win 0
14. 16:04:36.275759 IP 192.168.2.3.445 > 192.168.2.5.52222: S 574001478:574001478(0) ack 1284670683
win 17520 mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK
15. 16:04:36.275805 IP 192.168.2.5.52222 > 192.168.2.3.445: R 1284670683:1284670683(0) win 0
16. 16:04:36.275958 IP 192.168.2.3.445 > 192.168.2.5.52223: R 1457354825:1457354825(0) win 0
17. 16:04:36.276265 IP 192.168.2.3.445 > 192.168.2.5.52223: R 1457354825:1457354825(0) win 0
18. 16:04:36.276915 IP 192.168.2.5.52222 > 192.168.2.3.445: R 1284670683:1284670683(0) win 0
What strikes me about this traffic is the fact that it is not incredibly unusual. Sure, the pattern is not normal (there's no reason for the scanning host to send a SYN ACK packet), but the average sys admin is not going to detect this sort of reconnaissance. Here's the pattern.
- Scanner: SYN
- Scanner: SYN
- Target replies: SYN ACK
- Scanner tears down: RST
- Scanner: SYN with options
- Scanner: unsolicied SYN ACK
- Target replies to SYN: SYN ACK
- Scanner tears down: RST
- Scanner tears down: RST
- Scanner: SYN with options
- Scanner: unsolicied SYN ACK
- Target replies to SYN: SYN ACK
- Scanner tears down: RST
- Target replies to SYN: SYN ACK
- Scanner tears down: RST
- Target replies: RST
- Target replies: RST
- Scanner tears down: RST
Here are a few other runs. First, against
richard@janney:~$ uname -a
Linux janney 2.4.27-3-686-smp #1 SMP Wed Feb 8 12:27:28 UTC 2006 i686 GNU/Linux
Linux on i386:
orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.7 -p 22
T1: B10111 F0x12 W5840 O0204ffff M1460
T2: B10111 F0x12 W5792 O0204ffff0402080affffffff4445414401030300 M1460
T3: B11110 F0x04 W0 O0 M0
IPv4: EXACT/FULL: GNU/Linux: OSS: Linux: 2.6.x (2.6.3)
Next,
richard@thornton:~$ uname -a
Linux thornton 2.6.8-2-32-smp #1 SMP Wed Aug 24 17:55:41 UTC 2005 parisc GNU/Linux
Linux on PA-RISC:
orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.15 -p 22
T1: B10111 F0x12 W5840 O0204ffff M1460
T2: B10111 F0x12 W5792 O0204ffff0402080affffffff4445414401030300 M1460
T3: B11110 F0x04 W0 O0 M0
IPv4: EXACT/FULL: GNU/Linux: OSS: Linux: 2.6.x (2.6.3)
Next, against the earlier Windows box, to a closed port:
orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.3 -p 22
T1: B11001 F0x14 W0 O0 M0
T2: B11001 F0x14 W0 O0 M0
T3: B11011 F0x04 W0 O0 M0
IPv4: unknown
Against www.freebsd.org:
orr:/usr/local/sinfp/bin# ./sinfp.pl -i 216.136.204.117 -p 80
T1: B11111 F0x12 W57344 O0204ffff M1460
T2: B11111 F0x12 W57344 O0204ffff010303000101080affffffff44454144 M1460
T3: B00000 F0 W0 O0 M0
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.7
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.9
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.10
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.11 (4.11-RELEASE)
Against one of the www.microsoft.com IPs:
orr:/usr/local/sinfp/bin# ./sinfp.pl -i 207.46.198.30 -p 80
T1: B11011 F0x12 W16384 O0204ffff M1460
T2: B11011 F0x12 W16384 O0204ffff010303000101080a000000000000000001010402 M1460
T3: B00000 F0 W0 O0 M0
IPv4: EXACT/FIREWALLED: Windows: Microsoft: Windows: 2000
IPv4: EXACT/FIREWALLED: Windows: Microsoft: Windows: 2003 (2003 SP1)
Give SinFP a try and let me know what you think as a comment here.
Incidentally, I am definitely not a "cat person." I am a dog person.
0 komentar:
Posting Komentar