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?

3 Answers 3


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.


No Open Ports Password hashing SYN cookies


  • Configurable Firewall
  • Filesystem Capabilities

Mandatory Access Control (MAC)

  • AppArmor
  • SELinux

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        SYN_RECV    - tcp        0      0        SYN_RECV    - tcp        0      0        SYN_RECV    - tcp        0      0        SYN_RECV    - tcp        0      0            

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.
  • Yeah. Bucku edited on me. I wanted to ask if you could extend your iptable definitions to the virtual box connections. Both to the computer and to the internet. A majority of it otherwise is intact. And my wording has been changed almost completely. Thanks man. Appreciate the deviation to intent.
    – Miphix
    Jan 22, 2014 at 18:56

Have a look at the following links which may help strengthen your Ubuntu install:




  • It's considered best practice to include the relevant content from links in the answer in the event the source were to go away.
    – lazyPower
    Jan 22, 2014 at 9:34
  • Easier said than done, some of the links span pages and I always test links before I paste them to make sure they are alive...
    – TenPlus1
    Jan 23, 2014 at 8:14
  • The problem is six months, a year, etc. after this post when the source links have gone away. Its great that you're testing them before posting them but will you continue to curate your links after the fact?
    – lazyPower
    Jan 23, 2014 at 14:42

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.
  • 1
    It's considered best practice to include the relevant content from links in the answer in the event the source were to go away.
    – lazyPower
    Jan 22, 2014 at 9:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.