Про интернет от киевстара

[chabapok]

С машиной, ssh порт которой смотрит в публичный интернет, бывают неприятные особенности - туда ломятся и начинают подбирать пароли по словарю. Нестандартный порт спасает, ненадолго, у нас его за несколько лет нашли, например. В какой-то момент ломящихся становится много, каждую секунду идет 5..10 попыток ввода пароля. Банить ip-аддреса бесполезно, они очень быстро меняются. Я в итоге банил даже /8 подсети, таких подсетей забанил штук 50. Это улучшило ситуацию, но полностью не спасло.

И вот узнал я, что есть port knocking. Выглядит это так, что запускается демон knockd и если ему в течении сконфигурированного времени (10..30сек) на заданные порты придут пакеты, это воспринимается как стук в дверь, и он добавляет src-аддрес в iptables. После этого можно с этого ip-аддреса заходить по ssh. А всем остальным (кроме белого списка, разумеется) - бан.

Настроил, проверил - работает. Ну а как проверить? Через 4g сотового оператора. Через какое-то время думаю - дай ка еще раз проверю. Проверяю - не работает. Начинаю копать. Выясняется: киевстар каждое новое tcp-соединение начал делать с разных ip-аддресов. Пакеты на нужные порты приходят - адрес источника у них у всех разный. Так происходит у киевстара не всегда. Например, сегодня адрес источника меняется реже, но все равно меняется.

Ну то есть - раз так сделал киевстар, значит и любой другой говнопровайдер может так сделать. Таким образом, port knocking выглядит красиво, но работать будет не стабильно.

ИИ предлагает fwknop. Это другая технология, в ней 1 пакет с зашифрованной информацией открывает порт ssh во внешний мир на какое-то небольшое время.

Comments

[ufm]

Отключить логирование у sshd. Не знаешь о проблеме - спишь спокойно. :)

[chabapok]

%)))

[ufm]

а если серьёзно - ну пусть подбирают. У тебя-же, я надеюсь, вход по ключу а не по паролю?

[chabapok]

Есть и ключ, и пароль. Но пароль - сложный, все как положено. Бессвязный набор цифр, букв, символов.

Поначалу у нас был user:user, году так в 2010 это было или раньше, еще и со стандартным портом. Проработало оно так всего неделю, потом сломали и пароль сменили. Пройденный этап это.

Они ж канал забивают, в логи срут. Короче - признаю, что некоторые замашки перфекциониста у меня действительно есть. Но думаю, что на самотек такое можно пускать не более чем на ~10 лет. Потом их становится много и с ними надо что-то делать. Причем перескочить на другой порт уже не выйдет. Все эти боты уже знают, что на таком-то ip есть ssh, и когда ты перескакиваешь на другой порт, они его относительно быстро находят, за считанные дни.

[juan_gandhi]

Когда я хостил свою хрень на AWS, я там просто держал whitelist на один айпи. А у моего провайдера добивался (не всегда получалось), чтоб у меня был постоянный айпи. Иногда приходилось доплачивать.

[chabapok]

У меня бывают командировки, из которых иногда приходится заходить по ssh.

так то конечно да. Еще можно сервер в интернете арендовать и(или) впн сделать. И потом самому по впн заходить.
Но - это стоит каких-то денег (небольших), и такая схема зависит от сервера этого. Мне не нравится.

[rampitec]

fail2ban посмотри. Несколько неудачных попыток и бот отправляется в бан на какое-то время.

[chabapok]

я руками пробовал банить, что по сути то же самое.
Если банишь бота - он через минуту на другом ip вылазит.

В итоге мне надоело это, я пользовался онлайн сервисами whois. По айпи аддресу сервис выдавал диапазон, и я банил сразу всю подсеть. Всего около 150 записей в iptables, из которых около 50 это /8 подсети.

В итоге сделал вывод - нет смысла банить по ip аддресам, там такие масштабы ботнетов, что будут просто раздувать тебе список, без особого эффекта.

[rampitec]

Я лично в какой-то момент забил и отключил логирование вот этого. У меня причем не только в sshd ломятся. А сам sshd пересадил не просто на альтернативный высокий порт, но на порт широко известного сервиса. Там пока не ищут. Ну и логин с паролем у меня выключен, так что я мало рискую.

[cybernatic_cat]

Всего около 150 записей в iptables, из которых около 50 это /8 подсети.

