Архивы рубрики: Linux

Логирование HTTP трафика для отладки запросов AJAX в Linux

Posted on by

Часто разработчику требуется видеть весь обмен трафиком между клиентом и сервером, не только заголовки HTTP, но и тело запроса и ответа. Я довольно долго разыскивал подходящий инструмент для этих целей. Но оказалось, что удобнее всего пользоваться не какими-то плагинами для браузера, а простейшим прокси и перехватом трафика с помощью tcpdump.

Выглядит это так:

1. В браузере прописываем использование прокси по адресу 127.0.0.1 порт 5678
2. В терминале открываем сессию ssh с локальным порт-форвардингом (можно и со сжатием трафика), например так:

$ ssh -C -D 5678 username@myhost.com

3. В другом терминале запускаем tcpdump и слушаем трафик на интерфейсе lo порт 5678:

# tcpdump -vvv -s0 ‘port 5678′ -w “/home/username/http.pcap” -i lo

Далее в браузере выполняем необходимые действия, после чего останавливаем tcpdump. Смотреть записанный трафик лучше всего с помощью strings:

$ strings /home/username/http.pcap

Иногда в выводе может быть немного мусора из-за keepalive запросов, но в целом видно все, что требовалось узнать.

Запуск джоба чаще, чем 1 раз в минуту

Posted on by

Старый добрый cron не позволял ставить в расписание задачи, которые бы запускались чаще, чем 1 раз в минуту. Приходилось решать подобные задачи совсем другими способами. Но теперь есть systemd, который умеет это делать.

Пример такой конфигурации:

server:/etc/systemd/system # cat my.service
[Unit]
Description=My Script

[Service]
Type=simple
ExecStart=/path/to/my/script.sh
StartLimitInterval=0
StartLimitBurst=0

server:/etc/systemd/system # cat my.timer
[Unit]
Description=Runs job every 10 seconds

[Timer]
OnBootSec=1sec
OnCalendar=*-*-* *:*:0,10,20,30,40,50
Unit=my.service

[Install]
WantedBy=multi-user.target

Запуск таймера:

# systemctl start my.timer

Добавление в автозагрузку:

# systemctl enable my.timer

Мониторинг работы:

# journalctl -f

Оживление почти убитого D-Link DNS 320l

Posted on by

У меня этот чудо девайс работает уже полтора года. Работает отлично, и особых нареканий к нему нет. Разве что стоковая прошивка совсем уж бедная по своим возможностям, и чтобы более полноценно использовать D-Link DNS 320l, желательно установить на него fun_plug, или прошить альтернативной прошивкой Alt-f.

fun_plug я поставил в первую очередь, и он мне очень понравился. Можно ставить дополнительные программы, использовать всю мощь доступа по ssh, в том числе и для бэкапа важных данных через rsync. Все просто замечательно было с fun_plug, если бы не сильно урезанное ядро системы. Уж не знаю зачем, но D-Link в своем firmware из ядра выпилил модуль iptables, и без него невозможно настроить nat, маскарадинг и прочие прелести. А мне вот что-то вдруг захотелось развернуть на своем аппарате OpenVPN, и я решил таки сменить прошивку на Alt-f.

Кстати, Alt-f — молодцы, сделали весьма качественный продукт. Комьюнити проекта пока не очень большое, но оно динамично развивается. Мне прошивка в целом понравилась, но в ней есть и минусы:

1. Веб интерфейс D-Link DNS 320l в прошивке Alt-F весьма убог по сравнению с родым firmware D-Link. Это не так критично, если конфигурировать устройство через консоль, но все равно — неприятно.

2. По умолчанию после установки прошивки у меня не запустился важны демон — dns320l-daemon. Он снимает показания с датчиков температуры и без него вентилятор охлаждения просто не запустится. А это уже серьезно, поскольку чревато перегревом как процессора, так и винчестеров и выходом их из строя. Проблема эта легко устраняется, но надо знать, что проблема существует.

