(перенесено из SO)
У меня есть iptables, защищающий sip-сервер. Он блокирует все IP-адреса, кроме тех, которые я специально открыл, и, кажется, работает почти для всех. Я проверил множество IP-адресов, которые не включены в белый список, и все они отброшены, как и должно быть.
НО, я подобрал «хакера», который, кажется, в состоянии обойти правила iptables. Его зондирующие ПРИГЛАШЕНИЯ проходят через это, и я понятия не имею, как, или что это вообще было возможно. В 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 в (что я могу). Если я бросаю вызовы на них, они все сбрасываются. Но Wireshark показывает мне это (мой 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
РЕДАКТИРОВАТЬ: только что видел это из Wireshark. Могут ли они делать что-то ужасное, например, установить что-то другое, чем играть по установленному правилу? Может они играют на какой-то дыре в СВЯЗАННЫХ?
89.163.146.25 -> <redacted> RTCP 806 Source port: tag-pm Destination port: sip
РЕДАКТИРОВАТЬ 2: UDP является ключом здесь. Когда я настраиваю OpenSIPS на прослушивание только TCP, проблема, похоже, исчезает. Ни одна из их попыток больше не проходит, хотя они отправляют больше этих сообщений "tag-pm". Не объясняет, почему пакеты даже попадают в opensips. Iptables должен был остановить их в первую очередь. Хотелось бы узнать, что я здесь не так сделал.
РЕДАКТИРОВАТЬ 3: Если я удаляю СВЯЗАННЫЕ, я прекращаю отвечать на них, так что это как-то связано с этим. Но я думаю, что мне нужно иметь отношение. Любые советы по обходным путям?
ESTABLISHED
должен работать для UDP. Похоже, что поток пакетов и принимает ответы на (исходящие) запросы. У ваших "хакеров" есть статические IP-адреса? ;-) Если это так, проверьте / proc / net / nf_conntrack, чтобы увидеть, что таблица состояний содержит о них, когда они в настоящее время / не подключены ...RELATED
это более сложная вещь ... Не знаю, что она делает для SIP , Имеет лиmodprobe
возможно показать модуль ipt_sip или что - то нагружать , что будет делать «волшебные» вещи?RELATED
до-p icmp
. Может быть, это решает проблему (или является подходящим решением, которое не требует от вас читать о помощниках conntrack).Ответы:
Единственное правдоподобное объяснение того, как это может работать, состоит в том, что нарушающие дейтаграммы UDP как-то проходят
--state ESTABLISHED,RELATED
.Учитывая, что UDP является протоколом без сохранения состояния, я сомневаюсь, что
state
модуль имеет эффективное отслеживание по нему.Чтобы разобраться в проблеме, я бы ограничил проверку состояния протоколом TCP следующим образом:
И предварительный фильтр
ALLOWEDSIP
с протоколом UDP (и желательно, с портом назначения тоже):источник
Вы могли бы nullroute. Это должно обойти iptables.
Проверь это
ИЛИ
источник