Junos 10

Today I have been mostly installing Junos. Well actually I’ve wasted most of the day trying to get Junos 10.4 to work in Olive under VirtualBox. I understood that it required FreeBSD 7.1, so tried installing it under 7.1 and 7.4 to no avail.

In the end I cloned my Junos 9.0/FreeBSD 4.11 VM, allocated 512Mb instead of 256Mb and installed 10.4 as an upgrade, which also meant I didn’t have to bother removing checkpic.

I wasted a few rounds of installing due to using the export version, which doesn’t include SSH! Also part of the trick of getting it to work under VBox seemed to be to create a serial port as a named pipe – not sure why but that seemed to help get past the bootloader hanging, possibly as it had a TTY to allocate.

I also upgraded my 9.0 to 9.6 which has a bit of a more useful JWeb interface, and also requires 512Mb now.

All of this was to aide my development of a set of NASL scripts to do Junos security compliance auditing. It seems Tenable have worked around the UNIX-only limitation of Nessus’ ssh_cmd() function by putting in a special check for when uname -a fails – i.e. its either IOS or Junos (or unsupported). Of course in Junos shell mode, it will pass (as its FreeBSD) so you have to check that you’re in CLI mode to do the config checking.

Its only taken them four years of me asking for this, and I guess its come as a result of Nessus’s new IOS support for their own compliance plugin and local security checks for Junos patches etc.

Update: I’ve written 20 NASL plugins to do the Junos auditing now and I noticed I was hitting the SSH rate-limit setting in Junos, so my plugins were getting booted off. It was because for each plugin I was calling ssh_cmd() at least once and also a function that checks I could login with the correct level/privileges etc; so was making at least two SSH connection attempts per plugin, which soon hit the 10 connection attempts per minute limit that was configured.

So now I’ve moved all of my ssh_cmd() calls into one big include file which uses a single SSH connection to send 30 or so commands, and populates the knowledgebase with the results. The plugins then have that in their script_dependencies() and don’t use SSH at all, just a couple of calls to get_kb_item() which simplifies the code quite a lot and an entire scan can be done in 10secs!

Nessus ssh_cmd() fix?

I think I’ve found the main source of the PS1 problem with Nessus’ ssh_cmd(); it would seem it doesn’t like ksh, as it produces something like the following in the report output, which appears to be due to PS1 being set to “$ “:

Last login: Fri Dec 3 11:08:43 2010 from
$ $

