(перенесено из SO)
У меня есть iptables, защищающий sip-сервер. Он блокирует все IP-адреса, кроме тех, которые я специально открыл, и, похоже, работает почти для всех. Я тестировал множество IP-адресов, которые не внесены в белый список, и все они отбрасываются, как должны.
НО, я поймал "хакера", который, кажется, может обойти правила iptables. Его зондирование INVITE проходит, и я понятия не имею, как и что это вообще было возможно. За 10 лет такого не видел.
Я полагаю, это должно быть что-то, что я сделал, но я этого не вижу.
iptables, созданные следующим образом (MYIP определен вверху - отредактирован):
iptables -F
iptables -X
iptables -N ALLOWEDSIP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -d $MYIP --dport 22 -j ACCEPT
iptables -t filter -A INPUT -j ALLOWEDSIP
# This is my white list.
iptables -A ALLOWEDSIP -j RETURN
Теперь, когда в РАЗРЕШЕННОМ СИПЕ НИЧЕГО нет, все, что я должен делать, это использовать SSH (что я могу). Если я кидаю на него звонки, они все отбрасываются. Но wirehark показывает мне это (мой ip отредактирован):
89.163.146.25 -> x.x.x.x SIP/SDP 805 Request: INVITE sip:521088972597572280@x.x.x.x |
x.x.x.x -> 89.163.146.25 SIP 417 Status: 100 Giving a try |
x.x.x.x -> 89.163.146.25 SIP 875 Status: 407 Proxy Authentication Required |
Его вызовы попали в мой переключатель, и хотя ACL в конечном итоге их отклонил, они никогда не должны были попасть туда. Больше ничего не проходит. Выдергивает волосы. Кто-нибудь знает?
Для полноты, вот результат iptables -L:
# iptables -L --line-numbers -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 10 640 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
2 0 0 ACCEPT all -- lo any anywhere anywhere
3 0 0 ACCEPT tcp -- any any anywhere <redacted>.com tcp dpt:6928
4 0 0 ALLOWEDSIP all -- any any anywhere anywhere
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 6 packets, 544 bytes)
num pkts bytes target prot opt in out source destination
Chain ALLOWEDSIP (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 RETURN all -- any any anywhere anywhere
РЕДАКТИРОВАТЬ: только что видел это из wirehark. Могут ли они сделать что-то ужасное, например, получить статус по-другому, а не играть по установленному правилу? Может они играют на какой-нибудь дыре в СВЯЗАННОМ?
89.163.146.25 -> <redacted> RTCP 806 Source port: tag-pm Destination port: sip
РЕДАКТИРОВАТЬ 2: UDP является ключевым здесь. Когда я настроил OpenSIPS на прослушивание только TCP, проблема, похоже, исчезла. Ни одна из их попыток больше не проходит, хотя они отправляют больше сообщений типа «tag-pm». Это не объясняет, почему пакеты даже доходят до OpenIP. iptables должен был сначала остановить их. Хотел бы знать, что я здесь сделал не так.
РЕДАКТИРОВАТЬ 3: Если я удалю СВЯЗАННЫЕ, я перестану им отвечать, так что это как-то связано с этим. Но я думаю, мне нужно родство. Какие-нибудь советы по обходным путям?
Единственное правдоподобное объяснение того, как это может работать, заключается в том, что датаграммы UDP каким-то образом проходят --state ESTABLISHED,RELATED.
Учитывая, что UDP является протоколом без сохранения состояния, я сомневаюсь, что state модуль имеет эффективное отслеживание над ним.
Чтобы решить эту проблему, я бы ограничил проверку состояния протоколом TCP:
-A INPUT -m tcp -m state -p tcp --state ESTABLISHED,RELATED -j ACCEPT`
И предварительный фильтр ALLOWEDSIP с протоколом UDP (а также желательно с портом назначения):
iptables -t filter -A INPUT -m udp -p udp --dport 5060 -j ALLOWEDSIP
Вы можете использовать nullroute. Это должно обойти iptables.
route add 89.163.146.25 gw 127.0.0.1 lo
Проверь это
netstat -nr
ИЛИ
route -n