Системное администрирование

индекс

199,96

Оправданно ли размещение SSH на порту, отличном от 22?

48.01%
(1023): Да

34.82%
(742): Нет

17.18%
(366): Не использую SSH / Меня это не интересует

Проголосовал 2131 человек. Воздержалось 449 человек.

+26

22 марта 2010, 10:08

zivot_je_cudo

комментарии (189)

+27

zivot_je_cudo 22 марта 2010, 10:08 #

Сам считаю, что перевешивание порта с целью безопасности не имеет смысла, ведь на любом порту все равно придется ставить адекватную защиту вроде iptables -m recent, sshguard, fail2ban или что-то еще. А если эти средства одинаково хорошо защищают на любых портах, то для чего лишний раз нарушать стандарты и нормы? Упорядочение серверных служб, администрирование с использованием универсальных решений — вот удел хорошего системного администратора. В идеале, новый сисадмин на его месте должен максимально быстро «овладеть» сервером, не копаясь в алиасах и не используя лишний раз nmap, чтобы хотя бы залогиниться.
На днях довелось поучаствовать в дискуссии на эту тему, но ряд вопросов так и остался открыт. Оказывается, не все так очевидно, и системные администраторы очень часто перевешивают ssh на другой порт. Почему?

+12

bondbig 22 марта 2010, 10:13 # ↑

присоединяюсь. Никогда не меняю стандартный порт SSH. Это все равно как голову в песок. Запрещаем руту логин, разворачиваем аутентификацию по ключам. Для серверов, торчащих SSH-ем наружу применяем вышеуказанные примочки, либо универсальный SNORT (любую другую IPS по вкусу).

dkr6 22 марта 2010, 12:10 # ↑

Любая внешняя «обвеска» добавляет вероятности ложной блокировки…
Тот же SNORT часто ошибается…
Оно вам нужно?
Чем проще, тем надежнее…

bondbig 22 марта 2010, 12:17 # ↑

SNORT — всего лишь инструмент, он не может ошибаться. Ошибается админ, который его настраивает. Не нравится снорт (не можете настроить?) — покупайте железную IPS, серьезные производители (tipping point, mcafee, ibm, etc.) гарантируют отсутствие ложных срабатываний. Не устаю повторять про правило треугольника «дешево — быстро — хорошо».

dkr6 22 марта 2010, 12:31 # ↑

Вы противоречите принципу «Нет программ без ошибок»…
Может быть и ошибка в программе, и ошибка в правилах, и где угодно…
Когда-то долго мучился с настройкой SNORT на блокировку соединений SSH с характерной строкой отключения «Bay Bay»…
Так вот, SNORT такого просто не умеет, потому как вычитать ее не может…
А все остальные правила были для меня не интересны…
Так же считаю бессмысленным анализ логов 1 раз в минуту. Это все реакция «постфактум»…
К тому времени злоумышленник уже может быть в системе, а система честно и гордо выполнять «rm -rf /»…

bondbig 22 марта 2010, 12:43 # ↑

«SNORT ошибается» и «Ошибка в коде SNORT» — не одно и то же. Баги никто не отменял, на то они и баги.
>анализ логов 1 раз в минуту
А при чем тут анализ логов? Снорт работает с сетевым трафиком «на лету», вы его с чем-то другим путаете, наверное с наколенными скриптами для iptables+apache.
>злоумышленник уже может быть в системе
А вот от этого вас перевешивание порта точно никак не спасет, в отличие от правильно настроенной IPS. До перевешенного порта доберется чуть более опытный взломщик, и ему уже никто не помешает подбирать пасс. В случае с IPS это не так.

dkr6 22 марта 2010, 12:49 # ↑

SNORT действительно работает с трафиком…
Он его читает…
А трафик SSH он читать не может по определению…
В данном случае анализируется только активность,
с чем iptables справляется гораздо лучше…
Точнее, iptables справляется, а SNORT совсем не для этих задач.

Про периодический анализ логов сказано было не в связке с SNORT…

1amer 22 марта 2010, 14:37 # ↑

как дополнение снорт вполне хорош. он может поймать 0-day сплойт, например, найдя длинную цепочку 0x90(nop на ia-32) в трафике, где её не должно быть

dkr6 23 марта 2010, 13:31 # ↑

Ну и каким боком 0-day сплойт к SSH?
Вот так и ломают сервера у админов, которые «защищают» один из сервисов от механизмов взлома другого сервиса…
Это из серии «одеть мотоциклетный шлем, чтоб защитить задницу»…

Удачи…

1amer 23 марта 2010, 14:47 # ↑

1. «как дополнение снорт вполне хорош»
2. По вашему мнению для SSH сплойтов не бывает?
3. Разве в системе не может быть демонов кроме ssh?

dkr6 23 марта 2010, 14:53 # ↑

1) Как дополнение к защите SSH он бесполезен, ибо не умеет читать трафик его.
2) Наличие/отсутствие средств взлома SSH ни коим образом не отражается на функциональности SNORT, ибо п.1
3) Вы считаете уместным в обсуждении целесообразности некоторой конкретной настройки защиты SSH обсуждать все остальные, возможные к загрузке демоны *nix?

Попытайтесь включить соображалку и таки понять, что к защите SSH замок на двери серверной отношения не имеет… Равно как и решетки на окнах…
Огород, бузина, родственные связи…

Anton_DS 22 марта 2010, 17:17 # ↑

> Никогда не меняю стандартный порт SSH. Это все равно как голову в песок.
Полностью согласен, смысла в этом не много, достаточно лишь вбить в гугл это, и все встанет на свои места.
А по поводу зашиты методом «голову в песок», очень много натерпелся, у меня сейчас коллеги очень своеобразно понимают слово защита информации, у них стратегическая база Oracle не видит никаких других ресурсов(«база у нас секретная, и собаки вокруг должны бегать» (С) :)
при этом блин базу видят все :))) тоже своеобразное отношение к секурити в частности и жизни в целом…
При этом мне как кодеру который привык ранить всю логику в базе это просто страшно. Что я этим хотел сказать, не нужно решать проблему внесением путаницы, это не помешает злоумышленику и может очень сильно помешать работе ни в чем неповинных программистов.

Anton_DS 22 марта 2010, 17:25 # ↑

оффтоп, про страуса общее заблуждение страусы не прячут голову в песок, они ее опускают вниз )))

bondbig 30 марта 2010, 16:05 # ↑

прячут, но не с целью «спрятаться», а с целью охладить голову.

ibKpoxa 22 марта 2010, 11:05 # ↑

Когда серверов много, и с ними работает не один человек, а команда, то применение нестандартных портов это затрата лишнего времени и причина многих ошибок.

–1

takkmoil 22 марта 2010, 12:03 # ↑

А когда они все торчат наружу через один NAT?

zivot_je_cudo 22 марта 2010, 12:06 # ↑

Это частный случай, совершенно другая ситуация.
Очевидно, что для маршрутизации этого, придется пробрасывать различные порты на внутрисетевые адреса.
Но тут уж лучше vpn, чтобы избежать карусели с пробросом.

dkr6 22 марта 2010, 12:08 # ↑

Либо цепляться за первый сервер, а с него прыгать на внутренние, либо DNAT развешивать…
Решений много, и чем больше они отличаются от типовых, тем меньше вероятность случайного попадания…

FreeBSD 22 марта 2010, 12:10 # ↑

это совсем другое дело, но и тут, когда выделаете ПАТ, трансляцию яб не менял.

ibKpoxa 22 марта 2010, 12:17 # ↑

Это 2 отдельные задачи:
доступ к серверам из вне сети
доступ между серверами внутри сети

Anton_Shevtsov 22 марта 2010, 13:22 # ↑

