В этом приложении рассматривается несколько сетевых трассировок. У каждой из них есть своя история. Большинство трассировок приведены в формате отчетов TCPdump, который соответствует формату трассировок, использованному в книге Ричарда Стивенса TCP/IP Illustrated, Volume 1: The Protocols. Этот справочник всегда должен быть под рукой у каждого настоящего аналитика сетевого трафика.

Ложные тревоги

Начнем это приложение с описания наиболее распространенных ошибок аналитиков. Хотя в группы CIRT (Computer Incident Response Team - группа реагирования на угрозы безопасности компьютеров) берут только первоклассных специалистов, описанные в первом разделе ошибки могут допустить даже они. Официально многие группы CIRT заявляют о своем либеральном отношении к получаемым отчетам, даже если в них будут присутствовать сообщения о ложных тревогах. Я, в принципе, с этим согласен, но считаю, что если в чем-то не уверен, то так и нужно сказать в отчете! Аналитик имеет максимум информации о случившемся, и ложные тревоги может предотвратить именно он.

Реакция без воздействия

Следующая трассировка представляет собой стандартный пример ситуации, которую ошибочно принимают за атаку через потайной ход. В 7:17 датчик зарегистрировал получение пакета от хоста mysystem, при этом портом отправителя был порт службы echo (7). Пакет размером в 64 Кбайт был отправлен хосту targetlна порт 24925.

ВРЕМЯ Хост-отп. Порт_отп. > Хост-пол. Порт_пол. Протокол Размер 07:17:09.615279 mysystem.echo > targetl.24925: udp 64

Когда я впервые увидел этот отчет, мне стало плохо. Я был уверен, что имею дело с потайным ходом. Бы спросите, почему? Я знал, что в моей сети заблокированы исходящие эхо-запросы на брандмауэре, поэтому никто не должен был возвращать никаких эхо-ответов. Я решил, что имею дело с действиями какой-то программы атаки, наводнением UDP-пакетами через порт 7 или же с потайным ходом. Но этому не находилось подтверждений. Кто в здравом уме будет создавать программу атаки, использующую в качестве порта-отправителя порт 7? Это почти наверняка привлечет внимание.

Я попытался найти трафик, который привел к появлению ответного пакета, но ничего не нашел. Это меня озадачило. А произошло следующее. На самом деле за выходные изменился периметр моей сети, и кто-то на хосте mysystem действительно возвращал эхо-ответы. Почему я не увидел первоначальный пакет воздействия? Есть два наиболее вероятных варианта: асимметричная маршрутизация или неверная настройка связующего порта. Некоторые из старых реализаций коммутируемых сетей в режиме соединения позволяют передавать трафик только в одном направлении, что и может привести к возникновению ложной тревоги (как показано в следующей трассировке).

07:17:09.615279 mysystem.echo > targetl.24925: Udp 64

07:17:10.978236 mysystem.echo > ire.some.where.40809: udp 600

07:17:11.001745 mysystem.echo > ire.some.where.14643: udp 600

07:17:.11.146935 mysystem.echo-> ire.some.where.4 9911: udp 600 07:17:12.254277 -mysystem.echo > ire.some.where.28480: udp 600

07:17:12.350014 mysystem.echo > ire.some,where.20683: udp 600

07:17:12.835873 mysystem.echo > targetl.5134: udp 64

07:17:13.266794 mysystem.echo > ire.some.where.16911: udp 600

07:17:13.862476 mysystem.echo > targetl.32542: udp 64

07:17:14.032603 mysystem.echo > ire.some.where.32193: udp 600

07:17:14.579404 mysystem.echo > ire.some.where.24455: udp 600

07:17:14.619173 mysystem.echo > ire.some.where.512 0: udp 600 07:17:14.792983 mysystem.echo > ire.some.where.47466: udp 600

07:17:14.879559 mysystem.echo > targetl.16878: udp 64

07:17:15.308270 mysystem.echo > ire.some.where.12234: udp 600

U Связующие порты

