Начиная с 5-го релиза (вроде с 5.1), чудо-инженеры авайя взяли да и закрыли трафик на сервисном порту медиасервера. Причем не оставили возможность управлять этими правилами из web-интерфейса станции, что выглядит очень глупо и вообще не понятно зачем все эти манипуляции применялись. Как ответила служба глобальной поддержки, этим они закрыли уязвимость в станции. Хотя на логичный вопрос, в чем была уязвимость, если это сервисный порт, к которому подключается компьютер инсталлятора, они ответить не смогли:) Пробовал получить у них пачт, чтобы снять ограничения на сервисный порт - результатов не дало, мой запрос бессмыслено бороздил несколько месяцев из одной службы поддержки авайя в другую. В итоге пришлось разбираться самому..

 

Я использую сервисный порт медиасервера для управления станцией, синхронизации времени и через него же принимаю аварийные SNMP Trap пакеты. Поэтому мне необходимо открыть поддержку исходящих UDP пакетов snmptrap и ntp.

Все манипуляции вы выполняете на свой страх и риск, авайцы подобных изменений не оценят..

1) правим файл настроек iptables:

vi /opt/ecs/sbin/ip_fw
....
# laptop interface -- allow only necessary traffic
...
# NEW input services port rules
...
# NEW output services port rules
add_fw_rule("$HEAD -m state --state RELATED,ESTABLISHED -j ACCEPT");
add_fw_rule("$HEAD $FLAG ftp $TAIL");
add_fw_rule("$HEAD $UDP_FLAG tftp $TAIL");
add_fw_rule("$HEAD $FLAG ssh $TAIL");
add_fw_rule("$HEAD $FLAG telnet $TAIL");
add_fw_rule("$HEAD $FLAG def-sat $TAIL");
add_fw_rule("$HEAD $FLAG secure-sat $TAIL");
add_fw_rule("$HEAD $FLAG 2222 $TAIL");
add_fw_rule("$HEAD $FLAG http $TAIL");
add_fw_rule("$HEAD $FLAG https $TAIL");
add_fw_rule("$HEAD -p icmp --icmp-type echo-request -j ACCEPT");

# CHANGE BEGIN
add_fw_rule("$HEAD $UDP_FLAG snmptrap $TAIL");
add_fw_rule("$HEAD $UDP_FLAG ntp $TAIL");
# CHANGE END

}

# ppp link
....

2) заходим через web на сервер, прописываем маршрут на адрес приема SNMP через сервисный порт станции

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

4) проверяем отправку аварийного сообщения.

SHELL:>snmptrap -c public -v 2c 10.10.10.10 "" 1.3.3.3.3.3.3 1.2.2.2.2.2.2 s "Test SNMP TRAP"

Если в результате данной команды вы получили: snmptrap: Failure in sendto (Operation not permitted), значит вы что-то сделали не так:)

Log in to comment