Существуют ли какие-либо риски безопасности, если для политики OUTPUT установлено значение ACCEPT?
Речь идет о VPS, на котором размещены несколько веб-сайтов, репозитории git, сервер jabber и почта.
«Риск» заключается в том, что любому процессу на машине будет разрешено инициировать сетевое соединение и отправлять сетевые пакеты.
Это означает, что на сервере нет ничего, что могло бы заблокировать любого пользователя, законного или нет, ни какой-либо процесс от потенциальной попытки подключения любого другого сетевого устройства в вашей собственной сети или, возможно, во всем Интернете.
Часто это не является большой проблемой, поскольку считается, что удаленные системы в первую очередь отвечают за ограничение входящего трафика, и у вас могут быть политики брандмауэра уже в критических точках вашей сети.
Установка любой другой политики по умолчанию, например REJECT, означает, что вам нужно будет явно разрешить все легитимные потоки трафика, что требует глубокого понимания вашей системы и всех приложений и зависимостей, которые работают на вашем сервере. Часто это означает значительную административную нагрузку.
Преимущество, конечно же, заключается в том, что потенциальное влияние неправильно настроенного приложения смягчается, что может затруднить злоупотребление системой, хотя на полностью скомпрометированной системе злоумышленник всегда может просто отключить программный брандмауэр ...
С точки зрения безопасности это, конечно, довольно просто: все, что явно не разрешено, должно быть запрещено. Это имеет смысл в среде с высокими требованиями к безопасности и, например, на выделенном межсетевом экране, на многоцелевом сервере сделать это может быть непомерно сложно.
Установка политики вывода не остановит попытки взлома, но может немного помочь против злонамеренных или просто невежественных пользователей, которые могут войти в систему. И это может помочь смягчить последствия атаки, особенно ботной.
Например, вы можете оказаться в ситуации, когда вам нужно позволить некоторым пользователям на машине, которым вы действительно не доверяете - вы не думаете, что они злонамеренные, а скорее некомпетентные. (Как мой клиент, который хотел отдельную директорию для своего 16-летнего сына, чтобы разместить его собственный веб-сайт, и который обязательный его сын должен иметь доступ по ssh. Или ваш начальник, который настаивает, чтобы вы предоставили новому стажёру доступ по ssh. Или ....). У них нет root-доступа (и они недостаточно умны, чтобы использовать некоторые эксплойты local-user-gets-root-exploit), поэтому они не могут сильно повредить, но блокировка всего выходного трафика, по крайней мере, не позволяет им установить TeamViewer или аналогичное программное обеспечение, которое открывает соединения изнутри, чтобы позволить другим IP-адресам подключаться.
Кроме того, если ваш сервер каким-то образом станет частью ботнета, отбрасывание исходящих пакетов предотвратит рассылку спама и DDOS-атак с вашего сервера. Конечно, при установке бота ущерб уже нанесен, но, по крайней мере, вы не будете платить за пропускную способность. если ты иметь для отправки почты с вашего сервера используйте выделенный почтовый хост и разрешите порт 25 этому хосту только; боты, как правило, недостаточно умен, чтобы направлять свой спам через этот почтовый хост.
Я регистрировал вывод, а также отклонял его и проверял журналы один раз в неделю (или один раз в день, или попросил программу мониторинга проверить увеличение размера файла журнала, или ... в зависимости от ваших требований). Это поможет вам: а) узнать, что вы должны разблокировать, если у приложения есть действительные запросы, которые блокируются, и б) узнать, что вас взломали, если вы видите много разорванных соединений в журнале OUTPUT.