Коммутируемые сети представляют собой одну из основных проблем для аналитика обнаружения взлома. Датчик с одним сетевым адаптером как для прослушивания трафика в неразборчивом режиме, так и для отправки отчетов на консоль аналитика, может нарушить работу нескольких коммутируемых сетей.

Если администратор сети хочет добавить второй адаптер для датчика, то на это следует согласиться. Используйте один интерфейс для прослушивания трафика в неразборчивом режиме (здесь даже не нужен IP-адрес), а второй - для взаимодействия датчика с консолью с аналитика. В наше время это лучший способ использовать датчик сетевой системы обна-1! ружения взлома, который позволяет защитить его от хакеров.

Если приведенная выше трассировка не вызвана неверной настройкой связующего порта в коммутируемой сети, то что еще может являться ее причиной? Например, соединение через потайной ход или программа атаки. Вначале стоит проверить второе предположение.

' Как правило, при соединениях по протоколу IP есть как реакция, так и воздействие. Когда аналитик сталкивается с непонятной трассировкой, он должен оп ределить, что ее вызвало. Это позволит понять, что происходит на самом деле. Эта трассировка выявлена потому, что перехватывался весь проходящий трафик, но найти первоначальное воздействие не удалось. Б данном случае требовалось найти эхо-запрос, отправленный компьютеру my system.

Что еще можно узнать из этой трассировки? Для начала нужно вспомнить принципы работы службы echo. Программа echo считывает строку символов и возвращает ее. Теперь можно представить, как должен выглядеть искомый трафик, если, например, неверно сконфигурирован датчик или используется соединение через потайной ход.

Предполагаемый трафик должен иметь следующий вид.

07:17:09.527910 targetl.24925 > mysystem.echo: udp 64

07:17:09.615279 mysystem.echo > targetl.24925: udp 64

07:17:10.823651 ire.some.where.40809 > mysystem.echo: udp 600

07:17:10.978236 mysystem.echo > ire.some.where.40809: udp 600

Что это значит? Это значит, что хосты targetl и ire . some . where отправили хосту' mysystem строку символов и получили эхо-ответ. Бозможно ли это? Скорее всего, нет. Даже если одной системой использовался эхо-запрос для тестирования соединения или устранения неполадок, такое совпадение одновременно для двух компьютеров практически нереально. Бозможно, что это атака отказа в обслуживании, направленная против компьютеров targetl и ire. some. where. Одним из основных правил безопасности является отключение на компьютере всех неиспользуемых служб. Если бы системный администратор хоста mysystem закомментировал службу echo в файле /etc/inetd. conf, то этой трассировки никогда бы не было. Если это еще не убедило вас в необходимости отключения службы echo - не беда. Далее мы рассмотрим еще более интересные трассировки, связанные с этой службой.

У указанной трассировки есть еще одна проблема. Портами получателя являются 24925, 40809, 14643, 49911 и т.д. Поскольку перед нами эхо-ответы, можно предположить, что они использовались в качестве портов отправителя в эхо-запросах. Однако эти порты скорее случайны, что не характерно при выборе порта отправителя. Обычно после порта 24925 используется порт 24926 и т.д. Таким образом, вероятно, приходят эхо-ответы на специально подготовленные пакеты. Такую трассировку можно по ошибке принять за действия через потайной ход (когда на самом деле она вызвана неправильной настройкой коммутируемой сети), но случается это нечасто.

Рассмотрим последний пример подобной трассировки. На первый взгляд, ее также можно принять за какую-то атаку.

11:38:54.010000 masker.сот > 192.168.133.127: icmp: address mask is Oxfffffe00

11:39:43.180000 masker.com > 172.16.33.116: icmp: address mask is OxfffffeOO 11:53:37.780000 masker.com > 192.168.58.105: icmp: address mask is OxfffffeOO 11:56:43.690000 masker.com > 172.16.178.85: icmp: address mask is OxfffffeOO

12:15:52.550000 masker.com > 172.16.121.67: icmp: address mask is OxfffffeOO

12:25:41.800000 masker.com > 172.16.247.72: icmp: address mask is OxfffffeOO

12:45:07.470000 masker.com > 172.16.110.69: icmp: address mask is OxfffffeOO

12:45:31.530000 masker.com > 172.16.167.73: icmp: address mask is OxfffffeOO

12:58:23.350000 masker.com > 192.168.214.116: icmp: address mask is OxfffffeOO

Помните, что такое ICMP-запрос маски подсети? В ответе хоста должна содержаться маска подсети той сети, в которой он установлен. Хотя в отчетах TCPdump не указывается слово reply (ответ), но есть слова address mask (адресная маска) и приводится ее шестнадцатеричное значение. Это и есть ответы на ICMP-запрос о маске подсети. Однако ни один из хостов, получающих ответ, реально не существует, поэтому они не могли быть инициаторами запроса.

Итак, похоже, что дело снова в подмене в запросах IP-адресов сетей 192 .168 и 172 .16. Зачем это кому-то нужно? Возможно, это попытка наводнить пакетами хост masker. com с помощью метода доставки пакетов, отличного от эхо-запросов ICMP. На самом деле не имеет значения, какой вид трафика направляется на атакуемый хост при организации наводнения или атаки отказа в обслуживании. Рассмотрим ложную тревогу, которая заставляла ошибаться многих начинающих аналитиков.

Сканирование или реакция

Ниже приведена трассировка, полученная из ежечасного отчета системы Shadow. Эта система была настроена на отслеживание трафика, предназначенного для UDP-порта 1080, который используется для ргоху-сервера службы socks. Существует несколько программ атаки на эту службу, поэтому желательно отслеживать несанкционированный доступ к UDP-порту 1080.

18:20:12.080000 dns.сот.53 > myhost.сот.1080 : 5 NXDomain* 0/1/0 (128) 18:20:12.300000 dns.сот.53 > myhost.сот.1080 : 6 NXDomain* 0/1/0 (119) 18:20:12.410000 dns.сот.53 > myhost.сот.1080 : 7* 1/0/0 (48)

Этот отчет ничего вам не напоминает? Обратите внимание на запись после 1080. Являются ли пакеты окончательным ответом? Что можно сказать о порте отправителя ? Напоминает ли это пакеты службы DNS? Да, похоже, что это ответы хоста dns. com на несколько отправленных DNS-запросов. Идентификационные номера запросов - 5, б и 7, и в ответе на последний запрос содержится одна запись о ресурсах, ни одной записи о полномочиях и никаких дополнительных записей.

Поскольку это больше напоминает ответ, чем сканирование, нужно изучить исходящий трафик и проверить, были ли хостом myhost. com отправлены DNS-запросы. Следующий результат позволяет расставить все по своим местам.

18:20:11.870000 myhost.com.1080 > dns.com.53: 5+ (50)

18:20:12.090000 myhost.com.1080 > dns.com.53: 6+ (41)

18:20:12.310000 myhost.com.1080 > dns.com.53: 7+ (32)

Объясняется все тем, что хост myhost. com отправил запросы на определение имен под номерами 5, б и 7 DNS-серверу dns . com. При этом клиентом использовался временный порт 1080. Система Shadow не способна учитывать наши собственные действия, она просто сообщает о каждом совпадении с заданной сигнатурой. Это - ложная тревога. Одна из наиболее распространенных ложных тревог связана с наводнением SYN-пакетами.

SYN-наводнение

Интерпретация SYN-наводнений является весьма неприятной обязанностью аналитика сетевого трафика. Системы обнаружения вторжений очень часто ошибаются по этому поводу и выдают ложные уведомления о тревогах. Можно отчитаться о выявлении атаки, если пакеты SYN-наводнения поступают от известного враждебного хоста, или с данным соединением связаны другие вредоносные действия, или наводнение очевидно (например, получение более 50 запросов на соединение за минуту). В противном случае приходится сидеть и ждать дальнейших событий.

Настоящее SYN-наводнение

Следующая трассировка соответствует настоящему наводнению SYN-пакетами.

14:18:22.5660 flooder.601 > server.login: S 1382726961:1382726961(0) win 4096

14:18:22.7447 flooder.602 > server.login: S 1382726962:1382726962(0) win 4096