Выработайте единую политику — в этой конторе весь ssh висит на 9999 порту… и все…
или sss*2, где sss последная байт ip адреса xxx.yyy.zzz.sss =)) мозг развивает :D

dkr6 22 марта 2010, 14:11 # ↑

Когда серверов много, и с ними работает не один человек, а команда

Для этого есть такое понятие, как корпоративная политика.

ibKpoxa 22 марта 2010, 14:21 # ↑

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

dkr6 22 марта 2010, 14:45 # ↑

Почти логично и правильно…
Разве что доступ к порту, на котором висит SSH на работу компании ни коим образом не влияет…
Это только удобство/неудобство работы некоторого числа сисадминов.
Для того, чтобы это было удобно и практично, пишем в
~/.ssh/config
Host hostname
HostName 111.222.333.444
IdentityFile ~/.ssh/id_rsa
Port 9999
User username
Protocol 2
ForwardX11 yes
ForwardAgent no
Compression no
И админ просто набирает в консоли
ssh hostname
Все…
Не нужно каждый раз помнить про порты и ключи…
Это очень удобно, так как не требует запоминания портов.
В крайнем случае, ssh -p 9999 username@hostname
И это то же работает.
Для сисадминов это удобно. Для всех остальных — безразлично, так как они не пользуются этим сервисом.
Для IT-менеджмента — более чем удобно, так как защищенность системы возросла. Сильно или нет — вопрос другой. Но возросла…

JC_Piligrim 23 марта 2010, 15:58 # ↑

Не так. Существует куча решений, в которых, при смене стандартного ssh-порта, придется этот порт указывать. И причем не всегда очевидным способом. Посмотрите, как различны способы указания, например для rsync, scp, mercurial… Я уже напоролся. Ну его нафиг. Все равно, если вас захотят побрутфорсить — первым делом просканят порты.

–1

dkr6 23 марта 2010, 17:24 # ↑

Посмотрите, как различны способы указания, например для rsync, scp, mercurial…

Смотрел…
Даже указывал…
Всего один раз исправил 8 скриптов на 3-х серверах…
И опять уже которую неделю плюю в потолок, потому как все работает, в логах чисто…
Можно потрепаться на Хабре, предоставив сообществу возможность пообщаться с умным человеком (/шутка).
Я действительно не понимаю, почему человек, четко и ясно понимающий свои действия, боится сделать шаг в сторону от «типовых» и «стандартных» рекомендаций в явно нестандартных ситуациях.
Если бы этого делать было нельзя, соответствующей опции в конфиге просто не было бы.
Автор предусмотрел смену порта. Это — стандартный функционал. Это — абсолютно нормально и штатно.
Это вам не Винда, где за рамки графической конфигурялки — ни-ни…

Осознайте, в конце концов, что в *nix работает принцип «понимаю, могу, хочу и буду».
На машине хозяин — админ, и не тупой железяке с недоОСью учить меня, гениального, что и как настраивать…

Да, трудно быть богом, даже в пределах одного сервера…
Вы не готовы? Тогда «они» идут к вам…
А у нас все «почикано» ;)

JC_Piligrim 23 марта 2010, 17:55 # ↑

Снимаю перед Вами шляпу. :)

Я не боюсь делать шаги в сторону. Сам люблю линуху, уже 2 года не вылажу из нее. Но к сожалению, не обладаю бессмертием, поэтому для себя решил, что свое время предпочту потратить на что мне нравится, а при острой необходимости — нанять такого профессионала, как вы.

Не совсем об администрировании, и ssh на не стандартном порту, но очень точно отражает то, что я хочу Вам сказать. Цитата из Спольски:

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

local.joelonsoftware.com/wiki/Письмо_о_стратегии_VI

dkr6 23 марта 2010, 18:07 # ↑

И это то же правильный подход…
Специалист сделает хорошо и быстро, а вы платите либо своим временем, либо своими деньгами…
Я потратил много лет своей жизни на достижение некоторых результатов, но не могу сказать, что не испытывал морального удовлетворения от результатов своей работы.
Хорошо работающий сервер (программа) дает такой же эффект, как и написанная картина или книга.
Ощущение эйфории от осознания того, что ты осилил… А если за это еще и денег дадут, то вообще :)
И, как показала практика, кайф тем больше, чем элегантнее и надежнее решение найдено.
И вот тут, как раз, простые и надежные инструменты применить интереснее, чем трахаться с настройками монструозного размера…
Примеров могу привести множество…
Но наверное не в этом треде, уже ;)

–1

zivot_je_cudo 23 марта 2010, 19:18 # ↑

Я действительно не понимаю, почему человек, четко и ясно понимающий свои действия, боится сделать шаг в сторону от «типовых» и «стандартных» рекомендаций в явно нестандартных ситуациях.
Если бы этого делать было нельзя, соответствующей опции в конфиге просто не было бы.

Перевес порта — не творческое решение, это обезьянничество за другими. «Меня брутфорсят!» — «Смени порт!».
Я не боюсь перевешивать порт, и понимаю, что нередко перевес порта необходим. Просто мне известен преркасный, простой и изящный способ отлова простых атак, при котором так же не зе засоряются логи, но ssh остается на своем месте.
Кто-то не умеет настраивать файрволл, поэтому меняет порт, кому-то плевать на стандарт, согласен с Shark, что ничего в этом страшного нет.
Еще раз убедился, что тема холиварная, методы бывают разными, пусть каждый админит как умеет.

+13

smind 22 марта 2010, 12:00 # ↑

от специализированной атаки нацеленной на ваш конкретный хост перевешивание не спасет, но от тупых ботов помогает 100%, как только перевешивал на другой порт — долбеж прекращался…

–1

zivot_je_cudo 22 марта 2010, 12:01 # ↑

Когда Вы перевешивали порт, Вам были известны другие способы защиты? Почему выбор пал на этот способ?

charon 22 марта 2010, 12:17 # ↑

я тоже перевешивал. Знаю и другие способы. Этот сильно проще.
Как показали испытания fail2ban сильно грузит ВПСку.
А перевешивание — это просто и эффективно.

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

zivot_je_cudo 22 марта 2010, 12:24 # ↑

Fail2ban это не все решения. Как насчет iptables?
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j TARPIT
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT

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

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

charon 22 марта 2010, 12:36 # ↑

а цепочка TARPIT — это стандартная в iptables? Или там надо еще сто строк в фаервол добавить, чтобы система работала?

zivot_je_cudo 22 марта 2010, 12:38 # ↑

Используйте DROP или REJECT, как угодно.
Для TARPIT нужен модуль xt_TARPIT.

Sap_ru 22 марта 2010, 12:49 # ↑

А он есть? в VPS с этим сложности :)

zivot_je_cudo 22 марта 2010, 12:50 # ↑

Используйте DROP или REJECT, как угодно.

dkr6 22 марта 2010, 14:06 # ↑

DROP-ать интереснее, так как атакующий не получит ответа…
Ни какого… То есть, запрос уйдет в пустоту.
При REJECT ответ таки будет…
При тихом DROP некоторые сканеры тупо зависают…
Что не может не радовать ;)

zivot_je_cudo 22 марта 2010, 14:28 # ↑

У многих брутфорсеров стоит таймаут ожидания SYN/ACK.
А вот при TARPIT они зависают гарантировано =)

dkr6 22 марта 2010, 14:47 # ↑

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

Кстати, я разделяю понятия «хакер» и «крякер», уважительно относясь к первому и злобно противодействуя второму…

zivot_je_cudo 22 марта 2010, 14:53 # ↑

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

Согласен, кроме того, метод с TARPIT менее ресурсоемок, так как заставляет атакующего прерывать посылку SYN в ожидании передачи данных.

dkr6 22 марта 2010, 14:57 # ↑

