Стоит ли закрывать iptables'ом все кроме 80 порта и ssh на vps сервере популярного сайта?

[p22s]

Стоит ли закрывать iptables'ом все кроме 80 порта и ssh на vps сервере популярного сайта?

[yars]

Очевидно, стоит запрещать все, что не разрешено явно. И ssh на нестандартный порт перенастроить.

[neol]

По желанию. Хуже не будет, лучше тоже.
ICMP только не блокируйте.

Очевидно, стоит запрещать все, что не разрешено явно.

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

[MrClon]

Стоит ли закрывать iptables'ом все кроме 80 порта и ssh на vps сервере популярного сайта?

Только если не уверен что ты (или кто-то другой) не выставит по оплошности наружу что-то что выставлять не нужно. В общем в качестве подстраховки.

P.S. запрети руту логиниться по ssh, если ещё не запретил.

И ssh на нестандартный порт перенастроить.

Абаснуй. Если логин не «admin» или «bob» и пароль не тривиален то боты и так не проломятся, а при целенаправленном взломе нестандартный порт не поможет.
Минусы у нестандартного порта правда тоже не особо фатальные, необходимость помнить какой там порт на каком сервере используется. ~/.ssh/config конечно помнит, но ведь иногда приходится и не со своего компа на сервер заходить.

[Bizdelnick]

запрети руту логиниться по ssh, если ещё не запретил.

Главное - вход только по ключу сделать.

[p22s]

Главное - вход только по ключу сделать.

зачем? какой смысл?

[Bizdelnick]

Затем, что ключ боты не подберут, в отличие от пароля.

[SLEDopit]

Затем, что ключ боты не подберут, в отличие от пароля.

Это не единственная причина. ssh авторизация по паролю уязвима mitm. даже инструкция есть в интернетах, как такое реализовать.
с авторизацией по ключам такую штуку пока никому провернуть не удавалось. хотя, конечно, теоретически и это возможно.

[drBatty]

Главное - вход только по ключу сделать.

зачем? какой смысл?

кроме того, что выше перечислили, пароль можно банально подсмотреть, а можно украсть кейлогером. Причём если вы в Xorg, то кейлогер успешно работает из под другого пользователя, т.е. из любой песочницы. А вот файл контролировать проще: его легче защитить, и легче уничтожить.

[pelmen]

Понимаю, что поднимаю немного устаревшую, да и уже решённую тему, но добавлю свои 5 копеек: если очень не хочется вешать ssh на нестандартный порт и делать авторизацию по ключу, то можно использовать port-knocking - еще одно интересное решение в разрезе безопасности

[SLEDopit]

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

то реализовывать port-knocking тем более не хочется. ваш кэп. (:

[drBatty]

если очень не хочется вешать ssh на нестандартный порт

это канал аниме? Или что значит на техническом форуме "не хочется"?

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

не осилил?

то можно использовать port-knocking

костыль ИМХО.

[pelmen]

если очень не хочется вешать ssh на нестандартный порт

это канал аниме? Или что значит на техническом форуме "не хочется"?

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

не осилил?

то можно использовать port-knocking

костыль ИМХО.

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

[Bizdelnick]

когда у тебя перевешивание службы на другой порт вызывает обилие вытекающей работы

А port knocking её при этом не вызовет? Что-то не могу себе представить такую ситуацию.

[pelmen]

У меня к серверу по ssh подключаются много клиентов (да, ssh не только для админа, но и для пользователей бывает нужен). Все они используют (так исторически сложилось) пароль. Переделывать аутентификацию на основании ключа для +10К пользователей пока что лень - и без этого много текущей работы. Вешать на нестандартный порт - тоже работы немало по перенастройке у всех, потом дебажить (ничего не забыл ли). А цена ошибки очень велика. Это и есть то обилие вытекающей работы. Но при этом все пользовательские ip-адреса уже в файерволе (accept).
Вообще, оказавшись где-нибудь на отдыхе вдалеке от своего ноутбука (или допуская гипотетически его пропажу) достаточно удобно иметь все свои серверы - с аутентификацией по ключу, а один - с аутентификацией по паролю, но за порт-кнокингом. А уже из-под него выполняется подключение к остальным серверам по ключам (секретные ключи, конечно, тоже запаролены). Когда данные на сервере крайне важны, невольно становишься параноиком. Время реагирования на сбой максимум 15 минут и в любое время (отпуск, ночь, в том числе и новогодняя). Меня не поймут, если я скажу "у меня ключа с собой не было".
На всякий случай: аутентификация по ключу, нестандартный порт и port-knocking - это всё методы защиты (в нашем случае - от взлома ssh). Но это разные методы и сравнивать их напрямую "что-то лучше, а что-т хуже" можно только для конкретных ситуаций. А в общем случае, они различны так же, как мягкий с зелёным. По этому, в моём сообщении написано, что "если вдруг первые два конкретно в вашей ситуации вас чем-то не устраивают, то обратите внимание на третий".
Вспомнилось: У меня вообще на одном из серверов все три метода используются: и ключ, и нестандартный порт, и кнокинг.
Однажды, даже не смотря на то, что на сервере у меня использовалась аутентификация по ключу, сам сервер отбрасывал мои попытки подключиться, т.к. на него был шквал подключений на ssh-порт (fail2ban не было настроено). Я не стал мучаться - сделал PK.
Читал в интернете, что некоторые товарищи даже делают PK второго, третьего уровня, но до такого я еще не доходил

[Bizdelnick]

аутентификация по ключу, нестандартный порт и port-knocking - это всё методы защиты (в нашем случае - от взлома ssh). Но это разные методы

Я бы сказал - это два разных метода. Один называется security through obscurity (нестандартный порт, port knocking - годятся только для отсева самых тупых ботов), другой - надёжная защита (аутентификация по ключу помогает и в случае направленной атаки).

Вспомнилось: У меня вообще на одном из серверов все три метода используются: и ключ, и нестандартный порт, и кнокинг.
Однажды, даже не смотря на то, что на сервере у меня использовалась аутентификация по ключу, сам сервер отбрасывал мои попытки подключиться, т.к. на него был шквал подключений на ssh-порт (fail2ban не было настроено).

Тут даже fail2ban не обязательно нужен, не говоря уже про port knocking. Помогло бы ограничение на число новых соединений с адреса посредством iptables.

[drBatty]

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

это называется "сделать через задницу". Если вы всё грамотно делаете, то проблем с портом не будет.

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

а бумажка с паролем всегда с вами, да? Или у вас везде 123 пароль?

Переделывать аутентификацию на основании ключа для +10К пользователей пока что лень

Переделывать аутентификацию на основании ключа для +10К пользователей пока что лень

вообще-то этим пользователи должны заниматься.
админ туда не должен соваться.