Хакер в обход iptables


9

(перенесено из 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: Если я удаляю СВЯЗАННЫЕ, я прекращаю отвечать на них, так что это как-то связано с этим. Но я думаю, что мне нужно иметь отношение. Любые советы по обходным путям?


1
ESTABLISHEDдолжен работать для UDP. Похоже, что поток пакетов и принимает ответы на (исходящие) запросы. У ваших "хакеров" есть статические IP-адреса? ;-) Если это так, проверьте / proc / net / nf_conntrack, чтобы увидеть, что таблица состояний содержит о них, когда они в настоящее время / не подключены ... RELATEDэто более сложная вещь ... Не знаю, что она делает для SIP , Имеет ли modprobeвозможно показать модуль ipt_sip или что - то нагружать , что будет делать «волшебные» вещи?
Марки

@Marki - спасибо за этот совет. / proc / net / nf_conntrack не существует (centos 7), поэтому мне нужно выяснить, что / почему / где.
Дэвид Уайли

2
«conntrack-tools» - это то, что можно установить из репозитория, а затем запустить «conntrack -L», кажется, для их перечисления. Посмотрим, что это даст. Типично, однако, он остановился. Надеюсь, просто пауза.
Дэвид Уайли

1
Если возможно: попробуйте ограничиться RELATEDдо -p icmp. Может быть, это решает проблему (или является подходящим решением, которое не требует от вас читать о помощниках conntrack).
банально

1
Вы запутались, добавив цепочку. Если цепочки ACCEPT проверены перед вашим пользовательским разрешением ALLOWEDSIP, то разрешение ALLOWEDSIP может оказаться бесполезным.
Сверхразум

Ответы:


1

Единственное правдоподобное объяснение того, как это может работать, состоит в том, что нарушающие дейтаграммы 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

-2

Вы могли бы nullroute. Это должно обойти iptables.

route add 89.163.146.25 gw 127.0.0.1 lo

Проверь это

netstat -nr

ИЛИ

route -n

Он хочет заделать дыру против любого нового атакующего, а не просто блокировать этого.
Зденек
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.