Бгггг :).

$ cat iptables.conf | wc -l
62686

Тоже последствия попыток борьбы с целыми подсетями :). Правда, это, большей частью, баны отдельных стран целиком, по данным, которые берутся здесь. Тоже не сильно эффективно, как выяснилось - в нынешних условиях, когда существуют ублюдки под названием "public cloud providers". Особенно это касается клаудов в Гонконге, Китае и прочих shitholes.

[chabapok]

Если записей так много, помоему проще белый список делать. Если знаешь, точно, что с других аддресов тебе ненадо будет заходить.

Мне можно просто украину сделать белым списком - и все прекрасно работало бы.
Можно даже сделать ipset в котором вся украина, а если вдруг понадобиться зайти извне - fwknop или knockd.
это все в iptables добавляется и может в связке работать.

Или например, добавить провайдера, с которого ты заходишь, в белый список. А доступ из остальных мест - через fwknop или knockd.

Почему я так не сделал до сих пор? - лень. Надо будет так и сделать.

[rampitec]

О! А меня бы устроило просто сделать всю Украину черным списком. Потому что больше попыток атак, чем оттуда, просто и нету.

[chabapok]

Странно, я за все время не видел ни одной атаки из Украины. Видимо, бото-фермеры что-то знают и не атакуют своими ботами страну, в которой находятся их боты.

[rampitec]

Ну вот у меня в 99% случаев whois показывает на Киев.

[ufm]

бань всё кроме Украины.

[cybernatic_cat]

Выясняется: киевстар каждое новое tcp-соединение начал делать с разных ip-аддресов.

Интересно, как они это делают. А главное - зачем. knockd в такой схеме работать не будет - это ещё пол-беды; но бывают ведь и более "серьёзные" сервисы, требующие stateful connections. Да и IP-адресов у них в пуле наверняка не сто охулиардов, если только это не IPv6...

Интересно, а udp они пуляют тоже с разных originating адресов? knockd умеет работать и по udp, не только по tcp.

Возможное решение проблемы: правила в iptables, которые безусловно форвардят все пакеты с портами knockd с внешнего интерфейса на localhost, маскируя при этом source ip:

iptables -t nat -A PREROUTING -d -p tcp -m multiport --dports port1,port2,port3... -j DNAT --to-destination 127.0.0.1

iptables -t nat -A POSTROUTING -p tcp -m multiport --dports port1,port2,port3... -d 127.0.0.1 -j MASQUERADE

knockd при этом, разумеется, должен слушать на 127.0.0.1.

У меня самого, кстати, knockd юзается в домашней лабе, именно для доступа с мобильных устройств снаружи - только я им не ssh открываю, он закрыт наглухо, а разрешаю доступ к домашнему vpn-гейту. Ни разу не видел, чтобы штатовские мобильные провайдеры устраивали какой-нить карнавал с коннектами.

[rampitec]

Самый цимес это когда тебе надо срочно домой достучаться, а ты в другой стране. И если это, скажем, Бразилия, то там карнавалы любят и ценят.

[cybernatic_cat]

Слава великому Ктулху, у меня таких раскладов не бывает. И надеюсь, что и не будет впредь :).
На самый крайняк - в соседнем нейборхуде живёт хороший приятель и коллега. Remote hands, тысызыть :).

[rampitec]

Сам бы я может и не поехал, а может и поехал, чёрт меня знает, но меня туда запихали в командировку. Так что случаи всякие бывают.

[cybernatic_cat]

Сорян, в первое правило всралась опечатка. Точнее, движок DW похерил обязательный параметр, который я сдуру поставил в угловые скобки (из-за чего получился неизвестный тэг :).

Правильно будет вот так:

iptables -t nat -A PREROUTING -d public_ip -p tcp -m multiport --dports port1,port2,port3... -j DNAT --to-destination 127.0.0.1

[chabapok]

Ок. Увидел.

[chabapok]

> Интересно, а udp они пуляют тоже с разных originating адресов?

Это было первое, что я подумал.
Но я не стал это проверять: если так плохо делает киевстар, то и кто-то другой может делать. И даже если сейчас киевстар нормально UDP пришлет - это ничего не гарантирует. Я сначала настроил knockd и все работало. Через час решил проверить - уже не работает. Начал копать, запустил wireshark...
Поэтому, если все работает сейчас - это не означает, что киевстар не заговняет через время.

За правила кстати - спасибо. Я в iptables не очень, так что буду, по крайней мере, знать, что как-то так можно. Хотя навскидку мне кажется, что --to-destination будет подменять dst поле, а "плавающее" у пакетов - поле src.

Насколько понимаю, knockd по таким правилам откроет порты для замаскированного ip-аддреса, что это не имеет смысла. Поэтому настроить так можно - но в такой схеме порты придется открывать всем. А потом можно забыть закрыть. И опять же. Порты самого knockd так можно пробросить. Но потом для ssh провайдер подставит из пула другой ip-аддрес.

На сегодня я настроил fwknop. Он принимает 1 зашифрованный udp на определенный порт, и открывает порт ssh всем на установленное время. Этот пакет валиден какое-то время, например 30 секунд. Если злоумышленник его перехватывает и отправляет - в этом просто нет смысла, ведь в течении этих 30 сек порт ssh уже будет открыт этим пакетом. А потом истекает валидность пакета.

Недостаток - в плеймаркете нету приложения для fwknop. Но где-то на гитхабе я видел.

Вообще, чем хорош knockd - он умеет работать по tcp пакетам syn. Теоретически провайдер может резать udp, а вот обрезка tcp это уже вряд ли. По хорошему, оба механизма надо иметь.

[cybernatic_cat]

Я в iptables не очень, так что буду, по крайней мере, знать, что как-то так можно. Хотя навскидку мне кажется, что --to-destination будет подменять dst поле, а "плавающее" у пакетов - поле src.

А за подмену src отвечает второе правило, маскарадинг.

Насколько понимаю, knockd по таким правилам откроет порты для замаскированного ip-аддреса, что это не имеет смысла. Поэтому настроить так можно - но в такой схеме порты придется открывать всем.

Да, разумеется. Я забыл об этом упомянуть. В knockd.conf должно быть не дефолтное

command = /sbin/iptables -A INPUT -s %IP% -p tcp -m tcp --dport special_ssh_port -j ACCEPT

а

command = /sbin/iptables -A INPUT -d public_ip -p tcp -m tcp --dport special_ssh_port -j ACCEPT

Это, конечно, откроет ssh всему белому свету - но риск не особо велик, особенно если ssh аутентифицируется исключительно по RSA. А чтобы не забывать закрыть - можно в качестве command сунуть не голое правило iptables, а простенький скриптик, который сначала внесёт правило в файрволл, потом подождёт какое-то разумное время и отработает iptables -D INPUT [...], закрывая доступ. А если в файрволле предусмотрительно проставлены ACCEPT на коннекты с состояниями RELATED, ESTABLISHED - то iptables -D ещё и установленную сессию не должен порвать, по идее.

Кстате клиентская аппа knockd для андроида - совершенно прекрасна. Да ещё и довольно активно совершенствуется.

P.S. Ну и ещё одна подсказочка, которая теоретически может быть полезной в плане борьбы с брутфорсами ssh: PerSourcePenalties, интродактнуто в openssh 9.8. Но лично я с этим плотно не разбирался, честно говоря.

[chabapok]

Я тут еще упражнялся, и вспомнил, что вы интересовались udp.
С UDP ситуация у них лучше - но все равно все плохо.

скрин ваершарка (я там свой ip замазал, а то мало ли чего. Он везде одинаков)



Пакеты я высылал с телефона парами на 5000 и 5001 порт, использовал android приложение knock on ports.

Как видно, по вечерам с tcp у них все плохо. С UDP - несколько лучше, но толку мало: ssh-соединение все равно имеет не тот ip-аддрес.

В приложении knock on ports можно задать паузу между пакетами. По умолчанию пауза 500мс. Эту паузу можно сделать меньше, я попробовал 50мс - и о чудо IP-аддрес получается одинаковый. Но толку с этого мало.

Киевстар так работает не всегда.

[ufm]

Еще, кстати, вариант - использовать yggdrasil и перевесить ssh на его адреса. Но так как не все такие извращенцы как я - более человеческий вариант:
Поднять внутрь сети любой вариант тунеля, какой больше нравится, и сделать ssh доступным только из него. Логи на попытки взломать тунель - отключить, что-бы не раздажали. Как только в логах ssh появляются сообщения о том, что его опять пытаются отбрутфорсить - сменить пароль на тунеле.