Comments 53
ИМХО, лучше воспользоваться fail2ban.
К счастью, я с Вами соглашусь. Поскольку при настройке кнокинга возникло очень много трудностей, с которыми я боролся всю неделю.
fail2ban удобен тем, что прост в настройке, но он не полностью предотвращает попытки подключения. Да и порт остается открытым.
fail2ban удобен тем, что прост в настройке, но он не полностью предотвращает попытки подключения. Да и порт остается открытым.
В случае SSH сильно помогает смена порта ssh-сервера сразу при первоначальной настройке на что-то отличное от 22
Согласен! Была идея, но я решил пойти окольными путями настроив кнокинг и сделав подключение по RSA-ключу. В ближайшем будущем планирую переделать все, как только приобрету резервный сервер. Камни подводные всегда попадаются, на них и учимся.
Добавлю что смена порта на значение большее 1024 — плохая идея. Порты от 1024-го и выше может слушать программа, запущенная любым пользователем, а не только root-ом. А значит злоумышленник, имеющий доступ к вашему серверу, сможет запустить программу, имитирующую ssh-сервер и собирающую пароли.
А ECDSA-ключ она тоже без рутовых прав прочитает?
Ключ не прочитает, вы правы, но ведь предупреждение о смене ключа можно ненароком и не заметить. Короче говоря, лучше перестраховаться.
Как можно не заметить необходимость вручную вбить в консоль ssh-keygen -R?
Для того, чтобы слушать порт, нужно сначала его освободить.
А смена порта на значение <=1024 идея не плохая, но по-моему бесполезная. Все сканеры сканируют этот диапазон в первую очередь, так что это будет шило на мыло.
А смена порта на значение <=1024 идея не плохая, но по-моему бесполезная. Все сканеры сканируют этот диапазон в первую очередь, так что это будет шило на мыло.
UFO just landed and posted this here
С другой стороны, порты выше 1024 и сканируют реже :-)
У меня вообще была идея перевести SSH на ipv6-only. Вот там точно задолбуться подбирать комбинации.
Он конечно открытый остается, но перебор все-равно не возможен ибо будет оооочень долго.
ИМХО, для SSH-сервисов, доступных извне, безопасней всего будет использовать ключи и полностью запретить доступ через ввод пароля. Ибо блокировка по IP спасает только от «тупого» bruteforce, но не от того bruteforce, который распространен в интернете сейчас, когда с кучи разных IP-адресов ломятся и перебирают все возможные пароли.
А еще лучше если все вместе. Я оставил авторизацию только по ключам и доступ только со своих ип.
Тогда вы не сможете зайти на свой сервер, если смените провайдера или придется пользоваться мобильным интернетом :). На самом деле даже вариант с ключами плох тем, что нужно их бэкапить, иначе зайти на сервер не удастся без KVM…
достаточно сделать на сервере файл text.txt и по его загрузке добавлять правило в таблицу ipfw, разрешающее доступ скачавшему этот файл.
Совершенно верно, если ип сменился то добавить новый ип в список поможет мобильный который имеет статичный ип.
Так же на черный день в списках разрешенных один из тестовых серверов.
Так же на черный день в списках разрешенных один из тестовых серверов.
К сожалению по IP не могу сделать, так как частенько езжу в командировки и приходится заходить либо с планшета, либо с гостиничного WiFi. Поэтому и решено было настроить кнокинг + от CloudFlare подключение к ssh через поддомен.
Так же альтернатива: denyhosts
Port knocking помимо защиты от брутфорса позволяет защититься от удалённых атак на сервера. Например, вот от таких:
0day Linux/CentOS SSHd Spam Exploit — libkeyutils.so.1.9
Т.к. в случае использования Port knocking зловредные пакеты от злоумышленника даже не дойдут до уязвимого сервиса
Так что не стоит пренебрегать этой технологией
0day Linux/CentOS SSHd Spam Exploit — libkeyutils.so.1.9
Т.к. в случае использования Port knocking зловредные пакеты от злоумышленника даже не дойдут до уязвимого сервиса
Так что не стоит пренебрегать этой технологией
fail2ban из коробки справляется, а тут еще настраивать надо и махаться со входом… стоит ли игра свеч?
Картинка с Шелдоном клевая. Откуда взял?
Я использую ipset + kippo. Если система видит, что кто-то неправильно ввел пароль, то IP добавляется в ipset и iptables перенаправляет его на kippo, который порой пишет презабавнейшие логи активности «хакеров».
Отличная штука. Спасибо за наводку. Не могу плюсануть пока.
Посмотрел на youtube активность «хакеров», из логов kippo. На самом деле забавно. Давно так не смеялся. Особенно этот был подарком. А в конце в связи с ребутом вообще чуть не упал со смеху. Спасибо еще раз. Надо себе поставить. Юмор на каждый день, надеюсь, будет обеспечен.
От себя добавлю, что стоит заменить заново сгенерированные private.key и public.key на такие же, как в системе (при условии, что не используется ECDSA).
У меня ключики скопированы в %kippodir%/ssh_keys и соответственно:
private.key -> ssh_keys/ssh_host_rsa_key
public.key -> ssh_keys/ssh_host_rsa_key.pub
При таком хаке абсолютно не палится факт смены фингерпринта ssh, т.е. со стороны клиента не виден факт подмены оригинального ssh-сервера на фейковый.
У меня ключики скопированы в %kippodir%/ssh_keys и соответственно:
private.key -> ssh_keys/ssh_host_rsa_key
public.key -> ssh_keys/ssh_host_rsa_key.pub
При таком хаке абсолютно не палится факт смены фингерпринта ssh, т.е. со стороны клиента не виден факт подмены оригинального ssh-сервера на фейковый.
UFO just landed and posted this here
Если честно в топике писалось про юникс системы, фрибсд юникс без сомнений, но:
1) у них разные системы авторизации (в частности в линухах есть модуль пам pam_fail_delay, который вводит задержку после неудачного ввода пароля и скаждой неудачной увеличивается время задержки)
2) на моей практике обычно пользуют один фаерфол, или Packet Filter (PF) или IPFIREWALL (IPFW)
3) если взять юниксы в целом, то можно закрыть пароли и пускать только по ключу, если нет флешки(или хотябы мобилки с памятью на борту) не беда, ключи от ssh можно шифрануть (неважно чем, хоть винраром) и использовать почту допустим для хранения, естесственно с мерами безопасности и консперацией + при генерации ключа часть ключа можно вводить с клавы для более высокой стерени паранои.
1) у них разные системы авторизации (в частности в линухах есть модуль пам pam_fail_delay, который вводит задержку после неудачного ввода пароля и скаждой неудачной увеличивается время задержки)
2) на моей практике обычно пользуют один фаерфол, или Packet Filter (PF) или IPFIREWALL (IPFW)
3) если взять юниксы в целом, то можно закрыть пароли и пускать только по ключу, если нет флешки(или хотябы мобилки с памятью на борту) не беда, ключи от ssh можно шифрануть (неважно чем, хоть винраром) и использовать почту допустим для хранения, естесственно с мерами безопасности и консперацией + при генерации ключа часть ключа можно вводить с клавы для более высокой стерени паранои.
Если вы не возражаете, я бы хотел указать на источник картинки, которую вы использовали: knock knock knock penny, by sandara.
Можно прикрутить Google Authenticator. Как вариант.
tls?
rsa?
trigger-port?
ossec?
rsa?
trigger-port?
ossec?
Позвольте поинтересоваться.
А пароля на 16+ символов и таймаута разве недостаточно? Это реально сбрутфорсить, перебрать?
А пароля на 16+ символов и таймаута разве недостаточно? Это реально сбрутфорсить, перебрать?
Добавлю от себя. Обычно мне лениво делать стуки для удаления правила для доступа к сервису. Да и к сервисам этим часто по port knocking ещё люди из отдела стучатся. За всеми не уследить: кто-то был в командировке, кто-то ещё откуда-то. В итоге в списке iptables (т.к. я про Linux сейчас говорю) накапливается куча ненужного хлама. По этой причине я делаю так: в кроне каждую ночь в 4 утра восстанавливаю правила iptables скриптом, в котором прописано:
Соответственно, предварительно эти правила должны быть сохранены в файле:
iptables-restore < /etc/firewall.conf
Соответственно, предварительно эти правила должны быть сохранены в файле:
iptables-save >/etc/firewall.conf
Очень не советую использовать механизмы блокировки, основанные на анализе логов. Логи могут почему-то перестать писаться, или вдруг чуть изменить формат. Это происходит в самый неподходящий момент. Например: пришла атака, логи приложений резко выросли, партиция переполнилась, логи сломались, нокинг сломался. И вам повезло, если он просто выключился, и пускает всех. А вот если он не пускает никого до следующего логротейта, а сервера в Европе, тамошняя поддержка спит, ребут не помогает (не чистит партицию)… Не ходите по этим граблям.
В iptables уже давно существует прекрасный модуль recent, который позволяет отслеживать историю подключений с определённого IP и делать тот же самый порт нокинг.
В iptables уже давно существует прекрасный модуль recent, который позволяет отслеживать историю подключений с определённого IP и делать тот же самый порт нокинг.
вот кусок кода который делает всё то же самое что knockd
При стуке по портам по очереди 54321, 34512, 24513, 16438 ip c которого произошел «стук» попадает в список админов на 10 минут, а при попытке авторизации по ssh, если авторизация была неудачная, «падает» в бан на 10 минут.
iptables -N ssh
iptables -A ssh -m recent --name ssh_conn --set -j LOG --log-prefix "SSH INN "
iptables -A ssh -m recent --rcheck --name admins --seconds 60 -j ACCEPT
iptables -A ssh -m recent -p tcp --update --seconds 600 --hitcount 2 --name ssh_conn -j REJECT --reject-with tcp-reset
iptables -A ssh -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ssh
iptables -A INPUT -p tcp --dport 54321 -m recent --name adm1 --set
iptables -A INPUT -p tcp --dport 34512 -m recent --rcheck --name adm1 --seconds 200 -j adm1
iptables -A INPUT -p tcp --dport 24513 -m recent --rcheck --name adm2 --seconds 200 -j adm2
iptables -A INPUT -p tcp --dport 16438 -m recent --rcheck --name adm3 --seconds 200 -j adm3
iptables -A INPUT -m recent --rcheck --name adm4 --seconds 600 -j ACCEPT
При стуке по портам по очереди 54321, 34512, 24513, 16438 ip c которого произошел «стук» попадает в список админов на 10 минут, а при попытке авторизации по ssh, если авторизация была неудачная, «падает» в бан на 10 минут.
Забыл вставить, должно идти между двумя фрагментами предыдущими.
iptables -N adm1
iptables -A adm1 -m recent --name adm2 --set
iptables -N adm2
iptables -A adm2 -m recent --name adm3 --set
iptables -N adm3
iptables -A adm3 -m recent --name adm4 --set
К сожалению iptables под линь-ядра, а у меня семейство BSD. Но вариант интересный — спасибо за наводку. В свободное время попробую пошаманить.
Почему просто не закрыть вход по паролю и сгенерить ключ?
Очень и очень старый вариант «обезопасинвания».
Очень плохой и очень религиозно-неверный.
Очень плохой и очень религиозно-неверный.
на фре прекрасно себя чувствует bruteblock и sshit
Sign up to leave a comment.
Port knocking или как обезопасить себя от брута по ssh