14:18:22.8311 flooder.603 > server.login: S 1382726963:1382726963(0) win 4096

14:18:22.8868 fl-ooder.604 > server. login: S 1382726964:1382726964 (0) win 4096

14:18:22.9434 flooder.605 > server.login: S 1382726965:1382726965(0) win 4096

14:18:23.0025 flooder.606 > server.login: S 1382726966:1382726966(0) win 4096

14:18:23.1035 flooder.607 > server.login: S 1382726967:1382726967(0) win 4096

14:18:23.1621 flooder.608 > server.login: S 1382726968:1382726968(0) win 4096

14 :18 : 23 ■. 2284 flooder.609 > server . login: S 1382726969:1382726969(0) win 4096

14:18:23.2825 flooder.610 > server.login: S 1382726970:1382726970(0) win 4096

14:18:23.3457 flooder.611 > server.login: S 1382726971:1382726971(0) win 4096

14:18:23.4083 flooder.612 > server.login: S 1382726972:1382726972(0) win 4096

14:18:23.9030 flooder.613 > server.login: S 1382726973:1382726973(0) win 4096

14:18:24.0052 flooder.614 > server.login* S 1382726974:1382726974(0) win 4096

Что-то знакомое? Может, это поможет вспомнить:

От: tsutomu@ariel.sdsc.edu (Tsutomu Shimomura), comp.security.misc

Дата: 25 января 1995 года

“Примерно через шесть минут мы получили поток SYN-пакетов (попыток установки соединения) от хоста 130.92.6.97 на порт 513 (login) нашего сервера. Целью этого наводнения является заполнить очередь на установку соединений для порта 513 сервера, чтобы тот не мог устанавливать новые соединения. В ответ на отправку сервером SYN/ACK-пакетов не будут получены пакеты с установленным флагом RST”.

Ложное SYN-наводнение

После сравнения предыдущего фрагмента из отчета об атаке Митника можно вообще не найти отличий со следующей трассировкой. Они есть, хоть и весьма незначительны. В обоих трассировках увеличиваются номера портов отправителя и порядковые номера. Размер TCP-окна остается постоянным- 4096 байт. Очевидно, что ниже показан отчет о поступлении двух наборов пакетов (по четыре пакета в каждом), отправленных для установки соединения. Обратите внимание на неизменный порт отправителя, неизменный порядковый номер и времени ьге промежутки между получением пакетов (3, 6 и 12 секунд).

14:02:22.5166 host.2104 > server.25: S 13 82 72696 0:13 8272 6 960(0) win 4096 14:02:25.5669 host.2104 > server.25: S 13 82 726960:1382726960(0) win 4096

14:02:31.7447 host.2104 > server.25: S 13 8272 6 960:13 8272 696 0(0) win 4096

14:02:42.8311 host.2104 > server.25: S 13 82 72696 0:13 82726 960(0) win 4096

14:02:58.8868 host2.3311 > server.25: S 2382927964:2382927 964(0) win 4096 14:03:01.9434 host2.3311 > server.25: S 23 82927964:2382927964(0) Win 4096

14:03:07.0025 host2.3311 > server.25: S 2 3 82927964:2382927964(0) win 4096 14:03:19.1035 host2.3311 > server.25: S 2382927964:2382927964(0) win 4096

Казалось бы, такое небольшое отличие: использование электронной почты, а не какой-то другой службы, но какое оно имеет значение! Сообщение электронной почты очень важно, по крайней мере для ретрансляторов. Если ретранслятор не сможет отправить почту в первый раз, он попытается это сделать еще раз часом позже. Если обратить внимание на время, то можно догадаться, что происходит. Нет никакой атаки отказа в обслуживании, просто не работает сервер электронной почты. Почтовые ретрансляторы по всему миру каждый час (обычно в начале часа) пытаются доставить сообщение. Вот и необходимое условие для ложной тревоги.

Как еще одну причину для появления подобных ложных тревог можно назвать открытие Web-страницы с помощью Internet Explorer. Эта программа устанавливает соединение для каждого элемента страницы в форматах GIF, JPEG, HTML и так далее, пока не достигнет предела в 32 соединения. Поэтому следует отключить уведомление о тревоге для SYN-наводнений на ТСР-порты 25, 80 или 443.

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

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

