Exercise 1:  Brute force password guessing with Hydra

Help from http://www.thc.org/thc­hydra/

Get to the bin directory inside your homedir:
cd bin

First, let's try to log in as a user 'victim' with password 'pass':
To use the command line: hydra 127.0.0.1 ssh ­l name ­p pass
To use the gui: ./xhydra.  Then enter the target IP (127.0.0.1)  in the 'Target' tab.  Choose SSH as your 
protocol in the 'Target' tab. In the 'Passwords' tab check the two boxes at the bottom, 'Try login as 
password' and 'Try empty password'.  Enter the password 'pass' in 'Password' field. Go 'Start' tab and hit 
the 'Start' button.

What do you see in the logs now? Look at the end of /var/log/auth.log by typing:
tail /var/log/auth.log

That seems kind of limited.  Can't it do more? Yes!

Download the password list by going to: http://tinyurl.com/2eynrf.  Make sure to download to the same 
directory you're in now.

Open up another terminal window ­ we'll use this one to watch what hydra is doing.  In it type:
tail ­f /var/log/auth.log

Now go back to the original window:
To use the command line: hydra 127.0.0.1 ssh ­l name ­P password.lst
To use the gui: ./xhydra.  Then enter the target IP (127.0.0.1)  in the 'Target' tab.  Choose SSH as your 
protocol in the 'Target' tab. In the 'Passwords' tab check the two boxes at the bottom, 'Try login as 
password' and 'Try empty password'.  Instead of entering a password in the 'Password' field, check 
'Password list' and give it the name of the file 'password.lst'. 'Go 'Start' tab and hit the 'Start' button.

What's the difference between the log messages you saw the first time you ran hydra and the second?

Exercise 2: Disabling root login

Attempt to SSH into your box as the root user. Close the session once you succeed.

Find the 'sshd_config' file on your system.  Probably in /etc/ssh/sshd_config.  Find the line that says 
'PermitRootLogin'.  Change the line so it reads 'PermitRootLogin no'. Restart SSH – you can do this 
many ways.  One way is '/etc/init.d/ssh restart'.  Another is to find the sshd process, kill it and then start a 
new one.

Attempt again to SSH into your box as the root user. It should fail.

Exercise 3: Start the SSH server on a different port and nmap it

Nmap port 22 on your box: 'nmap ­p22 127.0.0.1'.  Make a note of what you see.
Find the 'sshd_config' file on your system.  Probably in /etc/ssh/sshd_config.  Find the line that says 
'Port'.  Change the line so it reads 'Port ' and then whatever number you want between 1024 and 65335. 
For example: 'Port 3452'. Restart SSH – you can do this many ways.  One way is '/etc/init.d/ssh restart'. 
Another is to find the sshd process, kill it and then start a new one.

Nmap the port you chose.  For our example: 'nmap ­p3452 127.0.0.1'.  Make a note of what you see.

Exercise 4: Set up blocking for IP addresses that trigger 'Illegal user' alerts

There will be two hosts you will be concerned with in this exercise.  One host is the victim (this is the 
host you're managing) and the second host will be the attacker.  All you have to be able to do on the 
second host is run the ssh client.  On the first host, the victim, you will need access as the 'root' user.

On the first host, the victim:

Make sure a hosts.deny file exists in /etc/.  If one does not type: 'touch /etc/hosts.deny'

Create a text file in your home directory to edit with your favorite editor named 'deny.sh'.

tail /var/log/auth.log | grep 'Illegal user' | cut -d “ “ -f 10 >> /etc/hosts.deny

Create another text file in your home directory with your favorite editor named 'deny.cron'.

* * * * * /yourhomedir/deny.sh

Create another text file in your home directory with your favorite text editor name 'empty.cron'.  This file 
should be. . .empty.  We'll see how we use it later.

Now we're going to use the crontab command – this command will let us load a job to be run at a 
specified time.  The directions in deny.cron tell cron to run the script deny.sh every minute.

To load the job type: 'crontab deny.cron'.

On the second host, the attacker:

Run Hydra using your host, the victim, as the target.  Then look at the contents of the hosts.deny on the 
victim host.        The IP address you were running Hydra from should show up in the hosts.deny file.

Once you've got it working, remove the crontab entry on the victim host by typing 'crontab empty.cron'. 
Also, open up the /etc/hosts.deny and delete its contents.

THIS IS NOT A  PRODUCTION READY SOLUTION.  Why?
– Password guessing attacks involve thousands of attempts per hour – such attacks would very quickly 
increase the size of the hosts.deny file.
– If you haven't already limited the hosts that can contact you down to a particular group of subnets 
then you probably have users in unpredictable locations – meaning you shouldn't limit this one IP 
address permanently.  The records should expire after a given period of time – hours or days 
depending on how sensitive the system is.
– You'll want something more dependable than a bunch of shell scripts.  There are many useful log 
 watching tools that can be configured to take action when a pattern is matched, like Swatch, Log 
Watcher, etc.

Exercise 5: Set up an SSH key and use it to login

We will be using two hosts again – I'll call them victim and attacker to be consistent with previous 
exercises, however, in this exercise the attacker isn't attacking.  Make sure you've deleted the contents of 
/etc/hosts.deny.

On the attacker, generate an SSH key using the command:

ssh­keygen ­t dsa

It will ask you for a pass phrase. It is best to set this, though it will accept a blank pass phrase.

There will now be two files in your .ssh directory, id_rsa and id_rsa.pub.  The first is your private key file 
– this is the one you keep secured and do not share with others.  The public key is the one you will copy 
up to your authorized_keys file (more on this later) on Jane.  This key will be used by the server to 
determine if your key is valid for authorizing you to login.  Think of id_rsa and id_rsa.pub as a matching 
set – if the server has id_rsa.pub it can determine if the private key you provide (id_rsa) matches that 
public key.

Now you will need to copy the PUBLIC key up to the victim.  To do this type this command on the 
attacker:
scp victim@<victim_ip> .ssh/id_rsa.pub ~victim/public_key

The next step is to add this key to the authorized hosts files on the victim.  To do this type the following 
command on the victim:
cat public_key >> .ssh/authorized_keys2

To test your key, go back to the attacker. Try to login without using password authentication like so:
ssh ­o PasswordAuthentication=no victim@<victim_ip>.

You will be asked for the pass phrase, if you set up a pass phrase when you created the key.

Exercise 6: Configure a host based firewall

With help from http://www.webhostingresourcekit.com/127.html.

Iptables is a basic firewall installed on Ubuntu. It has some limitations, which we can talk about later, but 
right now we're going to look at how to configure it.

First, let's start the webserver so we have something to test:
/etc/init.d/httpd start

Test that you can access the web server on the victim from the attacker.

To accept all traffic:
iptables ­A INPUT ­p tcp ­j ACCEPT
Test that you can still access the web server on the victim from the attacker.

But if we wanted to accept all traffic we wouldn't need a firewall. Let's see if we can block all traffic. 
The first command flushes all the rules so we start out with a blank slate:
iptables ­A INPUT ­F
iptables ­A INPUT ­p tcp ­j BLOCK

Now try to access the web server.  

So let's say I have an internal website I don't want others to access.  And in this hypothetical example my 
attacker is the intranet.  So I want to set it up so only the attacker's IP address can access my webserver. 
The first command flushes the rules again and the second says that block anyone who attempts to access 
my webserver that doesn't have the IP address <attacker_ip>:
iptables ­A INPUT ­F
iptables ­A INPUT ­p tcp ­­destination­port 80 ­s !<attacker_ip> ­j BLOCK

Now try to access the webserver ­ you should be able to.