Обход систем межсетевых защит используя несоответствия в реализациях TCP/IP протокола

Пауль Старзетз

Существуют некоторые несоответствия в реализациях TCP/IP протокола в различных операционных системах. Эта особенность в течение долгого времени используется для снятия отпечатков операционной системы, однако до сих пор никто не исследовал воздействие на защиту различных TCP/IP выполнений. Пауль Старзетз провел несколько экспериментов с открытой семантикой TCP/IP-соединений, которая очень важна для безопасности сетевых систем. Обнаруженные недостатки могут воздействовать на работу межсетевых защит и пакетных фильтров, и могут приводить к серьезным проблемам защиты.

Стек протокола TCP/IP использует три шага для установления TCP подключения. Подключение может быть открыто, посылая пакет синхронизации (synchronization packet, SYN) к службе на определенном порту. Хост ответит пакетом подтверждения синхронизации (acknowledgment packet, ASK), который, в свою очередь, должен быть признан запрашиваемым хостом. Тогда подключение считается открытым (на транспортном уровне), и эти два хоста могут обмениваться данными.

Эти три шага установления связи – основная часть подключений, использующих TCP протокол. Большинство пакетных фильтров пытаются предотвратить эти три шага установления связи от завершения, чтобы защитить внутреннюю/корпоративную сеть от подключений с внешней стороны. Межсетевые защиты, прослеживающие состояние подключения (statefull), имеют более сложный механизм работы.

Пауль Старзетз нашел очень неоднозначное поведение выполнения TCP/IP при выполнении исследования стадии запроса подключения. Ниже опубликованы результаты для различных OS, однако список нельзя считать завершенным. Для исследования использовался инструмент NemesisTCP, для генерации трафика и tcpdump, для перехвата пакетов.

• Нормальное поведение (для всех OS) выглядит примерно так:

14:18:00.595517 192.168.1.184.12345 > 192.168.1.111.9999: S 420:420(0) win 
512 (DF) [tos 0x18]
14:18:00.595731 192.168.1.111.9999 > 192.168.1.184.12345: S 
1679763291:1679763291(0) ack 421 win 5840 <mss 1460> (DF)

Первый хост посылает SYN пакет от 12345 порта к сервису на 9999 порту и получает SYN, ACK.

• Linux 2.4.19

Экспертиза исходного кода TCP механизма показывает, что TCP подключение может быть открыто любой комбинацией TCP флажков, с установленным SYN битом и сброшенным ACK битом. Например, мы можем открыть TCP подключение, посылая поддельный SYN, RST пакет:

 
14:25:43.888897 192.168.1.184.12345 > 192.168.1.111.9999: SR 420:420(0) 
win 512 (DF) [tos 0x18]
14:25:43.889143 192.168.1.111.9999 > 192.168.1.184.12345: S 
2168208394:2168208394(0) ack 421 win 5840 <mss 1460> (DF)

Или используя 'Christmas packet', со всеми установленными TCP флажками (кроме ACK флажка) :

 
14:30:46.341732 192.168.1.184.12345 > 192.168.1.111.9999: SFRP 420:420(0) 
win 512 urg 8 (DF) [tos 0x18]
14:30:46.342444 192.168.1.111.9999 > 192.168.1.184.12345: S 
2492223280:2492223280(0) ack 421 win 5840 <mss 1460> (DF)

Также работает и с SYN, FIN пакетами.

• Solaris 5.8

Здесь Пауль Старзетз успешно послал SYN, FIN пакеты:

14:33:24.549246 192.168.1.184.12345 > 192.168.1.84.9999: SF 420:420(0) win 
512 (DF) [tos 0x18]
14:33:24.549757 192.168.1.84.9999 > 192.168.1.184.12345: S 
913533039:913533039(0) ack 421 win 24656 <mss 1460> (DF)

Или SYN, FIN, PSH пакеты без полезного груза

14:35:14.398346 192.168.1.184.12345 > 192.168.1.84.9999: SFP 420:420(0) 
win 512 (DF) [tos 0x18]
14:35:14.398801 192.168.1.84.9999 > 192.168.1.184.12345: S 
940377913:940377913(0) ack 421 win 24656 <mss 1460> (DF)

Другие комбинации, не вызывают состояние SynSent в TCP/IP стеке.

• FreeBSD 4.5

Здесь Пауль Старзетз также успешно послал SYN, FIN пакеты:

14:47:21.558541 192.168.1.184.12345 > 192.168.1.104.9999: SF 420:420(0) 
win 512 (DF) [tos 0x18]
14:47:21.558719 192.168.1.104.9999 > 192.168.1.184.12345: S 
1333327436:1333327436(0) ack 421 win 65535 <mss 1460>

Также сработали другие комбинации, в которых не объединены RST и/или ACK флажки с SYN:

 
14:48:11.678246 192.168.1.184.12345 > 192.168.1.104.9999: SP 420:420(0) 
win 512 (DF) [tos 0x18]
14:48:11.678366 192.168.1.104.9999 > 192.168.1.184.12345: S 
1714046856:1714046856(0) ack 421 win 65535 <mss 1460>

• Windows NT 4.0

Как в случае BSD мы можем открыть подключения, используя любую комбинацию TCP флажков, пока мы не установили флажок ACK и/или RST:

 
14:59:46.315126 192.168.1.184.12345 > 192.168.1.17.9999: SF 420:420(0) win 
512 (DF) [tos 0x18]
14:59:46.315566 192.168.1.17.9999 > 192.168.1.184.12345: S 
15062452:15062452(0) ack 421 win 8576 <mss 1460> (DF)

Другие системы скорее всего будут вести себя подобным образом.

Приведенные методы могут использоваться для обхода систем межсетевых защит, которые не способны прослеживать состояние подключения, и использующих методы фильтрации, основанные на анализе определенного набора TCP флажков.

Администраторы устройств межсетевой защиты должны установить дополнительные правила фильтрации, чтобы не пропускать поддельные TCP пакеты, как упомянуто выше. Например, на системах, использующих iptables, можно использовать следующие правила:

iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j LOG 
-m limit --limit 10/m --log-level "LOGLEVEL" --log-prefix="bogus packet"
$IP -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j DROP

И так далее для других комбинаций флажков.

Для CISCO систем:

ip access-list extended filterout permit tcp 219.80.71.0 0.0.0.255 any 
reflect tcp-state
ip access-list extended filterin evaluate tcp-state