The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Для тех, кто доверяет ICMP трафику..."
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"Для тех, кто доверяет ICMP трафику..."
Сообщение от proff Искать по авторуВ закладки on 26-Дек-02, 17:50  (MSK)
Привет!

Только сегодня "стал свидетелем" DoS взлома, произошедшего в районной сети, к которой подключен мой домашний компьютер и тут в форуме (тред "ipfw rules", ссылка http://www.opennet.ru/openforum//vsluhforumID1/24530.html) вижу такую вещь:

----skipped-----
00200    1729    124370 allow icmp from any to any
----skipped-----

Так много говорят и пишут про Smurf взломы, но народ с завидным постоянством продолжает упорно доверять любому ICMP трафику...

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

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

С наступающим Новым Годом, Страна! ;-)))

--------------------------------------------

Описание атаки:

Симптомы свидетельствуют, что это известная DoS-атака Smurf (отказ в обслуживании в следствие перерасхода системных ресурсов из-за огромного наплыва ICMP Echo Reply сообщений).

Жертва:

Атака была направлена против хоста host.under.attack.ru.

Соотношения:

С IP 10.2.2.20 наша сеть сканировалась на предмет выяснения дополнительной информации.

Фрагмент лога брендмауэра хоста my.home.host.ru, находящегося в подсети host.under.attack.ru, свидетельствующий о сборе информации:

Dec 24 23:58:55 myserver /kernel: ipfw: 65200 Deny ICMP:17.0 10.2.2.20 my.home.host.ru in via ed0 # address mask request
Dec 24 23:58:55 myserver /kernel: ipfw: 65200 Deny ICMP:13.0 10.2.2.20 my.home.host.ru in via ed0 # timestamp request
Dec 24 23:58:55 myserver /kernel: ipfw: 65200 Deny ICMP:15.0 10.2.2.20 my.home.host.ru in via ed0 # information request

После того, как какой-то хост в нашей подсети предоставил запрашивающему маску подсети, у него появилась возможность организовать атаку DoS, подделав адрес отправителя для того, чтобы ответы на широковещательные запросы отправлялись на поддельный адрес (т.е. на адрес жертвы).

Вероятнее всего хост host.under.attack.ru, против которого была направлена атака, и был хостом, предоставившим информацию по этим запросам.

Вот фрагмент лога, свидетельствующего об организации атаки:

Dec 25 23:52:45 myserver /kernel: ipfw: 65200 Deny ICMP:8.0 host.under.attack.ru my.subnet.broadcast.ip in via ed0
Dec 25 23:53:52 myserver /kernel: ipfw: 65200 Deny ICMP:8.0 host.under.attack.ru my.subnet.broadcast.ip in via ed0

Расшифровка кодов ICMP сообщений:

echo reply (0), destination unreachable (3), source quench (4), redirect
(5), echo request (8), router adver-tisement (9), router solicitation(10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18).

Подлог IP-адреса отправителя:

Не смотря на то, что хоcт 10.2.2.20 при сканировании должен был получать ответы от сканируемых систем, это не настоящий адрес нарушителя.
Здесь возможны два варианта:
1. Это адрес анонимного прокси, который был использован для сокрытия источника угрозы
2. Либо была задействована схема "кто-то посреди", и адрес отправителя на самом деле поддельный.

На мой взгляд наиболее вероятен пункт 2, т.к. адрес 10.2.2.20 входит в диапазон зарезервированных адресов, отведенных для частных сетей.

Выводы:

