Once in a time, I get to travel to places that make me worry about the data on my laptop. This time, it is not the US, but another openly democratic country where they kill you for a joint, let alone nude pictures. Enough politics, though.

I have a laptop with the /boot in a separate partition, followed by a /root partition and a /swap. Having a separate /boot is mandatory, as the BIOS has to load an unencrypted kernel and its initrd before being able to access the encrypted partition. Another option is to keep /boot on a USB stick, but its setup can take a whole other post.

First things first, let us install software for managing encrypted disks and updating the initrd image:

aptitude install cryptsetup initramfs-tools

We have to make sure that the encryption modules are present on the initrd, so I add the following three modules to the initrd config:

echo aes-i586 >>/etc/initramfs-tools/modules
echo dm-crypt >>/etc/initramfs-tools/modules
echo dm-mod >>/etc/initramfs-tools/modules

Next step is to inform cryptsetup and inittab of the partition mapping between /dev/hda2 (the physical device) and /dev/mapper/root (its encryption interface).

echo "root /dev/hda2 none luks" >>/etc/crypttab
sed -i 's#/dev/hda2#/dev/mapper/root#' /etc/fstab

We also have to change the root device for grub the same way we did it for inittab:

sed -i 's#/dev/hda2#/dev/mapper/root#' /boot/grub/menu.lst

Now, recreate the initrd image by issuing

A few days ago, I lived through a DDOS attack at one of the sites I run. It started with the general unavialability of Apache, although the system was idle and the ssh access functioned perfectly. As I already had some experience with DDOS attacks, I immediately looked at the network connections using netstat and saw over 300 IPs sending SYN_REC packets in mass. The attack was much more powerful than I ever experienced.

~# netstat -n -p | grep SYN_REC | awk '{print $5}' | awk -F: '{print $1}'| sort |uniq |wc -l
310

I immediately started the APF firewall with RAB enabled and a script to block the offending IPs in iptables, as I had these at hand from the previous DDOS attack:

BEGIN {
 pipe = "netstat -n|gawk '{print $5}'|gawk 'BEGIN{FS=\":\"}{print $1}'|sort|uniq -c |sort -n"
 while (( pipe| getline) > 0 )  {
   if ($1 > 29 && $2 != "") {
     command="/sbin/iptables -I INPUT -s " $2 " -j DROP"
     date="date"
     command | getline result
     date | getline dateresult
     print dateresult " - command: " command ", result: " result >>"/var/log/firewall.log"
     }
   }
   close(pipe)
}

After a few hours it became clear that the IPs are rotating too often and the size of the botnet is well over 10.000, so I was left with a choice of either dying under DDOS or dying due to the performance hit of the large pool of IP addresses in iptables. The SYN_REC part was being filtered easily by syncookies, APF activated them on launch. The real problem was the HTTP flood.

I am probably the last webmaster in the world to ban Yahoo! Slurp from indexing my sites. Now, I am resolved. Bye-bye, Yahoo! You were just behaving too badly.

iptables -A INPUT -s 66.196.64.0/18 -j DROP
iptables -A INPUT -s 68.142.192.0/18 -j DROP
iptables -A INPUT -s 72.30.0.0/16 -j DROP
iptables -A INPUT -s 74.6.0.0/16 -j DROP

I did this a few times in my life, and every time it was painful to reconstruct the necessary toolset and configuration options. So, here it goes. First, enable the proxy support.

~# a2enmod proxy # utility functions
~# a2enmod proxy_http # http forwarding
~# a2enmod proxy_html # html rewriting
~# a2enmod headers # http headers rewriting

Then, assuming that your web application runs on port 3031 on the same host as Apache, and you want to make it available at the /demo url in Apache, write the following in the Apache config:

<IfModule mod_proxy.c>
  <IfModule mod_proxy_http.c>
    <IfModule mod_proxy_html.c>
      <IfModule mod_headers.c>
        ProxyRequests Off
        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>

        ProxyPass  /demo http://localhost:3301
        ProxyPassReverse /demo http://localhost:3301
        <Location "/demo">
            # ask the localhost to return the uncompressed HTML
            RequestHeader   unset   Accept-Encoding
            # Filter Responses through mod_proxy_html
            SetOutputFilter proxy-html
            # convert URLs in CSS and JavaScript as well
            ProxyHTMLExtended On
            # convert URLs in a.hrefs
            ProxyHTMLURLMap ^/ /demo/ R 
            # convert URLs in CSS and JS
            ProxyHTMLURLMap "'/" "'/demo/" 
            # convert URLs in CSS and JS
            ProxyHTMLURLMap "\"/" "\"/demo/" 
        </Location>
      </IfModule>
    </IfModule>
  </IfModule>
</IfModule>

Ну вот и ещё один дубль. Восьмого января фотосайт изменил структуру сайта и поломал так полюбившийся многим photosight wallpaper под Windows, а также скрипты дла автоматической установки "фото дня" на рабочий экран, используемые пользователями других OS.

Впрочем, от упрямого айтишника ничто не спасёт. Вот новый скрипт под Gnome Desktop для всеобщего пользования:

cd /tmp
ID=`wget -q -O - http://www.photosight.ru/wallpaper/week.wp` && \
wget -q -N  http://img-`date '+%Y-%m'`.photosight.ru/`date '+%d'`/$ID.jpg && \
gconftool-2 -t str --set /desktop/gnome/background/picture_filename /tmp/$ID.jpg && \
gconftool-2 -t str --set /desktop/gnome/background/picture_options "centered"

А вот версия под KDE по мотивам комментария

cd /tmp
ID=`wget -q -O - http://www.photosight.ru/wallpaper/week.wp` && \
wget -q -N  http://img-`date '+%Y-%m'`.photosight.ru/`date '+%d'`/$ID.jpg && \
dcop kdesktop KBackgroundIface setWallpaper /tmp/$ID.jpg 4