0 The basics of installing Backtrack 5R2 for the purposes of secure remote access.

So you are finally realizing how far behind the times you are and want to experiment with Backtrack. Better late than never With the new release of Backtrack 5 R2, they have not included a VMware image like in previous versions. So you have either two options, boot in live mode and lose changes and settings upon each boot-up cycle, or you can install backtrack to a partition on your machine. Now both have their pros and cons like everything else in the world, however this article is to help those out there who are opting to install to a partition. This is a great option if you want to have a Backtrack box always up and waiting to wreak network havoc with a remote install of backtrack that you can always connect to. I have a Backtrack box up that I access remotely if I want to do some testing and don’t want to boot up an image and go through all the hassle of setting the entire thing up, I just SSH into the box and do what I need to do. This article is help you securely setup your Backtrack box so that it can be accessed remotely from any computer that sits on the same subnet.

I’m assuming that you already have downloaded the ISO file and are booted up ready to install. I also assume that you are booted up and have a dedicated partition picked out for the install. Setting up and preparing for an install are out of the scope of this article.

Boot up into Backtrack. Log in with root/toor

At the prompt, type startx and press enter.

Assuming all goes well with your graphics card, you will soon be in the GUI portion of Backtrack.

Notice on the desktop you will see the install script. Double-click it and it will bring up a pretty straight-forward wizard on how to install to your partition. What I do recommend doing is having at least 15GBs of storage space free to install.

After all goes well, you will want to reboot. So go ahead and do that.

Upon a reboot you should now have a fresh copy of Backtrack installed and you should be sitting at the login prompt.

Go ahead and login with root/toor and then launch the startx command.

Now the fun begins:

Back in the GUI, the first thing we want to do is set up our static networking. (Unless you like guessing what IP address this box will have every time you do a reboot).

Open a terminal and launch this command:

#ifconfig -a

This should list all your networking interfaces. In my case, my box has a single ethernet port which correlates to the eth0 interface.

Your setup should be similar. Now to set static IP address scheming, (fill in the xxx with whatever subnet and IP address you want the box to have) do the following:

#pico /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.xxx.xxx
netmask 255.255.255.0
gateway 192.168.xxx.xxx
Close out and save this file and then do the following:
#pico /etc/resolv.conf
nameserver 192.168.xxx.xxx
nameserver 192.168.xxx.xxx
nameserver 208.67.222.222
nameserver 208.67.220.220
Close out and save this file

Change your password:

Assuming we have a backtrack box that is going to be on constantly you will want to change the password pretty quickly before you setup SSHD on the box. We don’t want anyone else to login to the box. To change the password do the following

#passwd root

Enter new complex, randomly generated password

Remote Access:

So now we want to setup remote command line access to our newly installed Backtrack box, but something I usually like to do is change the default SSH port to something other than 22 just for kicks.

#pico /etc/ssh/sshd_config

find the port line where it says 22 and change it to 800

Save the file and close out.

Now run the following command:

#sshd-generate

This will generate ssh keypairs and then

#/etc/init.d/ssh start

This will start up the sshd server and you should now be able to launch putty (or another ssh client) on another computer on the same subnet and connect to the Backtrack box at port 800.

For sshd to survive a reboot

#update-rc.d -f ssh defaults

This will bring sshd after a reboot.

Updating the box

It is important to upgrade the Backtrack box so it is most current and that you don’t get rooted

#apt-get update
#apt-get upgrade
#apt-get dist-upgrade

Firewall rules:

So the Ubuntu distro that Backtrack is based off of comes with iptables which is a stateful firewall, you can check out current rules by doing a

#iptables -L

This should list nothing in each of the three sections, INPUT, FORWARD, OUTPUT.
These are basically all inbound connections, forwarded ports if the box was a router and outbound ports/connections. This is not a tutorial for using iptables, just google around for some, there are plenty, but this should get you on the right track as far as using them.

We basically want to leave output alone as we want to use all the goodies built into backtrack to be able to connect to any target we want, however we do want to limit inbound connections to only those we choose.  Right off the bat, there should be only two inbound ports we would want, port 800 for remote access to our box, and a metasploit inbound port. Now this is not a metasploit tutorial but if we are going to run a metasploit exploit with a reverse payload to connect back to our backtrack machine, we want it to be able to get through and connect to our backtrack box. So we are going to create two inbound rules, one for inbound ssh on port 800 and one for port 443 which most outbound firewalls will allow for legitimate traffic, so it’s considered a good port to use for reverse payloads.