1. Взлом произведен на высоком техническом уровне, что свидетельствует о высокой потенциальной угрозе сканируемой сети.
2. Необходимо принимать контрмеры, для повышения защиты сети и рабочих станций.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "RE: Для тех, кто доверяет ICMP трафику..."
Сообщение от trin emailИскать по авторуВ закладки on 26-Дек-02, 18:20  (MSK)
В целом, все правильно. Только где видно "высокий технический уровень" взлома? Вероятнее всего, skript kiddie развлекался со скачанной из Инета программкой для огранизации атаки такого типа :) А то, что защищаться надо - это без вопросов. Любой входящий трафик, который не является прямым ответом на трафик изнутри сети (при условии гарантии отсутствия троянов и закладок на защищенных клиентах) будет представлять опасность. Правда, как защитить городскую сеть, где по умолчанию д.б. предоставлен нефильтрованный доступ? Если только поставить какой-нибудь IDS и блокировать атаки через него. Но тут, как в случае борьбы со спамом, можно с грязной водой выплеснуть ребенка :)
  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "RE: Для тех, кто доверяет ICMP трафику..."
Сообщение от lavr emailИскать по авторуВ закладки on 26-Дек-02, 18:40  (MSK)
>Привет!
>
>Только сегодня "стал свидетелем" DoS взлома, произошедшего в районной сети, к которой
>подключен мой домашний компьютер и тут в форуме (тред "ipfw rules",
>ссылка http://www.opennet.ru/openforum//vsluhforumID1/24530.html) вижу такую вещь:
>
>----skipped-----
>00200    1729    124370 allow icmp from
>any to any
>----skipped-----
>
>Так много говорят и пишут про Smurf взломы, но народ с завидным
>постоянством продолжает упорно доверять любому ICMP трафику...
>
>Описанная здесь атака -- один из примеров множества атак, совершающихся в последнее
>время.
>Пугает то, что количество попыток взлома в последнее время растет в арифметической
>прогрессии.
>Мало того, что подобные действия злоумышленников повышают вероятность взлома и разрушения систем
>пользователей, ресурсы домашних сетей, и без того дефицитные, расходуются на злонамеренный
>трафик.
>
>Надеюсь, что время, затраченное на описание взлома, не пропадет даром, а само
>описание станет кому-нибудь стимулом для повышения защищенности своих локальных сетей и
>рабочих станций...
>
>С наступающим Новым Годом, Страна! ;-)))
>
>--------------------------------------------
>
>Описание атаки:
>
>Симптомы свидетельствуют, что это известная DoS-атака Smurf (отказ в обслуживании в следствие
>перерасхода системных ресурсов из-за огромного наплыва ICMP Echo Reply сообщений).
>
>Жертва:
>
>Атака была направлена против хоста host.under.attack.ru.
>
>Соотношения:
>
>С IP 10.2.2.20 наша сеть сканировалась на предмет выяснения дополнительной информации.
>
>Фрагмент лога брендмауэра хоста my.home.host.ru, находящегося в подсети host.under.attack.ru, свидетельствующий о сборе
>информации:
>
>Dec 24 23:58:55 myserver /kernel: ipfw: 65200 Deny ICMP:17.0 10.2.2.20 my.home.host.ru in
>via ed0 # address mask request
>Dec 24 23:58:55 myserver /kernel: ipfw: 65200 Deny ICMP:13.0 10.2.2.20 my.home.host.ru in
>via ed0 # timestamp request
>Dec 24 23:58:55 myserver /kernel: ipfw: 65200 Deny ICMP:15.0 10.2.2.20 my.home.host.ru in
>via ed0 # information request
>
>После того, как какой-то хост в нашей подсети предоставил запрашивающему маску подсети,
>у него появилась возможность организовать атаку DoS, подделав адрес отправителя для
>того, чтобы ответы на широковещательные запросы отправлялись на поддельный адрес (т.е.
>на адрес жертвы).
>
>Вероятнее всего хост host.under.attack.ru, против которого была направлена атака, и был хостом,
>предоставившим информацию по этим запросам.
>
>Вот фрагмент лога, свидетельствующего об организации атаки:
>
>Dec 25 23:52:45 myserver /kernel: ipfw: 65200 Deny ICMP:8.0 host.under.attack.ru my.subnet.broadcast.ip in
>via ed0
>Dec 25 23:53:52 myserver /kernel: ipfw: 65200 Deny ICMP:8.0 host.under.attack.ru my.subnet.broadcast.ip in
>via ed0
>
>Расшифровка кодов ICMP сообщений:
>
>echo reply (0), destination unreachable (3), source quench (4), redirect
>(5), echo request (8), router adver-tisement (9), router solicitation(10), time-to-live exceeded (11),
>IP header bad (12), timestamp request (13), timestamp reply (14), information
>request (15), information reply (16), address mask request (17) and address
>mask reply (18).
>
>Подлог IP-адреса отправителя:
>
>Не смотря на то, что хоcт 10.2.2.20 при сканировании должен был получать
>ответы от сканируемых систем, это не настоящий адрес нарушителя.
>Здесь возможны два варианта:
>1. Это адрес анонимного прокси, который был использован для сокрытия источника угрозы
>
>2. Либо была задействована схема "кто-то посреди", и адрес отправителя на самом
>деле поддельный.
>
>На мой взгляд наиболее вероятен пункт 2, т.к. адрес 10.2.2.20 входит в
>диапазон зарезервированных адресов, отведенных для частных сетей.
>
>Выводы:
>
>1. Взлом произведен на высоком техническом уровне, что свидетельствует о высокой потенциальной
>угрозе сканируемой сети.
>2. Необходимо принимать контрмеры, для повышения защиты сети и рабочих станций.