3. Самое раздражающее в новой прошивке — это невозможность выключить сетевое хранилище программно. Нажатие на кнопку Power не выключает его, но останавливает работу всех сервисов и переводит коробочку в режим ожидания. И выключить хранилище по расписанию уже не представляется возможным, оно просто уйдет в спячку и дальше будет гудеть своим вентилятором.

В общем, поигравшись вдоволь с прошивкой Alt-F, я все-таки решил откатиться к прошивке оригинальной D-Link. И тут случилось страшное, во время перепрошивки хранилища пропало питание — и D-Link DNS 320l перестал загружаться. Совсем. Кнопка сброса к заводским установкам не помогла — достучаться до хранилища не было никакой возможности.

Последней надеждой была возможность подключения к хранилищу через serial console, для этого надо было найти соответствующие места на плате хранилища и припаять к ним провода. Но пайка проводов — это полбеды; настоящей проблемой было найти переходник RS232-ttl или USB-ttl. Причем DNS 320l использует низковольтный ttl (3.3 вольта), поэтому далеко не факт, что подойдет переходник на 5-вольтовый TTL. У нас в городе так и не удалось найти ни одного готового переходника, или подходящего телефонного дата-кабеля для создания такого переходника. Пришлось заказывать переходник в Китае, на AliExpress.

Удивительно, но покупка двух переходников на микросхеме PL2303 в Китае с доставкой в Россию оказалась намного выгоднее, чем покупка отдельных деталей и сборка своими силами. Я отдал меньше 1 доллара за каждый из переходников, а заказал я их 2 штуки — поскольку предполагал, что своими неумелыми действиями я могу спалить этот переходник. В общем, мне удалось подключить переходник к плате хранилища, и при включении питания хранилища я мог видеть все сообщения загрузки системы.

Выяснилось, что загрузчик u-boot был в полном порядке, а вот при попытке загрузки ядра выскакивало следующее сообщение:

...
starting pid 538, tty '': '/etc/rc.sh'
** Mounting /etc/fstab
umount: proc: not mounted
umount: proc: not mounted
umount: /usr/local/modules: not mounted
sh: can't open /usr/sbin/pre_usb.sh
umount: /usr/local/tmp/image.cfs: not found
umount: /usr/local/tmp: not mounted
first good block is 0
image len = 1835626867 , image checksum = 5f656761
kernel or ramdisk error
...

Образ рамдиска или ядра был битым во флеш-памяти, я мне надо было его перезаписать по новой. Говорят, как-то можно перезаписать флеш-память командами из u-boot, но я поступил по-другому.

Сначала я скачал firmware Alt-f, и с помощью утилиты dns323-firmware-tools-master извлек из firmware образ ядра и рамдиска:

splitdns323fw -k uKernel -i uInitrd -d uDefaults -s uSquashfs Alt-F-0.1RC4-DNS-320L-rev-A1.bin

На выходе получил файлы uKernel, uInitrd, uDefaults и uSquashfs (последние 2 не понадобились). Далее, развернул сервер tftp и в его корень положил полученные файлы. Потом, при загрузке хранилища в нужном месте нажал пробел и единицу, в результате получил доступ к командной строке u-boot:

 ** MARVELL BOARD: DB-88F6702A-BP LE
U-Boot 1.1.4 (Aug 22 2012 - 17:06:54) Marvell version: 3.6.0.DNS-320L.01
U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFB00
Soc: 88F6702 A1 CPU running @ 1000Mhz L2 running @ 500Mhz
SysClock = 400Mhz , TClock = 166Mhz
DRAM (DDR2) CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:128 MB
Flash:  0 kB
CPU : Marvell Feroceon (Rev 1)
Streaming disabled
Write allocate disabled
USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0 [PRIME]
Hit any key to stop autoboot:  0
Marvell>>

Про «Hit any key to stop autoboot» они конечно переврали, надо нажимать строго Пробел и потом цифру 1. Дальше последовательность действий была такой:

setenv ipaddr 192.168.1.7 # прописываю IP адрес сетевого хранилища
setenv serverip 192.168.1.9 # прописываю IP адрес tftp-сервера
tftp 0xa00000 uKernel # загружаю образ ядра в формате u-boot в память по адресу 0xa00000
tftp 0xf00000 uInitrd # загружаю initrd в память по адресу 0xf00000
bootm 0xa00000 0xf00000 # запускаю операционную систему БЕЗ перешивания флеш памяти — если что-то пойдет не так, всегда можно перезагрузиться.

Через некоторое время загрузился интерфейс Alt-F по адресу http://192.168.1.7 В нем уже есть возможность полноценно залить прошивку Alt-F или D-Link во флеш-память. После перепрошивки перезагрузился — и все заработало. Правда, при перепрошивке слетели все настройки — но это уже мелочи, сетевое хранилище удалось оживить.

Perl: как избавиться от Wide character in print

Posted on by

Как известно, при запуске программы на Perl автоматически открываются 3 файловых дескриптора: STDIN, STDOUT и STDERR. По умолчанию они не используют кодировку utf8, поэтому print вполне может выдавать вот такой вот warning при выводе кириллических символов:

Wide character in print at line …

Ничего страшного в этом нет, но такие предупреждения засоряют вывод и раздражают меня. Лечится это довольно просто, например, привязкой режима utf8 к уже открытому файловому дескриптору в начале программы:

binmode(STDOUT,’:utf8′);

Но есть и более элегантное решение. Можно прописать в самом начале программы флаг, который скажет интерпретатору Perl открывать файловые декрипторы при запуске программы сразу в utf8, примерно так:

#!/usr/bin/perl -CS

И больше никаких манипуляций с binmode не потребуется

Xfce, screen lock и смена раскладок клавиатуры

Posted on by

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

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

  • Установить xkb-switch
  • Написать скрипт-обертку, подменяющий стандартный скрин локер:
    • > cat /usr/local/bin/xflock4
#!/bin/bash
/usr/local/bin/xkb-switch -s us
/usr/bin/xflock4

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

    OpenSuSe 13.1, ноутбук с видеокартой Nvidia и старые игры в wine

    Posted on by

    Так получилось, что ранее я ругал карты ATI Radeon здесь, тут и там. И для разнообразия у меня появился ноутбук Lenovo Z560 с карточкой Nvidia на борту. Пропиетарные дрова с сайта Nvidia ставятся без проблем, все работает хорошо — за исключением одного маленького нюанса.

    Почему-то разработчики драйверов перешли на новую версию протокола randr, и теперь в системе для экрана ноутбука определяется только одно единственное разрешение экрана:

    > xrandr -q
Screen 0: minimum 8 x 8, current 1366 x 768, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
   1366x768       60.0*+   50.0  
HDMI-0 disconnected (normal left inverted right x axis y axis)

    В старой версии протокола разрешений экрана можно было получить гораздо больше:

    > xrandr --q1
 SZ:    Pixels          Physical       Refresh
*0   1366 x 768    ( 340mm x 191mm )  *50   51  
 1   1280 x 720    ( 318mm x 179mm )   52  
 2   1024 x 768    ( 254mm x 191mm )   53  
 3    800 x 600    ( 199mm x 149mm )   54  
 4    640 x 480    ( 159mm x 119mm )   55  
Current rotation - normal
Current reflection - none
Rotations possible - normal left inverted right 
Reflections possible - X Axis Y Axis

    Если надо кодить, или править документ какой-нибудь, то проблемы это не вызывает. Но если решил порубиться в старую игрушку с древним разрешением экрана (например, 640×480), то игра вполне себе может ругаться на разрешение экрана. Например, у меня fallout не запускался, и появлялось сообщение Error initializing video mode 640×480, и в консоли при этом был виден текст ошибки такого вот содержания:

    err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 640x480x8 @0! (XRandR 1.2)

    Оказывается, проблему победить можно. Надо лишь наваять 2 скрипта и поместить их куда-нибудь в пути. Первый скрипт позволяет менять разрешение экрана из командной строки:

    > cat setres.sh
