I’ve been experimenting with using SSH as a VPN. That is to say not just tunnelling a single port but forwarding all traffic through the remote host like a router.

I’ve pulled together instructions from here and here and have this:

1. Enable root SSH with keys and allow tunnelling on the remote machine in /etc/ssh/sshd_config:

PermitTunnel yes
PermitRootLogin without-password

2. Generate root SSH keys on the local machine and copy the public one to the remote machine:

ssh-keygen -t rsa
scp id_rsa.pub remote-ip:/root/.ssh/authorized_keys

3. SSH as root (or using sudo) from local to remote to setup the VPN, this will actually give you a login as I found that if you don’t make that a login session (i.e. ssh -NTFw 0:0 remote-ip) then you can’t take down the tun0 device when you’re finished, which makes for all sorts of problems when you try to bring it up again later:

sudo ssh -w0:0 remote-ip

4. Whilst in the root SSH session on the remote machine, you can configure the tun0 device (on a /30 as its point-to-point, using a private IP range), enable IP forwarding and NAT. Obviously you can’t use the same subnet for the VPN as your normal routing, so assume here eth0 is 192.168.0.5:

ifconfig tun0 10.0.2.1 netmask 255.255.255.252 up
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

5. Back on the local machine (as root) setup the static routes you require to go down the VPN, in this case I’m connecting to the entire 10.93.x.x private network the other side of the tunnel. I found that the usual “route add….” syntax didn’t work, so moved to the new “ip” system as described here:

ifconfig tun0 10.0.2.2 netmask 255.255.255.252 up
ip route add 10.93.0.0/24 dev tun0

That’s it, now on the local machine any traffic you point at 10.93.x.x goes down the SSH tunnel and is forwarded onto the machines the other side, this is much better than a regular SSH tunnel which just connects you from local port A to remote port B, this allows any traffic from local A via remote B to target C.

I’ve built a default install of Fedora 13 64-Bit in a virtual machine for the purpose of figuring out what are the dependencies and workarounds required to compile VirtualBox OSE from Subversion.

1. Install make, gcc etc; as root:

yum groupinstall "Development Tools" "Development Libraries"

2. Install 32-Bit build tools and some Qt4 libraries, Java etc; as root:

yum install dev86 iasl qt4-devel pulseaudio-libs-devel glibc-devel.i686 libgcc.i686 texlive-texmf-latex java-1.6.0-openjdk-devel zlib-static glibc-static libstdc++.i686 libvncserver-devel libxslt-devel libIDL-devel SDL-devel libXmu-devel libstdc++-static

3. Symlink the Fedora-packaged JVM to where Oracle expect it to be installed, as root:

cd /usr/lib/jvm/
ln -s java-1.6.0-openjdk.x86_64 java-6-openjdk

4. Install the bera-mono font into LaTeX, as root:

cd /usr/share/texmf/tex/latex/
mkdir bera
cd bera/
wget http://www.tug.org/texlive/devsrc/Master/texmf-dist/tex/latex/bera/beramono.sty
texhash

5. Download makeself, as a regular user:

cd /var/tmp/
wget http://megastep.org/makeself/makeself.run
sh makeself.run

6. Install and rename makeself.sh to makeself as Oracle are expecting, as root:

cd /var/tmp/makeself-2.1.5
mv makeself.sh makeself
cp makeself makeself-header.sh /usr/local/bin/

7. Compile VirtualBox, UserGuide.pdf, the kernel modules and the Guest Additions as a regular user:

cd ~/vbox/
svn update
./configure --disable-hardening
source env.sh
kmk all VBOX_WITH_VNC=1
cd out/linux.amd64/release/bin/src
make
cd ~/vbox/
kmk packing

Update: The same setup seems to work for Fedora 14 too.

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:

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 been experimenting with bypassing firewalls today, based on results from this Nessus plugin.

Essentially its down to misconfiguring a firewall to allow access based only on the source port. This way we can send packets to other destination ports through the firewall.

I’ve managed to exploit it on Linux by setting up these weak iptables rules:

iptables -A INPUT -p tcp --sport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT

I also managed to exploit it on Cisco IOS using these weak ACL rules: