Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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 iptable 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

Ps. Would some one give the code to properly box off scripting?

share|improve this question

3 Answers 3

up vote 2 down vote accepted

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.
share|improve this answer
    
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 at 18:56

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

http://www.maketecheasier.com/protect-ssh-server-with-fail2ban-ubuntu/

http://www.rawcomputing.co.uk/linux/linux-firewall-part1.html

http://blog.lavoie.sl/2012/09/protect-webserver-against-dos-attacks.html

share|improve this answer
    
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 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 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 at 14:42

These links you might find helpful

https://securityinabox.org/en

https://wiki.ubuntu.com/BasicSecurity

http://www.ubuntugeek.com/list-of-security-tools-available-in-ubuntu.htm

Some software might be usefull

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

share|improve this answer
    
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 at 9:34
1  
Thanks will apply best practice –  awolfp Jan 22 at 9:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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