#!/bin/bash
RESOLUTION=$1
nvidia-settings --assign CurrentMetaMode="LVDS-0: nvidia-auto-select @$RESOLUTION +0 +0 {ViewPortIn=$RESOLUTION, ViewPortOut=$RESOLUTION}"

    Второй скрипт собственно меняет разрешение экрана на правильное, запускает fallout в десктопе со «правильным» разрешением экрана, ну и возвращает настройки разрешения обратно по завершении игры:

    > cat fallout1.sh
#!/bin/sh
cd /home/username/.wine/drive_c/Program Files/GOG.com/Fallout
/usr/local/bin/setres.sh 640x480
wine explorer /desktop=foo,640x480 falloutw.exe
/usr/local/bin/setres.sh 1366x768
cd $HOME

    Смена разрешения на 640×480 — необязательный шаг, и если его не сделать, можно играть в оконном режиме. А вот для полноэкранного режима без смены разрешения не обойтись.

    Вышла OpenSuSe 13.1

    Posted on by
    Логотип OpenSuSe

    И вот черт меня дернул попробовать совсем уж новый дистрибутив. Обычно я не ставлю первые версии дистрибувов, т. к. они скорее всего будут сырыми и необкатанными, но в этот раз что-то меня переклинило и я поставил OpenSuSe 13.1 x86_64.

    В Gnome 3 работать невозможно, но об этой проблеме известно уже давно. Все их увещевания о том, что новый дизайн гнома является совершенством — мне очень напоминает историю про Windows 8 и кнопку «Пуск». Но в отличие от Microsoft, разработчикам Gnome было начхать на мнение пользователей, и к стилю проверенного временем Gnome 2 они возвращаться не хотят. Ну что ж, такова жизнь — прощай, Gnome 3.

    От KDE 4 я тоже не в восторге, уж больно он тяжелый. В OpenSuSe 12.2 я пару дней потратил на то, чтобы его допилить до удобного мне вида, но в этот раз даже заморачиваться не стал и решил поставить что-то другое. IceWM конечно очень легкий, но уж слишком он убого выглядит. Поэтому в этот раз в качестве оконного менеджера я выбрал Xfce, и в общем, остался доволен.

    Самое первое, что надо сделать — это поставить пропиетарные дрова на видеокарты ATI Radeon. К великому сожалению, опенсорсный аналог для этого драйвера не умеет пробуждаться после перехода в спящий режим. И тут дело даже не в дистрибутиве, дело в самом драйвере. С похожей проблемой столкнулись и убунтоводы с Хабра.

    Мне очень не понравилась настройка раскладок клавиатуры. Как ее не настравивай, после перезагрузки системы настройки слетали нафиг, и язык оставался только тот, что стоял по умолчанию. Проблему удалось решить вот как. Ставится пакет fsKbsettings вот отсюда, создаются для каждого пользователя директории /home/username/.config/autostart и с помощью этой утилиты под индивидуальные нужды легко и непринужденно настраивается раскладка клавиатуры.

    Вторая серьезная проблема — скайп сразу не заработал. Версия, скачанная с skype.com для SuSe, была 32-битной, и предназначалась для OpenSuSe 12.1. Она без проблем ставилась на 12.2, но отказывалась устанавливаться на 13.1, и выглядело это так:

    # rpm -ivh skype-4.2.0.11-suse.i586.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:skype-4.2.0.11-suse121           ################################# [100%]
error: unpacking of archive failed on file /usr/bin/skype;528dc292: cpio: read failed - No such file or directory
error: skype-4.2.0.11-suse121.i586: install failed

    Но если скачать версию dynamic, раскидать иконки, звуки, аватарки и файлы lang в /usr/share/skype — скайп запускается, но голосовые звонки в нем не работают. Да и звук вообще не работает, тут требуется кое-что допилить.

    Во-первых, эта версия skype не там ищет некоторые библиотеки. Я сделал симлинк на новую директорию со старым названием:

    # ln -s /usr/lib/alsa-lib /usr/lib64/alsa-lib

    Во-вторых, в свете последних изменений в коде PulseAudio, надо задавать некоторые переменные среды, чтобы скайп корректно заработал со звуком. В результате чего родился вот такой скрипт запуска скайпа:

    $ cat start_skype.sh
