Comments 119
На самом деле, желательно сразу менять стандартный порт, так как его постоянно тестируют на предмет уязвимостей и через попытки перебора паролей.
Пусть тестируют, и сколько угодно могут перебирать rsa4096 тоже, мне не жалко :)
Менять не всегда получается — иногда нужен именно 22 порт (банально для «красивых» url, без указания порта).
Менять не всегда получается — иногда нужен именно 22 порт (банально для «красивых» url, без указания порта).
Я не могу себе позволить выставлять SSH на стандартном 22 порту в интернет в виду следующих опасений:
1. Всем известно что 22 порт постоянно сканируется, ботнеты и пр. Любой владелец фаерволла который собирает его логи знает что постоянно происходят сканы по стандартным портам (~1000шт)
2. Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
…
3. Допустим в SSH протоколе обнаруживается 0-day уязвимость.
За последние пару лет мы видели что такое случается с проектами с открытым кодом, тот же OpenSSL.
Хорошо если эта уязвимость была обнаружена правильными товарищами, тогда есть шанс на то, что кто-то успеет обновиться.
Плохо, если об этой уязвимости все узнают после её открытой эксплуатации.
В такой ситуации, заполучив POC код, нет никаких проблем воспользоваться shodan.io (или тем же списком от ботов) и зодолбить всех кто найдётся на 22 порту.
0-day уязвимости вполне может быть не важна длина ключа.
Я параноик и это гипотетически невозможная ситуация?
1. Всем известно что 22 порт постоянно сканируется, ботнеты и пр. Любой владелец фаерволла который собирает его логи знает что постоянно происходят сканы по стандартным портам (~1000шт)
2. Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
…
3. Допустим в SSH протоколе обнаруживается 0-day уязвимость.
За последние пару лет мы видели что такое случается с проектами с открытым кодом, тот же OpenSSL.
Хорошо если эта уязвимость была обнаружена правильными товарищами, тогда есть шанс на то, что кто-то успеет обновиться.
Плохо, если об этой уязвимости все узнают после её открытой эксплуатации.
В такой ситуации, заполучив POC код, нет никаких проблем воспользоваться shodan.io (или тем же списком от ботов) и зодолбить всех кто найдётся на 22 порту.
0-day уязвимости вполне может быть не важна длина ключа.
Я параноик и это гипотетически невозможная ситуация?
Нестандартный порт — это такая security by obscurity. На веб-сервера тоже постоянно ломятся на всякие /phpMyAdmin и т.п., и что, теперь и вместо 80 порта другой использовать?
Я параноик и это гипотетически невозможная ситуация?
Гипотетически очень многое возможно, но ситуация, при которой вас спасёт именно другой порт, крайне маловероятна, потому что эта "защита" не идёт ни в какое сравнение с методами, используемыми самим ssh. Полагаться нужно на стойкую криптографию, а не на то, что атакующий не знает, на каком порте у вас ssh. Да, и она может подвести, но настолько редко, что перестраховки обычно бессмысленны. Если уж так хочется приложить подорожник, то port knocking, whitelist по IP или сложный пароль пользователя (и sudo) имеют куда больше смысла, хотя полезность первого тоже неочевидна.
Нестандартный порт — это такая 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 — нет особых проблем в использовании нестандартных портов.
Если вас сильно беспокоит, то идеальным вариантом может быть впн-сервер, с которого уже идет ссш доступ во внутреннюю сеть. Имхо конечно, но порт, отличимый от 22 — это немного костылестроение и как минимум не удобно.
В принципе, если ссш на всех хостах на каком-то 5222 — то еще ладно. А если везде разные команды и у каждого что-то свое — то это дичь.
В принципе, если ссш на всех хостах на каком-то 5222 — то еще ладно. А если везде разные команды и у каждого что-то свое — то это дичь.
> на каком-то 5222
А вот вешать еще и на порт который без того имеет четкое назначение
это уже не просто дичь, а дичь полнейшая.
А вот вешать еще и на порт который без того имеет четкое назначение
xmpp-client 5222/tcp jabber-client # Jabber Client Connection
xmpp-client 5222/udp jabber-clientэто уже не просто дичь, а дичь полнейшая.
Порт — это просто цифры, ничего сакрального в них нет. Самому ssh, что клиенту, что серверу, разницы нет, 22 или 5222.
Другое дело, что нестандартная конфигурация дороже в обслуживании… Вот, к примеру, добавится к этому серверу с ssh на 5222 межсетевой экран, или IDS, а в нем в шаблоне для правил ssh прописан порт 22. И те, кто админят ту железку, должны это помнить.
А на своем локалхосте можно хоть и демократию внедрять.
Другое дело, что нестандартная конфигурация дороже в обслуживании… Вот, к примеру, добавится к этому серверу с ssh на 5222 межсетевой экран, или IDS, а в нем в шаблоне для правил ssh прописан порт 22. И те, кто админят ту железку, должны это помнить.
А на своем локалхосте можно хоть и демократию внедрять.
> Порт — это просто цифры, ничего сакрального в них нет. Самому ssh, что клиенту, что серверу, разницы нет, 22 или 5222.
Давай ты не будешь это рассказывать тому, кто админит сервера дольше, чем большинство местных читателей на свете живут, хорошо?
Перевешивание на нестандартный порт — верный признак попингуя начитавшегося дурных статей. Ни один админ с опытом подобной глупости творить не будет
Давай ты не будешь это рассказывать тому, кто админит сервера дольше, чем большинство местных читателей на свете живут, хорошо?
Перевешивание на нестандартный порт — верный признак попингуя начитавшегося дурных статей. Ни один админ с опытом подобной глупости творить не будет
Давай ты не будешь это рассказывать тому..
А давайте дочитывать комент до конца, что ли… Или хотя бы до 2 абзаца… ;)
Давай ты не будешь это рассказывать тому, кто админит сервера дольше, чем большинство местных читателей на свете живут, хорошо?
/facepalm
Опыт далеко не всегда указывает на качество работы.
А высокомерия вам не занимать.
Я пробовал ssh на разных портах на белом IP. Трафик «любопытных» на любом из 'well known' портов куда я пробовал перемещать ssh очень слабо отличается от трафика на 22 порту. На 80 порту ssh пытаются взломать примерно с той же интенсивностью что и на 22-м. Если ставить не 'well known' но из первой тыщи, то трафик «любопытных» тоже очень приличный.
Все дело в том, что сканеры портов вполне успешно распознают ssh на любом порту.
И кроме как отказаться от парольной аутентификации — ничего не остается.
Все дело в том, что сканеры портов вполне успешно распознают ssh на любом порту.
И кроме как отказаться от парольной аутентификации — ничего не остается.
Нестандартный порт — это НЕ security by obscurity.
security by obscurity — это когда тайным является СПОСОБ.
Тут же способ известен — смена порта. Номер порта фактически является ключем. Да, величина ключа не большая (десяток бит), но тем не менее ухудшает эффективность атаки на порядки.
security by obscurity — это когда тайным является СПОСОБ.
Тут же способ известен — смена порта. Номер порта фактически является ключем. Да, величина ключа не большая (десяток бит), но тем не менее ухудшает эффективность атаки на порядки.
Всем известно что 22 порт постоянно сканируется, ботнеты и пр. Любой владелец фаерволла который собирает его логи знает что постоянно происходят сканы по стандартным портам (~1000шт)
Сканируются все 65 тысяч портов. Попробуйте повесить открытую http прокси на какой-нибудь совсем странный порт вроде 63241 и проверьте через сколько дней через нее повалит китайский спам.
Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
Тут дело не в каких-то листах. Просто все ipv4 адреса в мире постоянно сканируются. На гигабитном канале TCP-SYN скан всего интернета по одному порту занимает ~20 минут (zmap, masscan).
Чем перевешивать SSH на нестандартные порты, и думать будто это вас от чего-то защищает, я бы рекомендовал поступать так:
Отключить аутентификацию по паролю, оставив только ключи. В таком случае сервер SSH будет сразу закрывать подключение при попытке авторизоваться по паролю.
/etc/ssh/sshd_config
-----------
PasswordAuthentication no
Сканируются все 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 на нестандартные порты, и думать будто это вас от чего-то защищает
Не передёргивайте, никто не говорит что это мера защиты. Это всего лишь способ уменьшения риска с учётом вышесказанного.
в интернете 4294967296 адресов
Неправильно считаете. 592708864 адресов зарезервированы, так что сканировать достаточно 3702258432.
UFO just landed and posted this here
Можно поставить простенькую IPS и банить на сутки при попытках просканировать например более 5-10 портов. До 50022 порта таким образом, любые китайцы доберутся очень не скоро.
Как вам уже сказали — сканируют вообще всё и вся.
От «китайцев» надо защищаться не банальным прятаньем порта, а по-взрослому.
На почтовый сервер (на котором я не могу сменить порт по очевидным причинам) мне сыпется несколько десятков разных «китайцев» и прочих в минуту — приходится жить и обучать сервер отправлять отлупы таким товарищам.
От «китайцев» надо защищаться не банальным прятаньем порта, а по-взрослому.
На почтовый сервер (на котором я не могу сменить порт по очевидным причинам) мне сыпется несколько десятков разных «китайцев» и прочих в минуту — приходится жить и обучать сервер отправлять отлупы таким товарищам.
То-есть вы исключаете вариант что до появления 0-day уязвимости у вас кто-то упорный найдёт ssh на нестандартном порту?
Так для справки, у меня белым адресом в интернет светит порядка 250 устройств, на всех включен ssh, на всех нестандартные порты (порт не один на всех, их несколько). Вот только один фиг я в логах постоянно вижу попытки авторизации. Спасает разве что fail2ban с баном на месяц, и то иной раз открываешь список правил и офигеваешь с количества хостов и приходится подчищать, дабы не перегружать процессор обработкой всех этих правил.
Так для справки, у меня белым адресом в интернет светит порядка 250 устройств, на всех включен ssh, на всех нестандартные порты (порт не один на всех, их несколько). Вот только один фиг я в логах постоянно вижу попытки авторизации. Спасает разве что fail2ban с баном на месяц, и то иной раз открываешь список правил и офигеваешь с количества хостов и приходится подчищать, дабы не перегружать процессор обработкой всех этих правил.
То-есть вы исключаете вариант что до появления 0-day уязвимости у вас кто-то упорный найдёт ssh на нестандартном порту?
Конечно не исключаю.
Я просто увеличиваю время для его поиска, точно так же как увеличивается время подбора пароля при увеличение его длины. Плюс исключаю тех потенциальных атакующих, кто не ищет сервисы на нестандартных портах.
С учётом того что сменить порт абсолютно бесплатно и не вызывает особых проблем, то я не вижу причин этого не делать, и вижу в этом больше плюсов чем минусов.
> и приходится подчищать, дабы не перегружать процессор обработкой всех этих правил.
fail2ban прекрасно работает с ipset. И нет нужды что-то подчищать.
fail2ban прекрасно работает с ipset. И нет нужды что-то подчищать.
banaction = iptables-ipset-proto6-allports спасет отца русской демократии
- Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
Нет нужды в списках, просто сканируют и пробуют всё IPv4 пространство. Таким же образом тыкаются на всякие URL на 80 и 443 порты независимо от вообще какого-либо ответа от самого веб-сервера или наличия каких-либо файлов в DocumentRoot.
UFO just landed and posted this here
Мы все видели Heartbleed в OpenSSL, который затронул большинство веб серверов, Meltdown/Spectre, который затронул почти все Intel процессоры, (ещё был shellshock, но не настолько страшный) поэтому уязвимости в широко распространенном ПО существующем десятилетия перешли из разряда «фантастически невероятных» в просто «маловероятные».
И, похоже, все уже забыли 2002 год:
www.openssh.com/txt/preauth.adv.
> хотя пароли не отключаю, лишь бы они были достаточно большими (12 цифробукв это 100 лет перебора со скоростью 1e11 паролей в секунду.
Тут есть еще один фокус. Нужно подобрать не только пароль, но и логин. По дефолту во всех системах сейчас идет PermitRootLogin prohibit-password. А все остальные логины надо еще угадать. То есть брутфорсеру надо угадать пару логин-пароль, а не просто пароль, что превращает задачу из маловероятной в невозможную.
Тут есть еще один фокус. Нужно подобрать не только пароль, но и логин. По дефолту во всех системах сейчас идет PermitRootLogin prohibit-password. А все остальные логины надо еще угадать. То есть брутфорсеру надо угадать пару логин-пароль, а не просто пароль, что превращает задачу из маловероятной в невозможную.
Что мешает ботам перебирать все возможные порты?
Фуллскан портов — обыденность. Если ssh не прятать за port-knocking'ом и шодан и ботнеты о нем узнают.
Месяца два назад смотрел логи на своей VPS для домашних проектов, в нестандартный порт openvpn стучались также часто, как в стандартные порты ssh/ssl.
blog.shodan.io/dont-be-clever
Месяца два назад смотрел логи на своей VPS для домашних проектов, в нестандартный порт openvpn стучались также часто, как в стандартные порты ssh/ssl.
blog.shodan.io/dont-be-clever
Если вы параноик, используйте fail2ban, например.
если Вы такой параноик, настройте port knocking
Пусть тестируют, и сколько угодно могут перебирать rsa4096 тоже, мне не жалко :)Тут есть ещё один не самый очевидный (и не для всех актуальный) момент — мне как-то не то за две, не то за три недели вот так вот «пусть наперебирали» на 9 ГБ трафика. Прямо такой аккуратный длинный прямоугольник на графике bandwidth.
У многих безлимит, но на маленьких VPS нередко бывают ограничения, и когда вот так впустую съели девять ГБ из ста, мне это пришлось не по нраву. Остатка всё равно хватило с лихвой, но после этого порт поменял.
эти 9Гб пришли бы вне зависимости от порта, настроек, файрвола. вы это понимаете?
сколько угодно могут перебирать rsa4096 тоже, мне не жалко
А мне жалко. Поскольку из-за таких перебиральщиков «ssh по крону» периодически отваливается, напарываясь на лимит числа соединений, не прошедших стадию авторизации.
для «перебиральщиков» можно предоствлять беспалную услугу блокировки типа такой (пример куска 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 становиться чистым как стекло :)Это абсолютно бесполезное занятие, все другие порты тоже «тестируют».
Ну, есть же port-knocking :) удачи «тестировщикам», чо.
Если начали тестировать «все другие порты», значит пришли конкретно за этим сервером, что бывает не так часто, как обычный автоматизированный скан.
Обычный автоматический скан — сканит все порты — Тотже Шодан, а уж китая ботнетику из пары сотен-десятков-тысяч(тм) устройств пофиг что и как сканить.
Более того обнаружение на не стандартном порту — повышает приоритет скана этой машины ибо *чтото тут интересненькое* и скоро на нее придет более прошаренный ботнетик с более злым сканом.
ЗЫ чот судя по тредику — с основами работы интернетика и банальной безопасности чот у всех прям беда-беда случилась, раньшенебо было зеленее как-то прошаренее чтоль были :(
Более того обнаружение на не стандартном порту — повышает приоритет скана этой машины ибо *чтото тут интересненькое* и скоро на нее придет более прошаренный ботнетик с более злым сканом.
ЗЫ чот судя по тредику — с основами работы интернетика и банальной безопасности чот у всех прям беда-беда случилась, раньше
Обычный автоматический скан просто ищет популярные уязвимости. Нет смысла тратить время на перебор вообще всего на одной отдельно взятой машине, если за то же время можно найти несколько уязвимых.
> Более того обнаружение на не стандартном порту — повышает приоритет скана этой машины ибо *чтото тут интересненькое* и скоро на нее придет более прошаренный ботнетик с более злым сканом.
Ну как. Вот у меня ssh висит на нестандартном порту. Вход строго по ключам. Только один раз за несколько лет (на нескольких серверах) было что-то вроде
Ну как. Вот у меня ssh висит на нестандартном порту. Вход строго по ключам. Только один раз за несколько лет (на нескольких серверах) было что-то вроде
Disconnected from authenticating user root 89.187.88.79 port 45162 [preauth]Там перебирали несколько юзеров, вроде portal, postgres и т.п.
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]
...
Это полезное занятие, ибо все порты тестируют нааамного реже, чем пару сотен стандартных, и при отсутствии sshd на стандартном порту жуликами отнимается у сервера нааамного меньше ресурсов.
Разница заметна на маленьких, чахлых VPS — если боты перебирают пароли на стандартном порту в несколько потоков, то владелец зайти не может.
Разница заметна на маленьких, чахлых VPS — если боты перебирают пароли на стандартном порту в несколько потоков, то владелец зайти не может.
Это совершенно бесполезное занятие. Называется Security through obscurity. Еще раз. Нет нужды заниматься противоестественными вещами и вешать ssh непойми куда. Есть два шага для обеспечения полной безопасности ssh'а
1. Запрет авторайза по паролю, только ключ
2. fail2ban или его аналоги
Все. И не нужно прятать голову в песок и заниматься прочими глупостями
1. Запрет авторайза по паролю, только ключ
2. fail2ban или его аналоги
Все. И не нужно прятать голову в песок и заниматься прочими глупостями
Это, помимо всего прочего, снижает объём auth.log с гигабайтов до мегабайтов. Иногда существенно, особенно если вдс используется чисто для впн и большого диска ей неположено.
А те два шага в любом случае нужны…
А те два шага в любом случае нужны…
Ой, не рассказывайте сказки про гиги auth.log'а.
Гиги, блин.
ls -lah /var/log/auth.log
-rw-r----- 1 syslog adm 190K Jul 31 09:17 /var/log/auth.logГиги, блин.
```
# ls -lh /var/log/auth.log.1
-rw-r----- 1 root adm 862M Jul 29 06:25 /var/log/auth.log.1
```
Практически гиг за сутки.
# ls -lh /var/log/auth.log.1
-rw-r----- 1 root adm 862M Jul 29 06:25 /var/log/auth.log.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Крон там раз в 5 минут. Это именно ssh, причём чаще всего — сканирование порта, а не подбор паролей почему-то. А fail2ban есть… Только банить он настроен после 5 попыток подбора, а вчера шел поток с каждого ип по 3…
Это делается скорее из расчета на недонастроенные VPS, ленивых админов и пр. Достаточно закрыть логин руту, включить логин только по ключу, и вероятность успешного брутфорса устремится к нулю. Можно еще добавить fail2ban.
Можно еще добавить fail2banЕсли не возражаете, бессовестно вклинюсь:
Может быть Хабр подскажет альтернативу fail2ban для VPS с маленьким объёмом памяти?
Например, у меня 384 МБ и f2b явно туда не влезет. А заворачивать нехороших граждан всё-таки хотелось бы. Использую CentOS 7.
DenyHosts может подойти.
В ufw, например, есть вот такая штука. Добавляет некий набор правил в iptables. Ту же самую магию в iptables можно и ручками добавить если что.
Ну например, для iptables, с помощью замечательного модуля recent:
С временем --update --seconds 7200 лучше поиграть в обе стороны.
Потом по крону можно парсить логи и добавлять особо рьяных в ipset.
А правило
повесить ближе к началу портянки iptables.
-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.
Попробуйте denyhosts
sshguard. По сути, то же самое, но на C. Поддерживает не только SSH, как можно было бы подумать из названия.
А еще можно засунуть голову в песок. Тоже помогает не видеть опасностей. В перевешивании ssh'а на другой порт нет никакого смысла. Вообще.
1. Доступ только по ключу
2. fail2ban или его аналоги
И никаких голов в песок.
1. Доступ только по ключу
2. fail2ban или его аналоги
И никаких голов в песок.
Разве сложно просканить группу портов и найти рабочие?
Однажды столкнулся с тем, что корпоративный фаервол пропускал очень ограниченное количество портов, и когда я поменял порт SSH на VPS, то мой рабочий компьютер не смог подключиться к серверу. Пришлось менять настройки порта через смартфон…
Да, это поможет. Но я, не зная особенностей фаервола — поменял порт сразу после создания VPS, и получил дулю :)
А нечего порт менять :)
Вообще команда nginx'а молодцы с этой фичей в mainline, я думаю со временем на всех серверах у себя сделать подобный запасной вход. Просто на части использую mainline, там вот на днях собираюсь внести изменения в конфиги, на части, по ряду причин, stable, там с выходом 1.16 применю.
Такая конфигурация даст возможность подключаться и из очень ограниченных по портам сетей
Вообще команда nginx'а молодцы с этой фичей в mainline, я думаю со временем на всех серверах у себя сделать подобный запасной вход. Просто на части использую mainline, там вот на днях собираюсь внести изменения в конфиги, на части, по ряду причин, stable, там с выходом 1.16 применю.
Такая конфигурация даст возможность подключаться и из очень ограниченных по портам сетей
Эммм, а что, ssh у всех открыт прямо во весь интернет? По-моему риск можно уменьшить банально указав доступ только с определенных ип. Если у админа нет статики, то хотя бы ограничить диапазоном провайдера, ну или страны, в крайнем случае.
У нас можно зайти всего с одного ип, и это статический ип офиса, а к офису уже по впн.
Конечно можно потерять контроль над серверами, если в офисе обрушится интернет, но пока что ситуаций одновременных траблов в датацентре и в офисе не возникало
Прям читаю и не понимаю как вы не понимаете что ни в коем случае нельзя так делать.
В вашем случае невозможность попасть на сервера это просто вопрос времени. Объяснять почему?
В вашем случае невозможность попасть на сервера это просто вопрос времени. Объяснять почему?
Я не в теме, но попробую догадаться: потому что ip адрес отправителя в пакете можно заменить на любой?
Думаю, тут скорее имелось в виду некое событие, после которого сменится либо станет недоступным публичный IP-адрес офиса (например, провайдер решит адресацию сети поменять без предупреждения или просто у провайдера произойдёт долговременный технический сбой).
А поскольку к серверу можно подключиться только с одного IP-адреса, и этот адрес стал нам недоступен, то и подключиться к серверу мы не сможем.
А поскольку к серверу можно подключиться только с одного IP-адреса, и этот адрес стал нам недоступен, то и подключиться к серверу мы не сможем.
UFO just landed and posted this here
Если вы имеете ввиду, что злоумышленник может добраться до 22 порта даже при таких ограничениях, то да, я бы хотел знать почему это вопрос времени.
Если вы о подмене IP в заголовке пакета, то во-первых взломщик должен знать на какой IP менять, что не особо тривиально, если не прослушивать пакеты находясь между.
И конечно же все остальные условия безопасности, типа авторизации только по ключу, тоже выполнены.
Пока что таких событий не было, IP компании установлен контрактом и ни в коем случае не может быть поменян без предупреждения, после которого, конечно же правила доступа будут изменены. А что касается технических сбоев, ну в самом крайнем случае, на фаерволл можно зайти без привязки по IP и поменять правила доступа.
Ну и а с фаерволлом там свои условия для входа.
Ну так когда я в поездке, то я подключаюсь к офису через VPN и захожу на нужный ресурс.
Пока в РКН есть Р, они до нас не доберутся 8-)
Если вы о подмене IP в заголовке пакета, то во-первых взломщик должен знать на какой IP менять, что не особо тривиально, если не прослушивать пакеты находясь между.
И конечно же все остальные условия безопасности, типа авторизации только по ключу, тоже выполнены.
Думаю, тут скорее имелось в виду некое событие, после которого сменится либо станет недоступным публичный IP-адрес офиса (например, провайдер решит адресацию сети поменять без предупреждения или просто у провайдера произойдёт долговременный технический сбой).
А поскольку к серверу можно подключиться только с одного IP-адреса, и этот адрес стал нам недоступен, то и подключиться к серверу мы не сможем.
Пока что таких событий не было, IP компании установлен контрактом и ни в коем случае не может быть поменян без предупреждения, после которого, конечно же правила доступа будут изменены. А что касается технических сбоев, ну в самом крайнем случае, на фаерволл можно зайти без привязки по IP и поменять правила доступа.
Ну и а с фаерволлом там свои условия для входа.
Нет, потому что может потребоваться подключится к серверу с мобильного или в поездке. Вот если бы вы сказали про личный VPN, я бы понял.
Ну так когда я в поездке, то я подключаюсь к офису через VPN и захожу на нужный ресурс.
Неплохо бы, чтобы физический доступ к серверам был. А то, например, подсеть РКН забанит — и тогда трафик к ней может вообще перестать ходить (
Пока в РКН есть Р, они до нас не доберутся 8-)
Вы не думали что там может быть ec2 где правило можно поменять прямо из панели?
Неплохо бы, чтобы физический доступ к серверам был. А то, например, подсеть РКН забанит — и тогда трафик к ней может вообще перестать ходить (
> Если у админа нет статики, то хотя бы ограничить диапазоном провайдера, ну или страны, в крайнем случае.
А если админ может сегодня заходить из одного города, завтра из другого, а послезавтра из другой страны?
Доступ по ключу и fail2ban помогают, вместо засовывания головы в песок.
А если админ может сегодня заходить из одного города, завтра из другого, а послезавтра из другой страны?
Доступ по ключу и fail2ban помогают, вместо засовывания головы в песок.
Разве не Юлонен? Вроде бы в финском «Y» всегда «Ю»?
Это мягкая «у». Ближайший звук, пожалуй, как у «ю» в «мюслях». Из звуков русского языка больше подходит «ы» или «и». Обозначать его как начальную «ю» совсем некорректно, поскольку там нет звука «й».
Тем не менее, на русский принято транслитерировать именно буквой «ю»: ru.wikipedia.org/wiki/Юккёнен
Эх, просто отправил письмо и просто получил положительный ответ меньше, чем через сутки.
Интересна еще и история самого толчка для разработки 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.
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.
UFO just landed and posted this here
Контактное лицо для порта… прикольно
Судя по википедии Joyce K. Reynolds — женщина, а в тексте её имя склоняется по правилам мужского рода.
Я всегда считал, что номера портов у молодых проектов назначаются примерно так:
— Люда! Назови цифру от одного до 65535
— 22
— Вася, теперь SSH на 22 порту, добавь меня в контакты
Ведь когда-то все эти веб-серверы, ssh, ssl, telnet были «молодыми проектами».
А потом оно просто приживается и остается.
— Люда! Назови цифру от одного до 65535
— 22
— Вася, теперь SSH на 22 порту, добавь меня в контакты
Ведь когда-то все эти веб-серверы, ssh, ssl, telnet были «молодыми проектами».
А потом оно просто приживается и остается.
В то время это означало уважаемых первопроходцев интернета Джона Постела и Джойса К. Рейнольдса. Среди всего прочего, Джон являлся редактором таких незначительных протоколов, как IP (RFC 791), ICMP (RFC 792) и TCP (RFC 793). Возможно, кто-то из вас слышал о них.Вот вам фотография «первопроходца»; фразы надо переписать в женском роде:
icannwiki.org/Joyce_Reynolds
Давным-давно, запарившись проверять и настраивать порты, я поставил ovpn на сервер и оставил открытими только 80,443 и порт ovpn. Доступ ко всем остальным сервиcам настроил только с интерфейса ovpn. Все. Чистые логи, никакого брутфорса. И вам советую.
Для чего в правилах iptables опция "--ctstate NEW,ESTABLISHED"?
Sign up to leave a comment.
Как SSH появился на 22 порту