Чи зміна номера порту за замовчуванням насправді підвищує безпеку?

Я бачив поради, які повинні використовувати різні номери портів для приватних додатків (наприклад, інтранет, приватна база даних, все, що не використовує жоден сторонній чоловік).

Я не зовсім впевнений, що може покращити безпеку, оскільки

1. Порти сканерів існують
2. Якщо програма є вразливою, вона залишається такою, незалежно від її номера порту.

Я щось пропустив чи відповів на власне запитання?

Це не забезпечує серйозної оборони від цілеспрямованої атаки. Якщо ваш сервер орієнтований, то, як ви кажете, він порту сканує вас і дізнається, де ваші двері.

Однак переміщення SSH з порту за замовчуванням 22 буде стримувати деякі нецільові та аматорські сценарії дитячих атак. Це відносно непідготовлені користувачі, які використовують сценарії для сканування портів великих блоків IP-адрес одночасно, щоб побачити, чи відкритий порт 22, і коли вони знайдуть його, вони розпочнуть якусь атаку на нього (груба сила, атака словника, тощо). Якщо ваша машина знаходиться в тому блоці сканування IP-адрес, і він не працює SSH на порту 22, він не реагує і тому не відображатиметься у списку машин для атаки цього сценарію. Ерго, існує деяка безпека низького рівня, але лише для цього типу умовно-патогенних атак.

Наприклад, якщо у вас є час - зануріться на свій сервер (припустимо, що SSH знаходиться на порту 22) і витягніть всі унікальні невдалі спроби SSH, які ви можете. Потім перемістіть SSH з цього порту, зачекайте деякий час і знову перейдіть до дайвінгу. Ви, безсумнівно, знайдете менше атак.

Раніше я запускав Fail2Ban на загальнодоступному веб-сервері, і це було дійсно, дуже очевидно, коли я перемістив SSH з порту 22. Він вирізав опортуністичні атаки на порядок.

Дуже корисно зберегти журнали в чистоті.

Якщо ви побачите невдалі спроби запуску sshd на порту 33201, ви можете сміливо припустити, що особа націлена на вас, і у вас є можливість вжити відповідних заходів, якщо ви цього хочете. Наприклад, звернутися до органів влади, розслідувати, хто може бути цією особою ( шляхом перехресних посилань на IP-адреси ваших зареєстрованих користувачів або що завгодно) тощо.

Якщо ви використовуєте порт за замовчуванням, тоді буде неможливо дізнатися, чи хтось на вас нападає, чи це просто випадкові ідіоти, які роблять випадкові сканування.

Ні, це не так. Не зовсім. Термін для цього - " Захист від непрозорості", і це не є надійною практикою. Ви правильно в обох своїх пунктах.

Безпека з боку невідповідності в кращому випадку стримує випадкові спроби, які просто намагаються шукати порти за замовчуванням, знаючи, що в якийсь момент вони знайдуть когось, хто залишив вхідні двері відкритими. Однак якщо є якась серйозна загроза, що перед вами буде зміна дорогого порту, то принаймні сповільнить початкову атаку вниз, але лише настільки незначно через те, що ви вже вказали.

Зробіть собі прихильність і залиште свої порти налаштованими належним чином, але вживайте належних заходів безпеки, щоб заблокувати їх належним брандмауером, авторизаціями, ACL тощо.

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

Колись це було гарною ідеєю, щоб уникнути мережевих черв’яків, оскільки вони прагнули сканувати лише один порт. Однак час хробака, що швидко розмножується, минув.

Як зазначали інші, зміна номера порту не пропонує вам великої безпеки.

Хочу додати, що зміна номера порту насправді може завдати шкоди вашій безпеці.

Уявіть наступний спрощений сценарій. Зломщик сканує 100 господарів. У дев'яносто дев'яти з цих хостів є доступні сервіси на цих стандартних портах:

Port    Service
22      SSH
80      HTTP
443     HTTPS

Але тоді є один хост, який виділяється з натовпу, оскільки власник системи намагався придушити свої послуги.

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

Тепер це може бути цікавим злому, оскільки сканування пропонує дві речі:

1. Власник хоста намагається приховати номери портів у своїй системі. Можливо, власник вважає, що в системі є щось цінне. Це може бути не працює система млини.
2. Вони обрали неправильний метод для захисту своєї системи. Адміністратор допустив помилку, повіривши в затуманення портів, що вказує на те, що вони можуть бути недосвідченим адміністратором. Можливо, вони використовували обфускування портів замість належного брандмауера або належного IDS. Можливо, вони також допустили інші помилки безпеки і можуть бути вразливими до додаткових атак безпеки. Давайте зараз трохи пробуємо, чи не так?

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

Я збираюся йти проти загальної тенденції, принаймні частково.

Самостійно перехід на інший порт може отримати за пару секунд під час пошуку, а отже, нічого не отримати в реальному вираженні. Однак, якщо ви поєднаєте використання нестандартних портів разом із антипортовими сканерами, це може призвести до справжнього підвищення безпеки.

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

