Відповіді:
Це не так корисно, як стверджують деякі люди, але принаймні зменшить вплив на ваші файли журналів, оскільки багато спроб входу в грубу силу використовують лише порт за замовчуванням, а не сканування, щоб перевірити, чи SSH слухає в іншому місці. Деякі атаки будуть шукати SSH в іншому місці, тому це не срібна куля.
Якщо ваш сервер буде якимсь спільним хостом, а не просто обслуговує потреби ваших проектів, використання нестандартного порту може бути болем, оскільки вам доведеться пояснювати це своїм користувачам знову і знову і знову і знову коли вони забувають, а їхні клієнтські програми не підключаються до порту 22!
Інша можлива проблема з SSH на нестандартному порту - це якщо ви стикаєтесь із клієнтом із обмежувальним набором фільтрів, який не може підключитися до вашого користувальницького порту, оскільки їх фільтр дозволяє лише, наприклад, порти 22, 53, 80 і 443 - це місце для нових вихідних з'єднань. Це нечасто, але, безумовно, нечувано. У подібному питанні деякі провайдери можуть бачити зашифрований трафік на порту, відмінному від тих, де зазвичай очікується (порт 443 або HTTPS, 22 для SSH тощо) як спроба приховати з'єднання P2P та дросель (або блок) з'єднання незручним чином.
Я особисто зберігаю SSH на стандартному порту для зручності. Поки вживаються звичайні заходи безпеки (чітка політика щодо паролів / ключів, обмеження кореневих логінів, ...), це не повинно турбуватися, і проблема росту файлів журналу, коли ви потрапили в грубу атаку, може бути зменшена за допомогою таких інструментів як fial2ban тимчасово блокувати хости, які надають занадто багато поганих наборів облікових даних автентифікації за певний проміжок часу.
Який би порт ви не вибрали, якщо ви відійдете від 22, переконайтеся, що він нижчий за 1024. У більшості налаштувань, подібних Unix у конфігурації за замовчуванням, лише порт (або користувачі кореневої групи) можуть слухати на портах нижче 1024, але будь-який користувач може слухати на вищих портах. Запуск SSH на більш високому порту збільшує ймовірність того, що шахрайський (або зламаний) користувач вдається зірвати ваш демон SSH та замінити його своїм або проксі-сервером.
Це проста (але на диво ефективна) форма безпеки через неясність .
Якщо ваш SSH-сервер не знаходиться на порту 22, набагато рідше їх знайдуть ті, хто сканує весь Інтернет, шукаючи слабкі паролі в облікових записах за замовчуванням. Якщо ви скануєте всю мережу, ви не можете дозволити собі перевірити всі 64 000 можливих портів, щоб знайти SSH-сервер.
Однак якщо хтось активно націлює на вас конкретно, це не приносить користі, оскільки просте одноразове nmapсканування виявить порт, на якому він фактично працює.
Щоб справді уникнути грубих нападів, завжди важливо дотримуватися деяких кроків:
Так, це корисно, оскільки це просто допомагає уникнути всіх грубих атак та допомагає зберігати журнали чіткими :)
що стосується вашого номера порту, який ви вирішили, я бачив, як компанії використовують 1291 досить часто. Я використовую щось вище, хоча просто, щоб уникнути деяких сценаріїв.
Не дозволяючи входити в корінь ssh та змінювати номер порту, можливо, щось на кшталт fail2ban, і ви повинні бути золотими. додайте iptables для гарної міри та постійно інформуйте вас, і у вас не повинно виникнути жодних проблем.
Використання нестандартного порту ssh вимагатиме більше пояснень та документації та відповіді на електронні листи "я не можу ввійти".
Я вважаю наступні переваги запуску sshd на нестандартному порту важливішими, ніж проблеми, які він створює:
Більше того, якщо ви хочете бути справді неприємними, ви завжди можете запустити підроблений sshd (з DenyUsers * ) на стандартному порту 22, тоді як ваш звичайний sshd працює на порту 54321. Це запевнить вас, що всі боти та зловмисники бажають назавжди спробуйте увійти в службу, яка заперечує всі входи, оскільки ніхто ніколи не задумається намагатися знайти вашу справжню службу sshd.
Мої 2 копійки.
Робити це з будь-якої причини "безпеки" - неправдиво. Це найкращий приклад безпеки через невідомість, яка не є безпекою.
Якщо ви хочете, щоб ваші журнали були трохи світлішими та чистішими, то так, це корисно, оскільки у вас не вийде стільки спроб збивання портів / скрипт-kiddy bruteforce.
Я б запустив ssh на стандартний порт і використовував щось на кшталт fail2ban або denyhosts, щоб обмежити кількість атак на словник.
Інший варіант - відключити вхід із паролем altogheter і дозволити входити в систему лише за допомогою ssh-ключів.
Тому що там багато поганих людей, які сканують усі IP-адреси сервера на наявність відкритих портів, намагаючись використати. У мене протягом усього дня були атаки молотом на мій порт SSH, поки я не перемістив його на інший порт і на IP-адресу, яка більше не була пов'язана з жодним із моїх веб-сайтів.
Це корисно тим, що скрипт-боти, які намагаються атакувати жорстокі дії пароля, зазвичай зосереджуються на порту 22, тому зміна портів зазвичай відкидає їх. Вам потрібно буде врівноважувати значення пом'якшення цього ризику з болем налаштування ssh-клієнтів для підключення до нестандартного порту (правда, не дуже багато, якщо у вас не так багато користувачів, що підключаються).
Крім того, ви можете пом'якшити грубу силу ризику, вимкнувши аутентифікацію пароля та вимагаючи автентифікації ключа RSA.
Зазвичай я не змінюю порт на SSHD, тому не можу запропонувати інше число, але перевірте загальновживаний список портів, щоб знайти інше число (тобто той, який не використовується чимось іншим, і таким чином може бути сканований) .
Я завжди міняю свій SSHd, щоб використовувати порт 2222, кожен, кому потрібно буде потрапити на мої сервери, знає це, і це не секрет. Здійснюючи це, немає абсолютно ніякого приросту безпеки (якщо тільки хакер не є абсолютним дебілом).
Єдину користь, яку я отримую від цього, є те, що в журналі auth немає мільйона невдалих спроб входу для 'root', 'alice', 'bob', 'sally', 'admin' тощо.
Безпека через незрозумілість виявилася марною, зазвичай я налаштовую доступ ssh за допомогою стандартного порту з усіх вищезгаданих причин (проблеми клієнта при переконфігуруванні, проблеми брандмауера та проксі тощо).
На додаток до цього, я завжди відключаю кореневу реєстрацію та автентифікацію пароля, і як останній крок, я використовую fail2ban, щоб позбутися цих дратівливих повідомлень у syslog. У Debian / Ubuntu це так само просто, як і введення тексту aptitude install fail2ban. Конфігурація за замовчуванням працює досить добре, але я зазвичай налаштовую деякі параметри на більш обмежувальні, маючи більший час заборони (принаймні один день) і лише 2 невдалі спроби аутентифікації як тригер для заборони.
Я б сказав, що те, від чого ти найбільше захищаєш себе при зміні порту SSH, - це автоматизовані сканування, які намагатимуться отримати доступ за допомогою стандартних імен користувачів / паролів, якщо ваші правила паролів жорсткі, вам не потрібно буде турбуватися їх.
Якщо ви відключите вхід пароля на свій сервер (що настійно рекомендується), то міняти порт SSH абсолютно марно. Відключивши вхід до пароля (і вимагаючи автентифікації на основі ключа), ви виключаєте можливість грубої спроби пароля, тому нічого не отримуєте, вдаючись до номерів портів.
Якщо ви й надалі дозволяєте встановити автентифікацію бази паролів, ви залишаєте себе відкритими для можливості успішної спроби грубої спроби або - що більш часто зустрічається, на мій досвід - ваш пароль порушений, оскільки ви вводите його під час використання системи, що працює кейлоггер.
man ssh-keygenз великою кількістю інформації.
Не відповідь, але занадто довго для коментаря, тому я зроблю це CW.
Я деякий час думав над цим і прийшов до висновку, що багато правди в тому, що говорить Джуліано в коментарях до відповіді Альнітака. Тим не менш, я вважаю, що запуск SSH на порт 22 просто надто легко запускати проти нього будь-які атаки.
Щоб вирішити цю проблему, я запускаю свої внутрішні SSH-сервери на порт 22 і використовую брандмауер, щоб перенести високий порт до 22 на цільових машинах. Це дає певну безпеку через неясність, зберігаючи безпеку низького порту, як зазначав Джуліано.
Безпека через невідомість - це не принцип, на який я зазвичай підписуюся, і часто вказується, що просте сканування портів дозволить виявити цільовий порт, що зробить незрозумілість нікчемною. Щоб вирішити цю проблему, мої брандмауэры (Smoothwall Express), як на роботі, так і вдома, використовуйте сценарій під назвою Guardian Active Response, який викликається сповіщеннями Snort. Зі спостереження я можу вам сказати, що коли ви потрапляєте на більше ніж 3 різні порти з одного джерела, ваші пакети падають до заданого часу скидання. Це робить досить важким і надзвичайно трудомістким запуск сканування портів, що робить незрозумілість насправді щось варте. Це насправді змусило мене закрити стільки разів у минулому, що я встановив виключення для моєї джерельної (домашньої чи офісної) IP-адреси.
Проблема у вас полягає в тому, що брандмауер налаштований лише для того, щоб дозволити підключення певних IP-адрес, а начальник втомився відкривати конкретні IP-адреси, коли він не працює. Якщо ви блокуєте певні IP-адреси на брандмауері, це може бути болем у дупі.
Тут я думаю про дві речі. Зміна порту захищає від автоматизованих атак. Це про це, але це велика частина середнього трафіку атаки там ... автоматизовані сценарії сканування мереж. Якщо ви зміните порт за замовчуванням, ці атаки повинні відпасти нанівець. Тож це має сенс у цьому плані. Але це не робить нічого проти направленої атаки, оскільки зловмисник може просто сканувати з Nessus або NMAP, щоб визначити, який порт (и) ви використовуєте, якщо у вас є спеціальний маленький друг, який вас досить ненавидить.
По-друге, якщо ви використовуєте схожі на UNIX сервери, ви можете встановити утиліту типу Denyhosts для припинення атак. Якщо ви встановите denyhosts, він відстежує наявність помилкових спроб входу, а після спроб (якщо ви визначите кількість) невдалих спроб заборонить IP протягом періоду часу, який ви вказали. Denyhosts також може поспілкуватися з іншими хостами denyhost та передавати списки заборон, тому якщо зловмисник заблокується із системи Linux Fred Fred в Монтані, ваша система також отримає цей IP для заборони. Дуже корисно, поки ваші користувачі пам’ятають свої паролі.
Все залежить від сценаріїв використання. Скільки у вас програм, які є "болем у дупі" щодо зміни порту підключення для SSH / SCP (і якщо вони цього не дозволяють або не заподіюють біль, вам дійсно потрібно розглянути можливість зміни постачальників). Якщо це просто потенційний страх, я б сказав, що це не проблема. І це ваш начальник, просячи щось не зовсім дурне, оскільки багато сисадмінів перевертають порт SSH (дещо лунає від людей, які ненавидять все, що пахне навіть безпекою через незрозумілість ... але це насправді скорочує чіткий фоновий шум від автоматизованого сканування.)
Зникла - зміна порту блокує автоматизовані сценарії та більшість поганого трафіку. Не зупинять спрямованих нападників. Спробуйте також встановити автоматизовану утиліту для заборони. Безпека в шарах не зашкодить вам при правильному виконанні та зміні портів допомагає більше, ніж шкодить у більшості ситуацій.
Я працюю SSH на порту> 1024 вже більше 5 років. З тих пір я не бачу жодної спроби портатичного сканування у своєму журналі журналу (крім мого власного). Є мої сервери, які я адмініструю, які працюють за допомогою порту> 1024.
Багато серверів SSH, які працюють на порту> 1024, мають власні веб-сайти, які є досить популярними.
Якщо сервер SSH працює в моїй власній компанії, можливо, я вже розмістив тут IP-адресу цього сервера, щоб ви, хлопці, могли спробувати зламати сервер. На жаль, сервер SSH не є моїм власним. ;-)
Але є й інші речі, які вам доведеться налаштувати, щоб зробити це безпечним. SSH> 1024 одних було б недостатньо. Номер порту не повинен бути в / etc / services, повинен використовувати переадресацію портів (наприклад, порт 1124-> 22), прямий доступ до Root повинен бути відключений та інше.
Отже, якщо ви хочете сперечатися, краще запустити SSH на порт> 1024 протягом декількох років.
p / s: 1124 - це не мій порт SSH. Ха-ха.
Добре переміщення SSH до іншого порту має певний сенс, це допомагає безпеці, але не дуже. Звичайно, для цього ви повинні мати контроль над брандмауерами, але це не є проблемою для вас. Те, що, на мою думку, скасовує перевагу переміщення порту, це відкриття прийнятого діапазону - адже я б сказав, що це більше, ніж скасовує вигоду і піддає вас далі, ніж ви є сьогодні. Я впевнений, що ви можете переконати його в тому, щоб перемістити порт І значно зменшити вхідний діапазон, склавши список ймовірних точок входу, а не просто відкривати їх усі.
Зміна вашого порту ssh - безглузда вправа, яка купує вам лише обмежену безпеку. Вам краще просто відключити автентифікацію пароля, що виключає ризик спроб пароля з грубою силою і покладатися виключно на аутентифікацію на основі ключа ssh. Якщо ваше середовище вимагає автентифікації пароля, прийміть якийсь двофакторний механізм, наприклад, SecurID або Wikid.
І те, і інше дає вам реальне підвищення безпеки, тоді як зміна ssh-порта створює лише ілюзію безпеки.
Це практично POV: я працював відкрито видимими приватними серверами ssh більше чотирьох років зі зміненим портом SSH і в мене не було жодної спроби сканування паролем. Заради цього QA я щойно включив 22 на один з них на один день. Як результат, мене сканували приблизно кожні 10 хвилин із частотою спроби пароля близько 5 в секунду. Більше того, "сканувати дітей" також шукають сервери з певними вразливими можливостями OpenSSH.
Напевно, це безпека через невідомість, яка не допомагає, якщо у вас є ворог.
Це чудово працює, незалежно від скуголення натовпу "безпека через неясність".
Нерозумні кролики, ВСЕ безпека - це безпека через неясність. Тільки тому, що ви вважаєте, що незрозумілий криптопротокол Z [вимагає комбінації зразків ДНК, спільних ключів та неможливого фактичного введення людьми паролів] насправді безпечний, це не робить цього так. Правда полягає в тому, що будь-який захід безпеки покладається на ймовірності та припущення з боку користувачів. Шкода для вас, якщо я знаю, як використати це припущення, але це так.
У будь-якому випадку,
Ми робимо це роками, поряд з a) обмеженням швидкості спроб з'єднання (однак, я не знаю, як ми це встановили, щось у ssh config), і b) скриптом, який забороняє будь-якому хосту виконувати атаку словника з більш ніж X неправильних здогадів за Y хвилини. Ми забороняємо хосту здійснювати з'єднання протягом певного часу, і це полегшує адаптацію до топології мінливих мереж.
Якщо ваші паролі досить складні, і вони можуть зробити лише 3 спроби за 15 хвилин, боятися не багато. Не так вже й важко стежити за розподіленими атаками - ми зазвичай порівнюємо по підмережі та ip, щоб виключати подібні речі.
Нарешті, все, що вам потрібно, - це секретний метод білки, щоб дозволити з'єднання з вашим портом, змінивши правила f / w. Це може бути все, що завгодно ... smtp, web, магічні запити dns. Такі речі, як SecurID або Wikid, просто передають більше інформації третім особам. І не запускайте мене на захищені сертифікати через третіх осіб.