# Nessus and Nmap running in Jail



## phips (Jan 25, 2016)

Hello community,

I want to run Nessus 6.5.4 under FreeBSD 10.2 RELEASE. It works like a charm, until I install it in a jail. If I start a scan it always fails because there are no targets available.
In the logfile I can see a message which says that the specified target is declined as "dead". So the host discovery doesn't seem to work right. Without host discovery turned on, the scans are working.

Nmap doesn't run in a jail, too. There is always an error saying that there is no route to target available.

I wanted to test it because in early versions, Nessus used Nmap for host discovery and other things. Maybe the same problem causes the two dysfunctions.

The Jails are built up by hand, extracting base.txz to a directory. The jails.conf looks like the following:

```
exec.clean;
exec.start += "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
mount.devfs;
allow.set_hostname = 0;
allow.raw_sockets = 0;

nessus {
  host.hostname = "nessus.example.com";
  path = "/usr/local/jails/nessus";
  interface="lo0";
  ip4.addr = "10.0.0.1/32";
  allow.raw_sockets = 1;
  exec.consolelog = "/var/log/jails/nessus_console.log";
}
```

In pf there is a NAT-rule for the jail. Traceroute, ping, fetch, and so on is working out of the jail.

Does anyone know how to get Nessus and/or Nmap running in a jail?
The only information I have found was a message in the mailing list but there was never an reply to it.
After searching in the forum I have found several answers about allow.raw_sockets and compiling nmap inside the jail (not installing it with pkg). But I have done both things before.



Greetings

Phips


----------



## kpa (Jan 25, 2016)

Those scans depend on broadcasts working on the network and with jails the broadcast address is interpreted to be the same as the IP adress itself making the jail IP the only address in the network visible from the jail.


----------



## asteriskRoss (Jan 25, 2016)

I suspect "Host discovery" uses an ICMP ping.  To allow a jail to create ICMP packets you need to configure the host to allow jails in general to use raw sockets in addition to configuring the specific jail to allow raw sockets (which you have already done).  On the host, as root, do this with `sysctl security.jail.allow_raw_sockets=1`.  To make the change persist after a reboot, add the following line to /etc/sysctl.conf:

```
security.jail.allow_raw_sockets=1
```


----------



## asteriskRoss (Jan 25, 2016)

I also just spotted this line in your jail configuration:

```
interface="lo0";
```
Unless you are only intending to target the host/other jails also attached to your loopback interface (lo0), you will need to include a real network interface (looking something like em0) in your jail's configuration.


----------



## phips (Jan 27, 2016)

kpa said:


> Those scans depend on broadcasts working on the network [...]



I don't scan a whole network, only a single IP. The host discovery also only runs against a single IP. I could see it in my pf-log.



asteriskRoss said:


> [...] To allow a jail to create ICMP packets you need to configure the host to allow jails in general to use raw sockets in addition to configuring the specific jail to allow raw sockets (which you have already done).  On the host, as root, do this with `sysctl security.jail.allow_raw_sockets=1`. [...] /etc/sysctl.conf:
> 
> ```
> security.jail.allow_raw_sockets=1
> ```



I have already done the changes.
ICMP pings are possible in the jail. I can successfully do `ping google.de`.



asteriskRoss said:


> [...] Unless you are only intending to target the host/other jails also attached to your loopback interface (lo0), you will need to include a real network interface (looking something like em0) in your jail's configuration.



The jail is bound to loopback interface with the IP 10.0.0.1. In pf there is a rule which NATs all the traffic from 10.0.0.1 to the internet. It works like a charm. I can do ping, traceroute, fetch websites, reach my external pkg repository and so on without problems. Only Nmap / Nessus don't work.


----------



## asteriskRoss (Jan 28, 2016)

Could it be that the packets Nmap and Nessus are generating are not surviving the transition across the firewall and NAT boundary?


----------



## phips (Jan 28, 2016)

In the logs I can see that the packet is sucessfully NATed...
How could I check this in an other way?

ICMP packets from Nmap/Nessus should be the same like my ping sends out. Or do I get it wrong?
(ping does work)


----------



## asteriskRoss (Jan 28, 2016)

phips said:


> ICMP packets from Nmap/Nessus should be the same like my ping sends out. Or do I get it wrong?
> (ping does work)


My thought is that if they were exactly the same, they would both work   Perhaps you could look for differences with tcpdump(1) or net/wireshark?


----------



## phips (Jan 28, 2016)

asteriskRoss said:


> My thought is that if they were exactly the same, they would both work   [...]



That is the thing I don't understand. 

I will try it!


----------



## asteriskRoss (Jan 28, 2016)

It looks like Nmap at least is not using just ICMP for host discovery.  I see in Nmap's fine manual:


> Because host discovery needs are so diverse, Nmap offers a wide variety of options for customizing the techniques used. Host discovery is sometimes called ping scan, but it goes well beyond the simple ICMP echo request packets associated with the ubiquitous ping tool. Users can skip the ping step entirely with a list scan (-sL) or by disabling ping (-Pn), or engage the network with arbitrary combinations of multi-port TCP SYN/ACK, UDP, SCTP INIT and ICMP probes.
> [...]
> If no host discovery options are given, Nmap sends an ICMP echo request, a TCP SYN packet to port 443, a TCP ACK packet to port 80, and an ICMP timestamp request. (For IPv6, the ICMP timestamp request is omitted because it is not part of ICMPv6.) [...] For unprivileged Unix shell users, the default probes are a SYN packet to ports 80 and 443 using the connect system call.


----------

