Comments 119
Менять не всегда получается — иногда нужен именно 22 порт (банально для «красивых» url, без указания порта).
1. Всем известно что 22 порт постоянно сканируется, ботнеты и пр. Любой владелец фаерволла который собирает его логи знает что постоянно происходят сканы по стандартным портам (~1000шт)
2. Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
…
3. Допустим в SSH протоколе обнаруживается 0-day уязвимость.
За последние пару лет мы видели что такое случается с проектами с открытым кодом, тот же OpenSSL.
Хорошо если эта уязвимость была обнаружена правильными товарищами, тогда есть шанс на то, что кто-то успеет обновиться.
Плохо, если об этой уязвимости все узнают после её открытой эксплуатации.
В такой ситуации, заполучив POC код, нет никаких проблем воспользоваться shodan.io (или тем же списком от ботов) и зодолбить всех кто найдётся на 22 порту.
0-day уязвимости вполне может быть не важна длина ключа.
Я параноик и это гипотетически невозможная ситуация?
Нестандартный порт — это такая security by obscurity. На веб-сервера тоже постоянно ломятся на всякие /phpMyAdmin и т.п., и что, теперь и вместо 80 порта другой использовать?
Я параноик и это гипотетически невозможная ситуация?
Гипотетически очень многое возможно, но ситуация, при которой вас спасёт именно другой порт, крайне маловероятна, потому что эта "защита" не идёт ни в какое сравнение с методами, используемыми самим ssh. Полагаться нужно на стойкую криптографию, а не на то, что атакующий не знает, на каком порте у вас ssh. Да, и она может подвести, но настолько редко, что перестраховки обычно бессмысленны. Если уж так хочется приложить подорожник, то port knocking, whitelist по IP или сложный пароль пользователя (и sudo) имеют куда больше смысла, хотя полезность первого тоже неочевидна.
Нестандартный порт — это такая security by obscurity.никто не называет изменение порта методом обеспечения безопасности.
На веб-сервера тоже постоянно ломятся на всякие /phpMyAdmin и т.п., и что, теперь и вместо 80 порта другой использовать?
В случае с 80/443 портом для веб сервера выбора особого действительно нет, но давайте сравним две простые гипотетические ситуации на примере веб серверов:
1. Веб сервер использует стандартный порт 80.
Чтобы просканить все 80 порты в ipv4 интернете нужно ~25 минут при канале в 1ГБит.
2. Веб сервер использует нестандартный порт (например 62831).
Чтобы просканить вообще все 65к портов в ipv4 интернете нужно ~19 суток при канале в 1ГБит.
В веб сервере обнаруживается DOS уязвимость. Злодеи публикуют POC код. Любой может его использовать.
25 минут меньше чем 19 суток и затраты на поиск уязвимого сервера на нестандартных портах явно выше (примерно в 65000 раз). Т.е. риск эксплуатации уязвимости во втором случае ниже (от 2 раз до 65 000).
В случае с веб сервером — да, от стандартных портов никуда не деться.
В случае с SSH — нет особых проблем в использовании нестандартных портов.
В принципе, если ссш на всех хостах на каком-то 5222 — то еще ладно. А если везде разные команды и у каждого что-то свое — то это дичь.
А вот вешать еще и на порт который без того имеет четкое назначение
xmpp-client 5222/tcp jabber-client # Jabber Client Connection
xmpp-client 5222/udp jabber-client
это уже не просто дичь, а дичь полнейшая.
Другое дело, что нестандартная конфигурация дороже в обслуживании… Вот, к примеру, добавится к этому серверу с ssh на 5222 межсетевой экран, или IDS, а в нем в шаблоне для правил ssh прописан порт 22. И те, кто админят ту железку, должны это помнить.
А на своем локалхосте можно хоть и демократию внедрять.
Давай ты не будешь это рассказывать тому, кто админит сервера дольше, чем большинство местных читателей на свете живут, хорошо?
Перевешивание на нестандартный порт — верный признак попингуя начитавшегося дурных статей. Ни один админ с опытом подобной глупости творить не будет
Давай ты не будешь это рассказывать тому..
А давайте дочитывать комент до конца, что ли… Или хотя бы до 2 абзаца… ;)
Давай ты не будешь это рассказывать тому, кто админит сервера дольше, чем большинство местных читателей на свете живут, хорошо?
/facepalm
Собственно любой сторонник перевешивания ssh на левые порты уже показывает, что его брать на работу не стоит, что он не думает о безопасности.
Все дело в том, что сканеры портов вполне успешно распознают ssh на любом порту.
И кроме как отказаться от парольной аутентификации — ничего не остается.
security by obscurity — это когда тайным является СПОСОБ.
Тут же способ известен — смена порта. Номер порта фактически является ключем. Да, величина ключа не большая (десяток бит), но тем не менее ухудшает эффективность атаки на порядки.
Всем известно что 22 порт постоянно сканируется, ботнеты и пр. Любой владелец фаерволла который собирает его логи знает что постоянно происходят сканы по стандартным портам (~1000шт)
Сканируются все 65 тысяч портов. Попробуйте повесить открытую http прокси на какой-нибудь совсем странный порт вроде 63241 и проверьте через сколько дней через нее повалит китайский спам.
Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
Тут дело не в каких-то листах. Просто все ipv4 адреса в мире постоянно сканируются. На гигабитном канале TCP-SYN скан всего интернета по одному порту занимает ~20 минут (zmap, masscan).
Чем перевешивать SSH на нестандартные порты, и думать будто это вас от чего-то защищает, я бы рекомендовал поступать так:
Отключить аутентификацию по паролю, оставив только ключи. В таком случае сервер SSH будет сразу закрывать подключение при попытке авторизоваться по паролю.
/etc/ssh/sshd_config
-----------
PasswordAuthentication no
Сканируются все 65 тысяч портов. Попробуйте повесить открытую http прокси на какой-нибудь совсем странный порт вроде 63241 и проверьте через сколько дней через нее повалит китайский спам.
Не спорю, что сканируются периодически все 65к портов, но судя по логам, полный портскан происходит заметно реже чем скан самых распространенных портов, на глаз — примерно в 100-1000 раз реже.
Тут дело не в каких-то листах. Просто все ipv4 адреса в мире постоянно сканируются.
Речь не о сканах, а о том, что после того как адрес+порт были отключены, именно в этот адрес+порт продолжаются попытки подключения в течении года и больше. Независимо от сканов портов.
Логи фаерволла собираю в graylog, там это очень наглядно.
На гигабитном канале TCP-SYN скан всего интернета по одному порту занимает ~20 минут (zmap, masscan).
Я может как-то неправильно считаю, но если размер TCP-SYN пакета ~48 байт, в интернете 4294967296 адресов, то это 192 ГБайт.
При канале в 1 ГБит/сек, 192Гбайта будут переданы за ~25 минут.
Т.е. скан всего интернета по одному порту со скоростью 1Гбит занимает ~25 минут.
По 65к портам — это ~19 суток.
Чем перевешивать SSH на нестандартные порты, и думать будто это вас от чего-то защищает
Не передёргивайте, никто не говорит что это мера защиты. Это всего лишь способ уменьшения риска с учётом вышесказанного.
в интернете 4294967296 адресов
Неправильно считаете. 592708864 адресов зарезервированы, так что сканировать достаточно 3702258432.
От «китайцев» надо защищаться не банальным прятаньем порта, а по-взрослому.
На почтовый сервер (на котором я не могу сменить порт по очевидным причинам) мне сыпется несколько десятков разных «китайцев» и прочих в минуту — приходится жить и обучать сервер отправлять отлупы таким товарищам.
Так для справки, у меня белым адресом в интернет светит порядка 250 устройств, на всех включен ssh, на всех нестандартные порты (порт не один на всех, их несколько). Вот только один фиг я в логах постоянно вижу попытки авторизации. Спасает разве что fail2ban с баном на месяц, и то иной раз открываешь список правил и офигеваешь с количества хостов и приходится подчищать, дабы не перегружать процессор обработкой всех этих правил.
То-есть вы исключаете вариант что до появления 0-day уязвимости у вас кто-то упорный найдёт ssh на нестандартном порту?
Конечно не исключаю.
Я просто увеличиваю время для его поиска, точно так же как увеличивается время подбора пароля при увеличение его длины. Плюс исключаю тех потенциальных атакующих, кто не ищет сервисы на нестандартных портах.
С учётом того что сменить порт абсолютно бесплатно и не вызывает особых проблем, то я не вижу причин этого не делать, и вижу в этом больше плюсов чем минусов.
fail2ban прекрасно работает с ipset. И нет нужды что-то подчищать.
banaction = iptables-ipset-proto6-allports
спасет отца русской демократии
- Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
Нет нужды в списках, просто сканируют и пробуют всё IPv4 пространство. Таким же образом тыкаются на всякие URL на 80 и 443 порты независимо от вообще какого-либо ответа от самого веб-сервера или наличия каких-либо файлов в DocumentRoot.
www.openssh.com/txt/preauth.adv.
Тут есть еще один фокус. Нужно подобрать не только пароль, но и логин. По дефолту во всех системах сейчас идет PermitRootLogin prohibit-password. А все остальные логины надо еще угадать. То есть брутфорсеру надо угадать пару логин-пароль, а не просто пароль, что превращает задачу из маловероятной в невозможную.
Месяца два назад смотрел логи на своей VPS для домашних проектов, в нестандартный порт openvpn стучались также часто, как в стандартные порты ssh/ssl.
blog.shodan.io/dont-be-clever
Пусть тестируют, и сколько угодно могут перебирать rsa4096 тоже, мне не жалко :)Тут есть ещё один не самый очевидный (и не для всех актуальный) момент — мне как-то не то за две, не то за три недели вот так вот «пусть наперебирали» на 9 ГБ трафика. Прямо такой аккуратный длинный прямоугольник на графике bandwidth.
У многих безлимит, но на маленьких VPS нередко бывают ограничения, и когда вот так впустую съели девять ГБ из ста, мне это пришлось не по нраву. Остатка всё равно хватило с лихвой, но после этого порт поменял.
Одно дело когда стучатся не получают ответа вообще.
Другое дело когда стучатся, получают какой-то ответ, посылают новый запрос.
Кроме того, если получили отклик на 22 порту, то зачастую включают брутфорс — это жрет куда больше траффика, чем разовый пинг порта.
сколько угодно могут перебирать rsa4096 тоже, мне не жалко
А мне жалко. Поскольку из-за таких перебиральщиков «ssh по крону» периодически отваливается, напарываясь на лимит числа соединений, не прошедших стадию авторизации.
table <bruteforce> persist
....
block in log quick from <bruteforce>
....
pass quick proto tcp to port ssh keep state (max-src-conn 15, \
max-src-conn-rate 5/3, overload <bruteforce> flush global)
Но вот я лично меняю порт
ssh
из простых практических соображений: /var/log/authlog
становиться чистым как стекло :)Более того обнаружение на не стандартном порту — повышает приоритет скана этой машины ибо *чтото тут интересненькое* и скоро на нее придет более прошаренный ботнетик с более злым сканом.
ЗЫ чот судя по тредику — с основами работы интернетика и банальной безопасности чот у всех прям беда-беда случилась, раньше
Ну как. Вот у меня ssh висит на нестандартном порту. Вход строго по ключам. Только один раз за несколько лет (на нескольких серверах) было что-то вроде
Disconnected from authenticating user root 89.187.88.79 port 45162 [preauth]Там перебирали несколько юзеров, вроде portal, postgres и т.п.
Received disconnect from 89.187.88.79 port 45503:11: Normal Shutdown, Thank you for playing [preauth]
Invalid user php from 89.187.88.79 port 48296
Disconnected from invalid user php 89.187.88.79 port 48296 [preauth]
...
Разница заметна на маленьких, чахлых VPS — если боты перебирают пароли на стандартном порту в несколько потоков, то владелец зайти не может.
1. Запрет авторайза по паролю, только ключ
2. fail2ban или его аналоги
Все. И не нужно прятать голову в песок и заниматься прочими глупостями
А те два шага в любом случае нужны…
ls -lah /var/log/auth.log
-rw-r----- 1 syslog adm 190K Jul 31 09:17 /var/log/auth.log
Гиги, блин.
# ls -lh /var/log/auth.log.1
-rw-r----- 1 root adm 862M Jul 29 06:25 /var/log/auth.log.1
```
Практически гиг за сутки.
ls -lah /var/log/auth.log.1
-rw-r----- 1 syslog adm 1.5M Jul 30 06:27 /var/log/auth.log.1
Стоит использовать fail2ban.
Серверу 6 лет, то есть во всех условных базах он есть и всем известно, что там ssh на 22ом. Стоит заглянуть в твой auth.log и увидеть, что там дело не в ssh'е, а в записях типа
CRON[NNNN]: pam_unix(cron:session): session closed for user root
Можно еще добавить fail2banЕсли не возражаете, бессовестно вклинюсь:
Может быть Хабр подскажет альтернативу fail2ban для VPS с маленьким объёмом памяти?
Например, у меня 384 МБ и f2b явно туда не влезет. А заворачивать нехороших граждан всё-таки хотелось бы. Использую CentOS 7.
-A ANTIFLOOD -p tcp -m tcp -m multiport --dports 22,23 -m state --state NEW -j ANTIFLOOD-SSH-TELNET
# с одного ip - не более 5-ти новых попыток за 2 минуты, иначе - в следующее правило "-2"
-A ANTIFLOOD-SSH-TELNET -m recent --update --seconds 120 --hitcount 5 --name SSH --mask 255.255.255.255 --rsource -j ANTIFLOOD-SSH-TELNET-2
-A ANTIFLOOD-SSH-TELNET -m recent --set --name SSH --mask 255.255.255.255 --rsource
-A ANTIFLOOD-SSH-TELNET -j RETURN
# Пишем в лог тех, кого сейчас забаним:
-A ANTIFLOOD-SSH-TELNET-2 -p tcp -m tcp -m recent --update --seconds 7200 --hitcount 1 --name SSH2 --mask 255.255.255.255 --rsource -j LOG --log-prefix "ANTIFLOOD-SSH-TELNET-2: "
# И пару часов отшиваем, чтоб охладить пыл...
-A ANTIFLOOD-SSH-TELNET-2 -p tcp -m tcp -m recent --update --seconds 7200 --hitcount 1 --name SSH2 --mask 255.255.255.255 --rsource -j REJECT --reject-with tcp-reset
# tcp reset, чтобы не висели полуоткрытые соединения, или же DROP
-A ANTIFLOOD-SSH-TELNET-2 -m recent --set --name SSH2 --mask 255.255.255.255 --rsource
-A ANTIFLOOD-SSH-TELNET-2 -j RETURN
С временем --update --seconds 7200 лучше поиграть в обе стороны.
Потом по крону можно парсить логи и добавлять особо рьяных в ipset.
А правило
-A INPUT -m set --match-set dropips src -j DROP
повесить ближе к началу портянки iptables.
Просто из-за IPv6 приходится на fail2ban 0.10 сидеть, который никак не зарелизится всё. Хотя случаев что бы какой-то бот нашел где там у меня в моей /56 что-то висит еще не было, но предпочитаю что бы этого бота если что поймали.
1. Доступ только по ключу
2. fail2ban или его аналоги
И никаких голов в песок.
Вообще команда nginx'а молодцы с этой фичей в mainline, я думаю со временем на всех серверах у себя сделать подобный запасной вход. Просто на части использую mainline, там вот на днях собираюсь внести изменения в конфиги, на части, по ряду причин, stable, там с выходом 1.16 применю.
Такая конфигурация даст возможность подключаться и из очень ограниченных по портам сетей
Эммм, а что, ssh у всех открыт прямо во весь интернет? По-моему риск можно уменьшить банально указав доступ только с определенных ип. Если у админа нет статики, то хотя бы ограничить диапазоном провайдера, ну или страны, в крайнем случае.
У нас можно зайти всего с одного ип, и это статический ип офиса, а к офису уже по впн.
Конечно можно потерять контроль над серверами, если в офисе обрушится интернет, но пока что ситуаций одновременных траблов в датацентре и в офисе не возникало
В вашем случае невозможность попасть на сервера это просто вопрос времени. Объяснять почему?
А поскольку к серверу можно подключиться только с одного IP-адреса, и этот адрес стал нам недоступен, то и подключиться к серверу мы не сможем.
Если вы о подмене IP в заголовке пакета, то во-первых взломщик должен знать на какой IP менять, что не особо тривиально, если не прослушивать пакеты находясь между.
И конечно же все остальные условия безопасности, типа авторизации только по ключу, тоже выполнены.
Думаю, тут скорее имелось в виду некое событие, после которого сменится либо станет недоступным публичный IP-адрес офиса (например, провайдер решит адресацию сети поменять без предупреждения или просто у провайдера произойдёт долговременный технический сбой).
А поскольку к серверу можно подключиться только с одного IP-адреса, и этот адрес стал нам недоступен, то и подключиться к серверу мы не сможем.
Пока что таких событий не было, IP компании установлен контрактом и ни в коем случае не может быть поменян без предупреждения, после которого, конечно же правила доступа будут изменены. А что касается технических сбоев, ну в самом крайнем случае, на фаерволл можно зайти без привязки по IP и поменять правила доступа.
Ну и а с фаерволлом там свои условия для входа.
Нет, потому что может потребоваться подключится к серверу с мобильного или в поездке. Вот если бы вы сказали про личный VPN, я бы понял.
Ну так когда я в поездке, то я подключаюсь к офису через VPN и захожу на нужный ресурс.
Неплохо бы, чтобы физический доступ к серверам был. А то, например, подсеть РКН забанит — и тогда трафик к ней может вообще перестать ходить (
Пока в РКН есть Р, они до нас не доберутся 8-)
Неплохо бы, чтобы физический доступ к серверам был. А то, например, подсеть РКН забанит — и тогда трафик к ней может вообще перестать ходить (
А если админ может сегодня заходить из одного города, завтра из другого, а послезавтра из другой страны?
Доступ по ключу и fail2ban помогают, вместо засовывания головы в песок.
Меньше, чем через 4 часа. Хотя в тексте перевода значится "На следующий день в почтовом ящике лежало письмо от Джойса".
www.ssh.com/ssh
The Secure Shell protocol was originally developed by Tatu Ylonen in 1995 in response to a hacking incident in the Finnish university network. A password sniffer had been installed on a server connected directly to the backbone, and when it was discovered, it had thousands of usernames and passwords in its database, including several from Ylonen's company.
That incident triggered Ylonen to study cryptography and develop a solution he could use himself for remote login over the Internet safely. His friends proposed additional features, and three months later, in July 1995, Ylonen published the first version as open source. It became OpenSSH. Later he took the protocol for standardization at the IETF and designed the SSH File Transfer Protocol (SFTP). He founded SSH Communications Security Corp in December 1995 to provide commercial support for the protocol.
— Люда! Назови цифру от одного до 65535
— 22
— Вася, теперь SSH на 22 порту, добавь меня в контакты
Ведь когда-то все эти веб-серверы, ssh, ssl, telnet были «молодыми проектами».
А потом оно просто приживается и остается.
В то время это означало уважаемых первопроходцев интернета Джона Постела и Джойса К. Рейнольдса. Среди всего прочего, Джон являлся редактором таких незначительных протоколов, как IP (RFC 791), ICMP (RFC 792) и TCP (RFC 793). Возможно, кто-то из вас слышал о них.Вот вам фотография «первопроходца»; фразы надо переписать в женском роде:
icannwiki.org/Joyce_Reynolds
Для чего в правилах iptables опция "--ctstate NEW,ESTABLISHED"?
Как SSH появился на 22 порту