Для эстетов: если редиректить поптки взлома на sourceIP, на его же порт, то может быть очень интересно…
Опять же, это отностися уже к активным системам защиты от взлома и если атакующий подменяет свой IP, может получиться не очень красиво…
Лет, эдак, 10 назад в качестве «наш ответ Чемберлену» использовался
boinc…
Подробностей уже не помню…

zivot_je_cudo 22 марта 2010, 15:03 # ↑

Угу, но слишком опасно в связи с возможностью подмены адреса источника, даже в манах предупреждают.
В принципе, сейчас есть где-то в patch-o-matic (-j MIRROR).

dkr6 22 марта 2010, 15:20 # ↑

Идеального средства нет.
В данном контексте самым красивым выглядит knock…
Но если вы случайно заскочили в Инеткафе, или пытаетесь зайти на свой сервер с какого-нить смартфона, то удобство будет сомнительным.
Любой из нас сможет найти как положительные, так и отрицательные стороны в любом решении.
И все аргументы будут «контекстозависимыми»…
То есть, зависить от конкретного применения каждым админом в каждом конкретном случае.

gluk 22 марта 2010, 19:21 # ↑

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

Nashev 22 марта 2010, 20:07 # ↑

Ну, после такого ответа придётся узнать и может быть полечиться…

gluk 22 марта 2010, 21:10 # ↑

После заворота входящих подключений в тарпит — сильно сомневаюсь. Одно время я внимательно просматривал отчеты об атаках типа ssh-scan на свои ресурсы, и в ответ запускал nmap. Очень часто находились открытые сервисы VNC, RDP, MySQL, иногда даже без пароля или с тупым паролем вроде qwerty или 12345. В таких случаях я заходил и смотрел что это за сервер. Во всех случаях это были не злобные крякеры, а просто серваки без вменяемого админа. Я оставлял им сообщения — мол, примите меры. Вот после этого они проникались и принимали меры, а потом еще и благодарили меня.

charon 22 марта 2010, 13:25 # ↑

спасибо, с DROP будет понятно. Модуля xt_TARPIT у меня в стандартной поставке нет, и доку я в инете не нашёл — вообще непонятно что это, откуда и с чем его едят.
Попробую ваш совет с -m recent.

zivot_je_cudo 22 марта 2010, 13:33 # ↑

TARPIT доступен в составе xtables-addons, почитать можно здесь и здесь.
В принципе, зря я в пример привел TARPIT, а не DROP, он только запутывает. Но TARPIT работает эффективнее, нежели DROP, так как атакующая система ждет, а не повторяет отправку SYN.

Sap_ru 22 марта 2010, 12:21 # ↑

Потому, как боты. И если у меня стоит слабенький VPS и вдруг ни с того ни с сего на него начинается брут-форс по подбору пароля, то даже если атака будет отбита, то это создаёт заметную нагрузку на сервер. АДолбёжка идёт практически непрерывно — похоже какие-то ботнеты сканируют сеть (а может не всю сеть а только VPS'ы провайдеров) в поисках дырок в надежде, что юзер купил VPS, поставил пароль «root» и успокоился. А как правильно заметили в комментарии выше — после переноса порта тупые брут-форсы исчезают, как класс.

–2

zivot_je_cudo 22 марта 2010, 12:26 # ↑

Как насчет такого способа? Нагрузка мизерная.
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j TARPIT
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT

Sap_ru 22 марта 2010, 12:49 # ↑

Не у всех VPS есть необходимые модули ядра. Например, CONTRACK в большинстве случаем или отсутствует или работает криво.

zivot_je_cudo 22 марта 2010, 13:07 # ↑

VPS на OpenVZ? Хм, да, это может стать преградой.
Как быть? Нельзя же защищаться одним только перевешиванием, одно сканирование и порт для брутфорса определен.

medvoodoo 22 марта 2010, 14:48 # ↑

Не знаю как у вас, а у меня были километровые логи на 21 и 22 порту сгенеренные тупыми автоботами, после перевешивания логи стали нормальными. Это так же как у нас на всех сайтах периодически пытаются найти директории phpmyadmin и т.п. Ну и нафига мне километры вирусованных ip созданные fail2ban, когда лучше я его использую для защиты от направленных атак на уникальных портах.

medvoodoo 22 марта 2010, 14:51 # ↑

Сейчас долбежка идет вобще по всем IP, логи с арендованного сервера и с домашнего реального ip. Из-за этого менял порты

smind 22 марта 2010, 12:37 # ↑

когда перевешивал — знал, не все доступно на стареньком ядре, не все позволяет дохленький проц и малое количество памяти. Пока мне достаточно таймаутов и перевешенного порта чтобы лог не распухал. и да блокировать по ip мне не помогало, запросы шли из разных сетей и не повторялись в приемлемом интервале времени. Кроме того я не хочу чтобы меня забанило когда я буду ломиться без ключей вспоминая/перебирая пароль…

zivot_je_cudo 22 марта 2010, 12:47 # ↑

Способ с -m recent Вас забанит максимум на 20 секунд, прописывать адреса он не просит, ловит и банит их сам. Не слышали раньше?
Я упоминаю о recent уже почти в каждом комментарии, и это не просто так. Это решение отличается универсальностью, эффективностью и наименьшей ресурсоемкостью (портнокинг менее универсален).
Хорошо настроенный файрволл избавляет от необходимости что-то выдумывать с переносом порта.

dkr6 22 марта 2010, 12:59 # ↑

Способ с -m recent Вас забанит максимум на 20 секунд

Тогда еще sshutout в комплект…
Тот может банить на до-о-о-олго…
Как пропишите в конфиге…
10 минут default…

Shark 22 марта 2010, 13:05 # ↑

-m recent тоже можно настроить на сутки бана. Но тогда ошибка админу может дорогого стоить :)

dkr6 22 марта 2010, 13:08 # ↑

Любой, из рассматриваемых тут механизмов, может дорого стоить админу при неправильной настройке.
За долгую практику бывало всякое…

smind 22 марта 2010, 18:54 # ↑

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

zivot_je_cudo 22 марта 2010, 19:37 # ↑

И перевешивание порта тоже не решение. От распределенного брутфорса я бы использовал портнокинг.

dkr6 23 марта 2010, 11:53 # ↑

А кто вас держит за руки и не дает строить систему по принципу «И», вместо «ИЛИ»?
Убежден, что разумное сочетание простых механизмов будет гораздо эффективнее применение только одного из множества возможных ;)
Рекомендовано галактической ассоциацией собаководов…

dkr6 23 марта 2010, 11:51 # ↑

Если вы осилите автобан, то осилите и написание правил для себя, любимого…
Всего лишь одной строкой _выше_ правил автобана в iptables…
Так же полезно прописать себя в «белые списки»…

smind 23 марта 2010, 14:21 # ↑

прописать то не проблема, но ip-шник то динамический, + захожу через gprs разных операторов, разных регионов…

dkr6 23 марта 2010, 14:55 # ↑

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

dysangelium 22 марта 2010, 15:15 # ↑

В вопросе — ни слова про безопасность и защиту.
Имеет смысл перевешивать ssh для того, чтобы очистить логи.

–2

zivot_je_cudo 22 марта 2010, 15:20 # ↑

В вопросе — ни слова про безопасность и защиту.

Потому мне и пришлось дать поясняющий комментарий.

dio 22 марта 2010, 10:26 #

Перевешивать 22ой порт имеет смысл чтобы отбиться от тупых brute-force'ов, не смотря на то, что SSH и без того имеет отличный тайминг на такие случаи. У меня бывало по 10mb логов в день с Auth failed, а то что от port scanner'а таким способом не спрятаться — это очевидно. Просто зачем лишний раз светиться?

bondbig 22 марта 2010, 10:33 # ↑