Для перемоги над цією системою знадобиться або удача (потрапляння на правий порт перед тим, як заблокувати), або розподілене сканування, яке викликає інші заходи, або дуже тривалий час, який також можна було б помітити і діяти.

На мою думку, переміщення порту, на якому працює програма, зовсім не підвищує безпеку - просто з тієї причини, що та сама програма працює (з тими ж сильними і слабкими сторонами) просто на іншому порту. Якщо у вашої програми є слабкість при переміщенні порту, який він слухає на інший порт, це не усуває слабкість. Гірше, що він активно спонукає вас НЕ подолати слабкість, тому що тепер його не забивають постійно автоматизованим скануванням. У ньому прихована реальна проблема - проблема, яка насправді повинна бути вирішена.

Деякі приклади:

• "Очищає журнали" - тоді у вас виникає проблема з тим, як ви обробляєте свої журнали.
• "Це зменшує накладні витрати на з'єднання" - Накладні витрати або незначні (як і більшість скануючих), або вам потрібна якась фільтрація / Пом'якшення відмови від надання послуг, здійснене вгору за течією
• "Це зменшує експозицію програми" - Якщо ваша програма не може протистояти автоматичному скануванню та експлуатації, то у вашій програмі є серйозні недоліки безпеки, які потрібно усунути (тобто тримати її виправленими!).

Справжня проблема адміністративна: люди очікують, що SSH буде в 22, MSSQL в 1433 і так далі. Переміщення їх ще один складний рівень і необхідна документація. Дуже прикро сідати за мережу і доводиться використовувати nmap, щоб зрозуміти, куди перемістилися речі. Доповнення до безпеки є ефемерними в кращому випадку, і недоліки не суттєві. Не робіть цього. Виправте справжню проблему.

Ви впевнені, що це не принесе великої безпеки (оскільки діапазон портів серверів TCP має лише 16 біт ентропії), але ви можете зробити це з двох інших причин:

• як вже говорили інші: зловмисники, які намагаються здійснити багато входів, можуть захаращувати ваші журналові файли (навіть якщо атаки словника з одного IP-адреси можуть бути заблоковані програмою fail2ban);
• SSH потрібна криптографія відкритого ключа для обміну секретними ключами для створення захищеного тунелю (це дорога операція, яку в нормальних умовах робити не потрібно дуже часто); повторні з'єднання SSH можуть витрачати енергію процесора .

Зауваження: Я не кажу, що вам слід змінити порт сервера. Я просто описую розумні причини (IMO), щоб змінити номер порту.

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

Я бачу одну гіпотетичну ситуацію, коли потенційна користь для безпеки при запуску вашого sshd на альтернативному порту. Це було б у сценарії, коли виявлено тривіально використану віддалену вразливість у програмному забезпеченні sshd, яке ви працюєте. У такому випадку запуск вашого sshd на альтернативному порту може дати вам лише додатковий час, щоб не бути випадковою цільовою адресою.

Сам я запускаю sshd на альтернативному порту на своїх приватних машинах, але це головним чином як зручність утримувати безлад у /var/log/auth.log. У багатокористувацькій системі я дійсно не вважаю представлену вище невелику гіпотетичну перевагу безпеки достатньою причиною того, що додаткові клопоти, спричинені тим, що sshd не знайдеться у стандартній частині.

Це трохи підвищує безпеку. У тому, що зловмисник, знайшовши відкритий порт, тепер повинен розібратися, що працює в порту. Не маючи доступу до ваших конфігураційних файлів (поки :-)), він не має уявлення, чи працює порт 12345 http, sshd або хтось із тисячі інших загальних служб, тому їм потрібно зробити додаткову роботу, щоб з’ясувати, що працює, перш ніж вони можуть серйозно атакувати його.

Крім того, як вказував інший плакат, тоді як спроби увійти в порт 22 можуть бути безглуздими скриптами-дітками, зомбі-троянами або навіть справжніми користувачами, які неправильно ввели IP-адресу. Спроба увійти в порт 12345 майже впевнена, що це справжній користувач або серйозний зловмисник.

Іншою стратегією є наявність декількох портів «медоловки». Оскільки жоден справжній користувач не знає про ці номери портів, то будь-яка спроба підключення повинна вважатися шкідливою, і ви можете автоматично блокувати / повідомляти про IP-адресу, що порушує право.

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

Не сама по собі. Однак, не використовуючи порт за замовчуванням для певної програми (скажімо, SQL Server), в основному змусить ваш зловмисник сканувати ваші порти; потім ця поведінка може бути виявлена ​​вашим брандмауером або іншими показниками моніторингу, а IP-адреса зловмисника заблокована. Крім того, середній "скрипт дитячий" швидше буде відшкодований, коли простий інструмент або командний скрипт, який вони використовують, не знайде екземпляр сервера SQL на вашій машині (оскільки інструмент перевіряє лише порт за замовчуванням).