фильтровать ВСЕ icmp пакеты просто неразумно.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "RE: Для тех, кто доверяет ICMP трафику..."
Сообщение от xlino emailИскать по авторуВ закладки on 26-Дек-02, 18:50  (MSK)
>
>фильтровать ВСЕ icmp пакеты просто неразумно.

А если и разумно где блин взять рекомендации какому сервису чего надо из icmp протокола. Попытался при настройке ipf оставить минимум сразу все перестало работать:(((

  Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "RE: Для тех, кто доверяет ICMP трафику..."
Сообщение от Nikola_SPb Искать по авторуВ закладки on 27-Дек-02, 05:06  (MSK)
2 lavr:
Если я не ошибаюсь :) , упоминания о фильтации всех ICMP пакетов речи не было. Товарищ proff лишь заметил, что админы очень часто оставляют ICMP без внимания.

2 xlino:
Подразумевается, что изначально ядро сконфигурировано без
options IPFIREWALL_DEFAULT_TO_ACCEPT
Также подразумевается, что перед приведенными правилами _не_ будет строки типа:
$(fwcmd) allow all from any to any # :)

-----------------------
# расшифровку типов сообщений смотри в первом посте
${fwcmd} add 00300 allow icmp from any to $внешний_IP in via $внешний_интерфейс icmptype 0,3,4,11,12
${fwcmd} add 00301 allow icmp from $внешний_IP to any out via $внешний_интерфейс icmptype 3,8,12

# вот над этими двумя строками подумай, прежде чем включать в рабочий скрипт: они позволяют провайдеру пинговать тебя.
# если служебные айпишники (для своих сотрудников) провайдер использует из своего общего адресного пространства (в
# котором находятся и его собственные клиенты, помимо тебя), то лучше не включать.
${fwcmd} add 00302 allow icmp from $внешний_IP to $IP_адрес_провайдера out via $внешний_интерфейс icmptype 0,3,11
${fwcmd} add 00303 allow icmp from $IP_адрес_провайдера to $внешний_IP in via $внешний_интерфейс icmptype 8

# стоит или не стоит выпускать из сети фрагментированные ICMP-пакеты из своей сети, решать тебе
${fwcmd} add 00304 allow icmp from $внешний_IP to any out via $внешний_интерфейс frag

${fwcmd} add 00305 deny log icmp from any to 255.255.255.255 in via $внешний_интерфейс
${fwcmd} add 00306 reject log icmp from any to 255.255.255.255 out via $внешний_интерфейс

${fwcmd} add 00306 deny log icmp from any to $маска_твоей_сети in via $внешний_интерфейс
${fwcmd} add 00307 reject log icmp from any to $маска_твоей_сети out via $внешний_интерфейс

${fwcmd} add 00308 deny log icmp from any to $твоя_сеть in via $внешний_интерфейс
${fwcmd} add 00309 reject log icmp from any to $твоя_сеть out via $внешний_интерфейс

-----------------------


2 ALL: C наступающим!

P.S. Также надеюсь, что эта писанина пригодится кому-нибудь :)

  Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "RE: Для тех, кто доверяет ICMP трафику..."
Сообщение от globus emailИскать по авторуВ закладки on 27-Дек-02, 08:06  (MSK)
Для предотвращения описанной атаки вполне хватило бы запретить доступ на внешний интерфейс из приватных сетей  (RFC1918)
  Рекомендовать в FAQ | Cообщить модератору | Наверх

6. "RE: Для тех, кто доверяет ICMP трафику..."
Сообщение от Dawnshade emailИскать по авторуВ закладки on 27-Дек-02, 09:41  (MSK)
>Для предотвращения описанной атаки вполне хватило бы запретить доступ на внешний интерфейс
>из приватных сетей  (RFC1918)

Кстати, да. В rc.firewall даже об этом написано.
И еще: формулировка "DoS взлом" некорректна по определению!

  Рекомендовать в FAQ | Cообщить модератору | Наверх

7. "RE: Для тех, кто доверяет ICMP трафику..."
Сообщение от lavr emailИскать по авторуВ закладки on 27-Дек-02, 15:01  (MSK)
>2 lavr:
>Если я не ошибаюсь :) , упоминания о фильтации всех ICMP пакетов
>речи не было. Товарищ proff лишь заметил, что админы очень часто
>оставляют ICMP без внимания.