Back Orifice

Внедрение троянских программ и сканирование в поисках подходящих целей стали популярными начиная с середины 1997 года и остаются таковыми по нынешнее время. В конце 1998 и начале 1999 года лидерство удерживали программы Back Orifice и Netbus, а в конце 1999 года его перехватила программа SubSeven. Для Back Orifice по умолчанию используется UDP-порт 31337, а для Netbus - ТСР-порт 12345 (а также ТСР-порт 12346, хотя я никогда не видел реальных примеров его использования). Конечно, для большинства троянских программ номера портов можно изменить, что значительно усложняет их обнаружение. Следующую трассировку мы как-то наблюдали дважды за один день.

11:20:44.148361 nsl.сош.31337 > ns2.arpa.net.53 : 38787 А? arb.arpa.net. (34) 11:52:49.779731 nsl.сош.31337 > nsl.arpa.net.53 : 39230 ANY? hq.arpa.net. (36)

Самое время напомнить о пользе TCPdump. Хотя это UDP-трассировка, она не похожа на первую трассировку в этой главе. Программа TCPdump сообщает до полнительные сведения о пакете, так как она поддерживает работу с протоколом DNS (UDP-порт 53). Наша клиентская система выполняет поиск имени на DNS-сервере ns* . arpa. net. Так причем здесь все эти порты 313 3 7?

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

До появления программного пакета BIND 8 ожидаемым, хотя и не обязательным, методом поиска имен DNS-сервером было использование порта 53. Иногда, если клиентом была Windows-система, я видел, что портом отправителя запроса на поиск имени был порт 137. Но почему 31337?

Я забыл об этом случае, пока другой аналитик не обратил мое внимание на такой же пакет. Я взялся за телефон и нашел человека, который управлял работой DNS-сервера в организации. Я рассказал ему о случившемся.

Норткат. Я наблюдаю поступление на DNS-серверы пакетов, в которых указан порт отправителя 31337.

Молодой человек. Мы все проверили и это не Back Orifice.

Норткат. Я тоже это знаю, но такие пакеты вызывают сообщения о тревогах на всех системах обнаружения вторжений.

Молодой человек. Вам следует настроить свою систему обнаружения вторжений.

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

Он переспросил, кто я такой, и мы начали искать приемлемое решение.

Таким образом, это была ложная тревога. Атаки не было. Просто один юноша вообразил себя “крутым” и решил настроить работу’ службы DNS. Ему оставалось доделать сущую мелочь, и все было бы в порядке. Несмотря на подобные случаи, аналитик сетевого трафика никогда не должен отключать фильтры для выявления потенциально опасных атак. Также он должен проверять, не^вляется ли уведомление об опасности ложной тревогой. Некоторым может показаться, что я был слишком резок с молодым человеком. Представьте себе, какие последствия могут вызвать его действия для группы CIRT. Не забывайте, только опытный аналитик может отличить ложную тревогу от реальной.

Заметим, что, хотя современные DNS-серверы, на которых установлен пакет BIND 8, используют для отправки пакетов временный порт с номером больше 1024, порт 31337 исключен из диапазона допустимых портов.

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

Блокирование в действии

Однажды нас не поддержал один из основных Internet-провайдеров, с ІР-адресов которого осуществлялись атаки на наши сети. Снова и снова мы пытались привлечь эту организацию к сотрудничеству. Наконец мы заблокировали им доступ к своим сетям (электронная почта, Web и все, что только можно). Через три недели они взмолились о пощаде, поскольку начали терять деньги из-за разрыва контрактов с корпоративными клиентами. Мы получили обещание нести ответственность за действия клиентов и утроить персонал обеспечения защиты. Большего и не требовалось.

На этом мы завершаем рассказ о ложных тревогах. Атакой можно назвать метод или программу, позволяющую хакеру использовать уязвимое место в компьютерной системе. На практике очень трудно найти различие между разведывательным сканированием и настоящей атакой. Современное поколение программ для атаки позволяет реализовать и то, и другое.

