Как SSH появился на 22 порту

https://www.ssh.com/ssh/port
  • Перевод
SSH по умолчанию работает на порту 22. Это не совпадение. Вот история, как ему достался этот порт.

Когда я (Тату Илонен) впервые опубликовал эту историю в апреле 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

Поделиться публикацией
Комментарии 125
    +5
    На самом деле, желательно сразу менять стандартный порт, так как его постоянно тестируют на предмет уязвимостей и через попытки перебора паролей.
      +9
      Пусть тестируют, и сколько угодно могут перебирать rsa4096 тоже, мне не жалко :)
      Менять не всегда получается — иногда нужен именно 22 порт (банально для «красивых» url, без указания порта).
        +12
        Я не могу себе позволить выставлять SSH на стандартном 22 порту в интернет в виду следующих опасений:
        1. Всем известно что 22 порт постоянно сканируется, ботнеты и пр. Любой владелец фаерволла который собирает его логи знает что постоянно происходят сканы по стандартным портам (~1000шт)
        2. Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список

        3. Допустим в SSH протоколе обнаруживается 0-day уязвимость.
        За последние пару лет мы видели что такое случается с проектами с открытым кодом, тот же OpenSSL.

        Хорошо если эта уязвимость была обнаружена правильными товарищами, тогда есть шанс на то, что кто-то успеет обновиться.
        Плохо, если об этой уязвимости все узнают после её открытой эксплуатации.

        В такой ситуации, заполучив POC код, нет никаких проблем воспользоваться shodan.io (или тем же списком от ботов) и зодолбить всех кто найдётся на 22 порту.

        0-day уязвимости вполне может быть не важна длина ключа.

        Я параноик и это гипотетически невозможная ситуация?
          +22

          Нестандартный порт — это такая security by obscurity. На веб-сервера тоже постоянно ломятся на всякие /phpMyAdmin и т.п., и что, теперь и вместо 80 порта другой использовать?


          Я параноик и это гипотетически невозможная ситуация?

          Гипотетически очень многое возможно, но ситуация, при которой вас спасёт именно другой порт, крайне маловероятна, потому что эта "защита" не идёт ни в какое сравнение с методами, используемыми самим ssh. Полагаться нужно на стойкую криптографию, а не на то, что атакующий не знает, на каком порте у вас ssh. Да, и она может подвести, но настолько редко, что перестраховки обычно бессмысленны. Если уж так хочется приложить подорожник, то port knocking, whitelist по IP или сложный пароль пользователя (и sudo) имеют куда больше смысла, хотя полезность первого тоже неочевидна.

            +4
            Нестандартный порт — это такая 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 — нет особых проблем в использовании нестандартных портов.
              +2
              Если вас сильно беспокоит, то идеальным вариантом может быть впн-сервер, с которого уже идет ссш доступ во внутреннюю сеть. Имхо конечно, но порт, отличимый от 22 — это немного костылестроение и как минимум не удобно.

              В принципе, если ссш на всех хостах на каком-то 5222 — то еще ладно. А если везде разные команды и у каждого что-то свое — то это дичь.
                –3
                > на каком-то 5222

                А вот вешать еще и на порт который без того имеет четкое назначение
                xmpp-client 5222/tcp jabber-client # Jabber Client Connection
                xmpp-client 5222/udp jabber-client

                это уже не просто дичь, а дичь полнейшая.
                  +2
                  Порт — это просто цифры, ничего сакрального в них нет. Самому ssh, что клиенту, что серверу, разницы нет, 22 или 5222.
                  Другое дело, что нестандартная конфигурация дороже в обслуживании… Вот, к примеру, добавится к этому серверу с ssh на 5222 межсетевой экран, или IDS, а в нем в шаблоне для правил ssh прописан порт 22. И те, кто админят ту железку, должны это помнить.
                  А на своем локалхосте можно хоть и демократию внедрять.
                    –14
                    > Порт — это просто цифры, ничего сакрального в них нет. Самому ssh, что клиенту, что серверу, разницы нет, 22 или 5222.

                    Давай ты не будешь это рассказывать тому, кто админит сервера дольше, чем большинство местных читателей на свете живут, хорошо?

                    Перевешивание на нестандартный порт — верный признак попингуя начитавшегося дурных статей. Ни один админ с опытом подобной глупости творить не будет
                      +3
                      Давай ты не будешь это рассказывать тому..

                      А давайте дочитывать комент до конца, что ли… Или хотя бы до 2 абзаца… ;)
                        –2
                        В интернете общаются на «ты». Так заведено еще с ФИДОшных времен.
                          +1

                          Вы ошибаетесь, экстраполируя свое личное (и, возможно, своего окружения) понимание этикета на весь интернет.

                            0
                            Поздно, он уже в read-only. Этикет подвел, видимо.
                        +1
                        Давай ты не будешь это рассказывать тому, кто админит сервера дольше, чем большинство местных читателей на свете живут, хорошо?


                        /facepalm
                          +3
                          Опыт далеко не всегда указывает на качество работы.
                            –2
                            В твоем случае, возможно, в моем указывает.
                            Собственно любой сторонник перевешивания ssh на левые порты уже показывает, что его брать на работу не стоит, что он не думает о безопасности.
                              0
                              Я думаю, за насколько ярко выраженным комплексом нестандартнопортофобии скрывается еще одна удивительная история.
                              :D
                                –2
                                Да. Скрывается. Я нанимал админов и все кого я брал любители вешать на нестандартные порты в работе показывали свою полную непригодность.
                            +1
                            А высокомерия вам не занимать.
                    +1
                    Я пробовал ssh на разных портах на белом IP. Трафик «любопытных» на любом из 'well known' портов куда я пробовал перемещать ssh очень слабо отличается от трафика на 22 порту. На 80 порту ssh пытаются взломать примерно с той же интенсивностью что и на 22-м. Если ставить не 'well known' но из первой тыщи, то трафик «любопытных» тоже очень приличный.

                    Все дело в том, что сканеры портов вполне успешно распознают ssh на любом порту.
                    И кроме как отказаться от парольной аутентификации — ничего не остается.
                      0
                      Нестандартный порт — это НЕ security by obscurity.
                      security by obscurity — это когда тайным является СПОСОБ.
                      Тут же способ известен — смена порта. Номер порта фактически является ключем. Да, величина ключа не большая (десяток бит), но тем не менее ухудшает эффективность атаки на порядки.
                      +12
                      Всем известно что 22 порт постоянно сканируется, ботнеты и пр. Любой владелец фаерволла который собирает его логи знает что постоянно происходят сканы по стандартным портам (~1000шт)

                      Сканируются все 65 тысяч портов. Попробуйте повесить открытую http прокси на какой-нибудь совсем странный порт вроде 63241 и проверьте через сколько дней через нее повалит китайский спам.

                      Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список

                      Тут дело не в каких-то листах. Просто все ipv4 адреса в мире постоянно сканируются. На гигабитном канале TCP-SYN скан всего интернета по одному порту занимает ~20 минут (zmap, masscan).

                      Чем перевешивать SSH на нестандартные порты, и думать будто это вас от чего-то защищает, я бы рекомендовал поступать так:

                      Отключить аутентификацию по паролю, оставив только ключи. В таком случае сервер SSH будет сразу закрывать подключение при попытке авторизоваться по паролю.
                      /etc/ssh/sshd_config
                      -----------
                      PasswordAuthentication no
                      

                        +1
                        Сканируются все 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 на нестандартные порты, и думать будто это вас от чего-то защищает

                        Не передёргивайте, никто не говорит что это мера защиты. Это всего лишь способ уменьшения риска с учётом вышесказанного.
                          +3
                          в интернете 4294967296 адресов

                          Неправильно считаете. 592708864 адресов зарезервированы, так что сканировать достаточно 3702258432.
                            0
                            Спасибо.
                            Действительно, я ошибся примерно на 14% в большую сторону.
                            Но качественно это не изменило оценку.
                          0
                          я бы рекомендовал поступать так:

                          Отключить аутентификацию по паролю, оставив только ключи.


                          К сожалению сутью потенциальной уязвимости, вполне может быть игнорирование этих настроек, а то и вовсе пароля. Ну примерно как Убунта (или другая ОС, не помню) игнорирует пароль при выходе из спящего режима — бага, но она работает\работала.
                            0
                            Можно поставить простенькую IPS и банить на сутки при попытках просканировать например более 5-10 портов. До 50022 порта таким образом, любые китайцы доберутся очень не скоро.
                            +3
                            Как вам уже сказали — сканируют вообще всё и вся.
                            От «китайцев» надо защищаться не банальным прятаньем порта, а по-взрослому.
                            На почтовый сервер (на котором я не могу сменить порт по очевидным причинам) мне сыпется несколько десятков разных «китайцев» и прочих в минуту — приходится жить и обучать сервер отправлять отлупы таким товарищам.
                              +2
                              То-есть вы исключаете вариант что до появления 0-day уязвимости у вас кто-то упорный найдёт ssh на нестандартном порту?
                              Так для справки, у меня белым адресом в интернет светит порядка 250 устройств, на всех включен ssh, на всех нестандартные порты (порт не один на всех, их несколько). Вот только один фиг я в логах постоянно вижу попытки авторизации. Спасает разве что fail2ban с баном на месяц, и то иной раз открываешь список правил и офигеваешь с количества хостов и приходится подчищать, дабы не перегружать процессор обработкой всех этих правил.
                                –2
                                То-есть вы исключаете вариант что до появления 0-day уязвимости у вас кто-то упорный найдёт ssh на нестандартном порту?

                                Конечно не исключаю.

                                Я просто увеличиваю время для его поиска, точно так же как увеличивается время подбора пароля при увеличение его длины. Плюс исключаю тех потенциальных атакующих, кто не ищет сервисы на нестандартных портах.
                                С учётом того что сменить порт абсолютно бесплатно и не вызывает особых проблем, то я не вижу причин этого не делать, и вижу в этом больше плюсов чем минусов.
                                  0
                                  > и приходится подчищать, дабы не перегружать процессор обработкой всех этих правил.

                                  fail2ban прекрасно работает с ipset. И нет нужды что-то подчищать.
                                  banaction = iptables-ipset-proto6-allports спасет отца русской демократии
                                  0
                                  1. Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список

                                  Нет нужды в списках, просто сканируют и пробуют всё IPv4 пространство. Таким же образом тыкаются на всякие URL на 80 и 443 порты независимо от вообще какого-либо ответа от самого веб-сервера или наличия каких-либо файлов в DocumentRoot.

                                    0
                                    Речь о целенаправленных попытках подключения именно на этот адрес+порт. Десятки и сотни тысяч попыток подключения в течении дня. Чаще целыми подсетями, иногда разрозненные адреса.
                                    0
                                    Эксплуатируемая 0-day уязвимость в ssh приведёт к такому кошмару, что ваш сервер тут будет вероятно не самой большой проблемой. Я тоже никогда ничего не делаю с ssh, лишнее это. Даже ключи использую исключительно для удобства, чтобы пароли не копипастить туда-сюда, хотя пароли не отключаю, лишь бы они были достаточно большими (12 цифробукв это 100 лет перебора со скоростью 1e11 паролей в секунду. Если проверка одного пароля требует 9 байтов (вот такой вот мегакомпактный протокол), то это 100 лет трафика в 8 терабитов в секунду. Понятно, что в реальности даже если конкретно на вашем сервере решили перебрать пароли, то скорость будет на много порядков меньше, а если ваш сервер просто тестят несколько сотен раз в сутки, то там вообще речь идёт только о паролях вида root:root.
                                      0
                                      Мы все видели Heartbleed в OpenSSL, который затронул большинство веб серверов, Meltdown/Spectre, который затронул почти все Intel процессоры, (ещё был shellshock, но не настолько страшный) поэтому уязвимости в широко распространенном ПО существующем десятилетия перешли из разряда «фантастически невероятных» в просто «маловероятные».
                                      0
                                      > хотя пароли не отключаю, лишь бы они были достаточно большими (12 цифробукв это 100 лет перебора со скоростью 1e11 паролей в секунду.

                                      Тут есть еще один фокус. Нужно подобрать не только пароль, но и логин. По дефолту во всех системах сейчас идет PermitRootLogin prohibit-password. А все остальные логины надо еще угадать. То есть брутфорсеру надо угадать пару логин-пароль, а не просто пароль, что превращает задачу из маловероятной в невозможную.
                                      0
                                      Что мешает ботам перебирать все возможные порты?
                                        +2
                                        Ничего.
                                        Если вы пытаетесь донести какую-то информацию или высказать свою точку зрения, то можете делать это сразу без вступлений.
                                        0
                                        Фуллскан портов — обыденность. Если ssh не прятать за port-knocking'ом и шодан и ботнеты о нем узнают.
                                        Месяца два назад смотрел логи на своей VPS для домашних проектов, в нестандартный порт openvpn стучались также часто, как в стандартные порты ssh/ssl.

                                        blog.shodan.io/dont-be-clever
                                          0
                                          Блин. Наверное не стоит нажимать кнопку «отправить», на комментарии, который написал и не отправил сутки назад=D
                                          0
                                          Если вы параноик, используйте fail2ban, например.
                                            0
                                            если Вы такой параноик, настройте port knocking
                                            +5
                                            Пусть тестируют, и сколько угодно могут перебирать rsa4096 тоже, мне не жалко :)
                                            Тут есть ещё один не самый очевидный (и не для всех актуальный) момент — мне как-то не то за две, не то за три недели вот так вот «пусть наперебирали» на 9 ГБ трафика. Прямо такой аккуратный длинный прямоугольник на графике bandwidth.

                                            У многих безлимит, но на маленьких VPS нередко бывают ограничения, и когда вот так впустую съели девять ГБ из ста, мне это пришлось не по нраву. Остатка всё равно хватило с лихвой, но после этого порт поменял.
                                              +4
                                              эти 9Гб пришли бы вне зависимости от порта, настроек, файрвола. вы это понимаете?
                                                +4
                                                Пришло бы меньше.
                                                Одно дело когда стучатся не получают ответа вообще.
                                                Другое дело когда стучатся, получают какой-то ответ, посылают новый запрос.
                                                Кроме того, если получили отклик на 22 порту, то зачастую включают брутфорс — это жрет куда больше траффика, чем разовый пинг порта.
                                                  0
                                                  Ага, именно поэтому DROP лучше REJECT в таких случаях :)
                                              +2
                                              сколько угодно могут перебирать rsa4096 тоже, мне не жалко


                                              А мне жалко. Поскольку из-за таких перебиральщиков «ssh по крону» периодически отваливается, напарываясь на лимит числа соединений, не прошедших стадию авторизации.
                                                +1
                                                для «перебиральщиков» можно предоствлять беспалную услугу блокировки типа такой (пример куска pf.conf, OpenBSD)
                                                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 становиться чистым как стекло :)
                                              +9
                                              Это абсолютно бесполезное занятие, все другие порты тоже «тестируют».
                                                0
                                                Ну, есть же port-knocking :) удачи «тестировщикам», чо.
                                                  +4
                                                  Если начали тестировать «все другие порты», значит пришли конкретно за этим сервером, что бывает не так часто, как обычный автоматизированный скан.
                                                    –4
                                                    Обычный автоматический скан — сканит все порты — Тотже Шодан, а уж китая ботнетику из пары сотен-десятков-тысяч(тм) устройств пофиг что и как сканить.
                                                    Более того обнаружение на не стандартном порту — повышает приоритет скана этой машины ибо *чтото тут интересненькое* и скоро на нее придет более прошаренный ботнетик с более злым сканом.

                                                    ЗЫ чот судя по тредику — с основами работы интернетика и банальной безопасности чот у всех прям беда-беда случилась, раньше небо было зеленее как-то прошаренее чтоль были :(
                                                      +2
                                                      Обычный автоматический скан просто ищет популярные уязвимости. Нет смысла тратить время на перебор вообще всего на одной отдельно взятой машине, если за то же время можно найти несколько уязвимых.
                                                        –2
                                                        про это и был постскриптум. дадада, все ок, как в Багдаде.
                                                          0
                                                          Сейчас ситуация совсем чуть-чуть лучше, в основном из-за того, что практики разработки софта немного поменялись. В остальном, хуже не стало.
                                                        0
                                                        > Более того обнаружение на не стандартном порту — повышает приоритет скана этой машины ибо *чтото тут интересненькое* и скоро на нее придет более прошаренный ботнетик с более злым сканом.

                                                        Ну как. Вот у меня ssh висит на нестандартном порту. Вход строго по ключам. Только один раз за несколько лет (на нескольких серверах) было что-то вроде
                                                        Disconnected from authenticating user root 89.187.88.79 port 45162 [preauth]
                                                        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]
                                                        ...
                                                        Там перебирали несколько юзеров, вроде portal, postgres и т.п.
                                                      0
                                                      Это полезное занятие, ибо все порты тестируют нааамного реже, чем пару сотен стандартных, и при отсутствии sshd на стандартном порту жуликами отнимается у сервера нааамного меньше ресурсов.
                                                      Разница заметна на маленьких, чахлых VPS — если боты перебирают пароли на стандартном порту в несколько потоков, то владелец зайти не может.
                                                        –2
                                                        Это совершенно бесполезное занятие. Называется Security through obscurity. Еще раз. Нет нужды заниматься противоестественными вещами и вешать ssh непойми куда. Есть два шага для обеспечения полной безопасности ssh'а
                                                        1. Запрет авторайза по паролю, только ключ
                                                        2. fail2ban или его аналоги
                                                        Все. И не нужно прятать голову в песок и заниматься прочими глупостями
                                                          0
                                                          Это, помимо всего прочего, снижает объём auth.log с гигабайтов до мегабайтов. Иногда существенно, особенно если вдс используется чисто для впн и большого диска ей неположено.
                                                          А те два шага в любом случае нужны…
                                                            –1
                                                            Ой, не рассказывайте сказки про гиги auth.log'а.
                                                            ls -lah /var/log/auth.log
                                                            -rw-r----- 1 syslog adm 190K Jul 31 09:17 /var/log/auth.log

                                                            Гиги, блин.
                                                              0
                                                              ```
                                                              # ls -lh /var/log/auth.log.1
                                                              -rw-r----- 1 root adm 862M Jul 29 06:25 /var/log/auth.log.1
                                                              ```
                                                              Практически гиг за сутки.
                                                                –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
                                                                  0
                                                                  Крон там раз в 5 минут. Это именно ssh, причём чаще всего — сканирование порта, а не подбор паролей почему-то. А fail2ban есть… Только банить он настроен после 5 попыток подбора, а вчера шел поток с каждого ип по 3…
                                                                    0
                                                                    У меня стоит блокировка за 1 неудачную попытку. Ибо все равно ключи и легальные пользователи ошибиться не могут
                                                                      0
                                                                      Я 5 поставил как раз после того, как на хреновом канале стало банить при неудачных соединениях…
                                                                        0
                                                                        Ну я вот уточку съел и не крякаю
                                                                        Не знаю, никаких проблем и при ауфе по ключу на плохом канале нет. А на крайний случай у меня на самих серверах IPшники других моих серверов в вайт-листах, если надо зайду на один через другой
                                                      +5
                                                      Это делается скорее из расчета на недонастроенные VPS, ленивых админов и пр. Достаточно закрыть логин руту, включить логин только по ключу, и вероятность успешного брутфорса устремится к нулю. Можно еще добавить fail2ban.
                                                        +1
                                                        Можно еще добавить fail2ban
                                                        Если не возражаете, бессовестно вклинюсь:
                                                        Может быть Хабр подскажет альтернативу fail2ban для VPS с маленьким объёмом памяти?
                                                        Например, у меня 384 МБ и f2b явно туда не влезет. А заворачивать нехороших граждан всё-таки хотелось бы. Использую CentOS 7.
                                                          0
                                                          DenyHosts может подойти.
                                                            0
                                                            В ufw, например, есть вот такая штука. Добавляет некий набор правил в iptables. Ту же самую магию в iptables можно и ручками добавить если что.
                                                              0
                                                              Ну например, для 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.
                                                                0
                                                                Попробуйте denyhosts
                                                                  0
                                                                  sshguard. По сути, то же самое, но на C. Поддерживает не только SSH, как можно было бы подумать из названия.
                                                                    0
                                                                    О! Вижу у sshguard заявлена поддержка IPv6. Все хорошо там с ней?
                                                                    Просто из-за IPv6 приходится на fail2ban 0.10 сидеть, который никак не зарелизится всё. Хотя случаев что бы какой-то бот нашел где там у меня в моей /56 что-то висит еще не было, но предпочитаю что бы этого бота если что поймали.
                                                                      0
                                                                      Должно быть хорошо, ко мне по IPv6 никто не ломится.
                                                                        0
                                                                        Спасибо за наводку, для теста подниму на домашнем ноуте(у меня дома нативный IPv6, хвала провайдеру), а там уже буду думать стоит ли в прочих случаях на замену fail2ban'у призывать
                                                                –2
                                                                А еще можно засунуть голову в песок. Тоже помогает не видеть опасностей. В перевешивании ssh'а на другой порт нет никакого смысла. Вообще.
                                                                1. Доступ только по ключу
                                                                2. fail2ban или его аналоги
                                                                И никаких голов в песок.
                                                                  0
                                                                  Разве сложно просканить группу портов и найти рабочие?
                                                                    0
                                                                    Однажды столкнулся с тем, что корпоративный фаервол пропускал очень ограниченное количество портов, и когда я поменял порт SSH на VPS, то мой рабочий компьютер не смог подключиться к серверу. Пришлось менять настройки порта через смартфон…
                                                                      0
                                                                      Для таких случаев ставим nginx из mainline(нам нужен выше 1.15.0) и читаем доку или пример в новости. Вешаем запасной ssh на 443/tcp. Вот уж 443/tcp должен проходить через любые рабочие файрволлы
                                                                        0
                                                                        Да, это поможет. Но я, не зная особенностей фаервола — поменял порт сразу после создания VPS, и получил дулю :)
                                                                          –1
                                                                          А нечего порт менять :)
                                                                          Вообще команда nginx'а молодцы с этой фичей в mainline, я думаю со временем на всех серверах у себя сделать подобный запасной вход. Просто на части использую mainline, там вот на днях собираюсь внести изменения в конфиги, на части, по ряду причин, stable, там с выходом 1.16 применю.
                                                                          Такая конфигурация даст возможность подключаться и из очень ограниченных по портам сетей
                                                                            0
                                                                            Я хотел как лучше… :)
                                                                              –2
                                                                              Я тут уже несколько раз повторял, что менять порт нет смысла.
                                                                              Есть смысл в закрытии парольного ауфа и fail2ban'е. Это обеспечит безопасность сервера без смены порта, при чем реальную безопасность, а не безопасность страуса спрятавшего голову в песок.
                                                                    +1

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


                                                                    У нас можно зайти всего с одного ип, и это статический ип офиса, а к офису уже по впн.
                                                                    Конечно можно потерять контроль над серверами, если в офисе обрушится интернет, но пока что ситуаций одновременных траблов в датацентре и в офисе не возникало

                                                                      +6
                                                                      Прям читаю и не понимаю как вы не понимаете что ни в коем случае нельзя так делать.
                                                                      В вашем случае невозможность попасть на сервера это просто вопрос времени. Объяснять почему?
                                                                        0
                                                                        Я не в теме, но попробую догадаться: потому что ip адрес отправителя в пакете можно заменить на любой?
                                                                          +3
                                                                          Думаю, тут скорее имелось в виду некое событие, после которого сменится либо станет недоступным публичный IP-адрес офиса (например, провайдер решит адресацию сети поменять без предупреждения или просто у провайдера произойдёт долговременный технический сбой).
                                                                          А поскольку к серверу можно подключиться только с одного IP-адреса, и этот адрес стал нам недоступен, то и подключиться к серверу мы не сможем.
                                                                            0
                                                                            Нет, потому что может потребоваться подключится к серверу с мобильного или в поездке. Вот если бы вы сказали про личный VPN, я бы понял.
                                                                            0
                                                                            Если вы имеете ввиду, что злоумышленник может добраться до 22 порта даже при таких ограничениях, то да, я бы хотел знать почему это вопрос времени.
                                                                            Если вы о подмене IP в заголовке пакета, то во-первых взломщик должен знать на какой IP менять, что не особо тривиально, если не прослушивать пакеты находясь между.
                                                                            И конечно же все остальные условия безопасности, типа авторизации только по ключу, тоже выполнены.
                                                                            Думаю, тут скорее имелось в виду некое событие, после которого сменится либо станет недоступным публичный IP-адрес офиса (например, провайдер решит адресацию сети поменять без предупреждения или просто у провайдера произойдёт долговременный технический сбой).
                                                                            А поскольку к серверу можно подключиться только с одного IP-адреса, и этот адрес стал нам недоступен, то и подключиться к серверу мы не сможем.

                                                                            Пока что таких событий не было, IP компании установлен контрактом и ни в коем случае не может быть поменян без предупреждения, после которого, конечно же правила доступа будут изменены. А что касается технических сбоев, ну в самом крайнем случае, на фаерволл можно зайти без привязки по IP и поменять правила доступа.
                                                                            Ну и а с фаерволлом там свои условия для входа.

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


                                                                            Ну так когда я в поездке, то я подключаюсь к офису через VPN и захожу на нужный ресурс.

                                                                            Неплохо бы, чтобы физический доступ к серверам был. А то, например, подсеть РКН забанит — и тогда трафик к ней может вообще перестать ходить (


                                                                            Пока в РКН есть Р, они до нас не доберутся 8-)
                                                                              0

                                                                              События, случившиеся во время охоты на телеграм, никого не смущают.

                                                                              0
                                                                              Вы не думали что там может быть ec2 где правило можно поменять прямо из панели?
                                                                              0

                                                                              Неплохо бы, чтобы физический доступ к серверам был. А то, например, подсеть РКН забанит — и тогда трафик к ней может вообще перестать ходить (

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

                                                                                А если админ может сегодня заходить из одного города, завтра из другого, а послезавтра из другой страны?
                                                                                Доступ по ключу и fail2ban помогают, вместо засовывания головы в песок.
                                                                                +2
                                                                                Разве не Юлонен? Вроде бы в финском «Y» всегда «Ю»?
                                                                                  +1
                                                                                  Это мягкая «у». Ближайший звук, пожалуй, как у «ю» в «мюслях». Из звуков русского языка больше подходит «ы» или «и». Обозначать его как начальную «ю» совсем некорректно, поскольку там нет звука «й».
                                                                                +13
                                                                                Эх, просто отправил письмо и просто получил положительный ответ меньше, чем через сутки.
                                                                                  0

                                                                                  Меньше, чем через 4 часа. Хотя в тексте перевода значится "На следующий день в почтовом ящике лежало письмо от Джойса".

                                                                                    0
                                                                                    >Меньше, чем через 4 часа.
                                                                                    Может у них часовые пояса разные
                                                                                      +1

                                                                                      Точно, 10 часов разницы.

                                                                                      0
                                                                                      Не меньше, чем через 4 часа. Стоит ещё учитывать часовые пояса. Хоть и меньше, чем через сутки, но все равно прошло некоторое время, за которое можно лечь спать и получить субъективное «завтра».
                                                                                    +4
                                                                                    Интересна еще и история самого толчка для разработки 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.
                                                                                      +11
                                                                                      Как SSH появился на 22 порту
                                                                                      Ну, 21 порт был занят, 23 тоже, а 22 свободен, отправил письмо с просьбой дать этот порт, и вот, теперь SSH на 22 порту. Вирусная история, господа.
                                                                                        +6

                                                                                        За каждым номером порта скрывается удивительная история.

                                                                                        0
                                                                                        Контактное лицо для порта… прикольно
                                                                                          +5
                                                                                          Судя по википедии Joyce K. Reynolds — женщина, а в тексте её имя склоняется по правилам мужского рода.
                                                                                            +2
                                                                                            Я всегда считал, что номера портов у молодых проектов назначаются примерно так:
                                                                                            — Люда! Назови цифру от одного до 65535
                                                                                            — 22
                                                                                            — Вася, теперь SSH на 22 порту, добавь меня в контакты

                                                                                            Ведь когда-то все эти веб-серверы, ssh, ssl, telnet были «молодыми проектами».
                                                                                            А потом оно просто приживается и остается.
                                                                                              +2
                                                                                              Ведь когда-то все эти веб-серверы, ssh, ssl, telnet были «молодыми проектами».


                                                                                              Я недавно был шокирован, узнав, что Git появился в 2005
                                                                                                +5
                                                                                                Шокированы тем, что давно, или тем, что недавно?
                                                                                                  0
                                                                                                  Тем, что недавно. Я был уверен, что git, linux, unix – наследие прошлых поколений. А вот оказывается, оно прямо рядом со мной появлялось!
                                                                                                  +2
                                                                                                  А я вот помню, как Линус сказал «Да любись оно все конем», заперся на несколько дней и представил нам git. Это же все происходило прямо у нас на глазах в режиме онлайн
                                                                                                +8
                                                                                                В то время это означало уважаемых первопроходцев интернета Джона Постела и Джойса К. Рейнольдса. Среди всего прочего, Джон являлся редактором таких незначительных протоколов, как IP (RFC 791), ICMP (RFC 792) и TCP (RFC 793). Возможно, кто-то из вас слышал о них.
                                                                                                Вот вам фотография «первопроходца»; фразы надо переписать в женском роде:

                                                                                                image

                                                                                                icannwiki.org/Joyce_Reynolds
                                                                                                  0
                                                                                                  Чёрт, неожиданно. Спасибо!
                                                                                                  0
                                                                                                  Давным-давно, запарившись проверять и настраивать порты, я поставил ovpn на сервер и оставил открытими только 80,443 и порт ovpn. Доступ ко всем остальным сервиcам настроил только с интерфейса ovpn. Все. Чистые логи, никакого брутфорса. И вам советую.
                                                                                                    +1
                                                                                                    > 443 и порт ovpn

                                                                                                    Можно пойти еще дальше и засунуть OpenVPN на тот же 443/tcp, при помощи sslh, либо повесив на 443/tcp свежий mainline nginx повесить там ssh одновременно с https.
                                                                                                    –1

                                                                                                    А затем, была добавлена поддержка ГОСТ-криптографии в ssh.

                                                                                                      0

                                                                                                      Для чего в правилах iptables опция "--ctstate NEW,ESTABLISHED"?

                                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                    Самое читаемое