Home / ubuntu / Questions / 408998
Accepted
Miphix
Asked: 2014-01-22 20:19:39 +0800 CST

How can I create a hardened Virtualbox image for PenTesting?

  • 772

As a serious security researcher, I'm looking for an answer to securing a Ubuntu installation against unwanted intrusion. This should include how I can:

  • Log and alert remote connection attempts,
  • Log and alert when a file changes, as well as restoration of those files on request,
  • Is it necessary to Harden the TCP/IP stack of the machine?

My end use case scenario is going to be in Virtualbox for ease of restoration, so it would be great to know what I need to do to get the image started.

Would the following iptables definitions work the same as fail2bans purpose?:

  • $ iptables -N IN_SSH

  • $ iptables -A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH

  • $ iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 3 --seconds 10 -j DROP
  • $ iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 4 --seconds 1800 -j DROP
  • $ iptables -A IN_SSH -m recent --name sshbf --set -j Accept
  • $ iptables -A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH

P.S.: Would some one give the code to properly box off scripting?

virtualbox

3 Answers

  1. Best Answer

    I'm tempted to flag this as a duplicate since there have been several questions like this asked before, but you ask for specific security-centric things. Therefore in the spirit of helping:

    There is an active security audit that's ongoing during every release cycle. It also contains good advice about some basic security measures that are already in place specifically to harden and test your system against unwanted external access.

    Configuration

    No Open Ports Password hashing SYN cookies

    Subsystems

    • Configurable Firewall
    • Filesystem Capabilities
    • PR_SET_SECCOMP

    Mandatory Access Control (MAC)

    • AppArmor
    • SELinux
    • SMACK

    Filesystem encryption

    • Encrypted LVM
    • eCryptfs

    Userspace Hardening

    • Stack Protector
    • Heap Protector
    • Pointer Obfuscation
    • Address Space Layout Randomisation (ASLR)
    • Built as PIE
    • Built with Fortify Source
    • Built with RELRO
    • Built with BIND_NOW
    • Non-Executable Memory
    • /proc/$pid/maps protection
    • Symlink restrictions
    • Hardlink restrictions
    • ptrace scope

    Kernel Hardening

    • 0-address protection
    • /dev/mem protection
    • /dev/kmem disabled
    • Block module loading
    • Read-only data sections
    • Stack protector
    • Module RO/NX
    • Kernel Address Display Restriction
    • Blacklist Rare Protocols
    • Syscall Filtering

    With the list of existing protections in place, lets examine the rest of your question:

    • In relation to Logging connection attempts, this has been covered, and if you want something simpler to configure there is always fail2ban or denyhosts.
    • When watching configurations for modifications, there is AppArmor.
    • As far as indicating on TCP/IP Stack hardening, you would need data to validate the necessity of performing this, but for the paranoid there is a good post on the advantages of blocking SYN flooding. But as you'll notice from the security audit link above, SYN Cookies is enabled by default, and helps mitigate this out of the box.

    So it appears that all you really need to do at this point, is ensure the extra applications you may/may not be installing are undergoing active security audits and that you are current with any patches. Have installed any extra AppArmor profiles required to secure your customizations. (or SELinux additions, respective to your particular configuration)

    How to detect a SYN attack

    It is very simple to detect SYN attacks. The netstat command shows us how many connections are currently in the half-open state. The half-open state is described as SYN_RECEIVED in Windows and as SYN_RECV in Unix systems.



# netstat -n -p TCP tcp        0      0 10.100.0.200:21            
237.177.154.8:25882     SYN_RECV    - tcp        0      0 10.100.0.200:21            
236.15.133.204:2577     SYN_RECV    - tcp        0      0 10.100.0.200:21            
127.160.6.129:51748     SYN_RECV    - tcp        0      0 10.100.0.200:21            
230.220.13.25:47393     SYN_RECV    - tcp        0      0 10.100.0.200:21            

We can also count how many half-open connections are in the backlog queue at the 
moment. In the example below, 769 connections (for TELNET) in the SYN RECEIVED state 
are kept in the backlog queue.



 # netstat -n -p TCP | grep SYN_RECV | grep :23 | wc -l 769 

The other method for detecting SYN attacks is to print TCP statistics and 
look at the TCP parameters which count dropped connection requests. While under 
attack, the values of these parameters grow rapidly.



 # netstat -s -P tcp | grep tcpHalfOpenDrop         tcpHalfOpenDrop     =   473 

It is important to note that every TCP port has its own backlog queue, but only
one variable of the TCP/IP stack controls the size of backlog queues for all ports.
    • 2
    • 0

  3. These links you might find helpful:

    Some software might be useful:

    • Nmap -- The Network Mapper.
    • Kismet -- Wireless 802.11b monitoring tool.
    • Chkrootkit -- Checks for signs of rootkits on the local system.
    • Rkhunter -- rootkit, backdoor, sniffer and exploit scanner.
    • GnuPG -- GNU privacy guard.
    • Snort -- Flexible Network Intrusion Detection System.
    • 0