от тупых брутфорсеров лично я закрываю снортом. Банит по ip на 24 часа после нескольких неудачных попыток и всё, никакого мусора в логах.

zivot_je_cudo 22 марта 2010, 10:34 # ↑

У меня бывало по 10mb логов в день с Auth failed

По 10Mb набегает, если сервер совсем никак не защищен.
Почему бы не использовать от тупого брутфорса такие правила:
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j TARPIT
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT
Разрешает одну попытку с одного адреса в течение двадцати секунд, иначе — TARPIT. С этим в логах вижу небольшой список хостов и всего одну попытку с каждого из них. И безопасность обеспечивает не ложную, и стандартов не нарушает, оставляя SSH на 22 порту.

dio 22 марта 2010, 11:05 # ↑

iptables и snort хорошие решения, но это решения за пределами самого ssh, в моём случае хватает перевешивания. Тем более что на загруженных серверах, с большим количеством постоянных соединений уже даже загрузка модуля iptables даёт небольшой latency.
Идеально когда стоит одна железка на входе и контроллирует это.

bondbig 22 марта 2010, 11:12 # ↑

в важных, сложных и нагруженных системах необходимо применять полноценную hardware-based IPS. Ну и порты, кроме рабочих портов приложения, никакие наружу выставлять нельзя, тем более SSH. Для управления снаружи организовываем VPN. В идеале удаленный доступ админа должен инициировать/согласовывать живой человек — дежурный инженер в дата-центре.

charon 22 марта 2010, 12:19 # ↑

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

–1

Shark 22 марта 2010, 12:23 # ↑

Подозреваю, что у хостера есть свой iptables между вами и интернетом. Но его влияние не так уж велико, наверное…

charon 22 марта 2010, 12:33 # ↑

нет у хостера своего iptables. Экономически неоправдано его ставить.

dkr6 22 марта 2010, 12:26 # ↑

С TARPIT наблюдал полную блокировку SSH во время атаки…
То есть, я сам не мог зайти на удаленный сервис.
Досконально разбираться не стал, а просто перевесил на нестандартный порт.
Может быть тут и выясним причину?
За одно добавим еще один патрон в обойму…

zivot_je_cudo 22 марта 2010, 12:29 # ↑

С TARPIT наблюдал полную блокировку SSH во время атаки…

А можете вспомнить конкретные правила?
С моими правилами -m recent матчит пакеты с конкретных адресов, закрывая порт только для них.

dkr6 22 марта 2010, 12:38 # ↑

Что-то в роде этого:
(начало строки откушено, потому как это кусок из /etc/sysconfig/iptables, а не скрипт с прямыми вызовами /sbin/iptables)
-A INPUT -p tcp --dport 22 -m recent -m state --state NEW --name sshattack --set
-A INPUT -p tcp --dport 22 -m recent -m state --state ESTABLISHED --tcp-flags FIN,ACK FIN,ACK --name sshattack --set
-A INPUT -p tcp --dport 22 -m recent -m state --state ESTABLISHED --tcp-flags RST RST --name sshattack --set
-A INPUT -p tcp --dport 22 -m recent --name sshattack --update --seconds 120 --hitcount 4 -m limit --limit 4/minute -j LOG --log-prefix SSH_attack:_
-A INPUT -p tcp --dport 22 -m recent --name sshattack --update --seconds 120 --hitcount 4 -j DROP

Правила не мои, сохранил когда-то кусок рекомендаций.
Если что, ругать не меня ;)

leshaogonkov 22 марта 2010, 10:28 #

Только как защиту от дурака, наверное.

charon 22 марта 2010, 12:20 # ↑

а вы думаете, что к вам только профи ломятся? Дураки там не ходят?

dkr6 22 марта 2010, 16:22 # ↑

Ну, не дураки, а члены секции «Юнный хацкер» районного Дворца пионЭров…
Найдя тулзень для взлома, начинают ее применять куда ни попадя…
Профи не будут ломиться без заказа и оплаты, а в случае заказа закроются цепочкой анонимайзеров, используют разовый ломанный shell и/или еще что-нибудь…
В любом случае, ломать SSH они будут после того, как проломят менее защищенные сервисы… Те же порталы на РНР…
Для них у нас есть другие инструменты…
А для пионэров достаточно нестандартного порта и TARPIT…

KiLEX 22 марта 2010, 10:28 #

ну лично мне перевес помог от постоянного брутфорса. логи пестрили файледными логинами, пеервесил на другой порт стало тихо. помогает от недохакеров :)

–2

zivot_je_cudo 22 марта 2010, 10:39 # ↑

Когда Вы перевешивали порт, Вам были известны другие способы защиты? Почему выбор пал на этот способ?

KiLEX 22 марта 2010, 10:47 # ↑

первое что пришло в голову.

а вот насчет способов интересно — может кто нить напишет статейку об этом? я только по ключам умею делать авторизацию.

zivot_je_cudo 22 марта 2010, 11:58 # ↑

первое что пришло в голову
я только по ключам умею делать авторизацию

В принципе, так и думал, что большинство админов вешают ssh на нестандартный порт по причине незнания хороших средств защиты.

dkr6 22 марта 2010, 12:45 # ↑

Еще полезно поиграться с конфигом:
PermitRootLogin without-password # Т.е. только по ключу
MaxStartups 2:70:10
AllowUsers <список юзверей через пробел>
Так же можно и список групп.
Остальное — малозначимо для безопасности.
Про порт уже сказано.

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

–6

DerSpinner 22 марта 2010, 10:32 #

в каждой организации свой «дефолтный» порт.

zivot_je_cudo 22 марта 2010, 10:37 # ↑

Это не так.

НЛО прилетело и опубликовало эту надпись здесь

Mithgol 22 марта 2010, 10:51 # ↑

Это соображение совершенно справедливо.

Однако многие дурни всё же не пользуются сканерами портов, а ограничиваются анализом порта 22.

umraf 22 марта 2010, 10:51 # ↑

Сделайте. Только вероятность увидеть заголовок ответа 1/65000. Либо придётся сделать примерно 65000/2 попыток.