#!/bin/sh                                                                         
PULSE_LATENCY_MSEC=60 /usr/local/bin/skype

    Вот теперь скайп работает так, как и ожидалось.

    Но в целом, дистрибутив мне понравился. Косяки со скайпом — это скорее проблема Microsoft, которая не успевает релизить свои версии программ под новые дистрибутивы.

    И тем не менее, мораль сей басни такова. Если не хотите стать добровольным бета-тестером, никогда не ставьте дистрибутивы первых версий. Времени на допиливание уйдет довльно много, и далеко не факт, что все заработает как надо.

    OpenSuse и интернет через Bluetooth

    Posted on by

    Nokia E5

    Я уже писал про использование телефона Nokia E5 в качестве модема, и даже приводил настройки интернета для черногорского оператора M-tel. Все это работает отлично, если бы не одно НО. Длинна USB кабеля для Nokia E5 меньше 10 сантиметров, и уж очень неудобно его крепить к ноутбуку. Телефон постоянно свешивается, дергается; связь может теряться в зоне неуверенного приема. И я решил попробовать использовать телефон в качестве модема при соединении через Bluetooth.

    Оказалось, все делается очень просто. Сначала надо сделать так, чтобы телефон и ноутбук снюхались по Bluetooth. Это делается очень просто — на телефоне разрешается соединение Bluetooth для всех, и с помощью апплета gnome-bluetooth находится телефон среди доступных. Далее следует обмен пин-кодами и вуаля, две железки снюхались.

    Затем надо посмотреть, какой канал модема используется в телефоне. Ищем адрес телефона:

    notebook:~ # hcitool scan
Scanning ...
        04:A8:2A:93:CE:48       Nokia E5

    Далее выясняем номер канала модема:

    # sdptool browse 04:A8:2A:93:CE:48
…
Service Name: Dial-Up Networking
Service RecHandle: 0x10009
Service Class ID List:
  "Dialup Networking" (0x1103)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 5
Language Base Attr List:
  code_ISO639: 0x454e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0100
…

    В моем случае это Channel 5. Теперь надо настроить модем:

    # cat /etc/bluetooth/rfcomm.conf
#
# RFCOMM configuration file.
#

rfcomm0 {
        # Automatically bind the device at startup
        bind yes;

        # Bluetooth address of the device
        device 04:A8:2A:93:CE:48;

        # RFCOMM channel for the connection
        channel 5;

        # Description of the connection
        comment "Nokia E5 Bluetooth Modem";
}

    Номер канала в настройках модема должен совпадать с номером обнаруженного канала, иначе модем работать не будет. После этого надо создать конфигурационный файл для «звонилки». Привожу свой конфиг для черногорского оператора T-mobile:

    # cat /etc/wvdial.conf
[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP","tmcg-wnw"
Modem = /dev/rfcomm0
Phone = *99#
Idle Seconds = 30000
Modem Type = USB Modem
Stupid Mode = 1
Compuserve = 0
Baud = 460800
Auto DNS = on
New PPPD = Yes
Dial Command = ATDT
Ask Password = 0
ISDN = 0
Password = 38167
Username = 38167

    Ну и последний скрипт запуска «звонилки»:

    # cat start_internet_via_bluetooth.sh
#!/bin/sh
rfcomm release 0 # разрываем текущую связь устройства с модемом
rfcomm bind 0 04:A8:2A:93:CE:48 5  # привязываем модем телефона на 5-м канале к устройству rfcomm0
wvdial # набираем номер и подключаемся к интернету

    Вот теперь телефону не обязательно находиться рядом с ноутбуком. Его можно держать, например, на балконе (где уровень сигнала выше чем в помещении). Главное, чтобы ноутбук видел телефон, а телефон видел сеть. Скорости передачи данных более чем достаточно для голосовой связи по SIP или Skype.

    Про уродов и людей: как защититься от UDP флуда.

    Posted on by

    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.

    Posted on by

    Сначала меня забавляли нелепые попытки подобрать пароли по 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 перестает зависать.