Всем привет!Проблема, наверное, стара, как мир. Идут постоянные попытки подобрать username/password на SSH. Простейшее решение - закрыть SSH, но он мне нужен самому. Есть мысль использовать что-то вроде /usr/ports/security/logcheck для периодической проверки /var/log/auth.log на предмет строк "...illegal user bla-bla from 111.222.333.444 port ...", вытаскивать IP и блокировать его firewall'ом. Но мне кажется, что это далеко не самое изящное решение, не говоря уже о том, что малоэффективное, т.к. хотелось бы блокировать злодеев практически в real-time, например после 3-4 попыток в течение последней минуты. Существуют ли уже готовые решения? Буду благодарен за любые идеи/ссылки/мысли и т.д.
>Всем привет!
>
>Проблема, наверное, стара, как мир. Идут постоянные попытки подобрать username/password на SSH.
>Простейшее решение - закрыть SSH, но он мне нужен самому. Есть
>мысль использовать что-то вроде /usr/ports/security/logcheck для периодической проверки /var/log/auth.log на предмет
>строк "...illegal user bla-bla from 111.222.333.444 port ...", вытаскивать IP и
>блокировать его firewall'ом. Но мне кажется, что это далеко не самое
>изящное решение, не говоря уже о том, что малоэффективное, т.к. хотелось
>бы блокировать злодеев практически в real-time, например после 3-4 попыток в
>течение последней минуты. Существуют ли уже готовые решения? Буду благодарен за
>любые идеи/ссылки/мысли и т.д.
snort?после 3-4'ех попыток я бы не советовал ;)
после 10'ти вероятно можно
>
>snort?
>
>после 3-4'ех попыток я бы не советовал ;)
>после 10'ти вероятно можноБольшое спасибо за ответ! Именно по snort'у я сейчас читаю документацию, но пока не нашел "своей" проблемы. Вероятно, она будет описана в главе "Preprocessors"
Авторизация по ключам.
IMHO 99% этих переборов - это тупые роботы.
С ними бороться элементарно: переносишь SSH на другой порт, например 3333.После того как я это сделал на своих серверах - я не зафиксировал не одного такого перебора.
>IMHO 99% этих переборов - это тупые роботы.
>С ними бороться элементарно: переносишь SSH на другой порт, например 3333.
>
>После того как я это сделал на своих серверах - я не
>зафиксировал не одного такого перебора.
Спасибо. Помогло.
Но всё-таки -- как и чем можно мониторить подозрительные последовательные обращения на ОДИН_И_ТОТ_ЖЕ порт? С отслеживанием перебора портов прекрасно справляются и snort (thanks to Lavr), и portsentry, и, наверное, есть ещё куча инструментов. А вот как быть с одним портом? Ну, допустим, "злодей" случайно найдет, где спрятан SSH... Тогда задача сводится к исходному посту.
>вот как быть с одним портом? Ну, допустим, "злодей" случайно найдет,
>где спрятан SSH... Тогда задача сводится к исходному посту.А это так критично, что кто-то пытается перебрать? Если пароль хороший, то шансов на подбор нет.
>>IMHO 99% этих переборов - это тупые роботы.
>>С ними бороться элементарно: переносишь SSH на другой порт, например 3333.
>>
>>После того как я это сделал на своих серверах - я не
>>зафиксировал не одного такого перебора.
>
>
>Спасибо. Помогло.
>Но всё-таки -- как и чем можно мониторить подозрительные последовательные обращения на
>ОДИН_И_ТОТ_ЖЕ порт? С отслеживанием перебора портов прекрасно справляются и snort (thanks
>to Lavr), и portsentry, и, наверное, есть ещё куча инструментов. А
>вот как быть с одним портом? Ну, допустим, "злодей" случайно найдет,
>где спрятан SSH... Тогда задача сводится к исходному посту.строят Бастионы и ДМЗ, имеют штат или штатного сотрудника security,
политику использования сети, регулярное чтение секурити списков рассылки,
рассылание писем об обнаружении атак, покупка коммерческого - "интеллектуального" firewall и тд и тп...Проблема комплексная и решать ее желательно в комплексе.