Portscans detection and the blacklist dilemma

Portscans are terribly annoying. But what to do when a host is scanning us? Block it for a set amount of time? Just log it? Do nothing at all?
Blocking hosts opens a nice DoS attack vector. I have always used to block for no more than a minute. You are never really sure if what you are blocking is a kiddo or some poor bastard which machine's address has been spoofed. If the poor bastard happens to be a gateway, you are going to regret your nice blacklisting trickery. Ignoring them completely is out of the question.

---

Useful links:

---

suPHP chroot gotchas

Keep your nose out! 

Chrooting is not a proper security measure and was never intended as such. Nonetheless, when 'proper' chrooting is deployed in a multi-user environment (such as web hosting), it adds a layer of protection against gathering information about the underlaying system, and, more importantly, it stops spying on, or messing with, other users' files. How?

Well, let's take the example at hand (web hosting). If you are hosting dynamic web sites you have to give your users some way to run php/cgi scripts. Apache (mod_php) will run all of yours (and others') scripts as the unprivileged user. By doing so, and since the unprivileged user has to have access to all the hosted web sites, I can write a script to gather your database passwords, to delete all your files, to change all your links to point to some nasty stuff, etc.

Better SSH Brute force prevention with iptables

There are countless of 'Howto prevent SSH Brute force attacks with iptables' scattered around the Net. What, in my opinion, is missing from those howtos is a 'holistic' approach to the problem. Only adding a 'recent' rule to iptables is just a part of the solution.

IPTables rule set

Let's take for example the ubiquitous:

# iptables -N IN_SSH

# iptables -A IN_SSH -m recent --name sshbf --rcheck \

              --hitcounts 3 --seconds 10 -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

Latest iptables, xtables, ipset for Ubuntu

By using Ubuntu 10.04 I am stuck with old versions of iptables, xtables and ipset (the latter is very old!) Is there a solution? Yes of course, I could compile those applications myself, but I prefer to have .deb packages managed by the good old dpkg. 

IPTables

With the method descibed in this post we can get the latest version of iptables (currently 1.4.10), but what about xtables or ipset?

Bash history autocomplete galore

Add the following lines to the end of .bashrc

-----8<-----

# make bash autocomplete with up/down arrow
bind '"\e[A":history-search-backward'
bind '"\e[B":history-search-forward'

# make tab cycle through commands instead of listing
bind '"\t":menu-complete'

----->8-----

Now by pressing arrow up/down bash will autocomplete based on your command line history, while pressing TAB will cycle through commands, directories and files names.

rsyslog and grsecurity (Ubuntu 10.04)

Selecting grsecurity's "Proc restrictions" might possibly break few things. One of these things is rsyslog kernel logging capability. Upon booting this message would show up in my kern.log:

kernel: imklog: Cannot read proc file system, 1.

One way to solve this problem is to assign rsyslog to a special group (defined during the kernel configuration phase) which members are able to view all processes, network-related information, and kernel and symbol information.

Prepping a fresh Ubuntu install

Very short and sweet TODO list after a fresh install. I have taken some of this from various guides on the net.

Disable dash:

# dpkg-reconfigure dash

-> no