sorry, истинно так.

>2 xlino:
>Подразумевается, что изначально ядро сконфигурировано без
>options IPFIREWALL_DEFAULT_TO_ACCEPT
>Также подразумевается, что перед приведенными правилами _не_ будет строки типа:
>$(fwcmd) allow all from any to any # :)
>
>-----------------------
># расшифровку типов сообщений смотри в первом посте
>${fwcmd} add 00300 allow icmp from any to $внешний_IP in via $внешний_интерфейс
>icmptype 0,3,4,11,12
>${fwcmd} add 00301 allow icmp from $внешний_IP to any out via $внешний_интерфейс
>icmptype 3,8,12
>
># вот над этими двумя строками подумай, прежде чем включать в рабочий
>скрипт: они позволяют провайдеру пинговать тебя.
># если служебные айпишники (для своих сотрудников) провайдер использует из своего общего
>адресного пространства (в
># котором находятся и его собственные клиенты, помимо тебя), то лучше не
>включать.
>${fwcmd} add 00302 allow icmp from $внешний_IP to $IP_адрес_провайдера out via $внешний_интерфейс
>icmptype 0,3,11
>${fwcmd} add 00303 allow icmp from $IP_адрес_провайдера to $внешний_IP in via $внешний_интерфейс
>icmptype 8
>
># стоит или не стоит выпускать из сети фрагментированные ICMP-пакеты из своей
>сети, решать тебе
>${fwcmd} add 00304 allow icmp from $внешний_IP to any out via $внешний_интерфейс
>frag
>
>
>
>${fwcmd} add 00305 deny log icmp from any to 255.255.255.255 in via
>$внешний_интерфейс
>${fwcmd} add 00306 reject log icmp from any to 255.255.255.255 out via
>$внешний_интерфейс
>
>${fwcmd} add 00306 deny log icmp from any to $маска_твоей_сети in via
>$внешний_интерфейс
>${fwcmd} add 00307 reject log icmp from any to $маска_твоей_сети out via
>$внешний_интерфейс
>
>${fwcmd} add 00308 deny log icmp from any to $твоя_сеть in via
>$внешний_интерфейс
>${fwcmd} add 00309 reject log icmp from any to $твоя_сеть out via
>$внешний_интерфейс
>
>-----------------------
>
>
>2 ALL: C наступающим!

Взаимно, присоединяюсь к поздравлению.

>P.S. Также надеюсь, что эта писанина пригодится кому-нибудь :)

несомненно плюс дополнение globus.

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру