Когда я (Тату Илонен) впервые опубликовал эту историю в апреле 2017 года, она стала вирусной: её прочитали около 120 000 читателей за три дня.
История получения порта 22 для SSH
Я написал первую версию SSH (Secure Shell) весной 1995 года. В то время широко использовались Telnet и FTP.
Но я всё равно разработал SSH для замены и
telnet (порт 23) и ftp (порт 21). Порт 22 был свободен и удобно располагался между портами для telnet и ftp. Я подумал, что такой номер порта может стать одной из тех маленьких деталей, которые придадут некоторую ауру доверия SSH. Но как его получить? Я никогда не распределял порты, но я знал тех, кто этим занимается.В то время процесс выделения портов был довольно простым. Интернет был меньше, и мы находились на самых ранних стадиях интернет-бума. Номера портов выделяла организация IANA (Internet Assigned Numbers Authority). В то время это означало уважаемых первопроходцев интернета Джона Постела и Джойс К. Рейнольдс. Среди всего прочего, Джон являлся редактором таких незначительных протоколов, как IP (RFC 791), ICMP (RFC 792) и TCP (RFC 793). Возможно, кто-то из вас слышал о них.
Меня откровенно пугал Джон как автор всех основных RFC для Интернета!
Так или иначе, но перед анонсом
ssh-1.0 в июле 1995 года я отправил в IANA такое электронное письмо:From ylo Mon Jul 10 11:45:48 +0300 1995
From: Tatu Ylonen <ylo@cs.hut.fi>
To: Internet Assigned Numbers Authority <iana@isi.edu>
Subject: request for port number
Organization: Helsinki University of Technology, Finland
Уважаемый сэр,
Я написал программу для безопасного входа с одной машины на другую по небезопасной сети. Это значительное улучшение безопасности по сравнению с существующими протоколами telnet и rlogin и их реализациями. В частности, она предотвращает спуфинг IP, DNS и маршрутизации. Мой план состоит в том, чтобы свободно распространять программу в интернете и обеспечить как можно более широкое её использование.
Я хотел бы получить зарегистрированный привилегированный номер порта для программы. Желательно в диапазоне 1-255, чтобы его можно было использовать в поле WKS на нейм-серверах.
Ниже прикладываю проект RFC для протокола. Программное обеспечение локально используется несколько месяцев и готово для публикации, за исключением номера порта. Если можно оперативно присвоить номер порта, я хотел бы выложить программу уже на этой неделе. В настоящее время в бета-тестировании я использую порт 22. Было бы отлично использовать этот номер (в настоящее время в списках он обозначен как «неприсвоенный»).
Название сервиса для программного обеспечения — "ssh" (Secure Shell).
С уважением,
Тату Илонен <ylo@cs.hut.fi>
… затем следуют спецификации протокола ssh-1.0
На следующий день в почтовом ящике лежало письмо от Джойс:
Date: Mon, 10 Jul 1995 15:35:33 -0700
From: jkrey@ISI.EDU
To: ylo@cs.hut.fi
Subject: Re: request for port number
Cc: iana@ISI.EDU
Тату,
Мы присвоили порт 22 для SSH, указав вас контактным лицом.
Джойс
У нас получилось! Теперь у SSH порт 22!!!
12 июля 1995 года в 2:32 утра я анонсировал окончательную бета-версию для своих бета-тестеров в Хельсинкском технологическом университете. В 17:23 выслал тестерам пакеты ssh-1.0.0, а в 17:51 отправил объявление о SSH (Secure Shell) в список рассылки
cypherpunks@toad.com. Я также продублировал анонс в несколько новостных групп, списков рассылки и непосредственно отдельным людям, которые обсуждали смежные темы в интернете.Изменение порта SSH на сервере
По умолчанию сервер SSH по-прежнему работает на порту 22. Однако бывает иначе. Одна из причин — тестирование. Другая — запуск нескольких конфигураций на одном хосте. Редко бывает, что сервер работает без рутовых привилегий, в этом случае он должен размещаться на непривилегированном порту (т. е. с номером 1024 или больше).
Номер порта можно настроить, изменив директиву
Port 22 в /etc/ssh/sshd_config. Он также указывается параметром -p <port> в sshd. Клиент SSH и программы sftp тоже поддерживают параметр -p <port>.Указание порта SSH в командной строке
Параметр
-p <port> можно использовать для указания номера порта при подключении с помощью команды ssh в Linux. В SFTP и scp используется параметр -P <port> (примечание: заглавная P). Указание из командной строки переопределяет любое значение в файлах конфигурации.Настройка доступа SSH через файрволы
SSH является одним из немногих протоколов, которому часто разрешено работать через файрволы на исходящий доступ, особенно в небольших и технических компаниях. Входящий SSH обычно разрешён к одному или нескольким серверам.
Исходящий SSH
Настройка исходящего SSH в файрволе очень проста. Если есть ограничения на исходящий трафик вообще, просто создайте правило, разрешающее исходящие соединения по порту TCP 22. Вот и всё. Если требуется ограничить адреса назначения, можно создать соответствующее правило, разрешив доступ только к серверам вашей организации в облаке или к jump-серверу, который защищает доступ к облаку.
Обратное туннелирование — это риск
Однако неограниченный исходящий SSH может быть рискованным. Протокол SSH поддерживает туннелирование. Основная идея в том, что сервер SSH на внешнем сервере прослушивает подключения отовсюду, переправляет их в организацию и устанавливает соединение с каким-то внутренним сервером.
В некоторых случаях это удобно. Разработчики и системные администраторы часто используют туннелирование, чтобы получить удалённый доступ из дома или с ноутбука во время путешествий.
Но обычно туннелирование нарушает политику безопасности и отнимает контроль у администраторов файрвола и команды ИБ. Например, оно может нарушать правила PCI, HIPAA или NIST SP 800-53. Его могут использовать хакеры и спецслужбы, чтобы оставить бэкдоры в локальной сети.
Программа CryptoAuditor контролирует туннелирование в файрволе или в точке входа в группу облачных серверов. Она работает в связке с Universal SSH Key Manager для получения доступа к ключам хоста, используя их для расшифровки сеансов SSH в брандмауэре и блокировки несанкционированного форвардинга.
Входящий SSH
Для входящего доступа есть несколько вариантов:
- Настройте файрвол для пересылки всех подключений к порту 22 на определённый IP-адрес во внутренней сети или DMZ. Запустите по этому IP-адресу CryptoAuditor или jump-сервер, чтобы контролировать и проверять дальнейший доступ в организацию.
- Используйте разные порты на файрволе для доступа к разным серверам.
- Разрешайте доступ по SSH только после входа в систему с помощью VPN, обычно по протоколу IPsec.
Включение SSH через iptables
Iptables — это файрвол хоста, встроенный в ядро Linux. Обычно он настроен для защиты сервера, предотвращая доступ ко всем портам, которые не были явно открыты.
Если на сервере включен iptables, следующие команды могут разрешить входящий доступа SSH. Их следует запускать из-под рута.
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT Если хотите сохранить правила навсегда, то в некоторых системах это можно сделать командой:
service iptables save 
Комментарии (121)
razielvamp
29.07.2018 04:12Эммм, а что, ssh у всех открыт прямо во весь интернет? По-моему риск можно уменьшить банально указав доступ только с определенных ип. Если у админа нет статики, то хотя бы ограничить диапазоном провайдера, ну или страны, в крайнем случае.
У нас можно зайти всего с одного ип, и это статический ип офиса, а к офису уже по впн.
Конечно можно потерять контроль над серверами, если в офисе обрушится интернет, но пока что ситуаций одновременных траблов в датацентре и в офисе не возникалоevil_random
29.07.2018 11:31+1Прям читаю и не понимаю как вы не понимаете что ни в коем случае нельзя так делать.
В вашем случае невозможность попасть на сервера это просто вопрос времени. Объяснять почему?mapron
29.07.2018 14:54Я не в теме, но попробую догадаться: потому что ip адрес отправителя в пакете можно заменить на любой?
lostpassword
29.07.2018 16:26Думаю, тут скорее имелось в виду некое событие, после которого сменится либо станет недоступным публичный IP-адрес офиса (например, провайдер решит адресацию сети поменять без предупреждения или просто у провайдера произойдёт долговременный технический сбой).
А поскольку к серверу можно подключиться только с одного IP-адреса, и этот адрес стал нам недоступен, то и подключиться к серверу мы не сможем.
sumanai
29.07.2018 16:30Нет, потому что может потребоваться подключится к серверу с мобильного или в поездке. Вот если бы вы сказали про личный VPN, я бы понял.
razielvamp
29.07.2018 18:06Если вы имеете ввиду, что злоумышленник может добраться до 22 порта даже при таких ограничениях, то да, я бы хотел знать почему это вопрос времени.
Если вы о подмене IP в заголовке пакета, то во-первых взломщик должен знать на какой IP менять, что не особо тривиально, если не прослушивать пакеты находясь между.
И конечно же все остальные условия безопасности, типа авторизации только по ключу, тоже выполнены.
Думаю, тут скорее имелось в виду некое событие, после которого сменится либо станет недоступным публичный IP-адрес офиса (например, провайдер решит адресацию сети поменять без предупреждения или просто у провайдера произойдёт долговременный технический сбой).
А поскольку к серверу можно подключиться только с одного IP-адреса, и этот адрес стал нам недоступен, то и подключиться к серверу мы не сможем.
Пока что таких событий не было, IP компании установлен контрактом и ни в коем случае не может быть поменян без предупреждения, после которого, конечно же правила доступа будут изменены. А что касается технических сбоев, ну в самом крайнем случае, на фаерволл можно зайти без привязки по IP и поменять правила доступа.
Ну и а с фаерволлом там свои условия для входа.
Нет, потому что может потребоваться подключится к серверу с мобильного или в поездке. Вот если бы вы сказали про личный VPN, я бы понял.
Ну так когда я в поездке, то я подключаюсь к офису через VPN и захожу на нужный ресурс.
Неплохо бы, чтобы физический доступ к серверам был. А то, например, подсеть РКН забанит — и тогда трафик к ней может вообще перестать ходить (
Пока в РКН есть Р, они до нас не доберутся 8-)
springimport
30.07.2018 16:56Вы не думали что там может быть ec2 где правило можно поменять прямо из панели?
lostpassword
29.07.2018 12:06Неплохо бы, чтобы физический доступ к серверам был. А то, например, подсеть РКН забанит — и тогда трафик к ней может вообще перестать ходить (
Ernillgeek
29.07.2018 21:22> Если у админа нет статики, то хотя бы ограничить диапазоном провайдера, ну или страны, в крайнем случае.
А если админ может сегодня заходить из одного города, завтра из другого, а послезавтра из другой страны?
Доступ по ключу и fail2ban помогают, вместо засовывания головы в песок.
cck7777
29.07.2018 04:43Разве не Юлонен? Вроде бы в финском «Y» всегда «Ю»?
ujifgc
29.07.2018 07:05Это мягкая «у». Ближайший звук, пожалуй, как у «ю» в «мюслях». Из звуков русского языка больше подходит «ы» или «и». Обозначать его как начальную «ю» совсем некорректно, поскольку там нет звука «й».
tyomitch
29.07.2018 09:54Тем не менее, на русский принято транслитерировать именно буквой «ю»: ru.wikipedia.org/wiki/Юккёнен
iPilot
29.07.2018 06:16+1Эх, просто отправил письмо и просто получил положительный ответ меньше, чем через сутки.
OKyJIucT
29.07.2018 09:49Меньше, чем через 4 часа. Хотя в тексте перевода значится "На следующий день в почтовом ящике лежало письмо от Джойса".
LaG1924
29.07.2018 22:47Не меньше, чем через 4 часа. Стоит ещё учитывать часовые пояса. Хоть и меньше, чем через сутки, но все равно прошло некоторое время, за которое можно лечь спать и получить субъективное «завтра».
denis-19
29.07.2018 09:38Интересна еще и история самого толчка для разработки SSH. Ведь пока данные с серверов компании автора не были скомпрометированы было все ок.
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.
phantom-code
29.07.2018 12:37+1Судя по википедии Joyce K. Reynolds — женщина, а в тексте её имя склоняется по правилам мужского рода.
Akuma
29.07.2018 12:57Я всегда считал, что номера портов у молодых проектов назначаются примерно так:
— Люда! Назови цифру от одного до 65535
— 22
— Вася, теперь SSH на 22 порту, добавь меня в контакты
Ведь когда-то все эти веб-серверы, ssh, ssl, telnet были «молодыми проектами».
А потом оно просто приживается и остается.TheIseAse
29.07.2018 14:49Ведь когда-то все эти веб-серверы, ssh, ssl, telnet были «молодыми проектами».
Я недавно был шокирован, узнав, что Git появился в 2005Ernillgeek
29.07.2018 21:23+1А я вот помню, как Линус сказал «Да любись оно все конем», заперся на несколько дней и представил нам git. Это же все происходило прямо у нас на глазах в режиме онлайн
bougakov
29.07.2018 16:55В то время это означало уважаемых первопроходцев интернета Джона Постела и Джойса К. Рейнольдса. Среди всего прочего, Джон являлся редактором таких незначительных протоколов, как IP (RFC 791), ICMP (RFC 792) и TCP (RFC 793). Возможно, кто-то из вас слышал о них.
Вот вам фотография «первопроходца»; фразы надо переписать в женском роде:
icannwiki.org/Joyce_Reynolds
tea
29.07.2018 19:04Давным-давно, запарившись проверять и настраивать порты, я поставил ovpn на сервер и оставил открытими только 80,443 и порт ovpn. Доступ ко всем остальным сервиcам настроил только с интерфейса ovpn. Все. Чистые логи, никакого брутфорса. И вам советую.
Ernillgeek
29.07.2018 21:25> 443 и порт ovpn
Можно пойти еще дальше и засунуть OpenVPN на тот же 443/tcp, при помощи sslh, либо повесив на 443/tcp свежий mainline nginx повесить там ssh одновременно с https.
Akdmeh
На самом деле, желательно сразу менять стандартный порт, так как его постоянно тестируют на предмет уязвимостей и через попытки перебора паролей.
Prototik
Пусть тестируют, и сколько угодно могут перебирать rsa4096 тоже, мне не жалко :)
Менять не всегда получается — иногда нужен именно 22 порт (банально для «красивых» url, без указания порта).
Cayp
Я не могу себе позволить выставлять SSH на стандартном 22 порту в интернет в виду следующих опасений:
1. Всем известно что 22 порт постоянно сканируется, ботнеты и пр. Любой владелец фаерволла который собирает его логи знает что постоянно происходят сканы по стандартным портам (~1000шт)
2. Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
…
3. Допустим в SSH протоколе обнаруживается 0-day уязвимость.
За последние пару лет мы видели что такое случается с проектами с открытым кодом, тот же OpenSSL.
Хорошо если эта уязвимость была обнаружена правильными товарищами, тогда есть шанс на то, что кто-то успеет обновиться.
Плохо, если об этой уязвимости все узнают после её открытой эксплуатации.
В такой ситуации, заполучив POC код, нет никаких проблем воспользоваться shodan.io (или тем же списком от ботов) и зодолбить всех кто найдётся на 22 порту.
0-day уязвимости вполне может быть не важна длина ключа.
Я параноик и это гипотетически невозможная ситуация?
Hilbert
Нестандартный порт — это такая security by obscurity. На веб-сервера тоже постоянно ломятся на всякие /phpMyAdmin и т.п., и что, теперь и вместо 80 порта другой использовать?
Гипотетически очень многое возможно, но ситуация, при которой вас спасёт именно другой порт, крайне маловероятна, потому что эта "защита" не идёт ни в какое сравнение с методами, используемыми самим ssh. Полагаться нужно на стойкую криптографию, а не на то, что атакующий не знает, на каком порте у вас ssh. Да, и она может подвести, но настолько редко, что перестраховки обычно бессмысленны. Если уж так хочется приложить подорожник, то port knocking, whitelist по IP или сложный пароль пользователя (и sudo) имеют куда больше смысла, хотя полезность первого тоже неочевидна.
Cayp
В случае с 80/443 портом для веб сервера выбора особого действительно нет, но давайте сравним две простые гипотетические ситуации на примере веб серверов:
1. Веб сервер использует стандартный порт 80.
Чтобы просканить все 80 порты в ipv4 интернете нужно ~25 минут при канале в 1ГБит.
2. Веб сервер использует нестандартный порт (например 62831).
Чтобы просканить вообще все 65к портов в ipv4 интернете нужно ~19 суток при канале в 1ГБит.
В веб сервере обнаруживается DOS уязвимость. Злодеи публикуют POC код. Любой может его использовать.
25 минут меньше чем 19 суток и затраты на поиск уязвимого сервера на нестандартных портах явно выше (примерно в 65000 раз). Т.е. риск эксплуатации уязвимости во втором случае ниже (от 2 раз до 65 000).
В случае с веб сервером — да, от стандартных портов никуда не деться.
В случае с SSH — нет особых проблем в использовании нестандартных портов.
Ipeacocks
Если вас сильно беспокоит, то идеальным вариантом может быть впн-сервер, с которого уже идет ссш доступ во внутреннюю сеть. Имхо конечно, но порт, отличимый от 22 — это немного костылестроение и как минимум не удобно.
В принципе, если ссш на всех хостах на каком-то 5222 — то еще ладно. А если везде разные команды и у каждого что-то свое — то это дичь.
Ernillgeek
> на каком-то 5222
А вот вешать еще и на порт который без того имеет четкое назначение
xmpp-client 5222/tcp jabber-client # Jabber Client Connectionxmpp-client 5222/udp jabber-client
это уже не просто дичь, а дичь полнейшая.
iig
Порт — это просто цифры, ничего сакрального в них нет. Самому ssh, что клиенту, что серверу, разницы нет, 22 или 5222.
Другое дело, что нестандартная конфигурация дороже в обслуживании… Вот, к примеру, добавится к этому серверу с ssh на 5222 межсетевой экран, или IDS, а в нем в шаблоне для правил ssh прописан порт 22. И те, кто админят ту железку, должны это помнить.
А на своем локалхосте можно хоть и демократию внедрять.
Ernillgeek
> Порт — это просто цифры, ничего сакрального в них нет. Самому ssh, что клиенту, что серверу, разницы нет, 22 или 5222.
Давай ты не будешь это рассказывать тому, кто админит сервера дольше, чем большинство местных читателей на свете живут, хорошо?
Перевешивание на нестандартный порт — верный признак попингуя начитавшегося дурных статей. Ни один админ с опытом подобной глупости творить не будет
iig
А давайте дочитывать комент до конца, что ли… Или хотя бы до 2 абзаца… ;)
Ernillgeek
В интернете общаются на «ты». Так заведено еще с ФИДОшных времен.
JC_IIB
/facepalm
Ipeacocks
Опыт далеко не всегда указывает на качество работы.
Ernillgeek
В твоем случае, возможно, в моем указывает.
Собственно любой сторонник перевешивания ssh на левые порты уже показывает, что его брать на работу не стоит, что он не думает о безопасности.
iig
Я думаю, за насколько ярко выраженным комплексом нестандартнопортофобии скрывается еще одна удивительная история.
:D
Ernillgeek
Да. Скрывается. Я нанимал админов и все кого я брал любители вешать на нестандартные порты в работе показывали свою полную непригодность.
Sersoftin
А высокомерия вам не занимать.
Sly_tom_cat
Я пробовал ssh на разных портах на белом IP. Трафик «любопытных» на любом из 'well known' портов куда я пробовал перемещать ssh очень слабо отличается от трафика на 22 порту. На 80 порту ssh пытаются взломать примерно с той же интенсивностью что и на 22-м. Если ставить не 'well known' но из первой тыщи, то трафик «любопытных» тоже очень приличный.
Все дело в том, что сканеры портов вполне успешно распознают ssh на любом порту.
И кроме как отказаться от парольной аутентификации — ничего не остается.
zhovner
Сканируются все 65 тысяч портов. Попробуйте повесить открытую http прокси на какой-нибудь совсем странный порт вроде 63241 и проверьте через сколько дней через нее повалит китайский спам.
Тут дело не в каких-то листах. Просто все ipv4 адреса в мире постоянно сканируются. На гигабитном канале TCP-SYN скан всего интернета по одному порту занимает ~20 минут (zmap, masscan).
Чем перевешивать SSH на нестандартные порты, и думать будто это вас от чего-то защищает, я бы рекомендовал поступать так:
Отключить аутентификацию по паролю, оставив только ключи. В таком случае сервер SSH будет сразу закрывать подключение при попытке авторизоваться по паролю.
Cayp
Не спорю, что сканируются периодически все 65к портов, но судя по логам, полный портскан происходит заметно реже чем скан самых распространенных портов, на глаз — примерно в 100-1000 раз реже.
Речь не о сканах, а о том, что после того как адрес+порт были отключены, именно в этот адрес+порт продолжаются попытки подключения в течении года и больше. Независимо от сканов портов.
Логи фаерволла собираю в graylog, там это очень наглядно.
Я может как-то неправильно считаю, но если размер TCP-SYN пакета ~48 байт, в интернете 4294967296 адресов, то это 192 ГБайт.
При канале в 1 ГБит/сек, 192Гбайта будут переданы за ~25 минут.
Т.е. скан всего интернета по одному порту со скоростью 1Гбит занимает ~25 минут.
По 65к портам — это ~19 суток.
Не передёргивайте, никто не говорит что это мера защиты. Это всего лишь способ уменьшения риска с учётом вышесказанного.
tyomitch
Неправильно считаете. 592708864 адресов зарезервированы, так что сканировать достаточно 3702258432.
Cayp
Спасибо.
Действительно, я ошибся примерно на 14% в большую сторону.
Но качественно это не изменило оценку.
ntfs1984
К сожалению сутью потенциальной уязвимости, вполне может быть игнорирование этих настроек, а то и вовсе пароля. Ну примерно как Убунта (или другая ОС, не помню) игнорирует пароль при выходе из спящего режима — бага, но она работает\работала.
Foggy4
Можно поставить простенькую IPS и банить на сутки при попытках просканировать например более 5-10 портов. До 50022 порта таким образом, любые китайцы доберутся очень не скоро.
Prototik
Как вам уже сказали — сканируют вообще всё и вся.
От «китайцев» надо защищаться не банальным прятаньем порта, а по-взрослому.
На почтовый сервер (на котором я не могу сменить порт по очевидным причинам) мне сыпется несколько десятков разных «китайцев» и прочих в минуту — приходится жить и обучать сервер отправлять отлупы таким товарищам.
Wexter
То-есть вы исключаете вариант что до появления 0-day уязвимости у вас кто-то упорный найдёт ssh на нестандартном порту?
Так для справки, у меня белым адресом в интернет светит порядка 250 устройств, на всех включен ssh, на всех нестандартные порты (порт не один на всех, их несколько). Вот только один фиг я в логах постоянно вижу попытки авторизации. Спасает разве что fail2ban с баном на месяц, и то иной раз открываешь список правил и офигеваешь с количества хостов и приходится подчищать, дабы не перегружать процессор обработкой всех этих правил.
Cayp
Конечно не исключаю.
Я просто увеличиваю время для его поиска, точно так же как увеличивается время подбора пароля при увеличение его длины. Плюс исключаю тех потенциальных атакующих, кто не ищет сервисы на нестандартных портах.
С учётом того что сменить порт абсолютно бесплатно и не вызывает особых проблем, то я не вижу причин этого не делать, и вижу в этом больше плюсов чем минусов.
Ernillgeek
> и приходится подчищать, дабы не перегружать процессор обработкой всех этих правил.
fail2ban прекрасно работает с ipset. И нет нужды что-то подчищать.
banaction = iptables-ipset-proto6-allportsспасет отца русской демократииdemfloro
Нет нужды в списках, просто сканируют и пробуют всё IPv4 пространство. Таким же образом тыкаются на всякие URL на 80 и 443 порты независимо от вообще какого-либо ответа от самого веб-сервера или наличия каких-либо файлов в DocumentRoot.
Cayp
Речь о целенаправленных попытках подключения именно на этот адрес+порт. Десятки и сотни тысяч попыток подключения в течении дня. Чаще целыми подсетями, иногда разрозненные адреса.
vsb
Эксплуатируемая 0-day уязвимость в ssh приведёт к такому кошмару, что ваш сервер тут будет вероятно не самой большой проблемой. Я тоже никогда ничего не делаю с ssh, лишнее это. Даже ключи использую исключительно для удобства, чтобы пароли не копипастить туда-сюда, хотя пароли не отключаю, лишь бы они были достаточно большими (12 цифробукв это 100 лет перебора со скоростью 1e11 паролей в секунду. Если проверка одного пароля требует 9 байтов (вот такой вот мегакомпактный протокол), то это 100 лет трафика в 8 терабитов в секунду. Понятно, что в реальности даже если конкретно на вашем сервере решили перебрать пароли, то скорость будет на много порядков меньше, а если ваш сервер просто тестят несколько сотен раз в сутки, то там вообще речь идёт только о паролях вида root:root.
Cayp
Мы все видели Heartbleed в OpenSSL, который затронул большинство веб серверов, Meltdown/Spectre, который затронул почти все Intel процессоры, (ещё был shellshock, но не настолько страшный) поэтому уязвимости в широко распространенном ПО существующем десятилетия перешли из разряда «фантастически невероятных» в просто «маловероятные».
Gutt
И, похоже, все уже забыли 2002 год:
.Ernillgeek
> хотя пароли не отключаю, лишь бы они были достаточно большими (12 цифробукв это 100 лет перебора со скоростью 1e11 паролей в секунду.
Тут есть еще один фокус. Нужно подобрать не только пароль, но и логин. По дефолту во всех системах сейчас идет PermitRootLogin prohibit-password. А все остальные логины надо еще угадать. То есть брутфорсеру надо угадать пару логин-пароль, а не просто пароль, что превращает задачу из маловероятной в невозможную.
Arris
Что мешает ботам перебирать все возможные порты?
Cayp
Ничего.
Если вы пытаетесь донести какую-то информацию или высказать свою точку зрения, то можете делать это сразу без вступлений.
arandomic
Фуллскан портов — обыденность. Если ssh не прятать за port-knocking'ом и шодан и ботнеты о нем узнают.
Месяца два назад смотрел логи на своей VPS для домашних проектов, в нестандартный порт openvpn стучались также часто, как в стандартные порты ssh/ssl.
blog.shodan.io/dont-be-clever
arandomic
Блин. Наверное не стоит нажимать кнопку «отправить», на комментарии, который написал и не отправил сутки назад=D
k0ldbl00d
Если вы параноик, используйте fail2ban, например.
AlexTorch
если Вы такой параноик, настройте port knocking
Zettabyte
У многих безлимит, но на маленьких VPS нередко бывают ограничения, и когда вот так впустую съели девять ГБ из ста, мне это пришлось не по нраву. Остатка всё равно хватило с лихвой, но после этого порт поменял.
Tortortor
эти 9Гб пришли бы вне зависимости от порта, настроек, файрвола. вы это понимаете?
edogs
Пришло бы меньше.
Одно дело когда стучатся не получают ответа вообще.
Другое дело когда стучатся, получают какой-то ответ, посылают новый запрос.
Кроме того, если получили отклик на 22 порту, то зачастую включают брутфорс — это жрет куда больше траффика, чем разовый пинг порта.
isden
Ага, именно поэтому DROP лучше REJECT в таких случаях :)
AEP
А мне жалко. Поскольку из-за таких перебиральщиков «ssh по крону» периодически отваливается, напарываясь на лимит числа соединений, не прошедших стадию авторизации.
artemisia_borealis
для «перебиральщиков» можно предоствлять беспалную услугу блокировки типа такой (пример куска pf.conf, OpenBSD)
Но вот я лично меняю порт
sshиз простых практических соображений:/var/log/authlogстановиться чистым как стекло :)Black_Shadow
Это абсолютно бесполезное занятие, все другие порты тоже «тестируют».
JC_IIB
Ну, есть же port-knocking :) удачи «тестировщикам», чо.
untilx
Если начали тестировать «все другие порты», значит пришли конкретно за этим сервером, что бывает не так часто, как обычный автоматизированный скан.
Merkat0r
Обычный автоматический скан — сканит все порты — Тотже Шодан, а уж китая ботнетику из пары сотен-десятков-тысяч(тм) устройств пофиг что и как сканить.
Более того обнаружение на не стандартном порту — повышает приоритет скана этой машины ибо *чтото тут интересненькое* и скоро на нее придет более прошаренный ботнетик с более злым сканом.
ЗЫ чот судя по тредику — с основами работы интернетика и банальной безопасности чот у всех прям беда-беда случилась, раньше
небо было зеленеекак-то прошаренее чтоль были :(untilx
Обычный автоматический скан просто ищет популярные уязвимости. Нет смысла тратить время на перебор вообще всего на одной отдельно взятой машине, если за то же время можно найти несколько уязвимых.
Merkat0r
про это и был постскриптум.дадада, все ок,как в Багдаде.untilx
Сейчас ситуация совсем чуть-чуть лучше, в основном из-за того, что практики разработки софта немного поменялись. В остальном, хуже не стало.
isden
> Более того обнаружение на не стандартном порту — повышает приоритет скана этой машины ибо *чтото тут интересненькое* и скоро на нее придет более прошаренный ботнетик с более злым сканом.
Там перебирали несколько юзеров, вроде portal, postgres и т.п.Ну как. Вот у меня ssh висит на нестандартном порту. Вход строго по ключам. Только один раз за несколько лет (на нескольких серверах) было что-то вроде
barbos6
Это полезное занятие, ибо все порты тестируют нааамного реже, чем пару сотен стандартных, и при отсутствии sshd на стандартном порту жуликами отнимается у сервера нааамного меньше ресурсов.
Разница заметна на маленьких, чахлых VPS — если боты перебирают пароли на стандартном порту в несколько потоков, то владелец зайти не может.
Ernillgeek
Это совершенно бесполезное занятие. Называется Security through obscurity. Еще раз. Нет нужды заниматься противоестественными вещами и вешать ssh непойми куда. Есть два шага для обеспечения полной безопасности ssh'а
1. Запрет авторайза по паролю, только ключ
2. fail2ban или его аналоги
Все. И не нужно прятать голову в песок и заниматься прочими глупостями
Stanislavvv
Это, помимо всего прочего, снижает объём auth.log с гигабайтов до мегабайтов. Иногда существенно, особенно если вдс используется чисто для впн и большого диска ей неположено.
А те два шага в любом случае нужны…
Ernillgeek
Ой, не рассказывайте сказки про гиги auth.log'а.
ls -lah /var/log/auth.log-rw-r----- 1 syslog adm 190K Jul 31 09:17 /var/log/auth.log
Гиги, блин.
Stanislavvv
```
# ls -lh /var/log/auth.log.1
-rw-r----- 1 root adm 862M Jul 29 06:25 /var/log/auth.log.1
```
Практически гиг за сутки.
Ernillgeek
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 rootStanislavvv
Крон там раз в 5 минут. Это именно ssh, причём чаще всего — сканирование порта, а не подбор паролей почему-то. А fail2ban есть… Только банить он настроен после 5 попыток подбора, а вчера шел поток с каждого ип по 3…
Ernillgeek
У меня стоит блокировка за 1 неудачную попытку. Ибо все равно ключи и легальные пользователи ошибиться не могут
Stanislavvv
Я 5 поставил как раз после того, как на хреновом канале стало банить при неудачных соединениях…
Ernillgeek
Ну я вот уточку съел и не крякаюНе знаю, никаких проблем и при ауфе по ключу на плохом канале нет. А на крайний случай у меня на самих серверах IPшники других моих серверов в вайт-листах, если надо зайду на один через другой
DSolodukhin
Это делается скорее из расчета на недонастроенные VPS, ленивых админов и пр. Достаточно закрыть логин руту, включить логин только по ключу, и вероятность успешного брутфорса устремится к нулю. Можно еще добавить fail2ban.
Zettabyte
Может быть Хабр подскажет альтернативу fail2ban для VPS с маленьким объёмом памяти?
Например, у меня 384 МБ и f2b явно туда не влезет. А заворачивать нехороших граждан всё-таки хотелось бы. Использую CentOS 7.
Revertis
DenyHosts может подойти.
isden
В ufw, например, есть вот такая штука. Добавляет некий набор правил в iptables. Ту же самую магию в iptables можно и ручками добавить если что.
skystart
Ну например, для iptables, с помощью замечательного модуля recent:
-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.
azevakin
Попробуйте denyhosts
ValdikSS
sshguard. По сути, то же самое, но на C. Поддерживает не только SSH, как можно было бы подумать из названия.
Ernillgeek
О! Вижу у sshguard заявлена поддержка IPv6. Все хорошо там с ней?
Просто из-за IPv6 приходится на fail2ban 0.10 сидеть, который никак не зарелизится всё. Хотя случаев что бы какой-то бот нашел где там у меня в моей /56 что-то висит еще не было, но предпочитаю что бы этого бота если что поймали.
ValdikSS
Должно быть хорошо, ко мне по IPv6 никто не ломится.
Ernillgeek
Спасибо за наводку, для теста подниму на домашнем ноуте(у меня дома нативный IPv6, хвала провайдеру), а там уже буду думать стоит ли в прочих случаях на замену fail2ban'у призывать
Ernillgeek
А еще можно засунуть голову в песок. Тоже помогает не видеть опасностей. В перевешивании ssh'а на другой порт нет никакого смысла. Вообще.
1. Доступ только по ключу
2. fail2ban или его аналоги
И никаких голов в песок.
Ipeacocks
Разве сложно просканить группу портов и найти рабочие?
vconst
Однажды столкнулся с тем, что корпоративный фаервол пропускал очень ограниченное количество портов, и когда я поменял порт SSH на VPS, то мой рабочий компьютер не смог подключиться к серверу. Пришлось менять настройки порта через смартфон…
Ernillgeek
Для таких случаев ставим nginx из mainline(нам нужен выше 1.15.0) и читаем доку или пример в новости. Вешаем запасной ssh на 443/tcp. Вот уж 443/tcp должен проходить через любые рабочие файрволлы
vconst
Да, это поможет. Но я, не зная особенностей фаервола — поменял порт сразу после создания VPS, и получил дулю :)
Ernillgeek
А нечего порт менять :)
Вообще команда nginx'а молодцы с этой фичей в mainline, я думаю со временем на всех серверах у себя сделать подобный запасной вход. Просто на части использую mainline, там вот на днях собираюсь внести изменения в конфиги, на части, по ряду причин, stable, там с выходом 1.16 применю.
Такая конфигурация даст возможность подключаться и из очень ограниченных по портам сетей
vconst
Я хотел как лучше… :)
Ernillgeek
Я тут уже несколько раз повторял, что менять порт нет смысла.
Есть смысл в закрытии парольного ауфа и fail2ban'е. Это обеспечит безопасность сервера без смены порта, при чем реальную безопасность, а не безопасность страуса спрятавшего голову в песок.