безопасность к взлому при открытом ssh

[azsx]

У меня на домашнем компьютере (дебиан) открыт ssh доступ с интернета. Хочу спросить, а насколько это безопасно? Домашний комп ведь не сервер, программы там просто навалены (установлены), пароли обычной сложности, никаких заморочек с файрволами или анализом логов разумеется никогда не будет. Не опасно ли такой комп в сеть выпускать?

[SLEDopit]

Хочу спросить, а насколько это безопасно?

Это безопасно при условии, что
1. Запрещен логин под рутом
2. ssh висит на нестандартном порту
3. стоит ограничение по пользователям, которым можно логиниться по ssh
4. (опционально, но желательно) стоит какой-нибудь фильтр типа fail2ban (он автоматически банит на 15 минут по ip после 3 неудачных попыток ввода пароля)
5. (опционально) запрещен логин по паролям, можно логиниться только по сертификатам.

[Ленивая Бестолочь]

6. система в целом, либо ssh и всё, что с ним связано своевременно обновляется ;-)

[rm_]

Ещё не мешало бы с помощью iptables разрешить доступ по SSH не отовсюду, а только с диапазонов тех провайдеров, с которых вы знаете, что будут заходить легитимные пользователи. В этом случае нестандартный порт в общем-то и ни к чему.

[t.t]

Ещё не мешало бы с помощью iptables разрешить доступ по SSH не отовсюду, а только с диапазонов тех провайдеров, с которых вы знаете, что будут заходить легитимные пользователи. В этом случае нестандартный порт в общем-то и ни к чему.

Это не всегда возможно, в отличие от нестандартного порта.

[AlexYeCu]

Ещё не мешало бы с помощью iptables разрешить доступ по SSH не отовсюду, а только с диапазонов тех провайдеров, с которых вы знаете, что будут заходить легитимные пользователи. В этом случае нестандартный порт в общем-то и ни к чему.

А в конфиге sshd задать ограничения на диапазон ip не достаточно?

[rm_]

Ещё не мешало бы с помощью iptables разрешить доступ по SSH не отовсюду, а только с диапазонов тех провайдеров, с которых вы знаете, что будут заходить легитимные пользователи. В этом случае нестандартный порт в общем-то и ни к чему.

А в конфиге sshd задать ограничения на диапазон ip не достаточно?

Во-первых я не знал, что можно, во-вторых через iptables всё-таки спокойней/железобетонней, не говоря уж о большей юниксвейности.

[pelmen]

7. iptables port knocking

[SLEDopit]

Это не всегда возможно

+1. Более того, имхо, в случае домашней машины это вообще невозможно. Т.к. такой доступ обеспечивается специально для доступа из любой точки домой. И порой совершенно невозможно предсказать с какого провайдера будет произведен вход.

7. iptables port knocking

имхо, это даже не на всех серверах стоит делать. уж слишком параноидально.

[t.t]

через iptables всё-таки спокойней/железобетонней

Почему?

не говоря уж о большей юниксвейности.

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

[t.t]

Это не всегда возможно

+1. Более того, имхо, в случае домашней машины это вообще невозможно. Т.к. такой доступ обеспечивается специально для доступа из любой точки домой. И порой совершенно невозможно предсказать с какого провайдера будет произведен вход.

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

[rm_]

Т.к. такой доступ обеспечивается специально для доступа из любой точки домой. И порой совершенно невозможно предсказать с какого провайдера будет произведен вход.

Бывает и так, но во многих случаях доступ домой необходимо обеспечить лишь из конечного числа точек (допустим работа/институт, да GPRS используемого сотового оператора).

через iptables всё-таки спокойней/железобетонней

Почему?

