Pull to refresh

Comments 53

ИМХО, лучше воспользоваться fail2ban.
К счастью, я с Вами соглашусь. Поскольку при настройке кнокинга возникло очень много трудностей, с которыми я боролся всю неделю.
fail2ban удобен тем, что прост в настройке, но он не полностью предотвращает попытки подключения. Да и порт остается открытым.
В случае SSH сильно помогает смена порта ssh-сервера сразу при первоначальной настройке на что-то отличное от 22
Согласен! Была идея, но я решил пойти окольными путями настроив кнокинг и сделав подключение по RSA-ключу. В ближайшем будущем планирую переделать все, как только приобрету резервный сервер. Камни подводные всегда попадаются, на них и учимся.
Добавлю что смена порта на значение большее 1024 — плохая идея. Порты от 1024-го и выше может слушать программа, запущенная любым пользователем, а не только root-ом. А значит злоумышленник, имеющий доступ к вашему серверу, сможет запустить программу, имитирующую ssh-сервер и собирающую пароли.
А ECDSA-ключ она тоже без рутовых прав прочитает?
Ключ не прочитает, вы правы, но ведь предупреждение о смене ключа можно ненароком и не заметить. Короче говоря, лучше перестраховаться.
Как можно не заметить необходимость вручную вбить в консоль ssh-keygen -R?
Можно на автомате в ответ на «Are you sure you want to continue connecting (yes/no)?» написать «yes» и отдать свой пароль.
Оно такую надпись выдаёт только при самом первом подключении. И да, тут должна быть простыня текста о полезности авторизации по ключам, но мне лень её писать.
Да, я понимаю, что вероятность попасться на такую уловку очень мала. Но когда речь идёт о безопасности, то по-моему лучше устранить даже такую маленькую угрозу. Особенно учитывая то, что для этого надо всего лишь правильно выбрать число.
Для того, чтобы слушать порт, нужно сначала его освободить.

А смена порта на значение <=1024 идея не плохая, но по-моему бесполезная. Все сканеры сканируют этот диапазон в первую очередь, так что это будет шило на мыло.
UFO landed and left these words here
С другой стороны, порты выше 1024 и сканируют реже :-)
У меня вообще была идея перевести SSH на ipv6-only. Вот там точно задолбуться подбирать комбинации.
UFO landed and left these words here
Потому что IPv6-адресов намного больше, чем IPv4, поэтому, чтобы «тупо перебрать все IP-адреса» нужно будет потратить намного больше времени :)
UFO landed and left these words here
Он конечно открытый остается, но перебор все-равно не возможен ибо будет оооочень долго.
ИМХО, для SSH-сервисов, доступных извне, безопасней всего будет использовать ключи и полностью запретить доступ через ввод пароля. Ибо блокировка по IP спасает только от «тупого» bruteforce, но не от того bruteforce, который распространен в интернете сейчас, когда с кучи разных IP-адресов ломятся и перебирают все возможные пароли.
А еще лучше если все вместе. Я оставил авторизацию только по ключам и доступ только со своих ип.
Тогда вы не сможете зайти на свой сервер, если смените провайдера или придется пользоваться мобильным интернетом :). На самом деле даже вариант с ключами плох тем, что нужно их бэкапить, иначе зайти на сервер не удастся без KVM…
достаточно сделать на сервере файл text.txt и по его загрузке добавлять правило в таблицу ipfw, разрешающее доступ скачавшему этот файл.
Совершенно верно, если ип сменился то добавить новый ип в список поможет мобильный который имеет статичный ип.
Так же на черный день в списках разрешенных один из тестовых серверов.
К сожалению по IP не могу сделать, так как частенько езжу в командировки и приходится заходить либо с планшета, либо с гостиничного WiFi. Поэтому и решено было настроить кнокинг + от CloudFlare подключение к ssh через поддомен.
Так же альтернатива: denyhosts
А я порекомендую sshguard. Он мониторит много всего, не только ssh, как отражено в названии.
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-сервера на фейковый.
UFO landed and left these words here
Если честно в топике писалось про юникс системы, фрибсд юникс без сомнений, но:
1) у них разные системы авторизации (в частности в линухах есть модуль пам pam_fail_delay, который вводит задержку после неудачного ввода пароля и скаждой неудачной увеличивается время задержки)
2) на моей практике обычно пользуют один фаерфол, или Packet Filter (PF) или IPFIREWALL (IPFW)
3) если взять юниксы в целом, то можно закрыть пароли и пускать только по ключу, если нет флешки(или хотябы мобилки с памятью на борту) не беда, ключи от ssh можно шифрануть (неважно чем, хоть винраром) и использовать почту допустим для хранения, естесственно с мерами безопасности и консперацией + при генерации ключа часть ключа можно вводить с клавы для более высокой стерени паранои.

Позвольте поинтересоваться.
А пароля на 16+ символов и таймаута разве недостаточно? Это реально сбрутфорсить, перебрать?
Это вроде нет, но переполнить раздел с логами вроде да.
Добавлю от себя. Обычно мне лениво делать стуки для удаления правила для доступа к сервису. Да и к сервисам этим часто по port knocking ещё люди из отдела стучатся. За всеми не уследить: кто-то был в командировке, кто-то ещё откуда-то. В итоге в списке iptables (т.к. я про Linux сейчас говорю) накапливается куча ненужного хлама. По этой причине я делаю так: в кроне каждую ночь в 4 утра восстанавливаю правила iptables скриптом, в котором прописано:
iptables-restore < /etc/firewall.conf


Соответственно, предварительно эти правила должны быть сохранены в файле:

iptables-save >/etc/firewall.conf
Очень не советую использовать механизмы блокировки, основанные на анализе логов. Логи могут почему-то перестать писаться, или вдруг чуть изменить формат. Это происходит в самый неподходящий момент. Например: пришла атака, логи приложений резко выросли, партиция переполнилась, логи сломались, нокинг сломался. И вам повезло, если он просто выключился, и пускает всех. А вот если он не пускает никого до следующего логротейта, а сервера в Европе, тамошняя поддержка спит, ребут не помогает (не чистит партицию)… Не ходите по этим граблям.

В iptables уже давно существует прекрасный модуль recent, который позволяет отслеживать историю подключений с определённого IP и делать тот же самый порт нокинг.
вот кусок кода который делает всё то же самое что knockd

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
Хотя на *BSD можно попробовать аналагично сделать через ipfw.
К сожалению iptables под линь-ядра, а у меня семейство BSD. Но вариант интересный — спасибо за наводку. В свободное время попробую пошаманить.
Потому что была идея именно скрыть порт от чужих глаз, но оставить его доступным для себя.
Очень и очень старый вариант «обезопасинвания».
Очень плохой и очень религиозно-неверный.
Каждый защищает себя по своему, я привел лишь один из вариантов. Если почитать комментарии выше, то можно встретить и другие варианты.
Only those users with full accounts are able to leave comments. Log in, please.