Есть у меня одна многолетняя привычка — лочить консоль, если я куда-то отхожу от компьютера. Потом консоль можно разлочить, но вот в xfce обнаружилось одно маленькое неудобство, мешающее работать. Скрин локер в xfce не показывает текущую раскладку клавиатуры, поэтому промахнуться с раскладкой клавиатуры при наборе пароля — как два байта переслать. А при ошибке ввода пароля предстоит ужасно раздражающее 30-секундное ожидание, которое в некоторых ситуациях просто бесит.

И раз нельзя вывести текущую раскладку клавиатуры на скрин локер, то можно попытаться ее сбрасывать в известную раскладку при его запуске. В общем, проблему можно решить следующим образом:

> cat /usr/local/bin/xflock4
#!/bin/bash
/usr/local/bin/xkb-switch -s us
/usr/bin/xflock4

И все, проблема решена. При локе экрана теперь всегда пароль будет набираться в английской раскладке клавиатуры.

Fail2ban очень хорош для блокирования нежелательных TCP-соединений, но для блокирования UDP флуда его применять нельзя. Дело в том, что протокол UDP не подразумевает проверки подлинности IP адреса отправителя, и очень часто его подделывают чужими адресами. Известны случаи, когда fail2ban блокировал по айпишнику вышестоящий роутер, и соединение с интернетом на сервере пропадало, поэтому просто так перекрывать трафик не стоит.

Обычно флудят UDP сервера, которые отвечают на запросы и шлют ответы на подделанный IP адрес отправителя, усиливая атаку на жертву. И самый распространенный вариант атаки — это атака на DNS-сервера.

Самый простой, но не самый правильный способ борьбы с UDP флудом — ограничить число принимаемых или отравляемых пакетов UDP в секунду с помощью iptables, примерно так:

iptables -A INPUT -p UDP -m pkttype --pkt-type broadcast -j DROP
iptables -A INPUT -p UDP -m limit --limit 3/s -j ACCEPT

Этот способ работает надежно, но довольно грубо. Если мы говорим про флуд DNS-сервера, то указанный способ ограничит и легитимные запросы к моим доменам, и флуд на левые доменные имена. А правильный способ борьбы с флудом DNS выглядит так.

1. Обновить bind до версии 9.9.3 (или до 9.9.2 с патчем для rate-limit)

2. Запретить рекурсию для всех доменов и ограничить число ответов в секунду для «левых» доменов и для своих:

  options {
        recursion no;
        allow-query { none; };
        rate-limit {
            responses-per-second 10;
            errors-per-second 1;
            window 5;
        };
  };

2. Для каждого домена в зону прописать allow-query { any; } :

zone "mydomain.com"
{
    type master;
    file "/path/to/file/mydomain.com";
    allow-query { any; };
};

Теперь ограничение стало более интеллектуальным, на правомерные запросы о моих доменах bind будет слать не более 10 ответов в секунду; а на запросы о левых доменах — максимум 1 запрос в секунду. С цифрами в настройках можно поиграться, и добиться желаемого результата.

Логи bind в случае атаки будут выглядеть примерно так:

Jul 18 17:30:54 named[24256]: client 188.40.25.2#34598 (help-u.ru): query (cache) 'help-u.ru/A/IN' denied
Jul 18 17:30:54 named[24256]: client 188.40.25.2#37411 (ns.help-u.ru): query (cache) 'ns.help-u.ru/AAAA/IN' denied
Jul 18 17:30:54 named[24256]: limit REFUSED responses to 188.40.25.0/24
Jul 18 17:31:35 named[24256]: client 49.128.63.42#29236 (help-u.ru): query (cache) 'help-u.ru/MX/IN' denied
Jul 18 17:32:02 named[24256]: stop limiting error responses to 188.40.25.0/24

Т.е. если флудер обнаглел и шлет запросы слишком часто, сервер на какое-то время ограничивает число ответов на айпишк, с которого пришел запрос.

Сначала меня забавляли нелепые попытки подобрать пароли по ssh на некоторые мои сервера. Возможность зайти сразу под root у меня отключена (PermitRootLogin no в /etc/ssh/sshd_config), да и имя пользователя, которому разрешен su, тоже никто не знает. Но когда число попыток подбора паролей стало переваливать за 17к в сутки, я решил прекратить этот коммунизм и поставил fail2ban.

Немного пошаманив с настройками, пришел к следующей конфигурации: 3 неверных попытки входа = бан айпишника на сутки. И, как говорят в Одессе, совсем другая картина маслом — нагрузка на сервер незначительно снизилась, и отчеты logwatch стали несколько короче.

Однако, спустя неделю после эксплуатации fail2ban, обнаружилась неприятная особенность его работы. В дефолтной конфигурации fail2ban делает запросы whois об айпишнике, который банит. И если сервер whois не отвечает, то fail2ban становится немного не живой — виснет, зараза.

Но если чуть-чуть подправить mail-whois.conf, mail-whois-lines.conf, sendmail-whois.conf и sendmail-whois-lines.conf в /etc/fail2ban/action.d и исключить обращения к whois, fail2ban перестает зависать.

Я довольно долго экспериментировал с хранением бэкапов разными способами, даже как-то баловался с GmailFS. Пару месяцев назад я попробовал Диск от Яндекса, и сейчас могу совершенно определенно сказать, что в кои-то веки Яндекс создал хоть что-то приличное. Уж не знаю, как позиционирует его сам Яндекс, но мне этот сервис приглянулся для хранения бэкапов. У меня оно работает примерно так:

# cat /etc/davfs2/davfs2.conf 
cache_dir       /var/cache/davfs2
cache_size      50
table_size      1024
dir_refresh     60
file_refresh    1
delay_upload    0
use_locks    0

Файл /etc/davfs2/secrets содержит строчку с логином и паролем на Яндекс.Диск:
https://webdav.yandex.ru topsecretlogin “topsecretpassword”

В /etc/fstab прописывается строчка:
https://webdav.yandex.ru /backup davfs rw,user,noauto 0 0

Почти готово. Теперь Яндекс.Диск легко монтируется командой mount /backup без ввода пароля. На тот случай, если кто-то посторонний получит доступ к бэкапам, их по-хорошему следует зашифровать чем-нибудь криптостойким, например, gpg.

Уже третий месяц сервис работает почти без нареканий, и бэкапы по расписанию аккуратно заливаются на Яндекс.Диск.

Один недостаток я нашел, но он не имеет отношения к сервису Яндекса. Периодически в директории /var/cache/davfs2 накапливается довольно много файлов, которые davfs2 почему-то не удаляет при размонтировании директории /backup. Чтобы исключить переполнения раздела /var, я их чищу после размонтирования:
/bin/rm -Rf /var/cache/davfs2/webdav.yandex.ru*