Ubuntu, Nessus authenticated scans.

With Heartbleed being reported literately everywhere now is a good time to start checking your home network for vulnerabilities beyond just heartbleed.

You can use the same tools as the pro's at home thanks to Tenable Home edition of Nessus with a generous 16 IP licence that should cover most home networks!

I have been using Nessus for over 10 years, I use it a lot in my job and now I can bring that good practice to my home network too.

The install process is quick and simple so much so I am not going to write down how to do it but assume you can mange it on your own :-).

Go here, http://www.tenable.com/products/nessus-home signup get an activation code, download and install the relevant version for your OS.

If you managed to follow the on screen instructions then you will be able to login to the rich html5 Nessus server started on your PC.

Once up and running clearly you are going to scan your network looking for vulnerabilities. BUT I cannot stress this enough, the best way to get the most value out of Nessus is to use authenticated scans.

This means Nessus is able to login to the hosts its scanning to test and audit thoroughly. Below is how to set this up when the Nessus server and the target of the scan are both running linux.

We will use ssh authentication with certificates so there is no password and this is how I did it.

On the Nessus server.

sudo ssh-keygen -t dsa

This will create a public and private key pair, the public key will be copied to each remote linux machine you want to scan. The private key remains on the server and should be kept secure.

Next we need to create a user for nessus on the remote linux machine

sudo useradd -d /home/nessus -m nessus

Now because we are authenticating using certificates this account should not be given a password and the account should be locked.

As a password has not been set, it should be locked by default, but check the status of the account.

As root (sudo su)

passwd –S nessus

So the account can run as root add the nessus user to sudoers

sudo adduser nessus sudo

Now make a location for the public key

cd /home/nessus

mkdir .ssh

From the Nessus server copy the public key to the remote machine, this is a little annoying, as the location you need to place the public key in you don't have permission to write too. A work around is to copy it to a location to can write to then move it.

sudo scp /root/.ssh/id_dsa.pub bob@192.168.1.111:/home/bob

Now on the remote linux server we need to move, rename and change the permission on the public key.

sudo cp /home/bob/id_dsa.pub /home/nessus/.ssh/authorized_keys

chown -R nessus:nessus /home/nessus/.ssh/

chmod 0600 /home/nessus/.ssh/authorized_keys

chmod 0700 /home/nessus/.ssh/

Now check your work. From the Nessus server we are going to run the id command over an ssh session. The first part of the command is referencing the private key you created earlier.

ssh -i /root/.ssh/id_dsa nessus@192.168.1.111 id

All being well you should get back something like

uid=1001(nessus) gid=1001(nessus) groups=1001(nessus)

The first time I did this it failed as I was not referencing the correct private key.

Assuming this worked you can now create an Authenticated scan within Nessus.

More information on how to setup authenticated scans for other OS's can of course be found on the Tenable site.

http://static.tenable.com/documentation/nessus_credential_checks.pdf

Ubuntu 12.04.2 LTS Interface bonding (802.3ad / LACP) with vlan tagging (802.1q)

Ubuntu 12.04.2 LTS Interface bonding (802.3ad) with vlan tagging (802.1q)

I just had a little wrestle to get this working on 12.04.2 so thought I would write it down quick!

Not sure why but the interface configuration changed between earlier versions of Ubuntu and 12.04.2 LTS.

I followed this guide to get bonding working. My switches support 802.1q / LACP make .  I must admit to already having vlan tagged interface and I cannot remember all of the steps, but my interface config works.

https://help.ubuntu.com/community/UbuntuBonding

Before you start think about how you are connecting to this server. Are you changing an Interface that you are using to connect to the server? Do you have a backup plan to control it if your config does not work first time?


Install the bonding package. (I am using aptitude, if you use apt-get use that instead ;-)

sudo aptitude install ifenslave

Install the vlan package.

sudo aptitude install vlan

Add the modules bonding and 8021q so they are loaded by the kernel.

nano /etc/modules

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

loop
lp
rtc
bonding
8021q

Edit the interface config.

sudo nano -w /etc/network/interfaces

Example config.

# Create a bond0 interface that binds eth1 and eth3 together.
auto eth1
        iface eth1 inet manual
bond-master bond0

auto eth3
        iface eth3 inet manual
bond-master bond0

# Next configure bond0 interface, I had to set an IP, I would prefer to use null..

UPDATE: if you don't want to set an IP address then instead of "iface bond0 inet static" make it "iface bon0 inet manual". Thanks to Sean for the tip.
 
# NB the bond-mode, try bond-mode 0 if LACP fails.

auto bond0
        iface bond0 inet static
        address 1.1.1.1
        netmask 255.255.255.252
        bond-slaves none
        bond-miimon 100
bond-mode 802.3ad


If you need more bonding modes have a look at this it might help.
https://www.kernel.org/doc/Documentation/networking/bonding.txt

# Next create as many vlan tagged Interfaces as you need!

auto bond0.140
        iface bond0.140 inet static
        address 10.10.140.10
        netmask 255.255.255.0
        broadcast 10.10.140.255
        gateway 10.10.140.1
        dns-nameservers 8.8.8.8
        dns-search w00t.local
vlan-raw-device bond0

auto bond0.10
        iface bond0.10 inet static
        address 10.10.10.10
        netmask 255.255.255.0
        broadcast 10.10.10.255
vlan-raw-device bond0

auto bond0.180
        iface bond0.180 inet static
        address 10.10.180.10
        netmask 255.255.255.0
        broadcast 10.10.10.255
vlan-raw-device bond0

Save the changes and reboot your server. You can restart the networking service if you prefer.
Now when you issue the ifconfig command you will see bond0 and bond0.vlanx interface.


Additional useful commands.

