У меня есть сервер CentOS 6, которому нужен rsh-доступ к одному из наших старых устаревших серверов, который не поддерживает ssh.
RSH подключается к порту 514 на удаленных серверах, который затем создает еще одно подключение к клиенту через порт между 512-1023. Мой текущий уровень навыков брандмауэра - «порт открыт / порт закрыт», и открытие всех из них не оставит много брандмауэра. Какой самый строгий способ разрешить исходящие соединения RSH?
Я бы ограничил входящий поток от ряда серверов, используя iptables -A INPUT --src {IP address or range}/{netmask} -m state --state NEW -m tcp -p tcp --dport 514:1023 -j ACCEPT.
Затем вы можете ограничить диапазоны входящих портов для правильных серверов.
Если вам не нужно ограничивать исходящие данные с определенного сервера, я бы не стал беспокоиться о настройке исходящих правил.
Я использую webmin для настройки своих основных правил, затем копирую их вручную (это быстрее и избавляет меня от поиска всей информации, которую я не использую регулярно). Webmin поддерживает всевозможные правила - входящие, исходящие и исключающие. Вы можете настроить webmin в тестовом окне, затем отредактировать, затем написать правила и скопировать их на соответствующий сервер.
В Ubuntu 18.04 с установленными пакетами rsh-redone-client / server rsh / rlogin на другой хост в локальной сети (под управлением CentOS 6) блокировался в течение долгого времени (около 30 секунд), пока я не открыл порт 113 (auth) в локальной сети. брандмауэр для входящих подключений из LAN. Я не уверен, как это было в конечном итоге (после этих ~ 30 секунд) рабочее событие без открытия порта 113. Возможно, сервер все равно разрешил соединение через некоторое время.
Некоторые старые службы включают функцию, которая будет отправлять запрос имени пользователя обратно на клиентский хост при каждом входящем соединении. Услуги, которые я видел, чтобы включить эту функцию:
Запрос имени пользователя имеет целевой TCP-порт 113, первоначально известный как auth порт, позже переименованный в ident поскольку было признано, что это не имеет ничего общего с реальной аутентификацией. На заре Интернета, когда большинство подключенных к TCP / IP систем были многопользовательскими системами Unix, эта служба принимала в качестве входных данных IP-адрес и номера портов источника + назначения другого TCP-соединения и просматривала клиентскую сторону. имя пользователя, связанное с подключением.
Сегодня такое слепо доверчивое и легко подделываемое раскрытие имен пользователей явно нехорошо.
В большинстве случаев служба, ident/auth query примет, что информация недоступна, но вы должны либо принять, либо отклонить запрос: если вы просто отбросите его, пользователь увидит задержки подключения до 30 секунд, пока серверная сторона не откажется. Оптимальное отклонение будет аналогично тому, что произойдет, если на хосте нет брандмауэра, но нет службы, прослушивающей TCP-порт 113, то есть пакета сброса TCP.
Для правил iptables это означает, что вы должны использовать REJECT правило, а не DROP для TCP-порта 113, если вы используете какие-либо устаревшие службы, которые все еще отправляют ident запросы.
Что-то вроде этого должно отклонить ident запросы таким образом, чтобы минимизировать задержки:
iptables -I INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset
Если вы опасаетесь, что кто-то может злоупотребить этим, чтобы создать атаку отказа в обслуживании, вы можете добавить правило ограничения скорости для порта 113 TCP перед этим правилом. Но я понимаю, что самые современные сетевые драйверы уже будут обрабатывать отправку ответов TCP Reset как задачу с очень низким приоритетом по умолчанию, так что это может быть не очень значительный риск.