В понедельник вышел отчет SANS Internet Storm Center (http://isc.sans.org/), предупреждающий о значительном росте количества brute-force атак на SSH серверы. В основе атаки лежит метод подбора паролей по определенному алгоритму или по словарю. Отчет основывается на информации, предоставленной непосредственно пользователями или через почтовые конференции.Данные собранные DenyHosts.org подтверждают эту информацию. На графике (http://stats.denyhosts.net/stats.html) видно резкое увеличение попыток взлома SSH серверов.
Рекомендации по защите от несанкционированного доступа предлагаются стандартные: разрешение доступа к серверу только с хостов с определенным именем, блокирование входа в систему root, использование стойких паролей и имен пользователей, использование аутентификации по публичному ключу или многоуровневой аутентификации, ограничение публичного доступа к второстепенным сервисам, например, с помощью iptables.
URL: http://lwn.net/Articles/282218/
Новость: http://www.opennet.me/opennews/art.shtml?num=15874
Хххх, из мухи слона сделали. SSHGuard, или ограничение по открытию новых соединений в еденицу времени с одного ip.
Кто сказал, что подключения ведутся с одного хоста?
>Кто сказал, что подключения ведутся с одного хоста?log'и.
есть такой анекдот:
> вчера перечитывал log'и. долго думал.
>>Кто сказал, что подключения ведутся с одного хоста?
>log'и.Кстати да, долбятся как дятлы.
Видел решение с отсылкой одного особенного пакета, после чего в правилах автоматом прописывалось разрешение на коннект с того ип откуда этот спец пакет пришел. Это один вариант, довольно интересный на мой взгляд.
Насчет атак, это они логи моего шлюза не видели, 90% всех левых тыканий по портам это брут на ссш. И так было и год назад, и два и три.
> Видел решение с отсылкой одного особенного пакета, после чего в правилах автоматом прописывалось разрешение на коннект с того ип откуда этот спец пакет пришел.Не проще ли открыть VPN-соединение, и потом по нему коннектиться по SSh?
если перевесить ssh на другой порт, то атаки прекратятся :)
>если перевесить ssh на другой порт, то атаки прекратятся :)если атака целенаправленная - не прекратятся. просканят порты и продолжут муму колбасить.
Да, если цель - именно эта машина, то да, будут долбить во все порты. Но чаще просто находят открытый 22-порт, и начинают ломать. В таком случае перенос номера порта помогает почти на 100 прОцентов.
>Да, если цель - именно эта машина, то да, будут долбить во
>все порты. Но чаще просто находят открытый 22-порт, и начинают ломать.
>В таком случае перенос номера порта помогает почти на 100 прОцентов.
>Угу. Роботы же долбят.
а что мешает ограничивать доступ к ssh по IP или хосту допустим? религия? :D
принцип "что не разрешено - то запрещено" никто не отменял.
>а что мешает ограничивать доступ к ssh по IP или хосту допустим?
>религия? :D
>принцип "что не разрешено - то запрещено" никто не отменял.Это не всегда удобно. Доступ может потребоваться из разных (случайных) мест.
fail2ban поможет буратинам :)
+1
Не держите ссх на 22-м порту и будет вам счастье.
+1
>Не держите ссх на 22-м порту и будет вам счастье.если публичный сервер - это не сильно помогает.
не сильно-то и удобно, если к серверу, например, нужен доступ из разных мест по svn поверх ssh - создавать каждый раз custom transport замахаишьси.
>не сильно-то и удобно, если к серверу, например, нужен доступ из разных
>мест по svn поверх ssh - создавать каждый раз custom transport
>замахаишьси.
Ой, да ладно... Атаки были, есть, и будут есть. Когда у нас появляется новый
наверняка связано с недавними проблемами с openssl в debian
>наверняка связано с недавними проблемами с openssl в debianнет, не связано. Проблемы с openssl ключами никак не влияют на стойкость паролей.
>>наверняка связано с недавними проблемами с openssl в debian
>
>нет, не связано. Проблемы с openssl ключами никак не влияют на стойкость
>паролей.Рост числа атак действительно может быть связан с последними ошибками в Дебиановском openssl. Оказалось, что возможное число ключей, которые генерились последние два года на деб-машинах, сильно ограничено (~2^16). Можно довольно эффективно удалённо брутфорснуть логин с аутентификацией по незапароленному ключу.
сервер, его атакуют в тот же день или от силы на следующий.
Но атакуют с одного-двух айпишнеков. Стоит его загнать в hosts.deny, как всё становится спокойно. Недельку побанить такие ботнеты, и можно расслабиться - атак больше нет.
>если атака целенаправленная - не прекратятся. просканят порты и продолжут муму колбасить.если атака целенаправленная, то никто не будит брутить %)
брутят скрипты/сканеры и прочая шваль автоматизированная
тупых школьнегов и недохацкеров еще никто не отменял. начитаются доисторической литературы, а потом рвуться все поломать. хотя таких в последнее время становится все меньше и меньше. взрослеют наверно.
А какая разница с каких ip ведутся атаки? Делаем с помощью iptables или pf ограничение по открытию новых соединений с одного хоста (например не больше трёх в минуту), и тогда brute-force просто теряет смысл - время перебора становится непомерно большим.
> А какая разница с каких ip ведутся атаки? Делаем с помощью
>iptables или pf ограничение по открытию новых соединений с одного хоста
>(например не больше трёх в минуту), и тогда brute-force просто теряет
>смысл - время перебора становится непомерно большим.ботнеты еще никто не отменял.
Хахаха, нашли проблему.
Ну, все время кто-то что-то там подбирает. Ну и что?
Если пароль взломоустойчивый то пускай подбирают.
Я не обращал и не обращаю никакого на это внимания.
Проблема находится тогда, когда ты пытаешься зайти на сервер, а тебя не поскает - потому что два бота DoSят твой sshd, перебирая пароли с максимальной возможной скоростью из расчёта, что бот один. Когда бот один - это не заметно. Когда их двое - третий уже не может зайти. Поэтому надо банить или ограничивать соединения по айпи.
denyhosts и никаких проблем.
Новость высосана из пальца.
>denyhosts и никаких проблем.
>Новость высосана из пальца.Это не новость а предостережение!
Пример с теми же червями, все знают что они есть, но иногда полезно знать что-то такой-то червь на таком-то порту набирает обороты...
Чем то напомнило анекдот:В чате:
HaCKer - Дайте мне IP какого-нибуль лоха, ща я его завалю!
Некто - 127.0.0.1
системное сообщение: HaCKer вышел из чата
По крайней мере, экспериментально доказано, что уже и BF-боты используют 1337. Порщайте, читаемые p@55w0rd-ы.
bilo bi xorosho eslib sshguard bil v sshd "integrirovan"
дам а просче всего запратит ползоватся user/pass толко с ключик и все ... атаки можно делата но они без смисл.
Да, за последнюю неделю увеличелось офигенно. первая колонка дата, вторая кол-во забаненных ИПшников. Причем после 5 неудачных логинов, ИПшка банится на час. По моим наблюдениям, в атаке участвуют до 1000 машин с разными ИП.FW 2
05 6
06 31
07 250
08 332
09 291
10 86
11 15
12 673
13 472
14 389FW 2
05 2
06 1
07 11
08 13
09 9
10 6
11 3
12 1243
13 418
Спасибо :-)
Я делаю так: автоматически запускается скрипт, проверяющий лог на предмет большого числа попыток подключиться к ssh, и, для "провинившегося" IP добавляю правило в iptables. Одновременно генерирую скрипт удаления этого правила. Следующим днем выполняю скрипт, и, накопившиеся правила предыдущего дня, сбрасываются.
И потом, важно придумать "хороший" логин и сложный пароль. Мой логин еще не разу не угадали - до пароля даже не дошло...
>Я делаю так: автоматически запускается скрипт, проверяющий лог на предмет большого числа
>попыток подключиться к ssh, и, для "провинившегося" IP добавляю правило в
>iptables. Одновременно генерирую скрипт удаления этого правила. Следующим днем выполняю скрипт,
>и, накопившиеся правила предыдущего дня, сбрасываются.
> И потом, важно придумать "хороший" логин и сложный пароль. Мой
>логин еще не разу не угадали - до пароля даже не
>дошло...использовать модуль recent на иптаблесе религия не позволяет?
> И потом, важно придумать "хороший" логин и сложный пароль. Мой
>логин еще не разу не угадали - до пароля даже не дошло...KjubyЕo`НbРfpeНtУuflfkb-LjGfhjkzLf;tYtLjikj... - ЛогинЕщеНеРазуНеУгадали-ДоПароляДажеНеДошло...
Пошел менять пароль :)
#!/bin/sh
# дата по которой фильтровать может быть в нужной форме: "Май 15" и "Май 1"
sToday=`date +%b" "%e`
cat /var/log/messages | grep sshd | grep "Invalid user" | grep "$sToday" | awk '{print $10}' | sort| uniq -c | sort -r -n | head -n 15 > /tmp/top_ssh
sDate=`date +%d.%m.%y`
sAutoDeleteLog=/var/log/fw_auto_ip${sDate}.log
sChangeDate=`date +%Y"-"%m"-"%d`
# отладка
cat /tmp/top_ssh >> /var/log/debug.log
while read row; do
iCount=`echo "$row" | cut -f 1 -d " "`
sIP=`echo "$row" | cut -f 2 -d " "`
# проверка от повторной вставки правила
sExists=`/usr/sbin/iptables -t filter -L -n | grep "$sIP"`
echo "IP=$sIP Count=$iCount Exist=$sExists" >> /var/log/debug.log
if [ -z "$sExists" ]; then
if [ $iCount -gt 50 ]; then
/usr/sbin/iptables -t filter -I INPUT -s $sIP -j DROP
/usr/sbin/iptables -t filter -I INPUT -s $sIP -m limit --limit 3/min -j LOG --log-prefix "AUTO_FILTER" --log-tcp-options --log-ip-option
echo "/usr/sbin/iptables -t filter --delete INPUT -s $sIP -j DROP" >> $sAutoDeleteLog
echo "/usr/sbin/iptables -t filter --delete INPUT -s $sIP -m limit --limit 3/min -j LOG --log-prefix "AUTO_FILTER" --log-tcp-options --log-ip-option" >> $sAutoDeleteLog
touch -c --date=$sChangeDate $sAutoDeleteLog
echo "IP=$sIP Count=$iCount `date` ADDED" >> /var/log/messages_auto_fw.log
fi
else
echo " IP=$sIP Count=$iCount EXISTS! " >> /var/log/debug.log
echo " IP=$sIP Count=$iCount EXISTS! " > /dev/null
fi
done < /tmp/top_sshrm -f /tmp/top_ssh
# отладка очищена echo " " > /var/log/debug.logif [ -f $sAutoDeleteLog ]; then
chmod +x $sAutoDeleteLog
chmod o-rwx $sAutoDeleteLog
fifind /var/log/ -type f -regex ".*\/fw_auto_ip.*\.log$" -mtime +1 -exec '{}' \;
find /var/log/ -type f -regex ".*\/fw_auto_ip.*\.log$" -mtime +1 -exec mv -f '{}' /root/ \;
перманентный фильтр на 22 порту с:
table <sshallow> persistpass from <sshallow> to $inet_addr port ssh keep state
Таблица <sshallow> заполняется путём выполнения шелл-скрипта из серверной части https-страницы, авторизующей пользователей по сертификатам. В конце шелл-скрипта стоит незатейливый примерно так: 'at "now + 5 minutes" pfctl -t sshallow -Td $HOSTIP', выглядящий уборщик мусора из таблицы.
KNOCK1="123"
KNOCK2="456"
KNOCK3="789"
KNOCK4="555"
TIME_OPEN="30"/sbin/iptables -N knock_rmv
/sbin/iptables -A knock_rmv -m recent --name phase1 --remove
/sbin/iptables -A knock_rmv -m recent --name phase2 --remove
/sbin/iptables -A knock_rmv -m recent --name phase3 --remove
/sbin/iptables -A knock_rmv -m recent --name phase4 --remove/sbin/iptables -N knock_ph1
/sbin/iptables -A knock_ph1 -m recent --name phase1 --remove
/sbin/iptables -A knock_ph1 -m recent --name phase2 --set
/sbin/iptables -A knock_ph1 -j DROP/sbin/iptables -N knock_ph2
/sbin/iptables -A knock_ph2 -m recent --name phase2 --remove
/sbin/iptables -A knock_ph2 -m recent --name phase3 --set
/sbin/iptables -A knock_ph2 -j DROP/sbin/iptables -N knock_ph3
/sbin/iptables -A knock_ph3 -m recent --name phase3 --remove
/sbin/iptables -A knock_ph3 -m recent --name phase4 --set
/sbin/iptables -A knock_ph3 -j DROP/sbin/iptables -N knock_end
/sbin/iptables -A knock_end -j knock_rmv
/sbin/iptables -A knock_end -j ACCEPT/sbin/iptables -A INPUT -i $IF_EXT -p udp --dport $KNOCK1 -m recent --name phase1 --set -j DROP
/sbin/iptables -A INPUT -i $IF_EXT -p udp --dport $KNOCK2 -m recent --name phase1 --rcheck -j knock_ph1
/sbin/iptables -A INPUT -i $IF_EXT -p udp --dport $KNOCK3 -m recent --name phase2 --rcheck -j knock_ph2
/sbin/iptables -A INPUT -i $IF_EXT -p udp --dport $KNOCK4 -m recent --name phase3 --rcheck -j knock_ph3
/sbin/iptables -A INPUT -i $IF_EXT -p udp -m multiport --dports $KNOCK2,$KNOCK3,$KNOCK4 -j knock_rmv
/sbin/iptables -A INPUT -i $IF_EXT -p tcp --dport 22 -m recent --rcheck --seconds $TIME_OPEN --name phase4 -j knock_endЭто дает возможность открыть порт SSH для доступа на $TIME_OPEN секунд для IP, с которого пришли UDP пакеты(любые) на порты $KNOCK1, затем $KNOCK2, $KNOCK3 и $KNOCK4. При этом обращение на эти порты в другом порядке не откроет порт SSH для доступа.
Для открытия порта SSH на host необходимо выполнить команды с удаленного хоста
echo " " | nc -w 1 -u host $KNOCK1
echo " " | nc -w 1 -u host $KNOCK2
echo " " | nc -w 1 -u host $KNOCK3
echo " " | nc -w 1 -u host $KNOCK4
ssh user@hostИ все. Предсказать порядок портов оооочень сложно - сканирование не спасает.
Для доступа с венды можно переделать на TCP вместо UDP и тыкаться в порты telnet'ом.
>KNOCK1="123"
>KNOCK2="456"
>KNOCK3="789"
>KNOCK4="555"
>TIME_OPEN="30"на порты $KNOCK1, затем $KNOCK2, $KNOCK3 и $KNOCK4.
> При этом обращение на эти порты в другом порядке не откроет порт SSH для доступа.Ещё бы номера портов вынести за 1024, приписать по 0 или 00
KNOCK1="12300"
KNOCK2="45600"
KNOCK3="7890"
KNOCK4="55500"
TIME_OPEN="30"Не забыть поправить в Linux_е ipv4.port_range="1024 65535"
>>KNOCK1="123"
>>KNOCK2="456"
>>KNOCK3="789"
>>KNOCK4="555"
>>TIME_OPEN="30"
>
>на порты $KNOCK1, затем $KNOCK2, $KNOCK3 и $KNOCK4.
>> При этом обращение на эти порты в другом порядке не откроет порт SSH для доступа.
>
>Ещё бы номера портов вынести за 1024, приписать по 0 или 00Если никто посторонний не сможет открывать порты, то да. Иначе пусть лучше будут только для рута...
>И все. Предсказать порядок портов оооочень сложно - сканирование не спасает.для пущей безопасности я бы еще использовал одноразовые пароли через OPIE.
Спасибо за скрипт, интересен, но на мой взгляд проще использовать fail2ban. Дополнительно позовляет банить неправильные логины на другие сервисы и осуществлять более гибкий контроль за процессом.
>Спасибо за скрипт, интересен, но на мой взгляд проще использовать fail2ban. Дополнительно
>позовляет банить неправильные логины на другие сервисы и осуществлять более гибкий
>контроль за процессом.Только разница в том, что мой пример не дает даже пытаться войти по SSH левому человеку.
стоит порт нокинг на основе iptables все пучком, смысла долбится или сканировать хост на сервере нет, не реальо не зная необходимые порты
У меня одно время хобби было. Ставил старенькую тачку "лицом в инет" с простеньким паролем (user: sergio, pass: sergio. Разгадывали на ура, если кому интересно будет повторить) ну и глядел че там кулхацкеры делают. Один скрипт-ломальщик (а может и живой кто это был) перетащил мне на машину всего себя, включая список с уже угаданными логинами/паролями других тачек. Большинство оказалось экзотическими девайсами с встроенными линуксами и старыми заброшеными машинами.
iptables -N SSHSCAN
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
>У меня одно время хобби было. Ставил старенькую тачку "лицом в инет"тоже хочу приколоться - поставить на виртуальной машине голой жопой в и-нет =))
посмотреть как кулхацкеры резвятся...
>>У меня одно время хобби было. Ставил старенькую тачку "лицом в инет"
>
> тоже хочу приколоться - поставить на виртуальной машине голой жопой
>в и-нет =))
> посмотреть как кулхацкеры резвятся...Ну так ставишь виртуалку, ставишь мониторы, делаеш юзеру root пароль 12345, и пускаешь жопой в инет. Только не забудь запретить исходящие конекты на реальном хосте, иначе твоя машина станет сканировать других. Потом делаешь дамп памяти и разбираешся на досуге чё там творится.
> тоже хочу приколоться - поставить на виртуальной машине голой жопой в и-нет =))
> посмотреть как кулхацкеры резвятся...А если с тебя начнут рассылать спам?
вспомнить про mlimit в iptables да запретить вход по логину паролю(тока сертификатом).ну и заодно разрешить вход тока с определнных айпишников
У меня сначал впн поднимаеться а там внурти уже что хочу ворочу помойму безопасне намного.
Использую pf и ограничение на количество соединений в единицу времени с одного ip + ограничение количества одновременных соединений с одного ip. Провинившиеся ip помещаю в таблицу и персонально для них устанавливаю "плохой канал", с потерей пакетов порядка 75%. Помогает хорошо...
>Использую pf и ограничение на количество соединений в единицу времени с одного
>ip + ограничение количества одновременных соединений с одного ip. Провинившиеся ip
>помещаю в таблицу и персонально для них устанавливаю "плохой канал", с
>потерей пакетов порядка 75%. Помогает хорошо...А какими средствами длается "плохой канал" с заданнм дропаньем?
>А какими средствами длается "плохой канал" с заданнм дропаньем?block on $ext_if proto tcp from <abusive_hosts> to $ext_addr port 22 probability 75%
/etc/pf.conf:
TCP="proto tcp"
SSA="flags S/SA"
MSF="modulate state"
.....
table <sshlock> persist
.....
pass in $TCP to $ext_addr port ssh $SSA label SSH-Limit \
$MSF (max-src-conn-rate 10/60, overload <sshlock> flush global)
block drop in log from <sshlock> to any label SSH-Lock
а кто отменил в ssh
AllowGroups sshusers-group???
А нельзя например 100 раз набрал неверный логин и пароль, то в бан IP адрес?
Как раз собиреться хороший список проксей....
>А нельзя например 100 раз набрал неверный логин и пароль, то в
>бан IP адрес?
>Как раз собиреться хороший список проксей....(имеется введу подрят 100 раз с ошибкой)
>А нельзя например 100 раз набрал неверный логин и пароль, то в
>бан IP адрес?
>Как раз собиреться хороший список проксей....(имеется введу подрят 100 раз с ошибкой)
В продолжении темы, интереснее было бы сделать так, что бы после 100 раз подрят неправильно набранных паролей залагиниться было бы вообше нельзя, но эмуляция работы ssh оставалась....
когдато, в древние времена (когда компы были деревянными, а кодировка была одна)
был такой трюк:
обратный дозвон.
Ох, и чего не понапридумывает народ, лишь бы не менять порт ssh. В хозяйстве более 50-и машин в разных сетях. При установке меняю порт ssh (ну и PermitRootLogin no на всякий случай). Некоторые 4 года уже стоят. Ни на одной ни разу не был замечен bruteforce. Да что там, хоть бы просто ткнулся кто.
так это.
плохо приглашаешь :-)
+1
Не мешай народу - люди мазохисты по природе. Им бы фаерволы построить, с извратом, , ключи. А пароль оставить 12345 :)
>+1
>Не мешай народу - люди мазохисты по природе. Им бы фаерволы построить,
>с извратом, , ключи. А пароль оставить 12345 :)О - кульцхарякеры подтянулись ... Ну - ну, живите пока, до первого скана ...
Перевесть порт это так - чтоб логи не пухли. Не защитит вас зарывание головы в песок - уж сколько раз о "security by obscurity" толковали ,)
>О - кульцхарякеры подтянулись ... Ну - ну, живите пока, до первого
>скана ...
>Перевесть порт это так - чтоб логи не пухли. Не защитит вас
>зарывание головы в песок - уж сколько раз о "security by
>obscurity" толковали ,)скан сам по себе ничем не опасен.
>>+1
>>Не мешай народу - люди мазохисты по природе. Им бы фаерволы построить,
>>с извратом, , ключи. А пароль оставить 12345 :)
>
>О - кульцхарякеры подтянулись ... Ну - ну, живите пока, до первого
>скана ...
>Перевесть порт это так - чтоб логи не пухли. Не защитит вас
>зарывание головы в песок - уж сколько раз о "security by
>obscurity" толковали ,)А PortSentry с блокировкой портскана или snort поставить религия не позволяет??
а если у тебя CVS сервер и около 300 пользователей на нем? каждому пройти и порт поменять?
понимаю, что надо было делать изначально, но так исторически сложилось.
веселее было бы использовать TARPIT для попавшихся, но его выкинули :(
/usr/ports/security/sshit
>/usr/ports/security/sshitоно отстой. выше gatekeeper показал верный метод, но я делал наоборот, 22 порт был открыт всем, разрешено было 3 попытки в мин с 1 ip коннектится, overload добавлялся в таблицу badusers которая и была закрыта.
geoip на 22 порт, оставляем только свой каунтри-остальные отдыхают
Запрет рутового логина, аунтификация только по ключу с парольной фразой.
брутер не пройдет )
>использование аутентификации по публичному ключуТаким хреновым советчикам надо больно е*нуть в бубен за такие советы учитывая уязвимость в дебиановском OpenSSL и геморрой с этими самыми ключами, мать их.
>>использование аутентификации по публичному ключу
>
>Таким хреновым советчикам надо больно е*нуть в бубен за такие советы учитывая
>уязвимость в дебиановском OpenSSL и геморрой с этими самыми ключами, мать
>их."уязвимость в дебиановском OpenSSL" это проблема исключительно тех кто пользуется дебианбейсд фигней, а также самим дебианом. Не нужно так резко отзываться о людях которые выбрали более адекватные дистрибутивы ;-)
>"уязвимость в дебиановском OpenSSL" это проблема исключительно тех
>кто пользуется дебианбейсд фигней, а также самим дебианом.Если бы...
>Не нужно так резко отзываться о людях
>которые выбрали более адекватные дистрибутивы ;-)Теперь представьте себе, что на хосте с более адекватным дистрибутивом размещён публичный ключик, при генерации которого мощность множества секретных ключей была сведена к 98301. Причём вероятность распределена заведомо неравномерно, особенно для пользователя root. Бишь всё это неплохо перебирается в обозримое время.
Так что если кто вдруг ещё не воспользовался утилитой для поиска увечных ключей, принесённых пользователями лучшего дистрибутива всех времён и народов (tm) или там самопопулярного дистрибутива всех времён и народов (tm) -- предлагаю заглянуть сюда:
http://wiki.debian.org/SSLkeys#head-45e521140d6b8f2a0f96a115...PS: в Owl и ALT Linux тем временем обкатывается оригинальный вариант openssh, который с несущественными накладными расходами отбрасывает такие ключи "на лету": http://openwall.com/lists/oss-security/2008/05/27/3
PPS: надеюсь, для разработчиков Debian это будет урок насчёт того, что здравый смысл поклонением инструментарию (полиси, whatever) не заменяется.
А чего никто до сих пор не предложил вызывать sshd из inetd? У inetd есть возможность лимитировать количество соединений с одного IP с минуту, например одно или два соединения в минуту.
>А чего никто до сих пор не предложил вызывать sshd из inetd?
>У inetd есть возможность лимитировать количество соединений с одного IP с
>минуту, например одно или два соединения в минуту.Ны как вариант ты потеряещь сервер если inetd глюканет.