Target - 9.0-RELEASE FreeBSD 9.0-RELEASE #0: amd64
When you are performing NPT using FreeBSD, you might encounter the something similar that I am discussing below
1. FreeBSD fails to provide routing information. Commands such as "netstat -r" | "netstat -rn" fails.
john# netstat -r
netstat: kvm not available: /dev/mem: No such file or directory
Routing tables
rt_tables: symbol not in namelist
john# netstat -rn
netstat: kvm not available: /dev/mem: No such file or directory
Routing tables
rt_tables: symbol not in namelist
2. Traceroute command works perfectly fine and provides desired results.
john# traceroute google.com
traceroute: Warning: google.com has multiple addresses; using 74.125.224.226
traceroute to google.com (74.125.224.226), 64 hops max, 52 byte packets
1 206.125.172.17 (206.125.172.17) 2.733 ms 0.958 ms 0.864 ms
2 ge0-15.as01.lax07.mzima.net (67.199.135.101) 5.611 ms 0.684 ms 1.295 ms
3 google.com.any2ix.coresite.com (206.223.143.41) 0.728 ms 0.702 ms 0.652 m
4 72.14.234.47 (72.14.234.47) 0.716 ms
64.233.174.41 (64.233.174.41) 0.747 ms 0.774 ms
5 216.239.43.76 (216.239.43.76) 0.976 ms 1.042 ms 0.959 ms
6 lax04s08-in-f2.1e100.net (74.125.224.226) 0.745 ms 0.652 ms 0.726 ms
3. Dig works fine and DNS names are resolved.
john# dig google.com +nocmd +short
74.125.224.232
74.125.224.224
74.125.224.226
74.125.224.228
74.125.224.238
74.125.224.231
74.125.224.227
74.125.224.229
74.125.224.230
74.125.224.225
74.125.224.233
3. Nmap does not trigger several set of scans on FreeBSD due to jails implementation. Primarily, in
my case Syn scan fails.
The overall problem is present in the support for raw sockets in FreeBSD when jails are implemented. By default, the support for raw sockets is not provided in jails because of security issues. The configuration parameter "security.jail.allow_raw_sockets" in sysctl.conf is the controlling agent. If the value is changed to "1", the raw sockets support is allowed.
I encountered errors related to "devfs" system. The jails, from where I was executing the scans did not support /dev/mem or /dev/kmem. Typically, I found that jail failed to find kvm. The solution is to provide access to critical sections of the memory to that specific jail. This can be done by making modifications in "/etc/devfs.rules". It means inside the jail, the user can access the all the sections of memory ( bypassing jail restrictions). Being an administrator, no body prefers to do that as it is not a best practice to grant users the root level access to control all sections of memory. This kind of scenarios lead to some management issues though for administrators.
Now the question is, if certain set of Nmap scans wont work what to do. No doubt, running scans in jail environment restricts some of the features of Nmap but we can still use (-sT) TCP connect scan to initiate scanning. Though it is time consuming as it is full three way handshake as compared to (-sS) which is two way but it works without any hassles. You have to make the (-sT) scan minimal which means even this scan does not work with other options in Nmap. You have to run it more simple way as discussed in some examples below.
john# nmap -Pn -vv -n -sT -O -A xxx.xxx.xxx.xxx -oA
first_subnet
Starting Nmap 6.00 ( http://nmap.org
) at 2012-06-01 21:53 UTC
NSE: Loaded 93 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
NSE: Starting runlevel 2 (of 2) scan.
nexthost: failed to determine route to xxx.xxx.xxx.xxx
QUITTING!
john# nmap -Pn -vv -n -sT -O -A xxx.xxx.xxx.xxx
Starting Nmap 6.00 ( http://nmap.org
) at 2012-06-01 21:53 UTC
NSE: Loaded 93 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
NSE: Starting runlevel 2 (of 2) scan.
nexthost: failed to determine route to xxx.xxx.xxx.xxx
QUITTING!
So what works in this case is as follows
john# nmap -Pn -sT -sV google.com -p 80
Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-04 00:23 UTC
Nmap scan report for google.com (74.125.224.229)
Host is up (0.00080s latency).
Other addresses for google.com (not scanned): 74.125.224.228 74.125.224.232 74.125.224.231 74.125.224.233 74.125.224.230 74.125.224.224 74.125.224.238 74.125.224.227
74.125.224.225 74.125.224.226
rDNS record for 74.125.224.229: lax04s08-in-f5.1e100.net
PORT STATE SERVICE VERSION
80/tcp open http Google httpd 2.0 (GFE)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
So the point to be considered while doing penetration testing is to take care for these situations. Even though there is restricted environment but we can still achieve what we want.
Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-04 00:23 UTC
Nmap scan report for google.com (74.125.224.229)
Host is up (0.00080s latency).
Other addresses for google.com (not scanned): 74.125.224.228 74.125.224.232 74.125.224.231 74.125.224.233 74.125.224.230 74.125.224.224 74.125.224.238 74.125.224.227
74.125.224.225 74.125.224.226
rDNS record for 74.125.224.229: lax04s08-in-f5.1e100.net
PORT STATE SERVICE VERSION
80/tcp open http Google httpd 2.0 (GFE)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
So the point to be considered while doing penetration testing is to take care for these situations. Even though there is restricted environment but we can still achieve what we want.
Hope it helps.