Потому что -- а кто его знает, как в конкретном сервисе реализован его встроенный ограничитель на подсети? Вдруг там глюки есть, и он некоторые адреса пропускает, или не всегда срабатывает? Или например срабатывает уже после того, как сервис форкнул очередную копию себя, открыл сокет и т.д. (добро пожаловать ddos), возможно даже получил от клиента и обработал какие-то данные (добро пожаловать buffer overflow).
То ли дело с iptables - при соответствующем правиле клиент всегда и без вариантов просто получит connection refused, до запущенного сервиса ни один пакет от зловредного клиента даже не дойдёт.

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

Ну а если открыто. Предлагаете настраивать ограничения по IP-адресам в конфиге каждой программы? А что если в некоторых это не поддерживается. Unix way: одна задача (фильтрация сетевых соединений, одним словом файрвол) == одна программа (iptables), делающая только это, но делающая очень хорошо.

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

Доступ по ключу никто и не предлагает заменять на только-пароль, ну а нестандартный порт ни от чего толком не защищает (от случайных сканов диапазонов в поисках ssh? "небось ещё найдут, а у вас там пароль 123"? ), а печатать каждый раз в консоли -p blah неудобно.

И вообще,

Код: Выделить всё

$ ssh www.debian.org
The authenticity of host 'www.debian.org (2001:858:2:1::10)' can't be established.
RSA key fingerprint is 5a:99:3c:f5:5c:70:a9:42:4d:e0:3d:66:e6:a8:c9:c6.
Are you sure you want to continue connecting (yes/no)?

$ ssh www.freebsd.org
The authenticity of host 'www.freebsd.org (2001:4f8:fff6::21)' can't be established.
DSA key fingerprint is 09:ae:f1:48:e0:76:c6:e1:13:ff:2b:cb:20:40:38:d0.
Are you sure you want to continue connecting (yes/no)?

$ ssh www.centos.com
The authenticity of host 'www.centos.com (87.106.187.200)' can't be established.
DSA key fingerprint is 34:47:0f:e9:1a:c2:eb:56:eb:cc:58:59:3a:02:80:b6.
Are you sure you want to continue connecting (yes/no)?

Так что PasswordAuthentication off однозначно всегда и везде, и держите спокойно SSH на стандартном порту.

[SLEDopit]

а печатать каждый раз в консоли -p blah неудобно.

а никто и не заставляет.

И вообще,

Еще один аргумент в пользу нестандартного порта - никакие боты не ломятся и не засоряют логи.

Так что PasswordAuthentication off однозначно всегда и везде

Некоторые пользователи windows панически боятся, что сертификаты утащит какой-нибудь случайно проскочивший троянец и пользуются исключительно авторизацией по паролям. Не один раз лично сталкивался с такими людьми. Переубеждать их бесполезно (:

[drBatty]

Еще один аргумент в пользу нестандартного порта - никакие боты не ломятся и не засоряют логи.

да, это действительно утомляет :(

Некоторые пользователи windows панически боятся, что сертификаты утащит какой-нибудь случайно проскочивший троянец и пользуются исключительно авторизацией по паролям. Не один раз лично сталкивался с такими людьми. Переубеждать их бесполезно (:

почему - нет? хотя я не слишком понимаю, как можно запомнить

Код: Выделить всё

\h$LyeRq(EaZ3fjnu1ODSv3h2

что-бы
а) это было-бы недоступно для трояна
б) это было-бы доступно для пользователя.
Подозреваю, что пароли можно легко узнать заразив putty.exe.
(и видимо так оно и делается) потому пароли применять не нужно, как и Windows.

[pelmen]

7. iptables port knocking

имхо, это даже не на всех серверах стоит делать. уж слишком параноидально.

Возможно я параноик, но у меня реализовано именно так:
1) ssh на нестандартном порту
2) iptables-ом закрыто все, нужное открывается через port knocking (это касается не только сервисов на этом сервере, но и сервисов всех внутренних серверов, на которые форвардит DNATом этот сервак, кроме smtp, конечно)
3) аутентификация по запароленному ключю (т.е. ключ + пароль). В этом случае пароль может быть не особо сложным и длинным, но и не "qwerty". Ключ генерируем раз в квартал.
4) запрет логиниться под рутом
Кстати, считаю, что ограничивать по ip лучше через iptables чем через ssh именно потому, что iptables отбросит, как будто сервер выключен (REJECT), а ssh наверное (сомневаюсь, но кажется так) сделает DROP, чем может привлечь откинутого бота.

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

[t.t]

через iptables всё-таки спокойней/железобетонней

Почему?

Потому что -- а кто его знает, как в конкретном сервисе реализован его встроенный ограничитель на подсети? Вдруг там глюки есть, и он некоторые адреса пропускает, или не всегда срабатывает? Или например срабатывает уже после того, как сервис форкнул очередную копию себя, открыл сокет и т.д. (добро пожаловать ddos), возможно даже получил от клиента и обработал какие-то данные (добро пожаловать buffer overflow).
То ли дело с iptables - при соответствующем правиле клиент всегда и без вариантов просто получит connection refused, до запущенного сервиса ни один пакет от зловредного клиента даже не дойдёт.

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

Ну а если открыто. Предлагаете настраивать ограничения по IP-адресам в конфиге каждой программы? А что если в некоторых это не поддерживается. Unix way: одна задача (фильтрация сетевых соединений, одним словом файрвол) == одна программа (iptables), делающая только это, но делающая очень хорошо.

Я, собственно, писал о том варианте, когда открывать наружу нужно только ssh. Не думаю, что реализацию отсева адресов ssh-сервера плохо тестируют на уязвимости. А городить отдельный забор из iptables для того, что можно реализовать средствами самого сервера, не считаю целесообразным (как и «юниксвэйным»). Если открытых «внешних доступов» несколько, ничего не имею против.

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

Доступ по ключу никто и не предлагает заменять на только-пароль, ну а нестандартный порт ни от чего толком не защищает (от случайных сканов диапазонов в поисках ssh? "небось ещё найдут, а у вас там пароль 123"? ), а печатать каждый раз в консоли -p blah неудобно.
[…]
Так что PasswordAuthentication off однозначно всегда и везде, и держите спокойно SSH на стандартном порту.

Я знаю наверняка только одно: когда несколько лет назад у меня ssh-сервер висел на 22-м порту, ломились на него _постоянно_; в среднем от тридцати до ста раз в час. Как только перевесил на другой порт, всё тут же прекратилось.

[t.t]