Бывает, что firewall`ом рулить обязан другой человек. Поэтому проще решить задачу не прибегая к «внешним» средствам.

Qiwichupa 22 марта 2010, 10:42 #

Как защита от дурака — почему нет? Зачем показывать дураку железобетонную дверь, когда можно сказать «ничего нет, нет ничего»?

НЛО прилетело и опубликовало эту надпись здесь

Qiwichupa 22 марта 2010, 10:57 # ↑

дурак сканит диапазоны ip на наличие открытого порта =). Тот кто целенаправленно ищет — уже не такой дурак

dkr6 22 марта 2010, 16:36 # ↑

В подавляющем большинстве случаев работает скрипт, а не дурак…
Дурак этот скрипт запускает, а выхлоп анализирует уже потом.
Скрипту сказано — продолбить в порт 22, если шо, то сложить результат в лог.
Нет активного порта, нет записи в логе…
Дурак, анализируя этот лог, про ваш сервер и не узнает…
Если же этот дурак начнет сканировать весь диапазон активных портов, результата он будет ждать оччччень долго…

Как уже писали тут, есть два режима:
Либо все хосты, но один порт, либо все порты, но один хост…
И на ту, и на другую резьбу у нас есть свои прибамбасы :)

P.S.
В рассуждении о способах защиты и взлома желательно бы выслушивать мнения людей, которые либо эффективно защищают, либо эффективно взламывают…
В крайнем случае, эффективно думают…
А рассуждать о вкусе устриц, ни разу их не попробовав…
Моветон…
;)

–2

zivot_je_cudo 22 марта 2010, 10:56 # ↑

Как защита от дурака — почему нет?

Заметил, что все называют это защитой от дурака. Не потому ли, что и сама защита дурацкая? Ведь любой, у кого что-то есть в голове, сразу ее обойдет.
Почему нельзя сразу на 22-й порт поставить адекватную защиту, и не устраивать карусель портов?

–1

Qiwichupa 22 марта 2010, 10:59 # ↑

почему бы не сделать и то и другое?

–3

zivot_je_cudo 22 марта 2010, 11:00 # ↑

Одно из них нарушает стандарт, а другое перекрывает свой эффективностью первое.

dkr6 22 марта 2010, 16:41 # ↑

Когда-то давно, когда деревья были большими, а жесткие диски — маленькими, мой первый *NIX-Гуру говорил:
«Если это сделано тупо, но работает, то это сделано не тупо».
Если я перекинул порт на нестандартный, и это решило конкретную мою проблему, то я выполнил задачу.
Еще раз акцентирую внимание на завершенной форме:
Я выполнил задачу.
И не важно, что есть еще N способов выполнить ту же задачу.
Она уже решена.
Кто-то другой решит ее иначе, но мы же не клоны.
Попытка причесать всех под одну гребенку, от лукавого…
Я даже знаю, как его зовут и какую ОСь он успешно продает, не реализовав и 10-й доли того уровня защиты, которую я могу реализовать в моей любимой *nix-системе…
;)

debugg 22 марта 2010, 11:28 # ↑

Для меня это лишь еще одна ступень в защите. Почему бы не перестраховаться и не поставить адекватную защиту на нестандартный порт? И почему карусель? У меня например на работе закрыты нестандартные порты наружу, решаю эту проблему простым редиректом

$ipt -t nat -A PREROUTING -p tcp -s $dist_ip --dport 22 -j REDIRECT --to-port 26

–2

zivot_je_cudo 22 марта 2010, 11:46 # ↑

Почему бы не перестраховаться и не поставить адекватную защиту на нестандартный порт?

Вы не уверены в средствах защиты, которые используете? iptables/fail2ban/sshguard представляют собой средства несравнимо более надежные, нежели какое-то перевешивание порта, причем с их использованием не приходится затрачивать лишнее время на поиск порта, согласование его с другими системными администраторами и прочие неудобства.
«Карусель» потому, что это самое подходящее слово для случая, когда службы занимают нестандартные, неоговоренные порты.

$ipt -t nat -A PREROUTING -p tcp -s $dist_ip --dport 22 -j REDIRECT --to-port 26

Что здесь в роли $dist_ip, внешний адрес /32?

debugg 22 марта 2010, 12:26 # ↑

На счет удобства использования специальных программных средств. Часто нет времени, а у многих и желания на их изучение. Тем более если не стоит какая то конкретная задача для которой это необходимо. Поэтому многие используют старый провереный способ — перевесил и забыл.

Shark 22 марта 2010, 12:28 # ↑

Гнать такого сисадмина взашей, который вместо нормальной защиты просто перевешивает порт :)

debugg 22 марта 2010, 12:35 # ↑

Это безусловно, а если не сисадмин? Тут 2 варианта или самому зарываться в документацию или платить деньги. Ну и третий собственно — просто перевесить :)

dkr6 22 марта 2010, 16:48 # ↑

Если я это задокументировал, шефа уведомил, снижение активности в логах показал, правомерность своих действий подтвердив…
За что меня гнать?
За то, что я не следую, кем-то из пальца высосанным стандартам?
Или за то, что бедный, несчастный недохацкер теперь мигрень зарабатывает, мой сервер взламывая?
Давайте не будем наезжать на сисадминов…
У них есть, чем ответить ;)

Shark 22 марта 2010, 19:15 # ↑

Но наверняка, кроме перевешивания портов, у такого внимательного сисадмина (задокументировал, обосновал — вау! все бы так…) и пароли не слабые или ключи, возможно, и другие средства защиты. И перевесили порт не из-за незнания, а чтобы ещё круче было. А я говорю именно о таких:

Часто нет времени, а у многих и желания на их изучение.

dkr6 23 марта 2010, 11:57 # ↑

А кто мешает стать крутым сисадмином?
Кто-то даже помогает… ;)
И более того, не только рекомендует, как делать, но и объясняет «зачем и почему»…
Не все рождаются гениальными сисадминами, но многие становятся, если пытаются осознать систему, а не тупо копипастят куски чужих конфигов и скриптов…

Shark 23 марта 2010, 13:01 # ↑

Абсолютно с вами согласен. Поэтому если человек ещё мало знает, но с энтузиазмом к дальнейшему обучению — ему можно простить многое. А если он перевесил порт и говорит что больше защиты не надо, потому что никто не знает, что SSH на другом порту и совсем не горит желанием изучать внутренности и пр., то именно такого «специалиста» сразу гнать надо. Сам столкнулся с подобной некомпетентностью у нас в университете, где админов набирают из студентов (так положено), а выбирают по знакомству/случаю. Работать в среде этих людей очень тяжело (мне даже не разрешили поднять Active Directory и нормальный файловый сервер для доступа к информации, а сетка достаточно большая и жутко неудобно если надо изменить что-то на всех компах сразу). Не в силах повлиять на ситуацию свалил оттуда сам :) А что говорить о той инфраструктуре, которой заведует подобный человек? Отсюда и берутся стереотипы о компьютерщиках, которые никому не хотят помогать, о глюкавых компьютерах, которые каждый день вываливаются в БСоД и прочих фантастических прелестях.

zivot_je_cudo 22 марта 2010, 12:33 # ↑

Согласен, многие пользуются перевешиванием по причине незнания хороших и эффективных средств защиты.

foe_nix 22 марта 2010, 12:02 # ↑

по моему, это вообще не защита…

НЛО прилетело и опубликовало эту надпись здесь

andrew_tch 22 марта 2010, 10:55 #

nmap -sV 1.2.3.4

bondbig 22 марта 2010, 10:58 # ↑

nmap -sV 1.2.3.4 -p1-65535
/fixed

kemko 22 марта 2010, 11:46 #

Порт в настройках shhd не менял. На интерфейсе, смотрящем во «внутреннюю» сеть каких-то ограничений нет, на «внешнем» по умолчанию SYN'ы на 22й порт запрещены. Временный доступ на коннект извне дает knockd, заметив верную комбинации «стуков».

zivot_je_cudo 22 марта 2010, 11:48 # ↑

Поддерживаю портнокинг — очень надежная защита, особенно при централизованной атаке ботнета, когда fail2ban и прочие не справляются.

Shark 22 марта 2010, 12:16 # ↑

И он однозначно лучше чем перевешивание портов и намного надёжней.

dark_dimius 22 марта 2010, 12:51 # ↑

Причем полные параноики могут выставить кучу одноразовых комбинаций стуков.

Для тех кто не знает: эти стуки — по пакету на нужные порты с нужными tcp флагами, в нужном порядке.

dkr6 22 марта 2010, 12:06 #

В любом случае, защита сервера — комплекс мероприятий.
И перевешивание на нестандартный порт, один из компонентов этого комплекса.
В любом случае, это полезно, но не панацея.
Кроме того, сильно зависит от дистрибутива, точнее, от настроек самого сервиса по умолчанию.
И, как показывает практика, несколько простых и малоэффективных, на первый взгляд, действий по донастройке делает сервер весьма защищенным.
Но каждый админ выбирает свой цвет карандаша :)

foe_nix 22 марта 2010, 12:07 #

вообще ufw limit 22 проще и быстей, чем перевешивание порта…

mahoro 22 марта 2010, 12:08 #

Я на своем VDS поменял порт, просто потому что раньше невозможно было читать логи.

Кстати, переопределить порт для конкретного сервера можно в .ssh/config, так что ни запоминать его самому, ни править скрипты, которые как-то используют SSH не нужно.

Кроме того, раньше заморачивался на тему смены banner'а, так что при коннекте телнетом в приглашении отображается не OpenSSH.., а, скажем, binkd/0.92. Но сейчас что-то лень :)

Pavel_Pronskiy 22 марта 2010, 12:47 # ↑

Это не эффективно, так как любой желающий сможет узнать помимо баннера ещё и реальную версию сервиса. Так как если включить дебаг (ssh -v root@host -pдругой порт ), то там видна реальная версия этого сервиса.

mahoro 30 марта 2010, 00:30 # ↑

Это достаточно эффективно, т.к. с большой вероятностью у злоумешленника просто не возникнет мысль стучаться с помощью ssh на порт, баннер которого сообщает о работающем binkd.

agh 22 марта 2010, 12:17 #

Защита должна быть комплексной, если у вас не так то
Считаю приемлемым перенос порта, но опять же если вы не используете другие методы защиты :)

хорошо если порт будет выше 1024 а ещё лучше выше 10 000. а ещё лучше…
Практика показывает, что в основном боты перебирают хосты с открытым 22 портом. дальше уже подбор.
Также практика показывает, что идёт сканирование первых 200-300 сотен портов.

так почему бы сразу от них не избавится путём переноса порта? пусть думают, что у меня нет общедоступного ssh, а от школоты что будет сканить чем-то похожим на xPider (кажется так софтина называлась :))) ) помогут другие

Shark 22 марта 2010, 12:22 # ↑

Больше всего раздражает, что эта школота грузит сервак. Толку-то от этих сканов? Ключ в 4К хрен взломаешь, а даже если взломаешь — логин-то всё равно не рутовый. Но грузят, гады, сервак и замусоривают логи. Вот и приходится портноккинг включать.

mvgolubev 22 марта 2010, 12:31 # ↑

даже если взломаешь — логин-то всё равно не рутовый.

А есть ли разница между разрешенным рутовым логином по ssh и нерутовым логином по ssh пользователю, у которого есть право sudo?
Иногда это «ну логин же нерутовый» всего лишь самообман.

Shark 22 марта 2010, 12:32 # ↑

Пользователя, у которого есть право sudo, ещё пароль можно заставить ввести. Рутовый. По умолчанию, кстати, такая настройка и включена.

mvgolubev 22 марта 2010, 12:35 # ↑

Пользователя, у которого есть право sudo, ещё пароль можно заставить ввести. Рутовый.

Не рутовый, а свой. Который может быть уже подобран брутфорсом по ssh.

Shark 22 марта 2010, 12:39 # ↑

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

fixx 22 марта 2010, 12:41 # ↑

э… пользовотелья у которого sudo настроено на права рута вводит только свой пароль, а не рутовый. в этом и есть суть sudo

Shark 22 марта 2010, 12:43 # ↑

Да, извиняюсь, перепутал :) Но суть не меняется, его всё равно надо взламывать, если хочешь получить доступ.

dkr6 22 марта 2010, 12:56 # ↑

Это смотря что написано в /etc/sudoers…
Если там ALL=(ALL) NOPASSWD:ALL, то сам себе буратин ;)

thecoder 22 марта 2010, 15:23 # ↑

При наличии логина с ненулевой командной строкой, рутовый доступ — дело техники, особенно если ядро несвежее. Самая короткая дорожка здесь — дырка в сайте, например на php, который умеет shell_exec.

Shark 22 марта 2010, 19:18 # ↑

Те, кто настраивают php, так чтобы не рут мог выполнять shell_exec от имени рута — сами виноваты. Уязвимость системы определяется уязвимостью самой слабой её части, так что надеяться, что какой-либо один элемент системы защитит от взлома и пренебрегать остальными — глупо и безрассудно.

thecoder 22 марта 2010, 20:45 # ↑

Я имел ввиду, что shell_exec от непривилегированного(!) пользователя с огромной вероятностью хватит для закачки эксплойта и получения рута.

Shark 23 марта 2010, 13:05 # ↑

Тут да. Но это уже серьёзные инструменты и к таким нужен индивидуальный подход. Хорошим эксплоитом можно вскрыть сервер даже не подключаясь по SSH. Правда их достаточно быстро устраняют :)

odiszapc 22 марта 2010, 12:23 #

Изменение порта не является защитой

mvgolubev 22 марта 2010, 12:35 # ↑

«Секретки» на автомобильных колёсах — тоже не серьёзная защита от профессионального вора. Но от подвыпившей шпаны и нарков колёса всё же защищают.

Softovick 22 марта 2010, 12:37 #

По моему, такого уж явного смысла в этом нет. Да, от дураков можно закрыться, но от более менее опытного все равно не спасет (тем более, что дурак может и почитать инструкцию, таких наверняка полно в интернете). По любому даже на нестандартном номере порта нужно будет настраивать дополнительную защиту.
А также использование нестандартного порта может иметь свои последствия — например можно попасть на порт другого сервиса или не сработает программа, использующая ssh.

Pavel_Pronskiy 22 марта 2010, 12:40 #

Можно отключить pam в openssh и оставить авторизацию по ключам.
Тогда смысл брутофорса логин/пароль станет не эффективным вообще, так как openssh ничего не будет знать об интерактивной авторизации «логин/пароль» и со-но будет отвергать любые попытки интерактивной авторизации.

Shark 22 марта 2010, 12:41 # ↑

Тут есть один нюанс. Все отвержения — дополнительная нагрузка на процессор, лишние записи в логах и пр.

Pavel_Pronskiy 22 марта 2010, 13:00 # ↑

1. Парсить логи никто не отменял.
grep 'sshd[^ ]*' /var/log/messages | egrep -v «Invalid user»

2. При отключенном pam, нагрузка должна быть минимальной, так как в этом случае не используется системная pam авторизация.

3. Ставим fail2ban, раскоменчиваем некоторые правила и пользуемся. Он умеет интерактивно следить за движняками некоторых сервисов в логах и блочить по кол-ву попыток на определённое время, которое тоже в конфе задаётся.

FlexIDK 22 марта 2010, 13:09 #

Переписал порт, только для того чтобы логи не росли, при подборе…
Перевесил, все стало тихо =)

FlexIDK 22 марта 2010, 13:18 # ↑

А какие есть способы защиты FTP/SSH от перебора на FreeBSD и как настраивать?

Shark 22 марта 2010, 13:21 # ↑

Использовать вместо FTP SCP или SFTP. А способы защиты от перебора такие же как и на Линуксе — портноккинг, IPS, временный бан.

–1

Leshiy35 22 марта 2010, 13:25 # ↑

Такая же ситуация. У меня линуксовый сервер используется в основном, как роутер и фтп. Поэтому что-то выдумывать для доп. защиты не стал, а просто поменял порты.

HighwayStar 22 марта 2010, 13:28 #

да, при размещении в интернете компа с открытым 22-м портом примерно через сутки китайские ботнеты круглосуточно стали подбирать логин/пароль, после смены порта на highport вообще в логах за пару месяцев не встречал попыток подбора и вообще коннектов с левых адресов

–1

printf 22 марта 2010, 13:48 # ↑

Да. Я перевешиваю именно по этой причине. Еще подберут, чего доброго.

–4

zivot_je_cudo 22 марта 2010, 13:49 # ↑

Когда Вы перевешивали порт, Вам были известны другие способы защиты? Почему выбор пал на этот способ?

–1

dysangelium 22 марта 2010, 15:04 # ↑

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

–1

zivot_je_cudo 22 марта 2010, 15:08 # ↑

Использование iptables так же избавляет от хаоса в логах.

dkr6 22 марта 2010, 15:10 # ↑

Перевешивание порта — то же защита сервиса…
Логи — следствие, а не причина.
Эффективность такой защиты — другой вопрос.

Qiwichupa 22 марта 2010, 16:08 # ↑

Перевешивание порта — ступень в защите. Небольшая, но скорее полезная чем вредная

dkr6 22 марта 2010, 16:15 # ↑

Именно это я и пытаюсь объяснить…
Если хоть один человек это понял, значить я изгалялся ту не зря…
Жаль, что кто-то так и не понял, в следствие чего кидается «минусами»…

А идеальной защиты «в одно действие» не существует в природе…
Разве что выключить сервер… Тогда его ни кто не «крякнет» ;)

Shark 22 марта 2010, 19:19 # ↑

Кто-то придёт и включит :)

dkr6 23 марта 2010, 11:59 # ↑

Ага…
И при загрузке скажет init=/bin/bash…
Потом passwd root
и перегрузит…
И потом поимеет систему в полном объеме ;)

4dmonster 22 марта 2010, 13:32 #

смена порта делается не для безопасности а для удобства — меньше логи, меньше трафик, меньше нагрузка.

zivot_je_cudo 22 марта 2010, 14:45 # ↑

При ограничении количества SYN на 22 порт логи содержат всего одну попытку логина с каждого хоста, трафик и нагрузка точно так же сокращаются.

4dmonster 22 марта 2010, 14:51 # ↑

а при изменении порта — НОЛЬ.

не кипятитесь, считайте мой комментарий так: смена порта оправдана ТОЛЬКО ЕСЛИ не предназначена для обеспечения безопасности

fork 22 марта 2010, 14:16 #

если на машине не поднят https, бывает, пересаживаю sshd на 443 — это дополнительно дает возможность логиниться и пробрасывать туннели из «чужих» мест, находясь за squid-ом, в котором connect разрешен только на «безопасные» порты

differentlocal 22 марта 2010, 14:28 #

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

Порт все равно просканить — минутное дело. И брутфорсить без разницы, 22 или 22222 порт.

–2

dkr6 22 марта 2010, 14:50 # ↑

Если вы забываете, на каком порту у вас висит сервис удаленного администрирования, то вам и администрировать удаленные сервера не совсем нужно :)
Это совершенно не ваше дело…
Может быть вы гениальный программист, или крутейший дизайнер…
Но сервера админить лучше оставьте профессионалам :)

Не в обиду… Каждому свое ;)

differentlocal 22 марта 2010, 14:56 # ↑

Очень толсто^W смешно.

Вообще-то, я как раз администрированием серверов и занимаюсь. А в комменте своем мягко намекнул на две вещи:

1) Нужна защита, а не ее иллюзия. Вот iptables\fail2ban\snort — защита, а перевешивание портов — иллюзия. Это примерно как защищаться от взлома квартиры перевешиванием номеров на дверях.

2) Сервер далеко не один (и даже не один десяток, не редко) и разводить зоопарк портов — это очень плохо. (да, я знаю про .ssh/config, ключи и алиасы bash. Но я не всегда в сети с 1 компьютера и думаю я такой не один. Плюс, есть сервисы и софт, которым ssh\scp\sftp нужны для работы и не все умеют легко и корректно менять порты.).

–1

dkr6 22 марта 2010, 15:03 # ↑

Ну, минусовать за наличие собственного мнения не следовало бы…

А все остальное… Да, это ваш подход к решению проблемы…
У меня свой… Да, он отличается от вашего…
Но и я же отличаюсь от вас ;)…
Про иллюзию защиты, так у меня не один прибабах, и не только этот… Я, вообще, параноик…
Я уже писал о том, что защита == комплекс мероприятий…
Перевешивание порта — один из компонентов комплекса…
Весь остальной комплекс можно обсуждать до одури, но консенсуса не будет по причине, изложенной в начале данного комментария.

–2

zivot_je_cudo 22 марта 2010, 14:57 # ↑

Профессионал способен обеспечить безопасность сервиса на любом порту, а применение неуниверсальных средств, таких как перевешивание порта, говорит не в пользу профессионала.

–1

dysangelium 22 марта 2010, 15:08 # ↑

Это почему это профессионал не может использовать неуниверсальные средства?

–1

zivot_je_cudo 22 марта 2010, 15:15 # ↑

Может, но это говорит не в его пользу. Очень часто без этого нельзя, особенно дело касается самописных скриптов, тут сам Бог велит оформить решение по своему усмотрению. Но профессионал явно не будет полагаться на надежность перевешивания порта, «Авось не заметят».
Выбор универсального решения, наиболее удобного для остальных людей, соответствие нормам, содержание всего на своих местах, упорядоченность конфигурации — вот признаки профессионализма.

–1

dkr6 23 марта 2010, 12:29 # ↑

А кто сказал, что профессионал надеется на «Авось не заметят» ???
И кто вам сказал, что профессионал должен делать что-то наиболее удобным для остальных людей, если эти остальные люди делятся на «атакующих» и «непричастных»?
Группа админов корпоративных ресурсов вырабатывает и утверждает свои политики, среди которых и нестандартные порты на их, сугубо админский ресурс. И всем будет удобно…

А на всех остальных можно откровенно забить, потому как удобство атакующих нас интересует с инверсией, а непричастным должно быть сугубо безразлично, на каком порту у нас дежурит SSH.

–1

zivot_je_cudo 23 марта 2010, 12:35 # ↑

А кто сказал, что профессионал надеется на «Авось не заметят» ???

Я пишу, что профессионал ЯВНО НЕ БУДЕТ полагаться на «Авось не заметят».

И кто вам сказал, что профессионал должен делать что-то наиболее удобным для остальных людей, если эти остальные люди делятся на «атакующих» и «непричастных»?

Что я должен ответить, «Илья сказал»? Таково мое понимание профессионализма.

–1

dkr6 23 марта 2010, 12:46 # ↑

Был случай, когда в одной конторе пригласили консультантов для определения уровня профессионализма сотрудников…
Два молодых паренька (лет по 20) задавали мне много вопросов и ставили «птички» в опроснике…
В результате они определили, что я не профессионал, хотя на тот момент у меня было 10 лет стажа экстремальной КамаСутры с различными *nix-системами, высшее образование по сетям связи и много всякого подобного…

Я долго смеялся…
Мой работодатель — то же…
А эти ребята не могли понять, почему всем так смешно, а их контора не получила денег за консалтинг…

Это все не имеет отношения к SSH, но иллюстрирует подход к определению профессионализма.

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

soider 25 октября 2011, 15:27 # ↑

В принципе, гарантии что вы и ваш руководитель хорошие профессионалы тоже нет.

–1

dkr6 22 марта 2010, 15:13 # ↑

Да ну?!?!?
Профессионал тем и отличается, что понимает следствие своих действий и все действия применяет осознанно.
Если он знает что и зачем делает, то и перевешивание порта будет аргументированно, как и неперевешивание.
Профессионал понимает, что эффективность смены порта по умолчанию будет не слишком эффективным, но эффективность такого действия будет ненулевой.

mvgolubev 22 марта 2010, 15:22 # ↑

Порт все равно просканить — минутное дело. И брутфорсить без разницы, 22 или 22222 порт.

Это всё верно только в том случае, если каждая брутфорс-атака на ваши серверы была изначально нацелена именно на ваш IP-адрес, чтобы найти именно на нём SSH и подбирать пароли. Тогда злоумышленику действительно не сильно важно, какой порт найти: 22 или 22222.

Но в реальном мире обычно происходит так, что атака изначально не направлена именно на ваш IP. Злоумышленики (бот-неты, кул-хацкеры, крякеры, скрипт-киддис) в подавляющем большинстве случаев просто сканируют произвольный диапазон IP-адресов в надежде найти именно на 22 порту SSH-сервис, чтобы потом начать его брутфорсить. Т.е. злоумышленики в реальной жизни гораздо(!) чаще сканируют 22 порт для диапазона IP, нежени диапазон портов для одного конкретного вашего сервера.
И цель смены SSH-порта это не защита от брутфорса паролей, а именно уклонение от веерного тупого сканирования на 22 порт описанных выше злоумышлеников (коих в инете тысячи). В итоге хоть и не гарантируем защиту, но за то не получаем лишнюю нагрузку и лишние записи в логах, и всё это без особых напрягов.

И для указанных целей это действительно хорошо работает и даёт результат. Так почему бы и нет?

bo2l 22 марта 2010, 15:26 #

Как уже писали выше — да, оправдано, в случае ВДС.

mvgolubev 22 марта 2010, 15:42 #

Давайте представим, что все SSH-брутфорс-атаки в интернете можно разделить на две группы:
1) Атаки случайных бот-нетов и крякеров, которые просто тупо и нецеленаправленно периодически сканируют диапазоны адресов в поисках сервиса именно на 22 порту (ибо стандарт для SSH).
2) Атаки которые чётко спланированы и изначально направлены именно на ваши серверы (например, по заказу конкурентов).
И по статистике атак первого типа гораздо-гораздо больше, чем вторых.

Перевод SSH на нестандартный порт ограждает сервер от случайных атак первого типа, но разумеется не спасает от нацеленных атак второго типа. И все админы прекрасно понимают это. Но некоторые и не хотят тотально защититься, а хотят просто оградить свой сервер от огромного процента таких вот случайных атак первого типа. И для этих целей перенос SSH на другой порт — это простой и при этом достаточный (в рамках поставленных целей) способ.

Резюме: Если цель не полная защита, а просто уменьшение (на много порядков) числа брутфорс-атак на SSH, то перенос на другой порт — это простая и действенная мера.

dkr6 22 марта 2010, 15:54 # ↑

Логично…
По второму типу атак защитой является долговременная блокировка адреса атакующего по результату сканирования логов.
Таким образом, применение нестандартного порта снизит нагрузку именно на сканер логов, а блокировка явных атак на о-о-о-чень долгое время отобьет желание продолжать атаки у второй категории атакеров.
Что остается добавить? Постоянный мониторинг специализированных блогов и новостных ресурсов на предмет новых дыр в безопсности, обновление софта и всякие другие повседневные мелочи тру-сисадмина.
Это и будет перечень того, чем занята та бородатая скотина в свитере, которая порезала «одноклассссников» вашей(нашей) конторе…
И чем непонятнее будет набор действий этой бородатой скотины, тем более защищенной, в конечном итоге, будет корпоративная сеть…
Крякер, с той стороны, то же не сразу поймет, что и как реализовано…

–2

zivot_je_cudo 22 марта 2010, 16:18 # ↑

Но некоторые и не хотят тотально защититься, а хотят просто оградить свой сервер от огромного процента таких вот случайных атак первого типа.

В результате, от нацеленного брутфорса они все равно оказываются незащищенными.

Резюме: Если цель не полная защита, а просто уменьшение (на много порядков) числа брутфорс-атак на SSH, то перенос на другой порт — это простая и действенная мера.

Согласен. Но в продакшн такое бы не пускал.

–1

dkr6 22 марта 2010, 17:04 # ↑

В результате, от нацеленного брутфорса они все равно оказываются незащищенными.

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

Но в продакшн такое бы не пускал.

А ни кто и не заставляет :)
Весь комплекс…
И паранойя тут, именно тут, вполне оправдана…

P.S. Анализ уязвимостей и успешных взломов однозначно доказывает, что *nix системы ломают чаще всего по причине неправильных настроек слабо подготовленными админами, либо недостаточными defaults из дистрибутива.

–1

zivot_je_cudo 22 марта 2010, 18:12 # ↑

Но некоторые и не хотят тотально защититься, а хотят просто оградить свой сервер от огромного процента таких вот случайных атак первого типа.
В результате, от нацеленного брутфорса они все равно оказываются незащищенными.
Нет. От этого типа атак сервер защищается немного другими механизмами.

Что «нет»? Вы про какой-то конкретный сервер, который точно защищен? Мы с mvgolubev не упоминали ничего о других средствах, его вывод касается только переноса порта.
Очевидно же, что перемещение ssh на другой порт не спасает от нацеленного брутфорса.

mvgolubev 22 марта 2010, 19:19 # ↑

Если сразу использовать «правильные меры защиты SSH от брутфорса» на дефолтовом 22 порту, то они будут более ресурсоёмкими, т.к. сотни тупых скриптов брутфорса именно 22 порта создают лишний шум и лишнюю нагрузку.
А если сначала отсечь этих «атакующих первого типа» путём изменения SSH-порта, а уже потом ставить на SSH «правильную защиту от брутфорса», то такая защита будет уже менее ресурсоёмкой, т.к. всякая тупая шваль по SSH-порту уже толпами не ломится.

По-моему сейчас речь идёт уже об этом.

–1

dkr6 23 марта 2010, 12:02 # ↑

Вопрос

В результате, от нацеленного брутфорса они все равно оказываются незащищенными.

подразумевает ответ «Нет», как подтверждение вашего же утверждения.
От нацеленного брутфорса спасают другие способы защиты, про что уже писалось многократно.

–1

zivot_je_cudo 23 марта 2010, 12:12 # ↑

Понял, что подразумеваете Вы, но на утверждение «от нацеленного брутфорса они все равно оказываются незащищенными» ответ «Нет» подразумевает «нет, они не оказываются».

dkr6 23 марта 2010, 12:21 # ↑

Вы исключаете «нацеленный брутфорс» на 22-й порт.
А он имеет место быть.
Аж пока атакующий не уразумеет, что SSH на нестандартном порту…
И это уже кое что…
Не 100%, но и не 0%…
Чего и добивались…
Если у вас есть Portsentry, который мониторит пустой 22-й порт, то до атаки на новый порт дело и не дойдет даже %)

Если вы понимаете алгоритм атаки, то сможете построить и алгоритм защиты.
Иначе будет пустой треп и переливание из пустого в порожнее…

–1

zivot_je_cudo 23 марта 2010, 12:31 # ↑

Я вообще-то просто говорил о правилах русского языка.
Хороший способ, но оправдана ли такая паранойя? Так можно на все стандартные порты повесить ханипоты вместо служб.

–1

dkr6 23 марта 2010, 12:36 # ↑

Простите, русский для меня не родной ;)
В защите SSH паранойя оправдана, на мой личный взгляд.
Естественно, мое мнение вы можете не разделять…
Как показала моя практика, лучше перестараться с защитой, чем потом разруливать проблемы.
Именно так меня учили мои учителя, за что я им по сей день благодарен…

P.S.
Похоже, все аргументы уже приведены.
Dixi

Qiwichupa 22 марта 2010, 16:12 #

почему-то обсуждение идет в ключе «перевешивание порта» vs «все остальные методы защиты». Другой порт — это один из пунктов комплексной защиты, скорее полезный, чем вредный, в ряде (не всегда) случаев.

mafet 22 марта 2010, 19:16 #

на всех серверах своих юзаю 8-10значные пароли из букв(разный регистр) и цифр. Вроде особо не парюсь по поводу паролей. Хотя на коалокейшне был вынужден сменить порт — там много разного народа тусуется… С изменённым портом вероятность того, что при массовом сканировании найдут куда порт был перемещён — очень мала.

Novikov 22 марта 2010, 19:23 #

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

У меня на некоторых сайтах так сделано — видим, что кто-то начинает стучаться по админским урлам (или тестировать инъекции разные) — баним сразу.

pietrovich 22 марта 2010, 19:30 #

хм… никогда не перевешивал, он просто закрыт на публичных интерфейсах.
если нужен SSH — OpenVpn в руки, подключился и изнутри коннекться на стандартный порт.

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