Навіщо змінювати порт ssh за замовчуванням?


Відповіді:


27

Найбільш вірогідна причина - це ускладнити людей, які випадковим чином намагаються жорстоко змусити будь-який SSH логін, який вони можуть знайти. Моя машина, орієнтована на Інтернет, використовує стандартний порт SSH, а мої журнали заповнювались такими матеріалами (витяг із фактичного файлу журналу):

sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96

Ці дні я використовую DenyHosts для блокування IP-адрес, які не вдається занадто багато разів автентифікуватись, але, мабуть, так само просто перемикати порти; практично всі напади грубої сили подібного роду не будуть турбувати сканування, щоб побачити, чи ваш sshd прослуховує інший порт, вони просто припускають, що ви не запускаєте його, і рухаєтесь далі


15

Ні, це безпека тактикою неясності .

Якщо ваша настройка sshd недостатньо підходить для того, щоб зіткнутися з тупими дітьми сценарію, які намагаються лише порт 22, у вас все одно виникнуть проблеми.

Більш раціональною реакцією буде:

  • переконайтеся, що ваші користувачі використовують хороші паролі, які важко здогадатися / грубо застосовувати
  • вимкнути автентифікацію пароля (принаймні для важливих облікових записів) та просто використовувати аутентифікацію відкритих ключів
  • стежте за проблемами безпеки та оновленнями ssh

Деяких людей також може дратувати шум, який sshd записує в системний журнал, наприклад:

Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth

Тоді може виникнути спокуса затемнити sshd-порт або використовувати автоматичне рішення блокування (наприклад, DenyHosts, Fail2ban або BlockHosts), щоб знову збільшити співвідношення сигнал-шум .

Але кращі альтернативи існують. Наприклад, ви можете налаштувати свого демона syslog таким чином, що шум журналу sshd записується лише до - скажімо - /var/log/sshd-attempts.logі сигнал (тобто решта повідомлень журналу sshd) записується в /var/log/messagesі т.д., як і раніше.

Розгортання засобів автоматичного блокування слід ретельно розглянути, оскільки додавання більшої складності до систем, що належать до безпеки, також означає збільшення ризику експлуатації . І дійсно, протягом багатьох років існує кілька звітів про вразливість DoS для кожного DenyHosts , Fail2ban і BlockHosts .


4
Я дійсно не згоден з тим, що "це безпека через неясність". Я думаю, що ця відповідь є звичайною помилкою в даному випадку. @ Міркування Майкла, як правило, показують, що це краща причина мати його в інших місцях. Це здебільшого просто для того, щоб позбутися від усіх скриптованих ботових атак. Це не означає, що ти їх боїшся чи вважаєш ефективним проти рішучого нападника. Я знаю, що я ніколи не хвилювався, що вони дійсно вберуться. Але все теребство дратувало.
ксенотерацид

1
@xenoterracide: Якщо ви стурбовані лише читабельністю ваших журнальних файлів, існують інші кращі альтернативи для виключення шуму замість зміни порту, як тактики невпевненості, в чому полягало питання. Щодо блокування IP, яке не було частиною питання: Зверніть увагу, що додавання більшої складності до систем, що стосуються безпеки, означає також збільшення ризику експлуатації. Розглянемо для прикладу seclists.org/fulldisclosure/2007/Jun/121 ossec.net/main/attacking-log-analysis-tools . Так, на це вплинув DenyHosts.
maxschlepzig

1
На увазі є не просто читабельність. Правильно задокументована зміна порту - це не безпека через невідомість.
ксенотеррацид

4

Зміна порту SSH - це здебільшого театр безпеки . Це дає вам нечітке відчуття, що ви щось зробили. Ви сховали порт SSH під дверною ковдрою.

Якщо ви запускаєте SSH-сервер в Інтернеті, ви побачите безліч невдалих спроб входу у свої журнали, від ботів, які шукають дурно слабкі паролі, слабкі клавіші та відомі подвиги в старших версіях сервера. Невдалі спроби - ось що: невдалі спроби. Щодо оцінки того, наскільки ви вразливі, вони абсолютно не мають значення. Що потрібно турбуватися - це успішні спроби вторгнення, і ви їх не побачите у своїх журналах.

Зміна порту за замовчуванням зменшить кількість звернень таких ботів, але це лише загрожує найменш складним зловмисникам, яких зупиняє будь-яка гідна безпека (оновлення безпеки застосовуються регулярно, досить міцні паролі або відключена перевірка пароля). Єдина перевага - зменшення обсягу колод. Якщо це проблема, розгляньте щось на зразок Denyhosts або Fail2ban, щоб обмежити швидкість з'єднання, це також зробить вашу пропускну здатність хорошою.

Зміна порту за замовчуванням має головний недолік: це робить менше шансів на можливість входу з-за брандмауера. Брандмауери швидше запускають служби через порт за замовчуванням, ніж на якийсь інший випадковий порт. Якщо ви не працюєте з сервером HTTPS, подумайте про те, щоб SSH прослуховував і порт 443 (або перенаправляв вхідні запити TCP з порту 443 на порт 22), оскільки деякі брандмауэры дозволяють трафік, який вони не можуть декодувати на порт 443, тому що це виглядає як HTTPS.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.