Некоторые пользователи windows панически боятся, что сертификаты утащит какой-нибудь случайно проскочивший троянец и пользуются исключительно авторизацией по паролям. Не один раз лично сталкивался с такими людьми. Переубеждать их бесполезно (:

Более того: мне пару раз рассказывали, что закрытый ключ можно перехватить из сетевого канала прямо в момент авторизации; т.е. даже независимо от клиентской операционки. На вопрос «как?» ответы были в духе «кому надо, тот знает».

[Ленивая Бестолочь]

iptables отбросит, как будто сервер выключен (REJECT)

iptables отбросит так, как вы ему скажете.

[sash-kan]

Более того: мне пару раз рассказывали, что закрытый ключ можно перехватить из сетевого канала прямо в момент авторизации; т.е. даже независимо от клиентской операционки. На вопрос «как?» ответы были в духе «кому надо, тот знает».

согласно протоколу ssh ключи по сети не передаются.
конспирологи — они такие забавные.

[AlexYeCu]

Некоторые пользователи windows панически боятся, что сертификаты утащит какой-нибудь случайно проскочивший троянец и пользуются исключительно авторизацией по паролям. Не один раз лично сталкивался с такими людьми. Переубеждать их бесполезно (:

Справедливости ради отметим, что ключи возможно использовать далеко не всегда, так putty для symbian понимает ключи только сгенерированные какой-то win-прогой.

[t.t]

Справедливости ради отметим, что ключи возможно использовать далеко не всегда, так putty для symbian понимает ключи только сгенерированные какой-то win-прогой.

Только мне сочетание фраз «далеко не всегда» и «putty для symbian» кажется странным? (:

[Voral]

Справедливости ради отметим, что ключи возможно использовать далеко не всегда, так putty для symbian понимает ключи только сгенерированные какой-то win-прогой.

Хм. странно. Может речь идет о разности ssh-1 ssh-2 тогда ведь дело просто в настройках.

[AlexYeCu]

Справедливости ради отметим, что ключи возможно использовать далеко не всегда, так putty для symbian понимает ключи только сгенерированные какой-то win-прогой.

Хм. странно. Может речь идет о разности ssh-1 ssh-2 тогда ведь дело просто в настройках.

http://s2putty.sourceforge.net/faq.html

[SLEDopit]

ну давайте справедливости ради вспомним и web ssh клиенты. типа shellinabox. я надеюсь что у людей не хватит мозгов выставлять такую штуку с авторизацией по ключам мордой в интернет (:

[sash-kan]

Справедливости ради отметим, что ключи возможно использовать далеко не всегда, так putty для symbian понимает ключи только сгенерированные какой-то win-прогой.

$ man puttygen (в частности, секция с примерами)
$ apt-file search bin/puttygen
putty-tools: /usr/bin/puttygen

разница в формате хранения, не более.

[AlexYeCu]

Код: Выделить всё

-O private

Надо будет проверить…

[azsx]

1. Запрещен логин под рутом

запретил

2. ssh висит на нестандартном порту

висит. Вот только такой наивный вопрос, а что есть нестандартный порт? Вот сто с чем то (1**) - это нестандартный порт? Порт — это любое случайное число, да?

3. стоит ограничение по пользователям, которым можно логиниться по ssh

извините — не понимаю. Делать не стал.

4. (опционально, но желательно) стоит какой-нибудь фильтр типа fail2ban (он автоматически банит на 15 минут по ip после 3 неудачных попыток ввода пароля)

пока не могу установить, борюсь.

6. система в целом, либо ssh и всё, что с ним связано своевременно обновляется ;-)

да, обновляю

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

5. (опционально) запрещен логин по паролям, можно логиниться только по сертификатам.

Я считаю, что мне это не нужно. Мне нужен доступ откуда угодно к винту и тройке программ на домашнем компе. А вовсе не супер надежность защиты.

7. iptables port knocking

ой, такое у меня пока не получится

[azsx]

-O private

Так что PasswordAuthentication off однозначно всегда и везде

не совсем понимаю, зачем мне надо отключить возможность ввода пароля. Делать не стал.

\h$LyeRq(EaZ3fjnu1ODSv3h2

извините — не понимаю.
зы
опять же, размышления оффтоп. У меня стоит такая матерая железная дверь (открывалкой не откроется). Один замок, дверные петли наружу, соседи не дружные. Я бы вскрыл такую дверь минут за 10, с помощником. Глазки бы им заклеил скотчем, телефон бы обрезал. Зашел бы и взял целиком компьютер. Это я к тому, что именно на домашний компьютер мне супер безопасность не нужна, а вот в теории, почитать интересно, как сделать идеально.

Вы ввели слишком много блоков с цитатой

[AlexYeCu]

извините — не понимаю.

Да мой коммент немного не в тему — просто putty-ключи имеют ряд отличий, я раньше их с OpenSSH не пользовал никогда, а тут с подачи sash-kan глянул — всё просто.

[deadhead]

Я бы вскрыл такую дверь минут за 10, с помощником. Глазки бы им заклеил скотчем, телефон бы обрезал. Зашел бы и взял целиком компьютер.

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

Я считаю, что мне это не нужно. Мне нужен доступ откуда угодно к винту и тройке программ на домашнем компе. А вовсе не супер надежность защиты

Носите ключ на флешке, например