If you change the login user’s shell to bash, the problem goes away (as long as PS1 ends with $, %, # or >), although I guess its possible that if the bash prompt was set to just “$ ” instead of the usual “-bash-3.00$ ” it would suffer the same problem as ksh.

Interestingly it seems to happen if you use su/sudo or not, I previously thought it was unique to su/sudo usage due to this section of code in the ssh_cmd() function from ssh_func.inc – note the prompt detection at line 2268:

 # su/sudo: shell prompt -> sends command
if ( strlen(tempbuf) > 5 ) last5 = substr(tempbuf, strlen(tempbuf) - 6, strlen(tempbuf) - 1 );
else last5 = tempbuf;
if (!isnull(su) && spass == 0 && ("$" >< last5 || "#" >< last5 || ">" >< last5 || "%" >< last5 ))
 for ( sub1 = 0 ; sub1 < strlen(cmd) ; sub1 += 1024 )
  if ( strlen(cmd) <= sub1 + 1023 )
    sub2 = strlen(cmd) - 1;
    sub2 = sub1 + 1023;
  cmdd = substr(cmd, sub1, sub2);
  payload = raw_int32(i:remote_channel) + putstring(buffer:cmdd);
  send_ssh_packet(payload:payload, code:raw_int8(i:94));
 spass = 1;


I’m getting fed up with Nessus 4.2.2/4.4.0 and its HTTPS timeouts, crap SSH banner handling (the $PS1/last bug) and closed-source nature meaning that we can’t use certain Linux distro’s anymore; and the fact that it uses Flash10 means we can’t use it over Citrix.

So I thought I’d give OpenVAS a try. Well all I can say is come back Nessus, all is forgiven!

For an opensource platform, OpenVAS really sucks as far as documentation and packaging goes.

Installation packages are all dealt with via odd openSUSE build servers that there are no instructions for – sorry but how do you install packages for Fedora from a SUSE build system?!

I eventually found a YUM repo file for Fedora 13, which despite being for v4 actually installed 3.2 code which didn’t work, the manager wouldn’t start and gsd required 777 permissions on /var/log/openvas/ for it to start.

On Debian 5 I found that you have to add this to your /etc/apt/source.lst, then you can install the packages, but openvas-manager won’t start and openvas-client/gsd won’t connect. After finding a post on an old mailling list archive, I found that you have to run:

apt-get install sqlite3
openvas-mkcert-client -n om -i

But that still doesn’t seem to work, so I next tried the stable v3 repository, that doesn’t seem to work either as the plugins are too new for it now!

OpenVAS bundles openvas-client its rebuild of NessusClient from Nessus 4.0 which on Nessus 4.2 or later only works on a ProFeed, and is no longer supported anyway. Also OpenVAS bundles openvas-cli which replaces nessus/nessuscmd which are deprecated in Nessus 4.2+ too.

You can check out the latest code from the SVN server, but there are no build instructions, and the preferred build environment is Debian 5 apparently, not OpenSUSE 11 at all, and 4beta2 doesn’t seem to be in SVN anyway.

You can download a prebuilt Virtual Machine which is openSUSE 11.2 with a half-arsed install of OpenVAS-3 without the desktop client, despite what it says is shipped with the desktop version.

Note that’s 3 different linux distro’s and about 5 different OpenVAS versions I’ve tried now, and none work – well the VM got the closest to it. Nice waste of 3 hours thanks!

It does seem that their NASL support is current as of about Nessus 4.0, there’s a few modifications needed to get NASL 4.2+ scripts working.

One nice thing about OpenVAS is that it uses rsync to do its plugin feed update, so in theory you could rsync from your local install to a remote server, and not have to worry about proprietary licensing. It only has half the plugins that Nessus does, at about 20,000 as opposed to 40,000.

There is some sort of commercial support from Greenbone but of course no pricing or SLA info.

I also updated the blog to WordPress 3.0.2

Password protecting files using GnuPG

I found a useful way of using GnuPG today when someone couldn’t decrypt a passworded zip file I sent them (probably using p7zip/infozip instead of “proper” unzip).

You can use symmetric encryption with GnuPG, i.e. just a password rather than a keypair+passphrase, and you don’t have to exchange keys or sign things etc:

gpg --symmetric myfile.pdf

Then decrpyt with simply “gpg myfile.pdf”.

I also fixed my NASL’s scripts with a bit of sed, this example replaces all the 50000 script_id()’s with 950000 ones:

for nasl in *.nasl ; do sed 's/script_id(5/script_id(95/g' $nasl > $nasl.new ; done
for nasl in *.nasl ; do mv $nasl.new $nasl ; done

Then just re-sign them and re-install them into Nessus, as root:

/etc/init.d/nessusd stop
cd /opt/nessus/lib/nessus/plugins/
for files in /git/nessus/*.nasl ; do /opt/nessus/bin/nasl -S $files > ls $files | awk -F/  {'print $8'} ; done
/opt/nessus/sbin/nessusd -R
/etc/init.d/nessusd start

The only problem then is that the current Nessus 4.2.2 with webserver version 2.0.0 truncates the plugin ID in the lists as the Flash needs updating to make the column wider, apparently will be fixed in 4.4

101 NASL’s

I’ve just finished writing some new Nessus plugins, taking my NASL count to over 100 now.

Just as I finished checking them into Git, Tenable decided to renumber the plugin ranges. Custom NASL’s were always given a range around 50000-53000, but now Tenable are up to 50321 themselves, so have decided on a new set of ranges:

Passive: 1 – 10,000
Active: 10,001 – 900,000
Custom: 900,001 – 999,999
Compliance: 1,000,000+

I’ve made some changes to my backup regime too, from now on I’m backing up my whole $HOME directory using BackInTime to an encrypted drive, rather than encrypting a tarball. This saves space as BIT uses rsync and hard links to create incremental backups. The old tar+gpg method would create a 3Gb file per backup, with BIT I’ve got 11 incremental backups totalling 9Gb.

Decrypting, decompressing and unpacking a 3.5Gb tarball to get to perhaps one file inside it is painfully slow, with BIT I can instantly restore (or just view or copy) a file at any date.

As it uses rsync as a backend its also simple to run from cron, which you can’t really do with GnuPG as you need to enter your passphrase.

I was thinking of using Deja Dup as its nicely integrated into Nautilus in Fedora/Ubuntu but its GUI is pretty minimal – literally a button or menu item for backup/restore/revert, and I’m not keen on the backend or limited use of GnuPG (passwords not keys, and no password input checking).