random sed

Ran into two problems that required sed today, figured I'd share them...

The simple one:
Inserting a line at the top of a file..
 
entropy ~ # echo "test file" > dump  
entropy ~ # cat dump
test file
entropy ~ # sed -i '1iwoot_woot' dump
entropy ~ # cat dump
woot_woot
test file


The nifty one:
Making a sed replacement that isnt greedy..

assume a file contained the following line:

alert x blah blah blah blah; flagged: yes; set: yes; ignore: no;

alert y blah blah blah blah; flagged: yes; set: yes; ignore: no;

alert x blah blah blah blah; flagged: maybe; set: yes; ignore: no;

and you wanted to get rid of the flagged statement, whether it was set to "yes" or to "maybe" or to anything else, only on lines that start with alert x.

the following effectively gets rid of the "flagged" statement but the regex is greedy and also takes out the "set" statement:

entropy ~ # sed '\,^alert x,s/flagged:.*; //' blah
alert x blah blah blah blah; ignore: no;
alert y blah blah blah blah; flagged: yes; set: yes; ignore: no;
alert x blah blah blah blah; ignore: no;

This one however limits its replacement based on the first encountered semicolon rather than the last, and thus does not greedily replace extra data:

entropy ~ # sed '\,^alert x,s/flagged:[^;]*; //' blah
alert x blah blah blah blah; set: yes; ignore: no;
alert y blah blah blah blah; flagged: yes; set: yes; ignore: no;
alert x blah blah blah blah; set: yes; ignore: no;

mysql optimization

so I had a mysql server that was getting a bit weighed down and needed a touch more performance customization than the default my.cnf provided for. So here's the fun, it seems pretty snappy and efficient so far, but over the next few days we'll see if anything explodes:

thread_concurrency=16

thread_cache_size=8

query_cache_type=1

query_cache_limit=3M

query_cache_size=128M

tmp_table_size=256M

max_heap_table_size=256M

read_rnd_buffer_size=3M

max_connections=100

key_buffer_size=512M

max_allowed_packet=32M

table_cache=512

sort_buffer_size=3M

read_buffer_size=3M

join_buffer_size=3M

figures are based on just over 2GB optimal memory usage by mysql, and a system with 8 processing cores.

This script helped alot: http://mysqltuner.pl

Protecting Dovecot with Fail2Ban

Tossing this on here before I forget about it...

I set up a simple mailserver a while back using dovecot (no it's not vulnerable to the passdb TAB issue, funny as that one is), but had a hell of a time getting the right regex and setup for fail2ban, most examples are for using the default auth pam passdb system rather than an sql authentication back-end.

Here's the jail.conf setup, the magic here is the "iptables-multiport" which is a target that must available from the netfilter kernel modules to work.

[dovecot]
enabled = true
filter = dovecot
action = iptables-multiport[name=dovecot, port="110,995,143,993", protocol=tcp]
         sendmail-whois[name=dovecot, dest=root@mydomain.tld, sender=fail2ban@mydomain.tld]
logpath  = /var/log/maillog

As for the filter.d match, here is the fancy regex for a unknown user:

dovecot.*auth-worker\(default\): sql\(.*,<HOST>\): unknown user

and for password failure:

dovecot.*auth-worker\(default\): sql\(.*,<HOST>\): Password mismatch

Next step is to write one that detects people trying to use that TAB exploit, even though it doesn't work on this setup I just really don't like people trying.