#iptables -P FOWARD DROP

this will set all forwarding packets to be dropped, we don’t want anything going anywhere we don’t want.

#iptables -I INPUT 1 -i lo -j ACCEPT

this sets the loopback interface to accept any packets, this is necessary/helpful if we run any local service ports that require the loopback/localhost adapter to run, especially if we want to run a spoofed dns/webserver we can run it off loopback/localhost to test it and it will work.

#iptables -I INPUT 2 -m state --state RELATED,ESTABLISHED -j ACCEPT

this rule lets all related/already established packets come inbound, for instance say we shoot out a ping to our default gateway, this will let the response back from the gateway to our backtrack box, or else it will get dropped by the iptables firewall

#iptables -I INPUT 3 -i eth0 -p tcp --dport 800 -m state --state NEW,ESTABLISHED -j ACCEPT

this rule allows all traffic from tcp port 800 to come into interface eth0, this is the rule that lets our ssh traffic into the backtrack box so we can remotely control it.

#iptables -I INPUT 4 -i eth0 -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT

this rule allows all traffic from tcp port 443 to come into interface eth0, this is the rule that lets our reverse payload to traverse firewalls back to our backtrack box so we can hopefully gain a reverse shell on a remotely exploited machine via metasploit (out of scope of this article).

#iptables -A INPUT -j DROP

this rule drops every other packet that is destined for our backtrack box. this will help to make sure that our backtrack box doesn’t get compromised it only allows what we want, 800 and 443, everything else will get dropped

Side Note:

The rules above will allow any inbound access to ports 800 and 443. We can further lock this down by changing the rules to allow inbound access on those ports from specific IP addresses. For instance, say you only want to connect to this Backtrack box from the IP address 192.168.1.100, you would modify the 3rd rule to this:

#iptables -I INPUT 3 -i eth0 -p tcp -s 192.168.1.100 --dport 800 -m state --state NEW,ESTABLISHED -j ACCEPT

The same applies to the 443 rule, let’s say we are only attacking the IP address 192.168.1.50, then we would only want to allow 443 inbound from that IP address so we would modify this rule to be:

#iptables -I INPUT 3 -i eth0 -p tcp -s 192.168.1.50 --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT

So you think you’re all set with the iptable rules until you do a reboot and guess what, they are gone upon a reboot, so you have to make these rules persistent across reboots, so you will need to create two scripts:

#pico /etc/network/if-pre-up.d/iptablesload

#!/bin/sh
iptables-restore < /etc/iptables.rules
exit 0

Save file and close and do the following:

#pico /etc/network/if-post-down/iptablessave

#!/bin/sh
iptables-save -c > /etc/iptables.rules
If [ -f /etc/iptables.downrules ] ; then
iptables-restore < /etc/iptables.downrules
fi
exit 0

Save the file and close.

Now do the following commands to make the scripts executable:
#chmod +x /etc/network/if-post-down.d/iptablessave
#chmod +x /etc/network/if-pre-up.d/iptablesload

This will put a script in the /etc/network/if-post-down.d and /etc/network/if-pre-up.d directories that will save and restore the iptables rules that are created so they last and survive on a reboot.

Security on ssh:

So you think you’re all set, but you want to make sure no one roots you What you can do is check out the following log file /var/log/auth.log.
Run the command

#cat /var/log/auth.log | grep sshd

This will show all sshd logins coming into your backtrack box and will show you what login names were tried and also which IP addresses they were coming from. If you have any remote syslog boxes it might be wise to install syslog-ng and ship these logs over to your remote syslog box, but that is out of the scope of this article.

That’s primarily it, you should now have a pretty secure/locked down Backtrack box that is ready for you to remotely access it and start trouble.

_flood

I’d like to thank _flood for submitting this post and encourage all of you HackTalkers to submit any articles you may have written and I’ll gladly post them on the blog and link to any website you’d like.
If you would like to ask _flood any questions or just meet the author of this post, head on over to irc.freenode.org #hacktalk and you can typically find _flood there.

As always, Cya In Cyberspace.