Назад | Перейти на главную страницу

Linux: Как настроить TCP-оболочки в /etc/hosts.allow для процессов, запускаемых вручную?

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

Мы не используем SELinux или IPtables внутри домена.

Одна вещь, которую я планирую сделать, - это ограничить доступ к серверам в домене определенными службами с помощью TCP-оболочек (редактирование /etc/hosts.allow/ и hosts.deny).

Из Официальная документация CentOS сайт:

Использование TCP Wrappers

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

echo "ВСЕ: ВСЕ" >> /etc/hosts.deny

echo "sshd: ALL" >> /etc/hosts.allow

У меня вопрос:

Мне нужен сервер для обслуживания запросов на портах:

1099 (Java RMI) 
5666 (NRPE)
22 (SSH)

Java RMI запускается вручную, а не демоном, и он правильно указан в /etc/services:

[root@srv4 scripts]# grep 1099 /etc/services
rmiregistry 1099/tcp            # RMI Registry

Кроме того, NRPE настроен для работы под xinetd, а не с ручным демоном.

Так как бы мой hosts.allow линии как бы выглядели?

В документации CentOS 5 есть хорошая статья для xinetd*. Что-то вроде

hosts.allow

xinetd: .example.com

hosts.deny

xinetd: ALL

должен разрешить все хосты в example.com и запретить доступ ко всему остальному для процессов, контролируемых xinetd. Порядок важен, файлы сканируются в порядке разрешить, запретить, и выигрывает первое совпадение.

Быстрый взгляд на вывод ldd /usr/bin/java показывает, что java не поддерживает libwrap, поэтому вы не можете использовать tcpwrappers напрямую с ним. Возможно, обертывание в xinetd сработает.

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

*Он может быть и для более поздних версий, но вряд ли он будет сильно отличаться