Нашел в гугле инфу про тулзу 'specter' (форк от улога с поддержкой нескольких nlgroup одним демоном). Но вот подумал, что может быть есть что-то более новое/удобное. Не могли бы вы посоветовать что-то конкретное? Желательно что-то элементарное, навроде ulog'а.

Спасибо!

Почитал на тему (D)DoS атак, вопрос снят. Всем спасибо!

Законопослушный пользователь с ip адресом отправителя флуда?

Вы о расширении recent?

Однако стоит перенести 22-й порт, на который лезет пионЭрия

Спасибо за советы! Это я первым делом сделал. Самое простое и очевидное. К тому же, доступ разрешен только из LAN и входящих ВПН подключений.

Я к тому - а как в подобном случае отличать упорных от неупорных? Ведь все подряд будут отметаться, а через сито 1 раз в секунду будут проходить случайные пакеты. В том числе - флудерские. Вернее: в большинстве своем флудерские, ибо их на порядки больше, нежели "честных".

Я сам принцип все в толк взять никак не могу. 
То есть, на время флуда правило:
iptables -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j ACCEPT
сам зафлуживаемый сервис доступнее никак не делает. То есть, по сути, происходит успешный DoS (если флуд достаточно интенсивный).

Как я разумею, эти правила защищают сам интрефейс от зависания. А для защиты от DoS нужны другие меры. Например, поднять необнаруживаемый снаружи виртуальный интерфейс в той же сети. Не отвечающий на эхо-запросы, вообще ни на что не отвечающий, кроме стука по одному конкретному порту. К которому можно подключиться, пока брандмауэр отмахивается от нападок флудера на основном адресе.

Я таки верно мыслю или совсем чего-то не понимаю?.. 

Мне казалось, что отправитель флуда в поле source_address флуд-пакетов может указывать что угодно (в том числе IP законопослушных пользователей - для пущего смеха): ему ведь не нужны ответы сервера... Т.е. он может генерировать случайный IP для каждого пакета.

Это тоже легко прикрывается. А именно - дропать упорных это правильно. Но всё равно в журнале все равно регистрируются такие попытки. Однако стоит перенести 22-й порт, на который лезет пионЭрия, на какой угодно случайно выбранный номер где-то там, наверху, а 22-й закрыть перманентно, как количество попыток подбора пароля сокращается на порядки. Проверено лично. Как только порт перенес - ни одной попытки подбора нет.
Ну и к этому еще маленькая фишка - у меня в интернет смотрит роутер (тупой до безобразия), который умеет редиректить порты, внешние, случайно выбранные, на стандартные порты реальных хостов в LAN. И чтобы работать с реальными хостами (на стандартных портах) - поднимаем VPN (openVPN). Или, если VPN нет, то тогда идем "через порты роутера".

Мне казалось, что отправитель флуда в поле source_address флуд-пакетов может указывать что угодно (в том числе IP законопослушных пользователей - для пущего смеха): ему ведь не нужны ответы сервера... Т.е. он может генерировать случайный IP для каждого пакета.

но "законопослушному" пользователю будет подключиться не реально. Т.к. вероятность того, что именно на его пакете правило сработает на разрешение обратно пропорциональна количеству флуд-пакетов. Или я не прав?

Законопослушный пользователь с ip адресом отправителя флуда?

> Трактовка примерно такая - будут приняты не более одного tcp пакета в секунду с флагами ALL RST
Это я понял... Я не понял смысла такой меры. Исключительно защита буфера от зафлуживания?

Например, при усердном флуде SSH порта SYN пакетами с подменой IP отправителя (даже с одной машины можно генерировать кучу пакетов в секунду) переполнения буфера полуоткрытых соединений не произойдет, но "законопослушному" пользователю будет подключиться не реально. Т.к. вероятность того, что именно на его пакете правило сработает на разрешение обратно пропорциональна количеству флуд-пакетов. Или я не прав?

1 iptables -N ssh_brute_check 
2 iptables -A ssh_brute_check -m conntrack --ctstate NEW -m recent --update --seconds 600 --hitcount 3 -j DROP
3 iptables -A ssh_brute_check -m recent --set -j ACCEPT
4 iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 22 -j ssh_brute_check

1 Создаем цепочку для проверки попыток соединений на защищаемый порт
2 Если за последние 10 минут (600 секунд) с одного адреса было 3 или более новых соединений — блокируем этот адрес
3 В противном случае — разрешаем
4 Все попытки открыть новое соединение по SSH направляем на проверку
...
Есди правило такое:

iptables -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j ACCEPT

Трактовка примерно такая - будут приняты не более одного tcp пакета в секунду с флагами ALL RST
Всё остальное на усмотрение установленной политики (DROP в нормальном варианте).

  #Incoming traffic
  einfo "Creating incoming ssh traffic chain"
  $IPTABLES -N allow-ssh-traffic-in
  $IPTABLES -F allow-ssh-traffic-in
  #Flood protection
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL RST --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL FIN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL SYN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT

Тут, по крайней мере, все понятно и логично...

Правда, я не совсем понимаю сути этой защиты... Если какой-то усердный товарищ будет долбить 22й порт такими пакетами, то ведь и "честный" пользователь будет испытывать проблемы при подключении? Тут уж кому повезет - чей пакет первым проскочит в очередную секунду, разве нет?

$IPTABLES -A ssh-in -m limit ! --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j DROP

(если я верно понял описание этого модуля из доков)

Почитай гентушные доки
...
Логика_и_правила_iptables

Немного не пойму вот этого участка из приведенного источника:

# 2. Входящий SSH трафик
  einfo "Creating incoming ssh traffic chain"
  $IPTABLES -N ssh-in
  $IPTABLES -F ssh-in
  $IPTABLES -A ssh-in -p tcp --dport 22 -j ACCEPT
# Защита о флуда по SSH
  $IPTABLES -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j ACCEPT
  $IPTABLES -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL FIN --dport ssh -j ACCEPT
  $IPTABLES -A ssh-in -m limit --limit 1/second -p tcp --tcp-flags ALL SYN --dport ssh -j ACCEPT
  $IPTABLES -A ssh-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT

Сперва правилом $IPTABLES -A ssh-in -p tcp --dport 22 -j ACCEPT безусловно разрешаются входящие TCP соединения на 22й порт. А потом добавляется ворох правил с ограничением по времени в качестве защиты от флуда. Какой в этом смысл? Ведь до них просто не будет до ходить дело: будет постоянно отрабатывать первое разрешающее правило. И если его поставить после правил с limit, это тоже играть роли не будет.

В чем я не прав?

Не совсем понимаю, что такое SSH-флуд... Это следствие неправильного взаимодействия клиента-сервера или злонамеренных действий злоумышленника? Необходимо ли предусматривать защиту от такого флуда, если SSH-демон поднят на нестандартном порту?

Спасибо!