Я не единственный, кто выступает против разделения рассмотренных трассировок по категориям. Исследователи в области обнаружения взлома работают над этой проблемой уже несколько лет, но пока так и не выработали единой системы классификации атак. Результатом этих исследований стал выпущенный в феврале 1999 года компакт-диск с проектом DOVES (Database of Vulnerabilities, Exploits, and Signatures - база данных уязвимых мест, программ атаки и сигнатур). Более подробную информацию можно получить у Мэта Бишопа (bishop@cs . ucdavis . edu). Компания Mitre стала организатором создания перечня уязвимых мест CVE (Common Vulnerability Enumeration). Этот проект стал одним из лучших и получил широкую поддержку производителей программного обеспечения. К настоящему времени описано более 2000 уязвимых мест и еще 1700 сообщений находятся на рассмотрении. Более подробную информацию можно узнать на сайте CVE по адресу cve.mitre.org.

Б следующем разделе рассмотрены трассировки атак, осуществляемых посредством протокола IMAP.

Программы атаки на IMAP

Ни один из типов программ атаки не наносил такого ущерба, как атаки посредством протокола IMAP. Нет ничего необычного в атаках на переполнение буфера IMAP, подобные проблемы возникали и для службы DNS. Поскольку обе эти программы работают в привилегированном режиме, то атаки на них особенно опасны и позволяют хакеру получить доступ с правами суперпользователя (root).

Сигнатура атаки на IMAP, порт отправителя 10143

Эта атака является одной из наиболее опасных атак на переполнение буфера. Обратите внимание на то, что данное сканирование (в приведенном ниже листинге) проводится сразу для двух сетей. Важное значение имеет и временной интервал между пакетами. Такой большой интервал между получением пакетов объясняется тем, что сканирование направлено на все сети класса В в Internet. Эта трассировка была зарегистрирована в середине 1997 года и сейчас встречается крайне редко.

14:13:54.847401 newbie.hacker.org.10143 > 192.168.1.1.143: S 14:24:58.151128 newbie.hacker.org.10143 > 172.31.1.1.143: S 14:35:40.311513 newbie.hacker.org.10143 > 192.168.1.2.143: S

14:43:55.459380 newbie.hacker.org.10143 > 192.168.2.1.143: S

14:54:58.693768 newbie.hacker.org.10143 > 172.31.2.1.143: S

15:05:41.039905 newbie.hacker.org.10143 > 192.168.2.2.. 143 : S

15:13:59.948065 newbie.hacker.org.10143 > 192.168.3.1.143: S

Сигнатура атаки на IMAP, порядковый номер 111

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

и, конечно, размер окна со значением 0. С точки зрения применения сигнатур эта трассировка представляет особенный интерес. Первый раз она была замечена в конце 1998 года, после чего появились многочисленные попытки сканирования с использованием порта отправителя 0 и установленными флагами SYN и FIN (как показано в следующем разделе). В начале 1999 года сигнатура была выявлена опять. Такое впечатление, что программа атаки была потеряна на несколько месяцев.

00:25:09.57 prober.2666 > relay.143: S 111:111(0) win О

00:25:09.59 prober.2666 > relay.143: S 111:111(0) win 0

00:42:50.79 prober.2666 > web.143: S 111:111(0) win 0 00:43:24.05 prober.2666 > relay.143: S 111:111(0) win 0

00:43:24.07 prober.2666 > relay.143: S 111:111(0) win 0

00:44:20.42 prober.2666 > relay2.143 : S 111:111(0) win 0 00:44:42.62 prober.2666 > ns2.143 : S 111:111(0) win 0

00:44:42.64 prober.2666 > ns2.143 : S 111:111(0) win 0

00:44:42.67 prober.2666 > nsl.143: S 111:111(0) win 0

00:44:42.69 prober.2666 > nsl.143 : S 111:111(0) win 0

Масштабное выявление попыток взлома | Обнаружение нарушений безопасности в сетях | Атака на порты с помощью syn/fin-пакетов


Обнаружение нарушений безопасности в сетях



Новости за месяц

  • Сентябрь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс