NMAP 6.00
-
Those are not fatal errors. Does it function or not once installed?
-
isn't 6.01 out?
http://www.freshports.org/security/nmap24 Jun 2012 15:54:18
6.01I just tried installing the package on my 2.1
2.1-BETA0 (i386)
built on Fri Jun 22 21:43:34 EDT 2012
FreeBSD 8.3-RELEASE-p3And it didn't seem to be working, I have not gitsync'd in a few days - so don't have the pbi commits I see.
command worked – no errors or not finding command, etc. But I tried from cmd line as well - but quick scan
[2.1-BETA0][root@pfsense.local.lan]/root(2): nmap -T4 -F 192.168.1.100
Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-26 00:06 CDT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.52 secondsSays device blocking pings – but clearly it pings.
[2.1-BETA0][root@pfsense.local.lan]/root(3): ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100): 56 data bytes
64 bytes from 192.168.1.100: icmp_seq=0 ttl=128 time=1.058 ms
64 bytes from 192.168.1.100: icmp_seq=1 ttl=128 time=0.567 ms -
Yes, 6.01 is out and I see that FreeBSD updated the port, but I haven't rebuilt the packcage/pbi yet, not sure when I will.
If I tell it to do a ping scan it says it's up for me. Not sure why it would be failing for you. It worked on both IPv4 and IPv6.
-
wondering how it picks interface? You would think it would hit the interface that connected to that network right??
But I do have 2 down vmxnet3 interfaces on my vm. Or wonder if could just be a VM thing? Will play with it more later. I think there was something in 6.0 about picking the wrong interface if in monitor mode? But I don't have any wireless interfaces?
-
Just noticed the nmap pkg commits at git and thought I'd offer a very quick note that the nmap versions I've used in the past can offer a root shell (since nmap runs as superuser).
id
uid=100(myuser) gid=101(myuser)
sudo nmap –interactiveStarting Nmap V. 4.11 ( http://www.insecure.org/nmap/ )
Welcome to Interactive Mode -- press h for help
nmap> !sh
id
uid=0(root) gid=0(root) groups=0(root) -
Ok something to do with raw socket access… Works if use --unprivileged flag
[2.1-BETA0][admin@pfsense.local.lan]/root(13): nmap 192.168.1.100 –unprivileged
Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-26 11:32 CDT
Nmap scan report for i5-w7.local.lan (192.168.1.100)
Host is up (0.00063s latency).
Not shown: 987 closed ports
PORT STATE SERVICE
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
1025/tcp open NFS-or-IIS
1026/tcp open LSA-or-nterm
1027/tcp open IIS
1028/tcp open unknown
1031/tcp open iad2
1033/tcp open netinfo
1037/tcp open ams
3389/tcp open ms-wbt-serverNmap done: 1 IP address (1 host up) scanned in 1.39 seconds
[2.1-BETA0][admin@pfsense.local.lan]/root(14): nmap 192.168.1.100
Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-26 11:32 CDT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.52 secondsBut shouldn't root have access?
[2.1-BETA0][admin@pfsense.local.lan]/root(15): whoami
rootedit: So do we have to change this setting to allow it to use raw
security.jail.allow_raw_sockets: 0 -
Ok this makes no sense, so if I do nmap –iflist, this is listed under routes
ROUTES
DST/MASK DEV GATEWAY
10.0.200.1/32 em1
10.0.200.2/32 em1
24.13.178.xx/32 em1
127.0.0.1/32 em1
192.168.1.253/32 em1
216.66.77.230/32 em1 24.13.176.1
10.0.200.0/24 em1 10.0.200.2
192.168.1.0/24 em1
24.13.176.0/21 em1
0.0.0.0/0 em1 24.13.176.1
fe80
:250:56ff:fe00:2/128 em0
::1/128 em0 ::1
fe80
:250:56ff:fe00:2/128 em0
2001:470:xx:xx::2/128 em0
fe80:6::1/128 em0
2001:470:xx:xx::1/128 em0
fe80:2::250:56ff:fe00:1/128 em0
fe80:1::250:56ff:fe00:2/128 em0
fe80:2::/32 em0What the hell?? em1 is my WAN interface!!
so if I run nmap -e em0 it works just fine or if I run nmap –unprivileged it works.
Where is it getting that info from? It show both my wan and lan on em1
but clearly that is not the case
netstat -rn
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 24.13.176.1 UGS 0 26406 em1
10.0.200.0/24 10.0.200.2 UGS 0 2902 ovpns1
10.0.200.1 link#11 UHS 0 0 lo0
10.0.200.2 link#11 UH 0 0 ovpns1
24.13.176.0/21 link#2 U 0 3778 em1
24.13.178.xx link#2 UHS 0 0 lo0
75.75.75.75 00:50:56:00:00:01 UHS 0 341 em1
75.75.76.76 00:50:56:00:00:01 UHS 0 341 em1
127.0.0.1 link#6 UH 0 119 lo0
192.168.1.0/24 link#1 U 0 35537 em0
192.168.1.253 link#1 UHS 0 0 lo0
216.66.77.230 24.13.176.1 UGHS 0 4711 em1WTF??
This part of nmap –iflist looks right
Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-26 14:14 CDT
INTERFACES
DEV (SHORT) IP/MASK TYPE UP MTU MAC
em0 (em0) 192.168.1.253/24 ethernet up 1500 00:50:56:00:00:02
em1 (em1) 24.13.178.xx/21 ethernet up 1500 00:50:56:00:00:01Why are the routes messed up for nmap?
edit: yeah this is clearly wrong!
nmap --route-dst 192.168.1.100
192.168.1.100
em1 em1 srcaddr 192.168.1.253 directwtf??
-
I have a vague recollection of hitting that on an older version of nmap (See here: http://forum.pfsense.org/index.php/topic,46058.msg242952.html#msg242952 ) - I'm not sure if it's an nmap issue entirely, or just on FreeBSD, or what.
I've always had better luck manually specifying the interface to use. If I get some time I'll add an interface drop-down (or perhaps source IP+Interface) to that, and to MTR while I'm at it since the code would be essentially identical.
Not sure if nmap 6.01 might help there, but the builders are tied up right now so I can't run off a new build just yet to find out. I doubt it'll help since it's been an issue on there for quite a while.
-
so I think it might be related to this
http://seclists.org/nmap-dev/2012/q2/920yeah a drop down on the gui to set interface would be helpful to work around the problem for sure.
From command line, knowing that its a bug can just always use -e flag, so not something that can not be worked through until they get it worked out. But very very strange! ;)
-
Just noticed the nmap pkg commits at git and thought I'd offer a very quick note that the nmap versions I've used in the past can offer a root shell (since nmap runs as superuser).
Not sure how that would matter. We pretty much consider all users as root anyhow, since the GUI has to run that way. Plus you can't exactly get an interactive shell from the GUI in PHP, and nmap isn't suid so if you had a normal user run it, they couldn't get a root shell anyhow.
Is there some way I'm not thinking of that is relevant there?
-
Bumped nmap to 6.01 today, and added an interface selector field to the GUI.
Also added an 'arp' scan type. Feed it a directly connected subnet, pick the corresponding interface, and it'll find anything in your subnet that will respond to arp.
I also added some input validation but that won't work quite right until a new 2.1 snap rolls out.
-
Bumped the package - and yup now with ability to pick interface the gui works!