Check your bonded interfaces are working as expected, this will also show the LACP actor and partner keys.

cat /proc/net/bonding/bond0

Hope this helps someone.

Checkpoint VE R71 Failed to Load Security Policy: No such file or directory

I use Checkpoint VE R71 clusters on ESXi to host bespoke cloud solutions for a number of customers. 

This week I had an irritating problem where after a reboot of the passive firewall it was unable to fetch a policy from the management server.

No amount of cpstop/cpstarts, manual fetches and reboots helped.

The error message was as follows.

fw fetch 10.10.10.10

Fetching Security Policy From: 10.10.10.10

Installing Security Policy vfw1 on all.all@ vfw1

 Failed to Load Security Policy: No such file or directory

 Failed to Load Security Policy: No such file or directory

 Fetching Security Policy Failed

The firewall was able to ping its ESX host, the virtual centre server and the firewall management station..

The solution in the end was to run sysconfg and take the “Configure vSphere connection settings” option. Then run through the establishing the connection to the Virtual Centre server again. 

Once this was done, fetching a policy worked.

I am assuming somehow the firewall was unable to authenticate itself to the virtual centre server by losing the cached copy of the certificate?

No one I have spoken to is sure why when operating in “network mode” not “hypervisor mode” the firewall needs to talk to the virtual centre server at all. If I had to guess I would say it need this for licensing..

Anyway, hope this helps someone.

Mat.

SNMPTRAPS

 I spent a lot of time getting this working, SNMPTRAPS are hard work.

There are plenty of guides on installing and configuring SNMPTRAPS, however I seem to have run into several pit falls so thought I would put them here in case it helps someone. 

It’s more of a list of things to check..

I installed Ubuntu snmpd version: 5.4.3~dfsg-2.5ubuntu1

Commands that help to test things are working.

To display the path being searched for MIBS, this is created via the export option.

Sudo net-snmp-config --default-mibdirs

Test OID translation is working? If it is you will get sysUptime.0 as output.

Sudo snmptranslate .1.3.6.1.2.1.1.3.0

SNMPv2-MIB::sysUpTime.0

Does the reverse translation work? 

Sudo snmptranslate –On SNMPv2-MIB::sysUpTime.0

.1.3.6.1.2.1.1.3.0

Do you have any MIBS?

MIBS do not come with the install! There is another package that will fetch the MIBs for you. This is because of copyright issues apparently.

Search for anything with MIB in its name.

sudo find * / |grep MIB

Else install snmp-mibs-downloader (I installed version 1.1)

sudo aptitude install snmp-mibs-downloader

Then download the MIBS

download-mibs

I found I still had missing MIBs so had to Google for them and download them. Ensure if you do this that the file name does not have an extension .txt or whatever, else it will be ignored. Also check the first line of the MIB to confirm it is indeed a MIB..

sudo head nameofmib

It should have something like DEFINITIONS ::= BEGIN as its first line.

Now because I spent a lot of time and made many config changes install / reinstall to get it working I gave up trying to get multiple mibdirs working. I decided instead to move all mibs to the first search location /root/.snmp/mibs.

Config files and starting and stopping the service.

Snmptrapd is started and stopped by snmpd,

Service snmpd start / Service snmpd stop

There are two config files you will also need to visit, this is the contents of mine.

cat /etc/snmp/snmptrapd.conf

# Run trap.

TRAPDRUN=yes

# Disable authorisation, it’s on by default, though if you have time you should use this!

disableAuthorization yes

# the IP address you want the trap to run on ( will use port udp 162)

snmpTrapdAddr 192.168.192.168

# Output to the following file.

logOption f /var/log/snmptrap.log

# You will not need the following line unless you are using JFFNMS (Just For Fun Network Monitoring System)

traphandle default /usr/share/jffnms/engine/trap_receiver.sh

cat /etc/default/snmpd

# Make sure this works, some guides say to use export MIBS, some export MIBDIRS, if you have

 # more than one location, you can add a second location using a : as a separator.

# export MIBS=/root/.snmp/mibs <- did not work for me!

export MIBDIRS=/root/.snmp/mibs

# SNMP Bit.

# snmpd control (yes means start daemon).

SNMPDRUN=yes

SNMPDOPTS='-LS6d -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -c /etc/snmp/snmpd.conf'

#SNMPTRAP bit

# snmpd control (yes means start daemon).

TRAPDRUN=yes

TRAPDOPTS='-Lsd -m ALL -p /var/run/snmptrapd.pid -c /etc/snmp/snmptrapd.conf 172.18.100.7'

# Note the –m ALL load all MIBS, if your location export works.

# See MAN page for a full list of options:   

#             http://manpages.ubuntu.com/manpages/dapper/man8/snmptrapd.8.html

# create symlink on Debian legacy location to official RFC path

SNMPDCOMPAT=yes

When things don't work. 

I used nmap to confirm the trap ports were open (or not) you could of course send a trap from another device which is the point of this exercise.

nmap -sU -p 161,162 192.168.192.186

To confirm you are being sent a trap, you can use tcpdump to look for the incoming packets. 

tcpdump -i eth2 dst port 162

Or watch the log live

tail -f /var/log/snmptrap.log

You can search for the process, this is useful because you can also see the commands its running.

ps -aux |grep snmp

You can also stop the process using kill -9 (process id)

To run the trap from the cli and output to /var/log/snmptrap.log

snmptrapd -m +ALL -Lf /var/log/snmptrap.log --disableAuthorization=yes

I had a problem in that running the command from the cli meant that the OID was translated, but running it as a process meant the OID was not translated. This was fixed by changing the "export" option in /etc/default/snmpd but took me sometime to work out that was the problem. 

Happy trapping.