cканирование портов: За и Против
В связи с недавним инцидентом по поводу массового сканирования портов на подозрительных системах почтовой службой Yandex.ru в целях борьбы со спамом, портал SecurityLabпровел опрос среди ведущих экспертов в области информационной безопасности, юристов и крупных российских провайдеров, чтобы узнать их мнение об этой проблеме. На вопросы отвечали: Е. Касперский, А. Лукацкий, А. Носик, Д. Леонов, С. Гордейчик, Г. Сотский, ЗАРАЗА, представители компаний Positive Technologies, Digital Security, Crime-research, Zenon N.S.P., "Диджитал Нетворк", MSM, “Элвис Телеком”, ЗАО "Демос-Интернет".
Итак, первый вопрос:
Является ли сканирование портов инцидентом безопасности? Как должен администратор безопасности реагировать на попытку сканирования портов? Каков, по-вашему, риск подобного инцидента?
Евгений Касперский (ЕК):Смотря что вкладывается в понятие "инцидент безопасности". Хотелось бы услышать точное определение.
Администратор, по нашему мнению, в современных условиях вообще не должен реагировать на подобные вещи. Его задача — защита системы. Можно, конечно, не следить за обновлениями продуктов, не ставить патчи, не консультировать пользователей, а просто сидеть и злобно кидаться на любого, кто попробует обратиться (а сканирование — это именно обращение) к любым портам в системе, писать гневные письма другим администраторам, искать виноватых. А можно просто закрыть ненужные/ опасные порты.
Из этого правила есть только одно исключение — если сканирование портов ведется постоянно, в течение достаточно долгого промежутка времени и вызывает перебои в работе защищаемой системы. Тут единственным фактором оценки может служить только экспертное мнение администратора.
Риск попасть под сканирование портов в настоящее время равен 100%. Порты в Интернете сканируются постоянно. Любой пользователь файрволла знает, что если включить вывод уведомлений о каждом случае обращения извне — работать станет просто невозможно.
ЗАРАЗА, security.nnov.ru (З):Ответ зависит от принятой политики безопасности. В большинстве случаев — да, является (попытка сбора информации о топологии сети и используемых сетевых службах). Администратор должен принять меры чтобы разобраться, что послужило причиной сканирования.
Алексей Лукацкий, www.infosec.ru (АЛ):Инцидентом является группа атак, связанных между собой общими параметрами и нанесшими ущерб жертве. Исходя из этого, само по себе сканирование не является инцидентом. Однако оно может являться событием, предшествующим реальному проникновению. Поэтому необходимо контролировать такие действия, чтобы своевременно отследить последующие (после сканирования) попытки вторжения. Правда часто бывает и так, что сканирование производится автоматически по целому диапазону и ничего за собой не несет. Поэтому я бы рекомендовал использовать системы корреляции событий безопасности, которые могут связать воедино сканирование и последующие попытки взлома системы.
Дмитрий Леонов, www.bugtraq.ru (ДЛ):Традиционно администраторы относятся к попыткам сканирования весьма болезненно. Но, на мой взгляд, максимум, что тут можно и нужно сделать — взять сканирующий хост на заметку, поскольку с него, возможно, последуют и более вредоносные действия. Как известно, при построении любой системы защиты следует исходить из враждебности окружения, так что подобные инциденты, в сущности, — часть штатной работы.
Г. Сотский, Руководитель СБ ЦИС МТ РФ (ГС):Инцидент безопасности — это событие, нарушающее политику безопасности. И администратор безопасности должен реагировать согласно этой политике. :)
Поскольку сканирование портов само по себе имеет невысокий риск, достаточно распространено и в большинстве случаев не имеет какого-либо продолжения, реагирование на него администратором по безопасности нерентабельно. Реагировать на него должна система, автоматически блокируя IP-адреса, с которых производилось сканирование.
Однако, если речь идет об объектах с повышенными требованиями к информационной безопасности, то в политике безопасности может быть прописано, что администратор ОБЯЗАН реагировать на такие события. Это реагирование может быть путем взятия на заметку скомпрометированных хостов и проведением исследования инцидента в комплексе с другими событиями. А может быть путем отправки жалобы провайдеру. Провайдеры обычно охотно идут на встречу и делают замечания нарушителям или даже отключают их от Интернета.
Другое дело, если речь идет не о простом сканировании портов, а о проверке уязвимостей на открытых портах. В этом случае, если после обнаружения открытого порта, производится попытка эксплуатации уязвимости на нем — риск подобной атаки может быть весьма высоким. Реакция на такое событие ДОЛЖНА БЫЛА БЫ бЫТЬ достаточно жесткой, вплоть до обращения в соответствующие органы.
Илья Медведовский, Digital Security (ИМ):Сканирование портов не является непосредственным инцидентом безопасности. Сканирование должно являться для администратора безопасности сигналом, что к его системе, возможно, некто проявляет повышенный интерес. Что касается риска, то риск сканирования невелик, так как большинство сканирований оканчивается ничем: сканирование портов само по себе не означает последующей атаки системы.
Дмитрий Максимов, www.ptsecurity.ru (ДМ):В какой-то мере является, потому что сканирование портов может показать общий уровень защиты даже навскидку. Все это, конечно, условно, но определенные выводы можно сделать, хотя это и не всегда работает. Например, когда хост не пингуется и у него открыт только 80 порт, это одно, а когда у хоста наружу торчит порядка 20 открытых портов, включая NetBIOS и т.д., то это уже наводит на определенные мысли.
С. Гордейчик, www.infosec.ru/edu/ (СГ):Сканирование портов, несомненно, является инцидентом, требующим соответствующей реакции администратора. Однако риск и меры реагирования в большой степени зависят от того, по отношению к какому ресурсу производилось сканирование. Если это публичный ресурс, доступ к которому регламентируется не внутренней политикой безопасности предприятия, а общими правилами пользования сети, то я вижу следующие причины сканирования и способы реакции:
1. Подготовка атаки (предварительная разведка).
Реакция: попытаться определить используемый инструмент и определить полученную злоумышленником информацию. Если сканирование производилось сканером безопасности (т.е. в процессе сканирования проводилось определение наличия признаков уязвимостей), закрыть уязвимости и сообщить службе abuse провайдера.
2. Поиск proxy/relay (определение возможности рассылки СПАМа).
Реакция: просканировать свои публичные ресурсы на наличие такой возможности и устранить уязвимость.
3. Активность сетевого червя.
Реакция: просканировать сканирующий адрес, и, в случае обнаружения характерных признаков троянской программы, анонимного Proxy и т.д., сообщить abuse провайдера.
Само по себе сканирование портов публичного сервиса не является нарушением каких-либо норм.
Crime-research.org (CR):Инциндентом (т.е событием) однозначно является. Реакция — скорее всего взять на внимание сканирующий хост. Так как на этом этапе "нарушения работы авт. системы" маловероятны —то обращаться по этому поводу в суд не стоит (это приминительно к Украине , но, я думаю, и для России справедливо тоже).
Если же сканирование происходит часто и действительно наблюдаются НАРУШЕНИЕ РАБОТЫ сети (или сервера) — то обратится в соответствующие органы нужно, это даст им повод предпринять какие-нибудь действия. Опять же, все будет зависеть от масштаба инцидента (если организация крупная, а у нас такие находятся под крылом Службы Безопасности —то что-нибудь да и произойдет).
Риск этого инцидента зависит от вашей политики безопасности и ДОЛЖЕН быть минимальным. К примеру, если у вас не закрытая дыра в WIN RPC — то, конечно, информация об этом создает большую вероятность для дальнейшей аттаки.
Вопрос N2: Как вы считаете, сканирование портов может быть причиной возбуждения уголовного дела? Каковы перспективы такого дела?
(ЕК):В действующем Уголовном Кодексе РФ нет статьи, под которую подпадает "сканирование портов". Вот, кстати, именно на securitylab.ru недавно читал очень хорошую аналогию: двое встретили на улице третьего, посмотрели на него и избили. Третий подает в суд на первых двух, но не за то что его избили, а за то что ПОСМОТРЕЛИ на него перед избиением :) Такое дело обречено на провал.
(З):Само по себе сканирование портов однозначно не может быть причиной возбуждения уголовного дела, т.к. не наносит ощутимого ущерба.
(АЛ):На этот вопрос в свое время пытались ответить в FIDO, в эхе RU.SECURITY, но так ни к чему не пришли (хотя некоторые провайдеры без предупреждения отключают от Интернета за такие действия). УК РФ подразумевает наказание за доступ к ИНФОРМАЦИИ, а сканирование такой доступ не подразумевает. Это скорее доступ к ЭВМ. Т.е. по 272 статье посадить человека нельзя. А вот попробовать применить 274 статью вполне по силам хорошему юристу. Т.к. сканирование могло повлечь блокирование доступа к информации (если связь этих двух событий доказана). Хотя 274-я статья достаточно скользкая в юридическом плане и ее можно крутить как угодно.
(ДЛ):Сканирование само по себе — очень сомневаюсь.
(ГС):К сожалению, правовая база и судебные прецеденты в РФ не позволяют серьезно надеяться на успешное проведение уголовных дел по преступлениям в сфере информационных технологий. Чтобы суметь инкриминировать в данном случае 274 статью УК, понадобилось бы привлечь самых лучших юристов. Но может быть уже пора?
(ИМ):Сканирование портов не может быть причиной возбуждения уголовного дела. Что касается перспектив такого дела в российском суде, то, как и в любом деле, связанным с информационной безопасностью, перспективы такого дела выглядят достаточно туманными.
(ДМ):Вряд ли. В штатах процесс по сканированию был проигран, судья сказал, что сканирование портов равносильно разглядыванию витрины в магазине. Наверно я с ним соглашусь.
(CR):У нас в Украине перспективы возбуждения уголовного дела стремятся к 0. Насчет России — не думаю что ситуация много лучше. Нам трудно судить - так как аналитическая информация у нас отсутствует.
Антон Носик (АН):Что же касается разговоров об Уголовном кодексе, то они, честно говоря, достаточно наивны. Ежедневно к любому серверу приходят тысячи обращений от сканнеров портов. Все, что по этому поводу делает администрация серверов — настраивает адекватную защиту. Но стоило прийти одному запросу от Яндекса, как сразу поднимается вопрос о юридическом аспекте. Не пора ли отказаться от привычки "лаять на слона" и озаботиться борьбой с теми, кто нам действительно вредит и угрожает? Ежику ясно, что это не Яндекс, а именно те, с кем он пытается бороться.
Вопрос N3: Насколько эффективно бороться со спамом, сканируя порты на подозрительной системе? Каков критерий работоспособности подобных методик? Насколько распространен в мире подобный способ борьбы со спамом?
(ЕК):Очень эффективно. Все существующие спам-фильтры не решают проблемы спама на 100%. Они могут частично решить следствие, но не саму проблему. А проблема состоит в том, что спамеры в союзе с вирусописателями все чаще и чаще становятся виновниками крупных вирусных эпидемий, целью которых является создание распределенных сетей из множества "взломанных" при помощи червей машин. В дальнейшем такие машины как раз и используются для спам-рассылок, а также для организации новых вирусных эпидемий. Так вот чем больше таких машин будет выявлено и "забанено" — тем меньше будет спама. Если известен какой-либо другой, более эффективный метод выявления таких машин без сканирования портов — было бы интересно о нем услышать.
Мир далеко не единогласен во взгляде на данную проблему. Где-то спаммеров не могут привлечь ни к какой ответственности, даже зная их адреса и телефоны, а где-то их могут посадить пожизненно или оштрафовать на миллионы долларов.
(З):DSBL (наиболее эффективный на сегодняшний день RBL из списков с минимальным риском заблэклистить что-либо нужное) строится практически исключительно по результатом сканирований удаленных хостов на открытые порты, проводимых администраторами крупных почтовых служб. В общем случае зависит от реализации — сканированию должны подвергаться только "подозрительные" хосты, попадающие под какой-либо критерий, например, большое количество примерно одинаковых писем на разные адреса в единицу времени.
(АН): Насколько я понимаю, сканирование портов — осуществляемое в первую очередь спаммерами, а не борцами с ними — позволяет выявить open relays, доступные для спаммерского использования. Мне кажется, что при оценке такой деятельности имеет смысл отталкиваться от ее цели. Спаммеры, сканируя ваши порты, проверяют возможность использования ваших серверов для собственной рассылки. Люди, в обязанности которых входит борьба со спамом, могут захотеть проверить тот или иной хост на предмет наличия там open relay выборочно — по факту получения несанкционированной рекламной рассылки оттуда.
В мире распространен способ борьбы со спамом, основанный на недопущении почты с open relays. Для этого составляются "черные списки", которые впоследствии используются либо провайдерами, либо клиентским софтом (SpamPal, например). Бывают, однако, случаи, когда несанкционированная реклама приходит с сервера, в принципе закрытого для проведения массовых рассылок (например, эту рекламу разослал некий локальный пользователь вручную по ограниченному списку). Вносить ли такой сервер в "черный список", или правильней ограничиться жалобой его админу? Для получения ответа на этот вопрос, мне кажется, совершенно легитимно проверить, открыт ли на данном сервере sendmail для посторонних отправителей спама. Если открыт — место такому серверу в RBL. Если закрыт — санкции следует применять не к серверу, а к конкретному его пользователю, злоупотребившему своим доступом к системе.
(ДЛ):Насколько я понимаю, к подобной методике прибегают в первую очередь серверы, поддерживающие всевозможные стоп-листы в целях поиска открытых релеев, доступных всем желающим. Впрочем, дело здесь ограничивается обычно лишь проверкой 25-го порта, в полном сканировании ради борьбы со спамом я не вижу никакого смысла.
(ГС):Простое сканирование портов не дает никакой информации для борьбы со спамом. Поэтому, если борьба со спамом не является отговоркой яндекса для прикрытия действий отдельных личностей, самостоятельно проведших сканирование, то значит, по моему мнению, речь идет о методике, используемой сетевыми червями или спамерам. Т.е. производится проверка на открытые proxy и relay. Но какой смысл производить проверку ВСЕХ портов? Например, 135-го? Можно было бы произвести проверку стандартных портов и портов, начиная с 1024. Такая проверка без разрешения владельца сети хотя и неэтична, на мой взгляд, но была бы, по крайней мере, обоснована. Честно говоря, я в последнее время уже и не знаю, чего мне не нравится больше: спам или борьба с ним. Одними лишь техническими методами проблемы спама и сканирования портов не решить. Тем более если, борясь с одной проблемой, усугубляешь другую. Надеюсь, что события, повлекшие дискуссию по этой теме, не вызваны официальной политикой уважаемого мною Яндекса, а являюся инициативой нижнего персонала, в отношении которых уже сделаны соответствующие выводы. :)
(ИМ):Сама эта история выглядит достаточно странно. Борьба со спамом тут явно не причем; официальный Яндекс скорее всего тоже. Вероятнее всего, это частная инициатива одного из специалистов Яндекса.
(ДМ):Просто сканировать порты достаточно глупо, если эти порты потом не проверяются на наличие сервисов. Можно конечно найти порты, на которых обычно стоят трояны, но это мало что даст, если эти порты потом не проверять. А если уж проверять, то это уже не просто сканирование портов.
(CR):Я думаю,что сканирование ВСЕХ портов — это слишком. Слишком грубый подход, который тратит время администраторов, трафик и время . Проверить конкретный порт того почтовика, что послал "предположительно" спам на open relay и сам хост на существование — разумно. Насколько распростанен подход Яндеса — не скажу. Не занимался этим вопросом.
Думаю, что в США за такое дают по шапке. Насчет других стран — трудно сказать. Официальная точка такая — бороться со спамом нужно на законодательной почве. :)
(СГ):Черные списки были и остаются наиболее эффективным методом борьбы с невостребованными почтовыми рассылками. Однако публичные черные списки зачастую имеют собственную политику, которая может не совпадать с политикой предприятия (например, доверенный сервер может быть занесен в список в RBL, что может привести к сбоям в почтовом обмене и как следствие — нарушению доступности СЭП, т.е. финансовым потерям). Сами серверы, поддерживающие списки, могу стать объектом атаки (информация может быть модифицирована или стать недоступной). Кроме того, в последнее время используются все более и более изощренные методы рассылки СПАМа. Подмена заголовков received, c целю добавления в них SMTP-узлов, не содержащихся в RBL, рассылка СПАМа через HTTP/Connect/FTP/Socks Proxy, использование HTML и скрытых полей с целью обмана систем контекстной фильтрации и баз данных сообщений, классифицированных как СПАМ и т.д. Несколько крупных вирусных эпидемий было направлено именно на заражение компьютеров троянскими программами, которые в дальнейшем могли бы использоваться для рассылки СПАМа (именно это, имхо, и является причиной последних антиспамерских акций, а не сам СПАМ).
В связи с вышесказанным, определение доверенности узла, от которого пришло почтовое сообщение, кажется мне довольно эффективным методом.
Идея заключается в анализе журналов севера SMTP с целью определения доверенности серверов, с которых почта была передана во внутреннюю сеть. В случае если данный сервер не является доверенным и отсутствует в черных списках, производится его тестирование на предмет наличия Proxy/Relay/Trojan, и если были обнаружены признаки одного из перечисленного, хост заносится в соответствующую зону для игнорирования/дополнительной обработки сообщений от этого источника.
Так же сканироваться могут все узлы в цепочке Received. Дополнительным критерием при проверке доверенности узла может выступать наличие соответствующей MX-записи в системе DNS.
Таким образом, у каждого почтового сервера появляется свой RBL, динамически обновляемый и управляемый непосредственно администратором узла. Кроме того, данные этого списка могут быть опубликованы для использования доверенными узлами.
В качестве примера реализации можно рассматривать http:// www.drbl.ofisp.org/ .
Информацией о распространенности не обладаю, однако считаю, что это довольно эффективный и мощный механизм.
Вопрос N4 адресован к провайдерам: Как вы реагируете на жалобы на сканирование портов? Оговариваются ли последствия подобных инцидентов при заключении договора с вашими клиентами?
Zenon N.S.P:Общий ответ на ваш вопрос таков: подобные действия запрещены в пункте 6 Приложения 2 к Договору с пользователем:
«УСЛОВИЯ ПРЕДОСТАВЛЕНИЯ УСЛУГ
6. АБОНЕНТУ запрещается:
Осуществлять попытки несанкционированного доступа к ресурсам ПРОВАЙДЕРА и к другим системам, доступным через сеть Интернет.
...»
Но, тем не менее, каждый конкретный случай и каждая жалоба рассматриваются персонально.
Андрей Гасов, ЗАО "Элвис Телеком":На мой взгляд подобные действия полностью определены в документе "Нормы пользования сетью" (http://www.ofisp.org/).
Этот документ является неотъемлемой частью договора с конечным пользователем. Если поступают жалобы на сканирование портов нашими клиентами, мы выясняем, кто, что и зачем сканил и, если эти действия нарушают "Нормы пользования сетью", имеем вполне законное право прекратить предоставление услуг.
Мирон М. Рудник, MSM:Мы регистрируем на сканирование портов только нашего центрального узла. Если сканирование носит достаточно постоянный характер или может иметь потенциальную угрозу, мы связываемся с техническим персоналом провайдера (источника) и решаем с ним эту проблему.
Если к нам обращаются с жалобами на сканирование, которое осуществляет какой-нибудь из наших клиентов, мы предупреждаем клиента, если он конечный. Если же клиентом является провайдер услуг, переадресуем жалобу в техническую службу данного провайдера.
Постоянные жалобы на действия клиента могут привести к его отключению на основании пункта договора:
5.3 Абоненту запрещается:
1. Передавать в сеть информацию, оскорбляющую честь и достоинство Других Абонентов и обслуживающего персонала msm.ru.
2. Использовать предоставленный ему доступ в сеть msm.ru для несанкционированного доступа и порчи компьютеров, к которым возможен доступ через сеть msm.ru.
Денис В. Губанов, ЗАО "Диджитал Нетворк":Реагируем просто: отключаем и всего делов :) В договоре оговариваем подобные инциденты.
Зарубин Сергей, ЗАО "Демос-Интернет":В структуре Компании существует Группа реагирования на нарушения информационной безопасности. В соответствии с процедурой эскалации докладов, как абоненты компании, так и сторонние пользователи сети Интернет сообщают Группе об имеющихся несанкционированных обращениях или иных аномалиях в области информационной безопасности. Компания выполняет сбор и сохранение данных, реагирование на нарушения информационной безопасности.
При использовании услуг сети Интернет/Россия Абонент ЗАО "Демос- Интернет" обязуется соблюдать Регламент, в котором оговорены недопустимые действия и ответственность Абонента в случае его нарушения.
SecurityLab.ru
Итак, первый вопрос:
Является ли сканирование портов инцидентом безопасности? Как должен администратор безопасности реагировать на попытку сканирования портов? Каков, по-вашему, риск подобного инцидента?
Евгений Касперский (ЕК):Смотря что вкладывается в понятие "инцидент безопасности". Хотелось бы услышать точное определение.
Администратор, по нашему мнению, в современных условиях вообще не должен реагировать на подобные вещи. Его задача — защита системы. Можно, конечно, не следить за обновлениями продуктов, не ставить патчи, не консультировать пользователей, а просто сидеть и злобно кидаться на любого, кто попробует обратиться (а сканирование — это именно обращение) к любым портам в системе, писать гневные письма другим администраторам, искать виноватых. А можно просто закрыть ненужные/ опасные порты.
Из этого правила есть только одно исключение — если сканирование портов ведется постоянно, в течение достаточно долгого промежутка времени и вызывает перебои в работе защищаемой системы. Тут единственным фактором оценки может служить только экспертное мнение администратора.
Риск попасть под сканирование портов в настоящее время равен 100%. Порты в Интернете сканируются постоянно. Любой пользователь файрволла знает, что если включить вывод уведомлений о каждом случае обращения извне — работать станет просто невозможно.
ЗАРАЗА, security.nnov.ru (З):Ответ зависит от принятой политики безопасности. В большинстве случаев — да, является (попытка сбора информации о топологии сети и используемых сетевых службах). Администратор должен принять меры чтобы разобраться, что послужило причиной сканирования.
Алексей Лукацкий, www.infosec.ru (АЛ):Инцидентом является группа атак, связанных между собой общими параметрами и нанесшими ущерб жертве. Исходя из этого, само по себе сканирование не является инцидентом. Однако оно может являться событием, предшествующим реальному проникновению. Поэтому необходимо контролировать такие действия, чтобы своевременно отследить последующие (после сканирования) попытки вторжения. Правда часто бывает и так, что сканирование производится автоматически по целому диапазону и ничего за собой не несет. Поэтому я бы рекомендовал использовать системы корреляции событий безопасности, которые могут связать воедино сканирование и последующие попытки взлома системы.
Дмитрий Леонов, www.bugtraq.ru (ДЛ):Традиционно администраторы относятся к попыткам сканирования весьма болезненно. Но, на мой взгляд, максимум, что тут можно и нужно сделать — взять сканирующий хост на заметку, поскольку с него, возможно, последуют и более вредоносные действия. Как известно, при построении любой системы защиты следует исходить из враждебности окружения, так что подобные инциденты, в сущности, — часть штатной работы.
Г. Сотский, Руководитель СБ ЦИС МТ РФ (ГС):Инцидент безопасности — это событие, нарушающее политику безопасности. И администратор безопасности должен реагировать согласно этой политике. :)
Поскольку сканирование портов само по себе имеет невысокий риск, достаточно распространено и в большинстве случаев не имеет какого-либо продолжения, реагирование на него администратором по безопасности нерентабельно. Реагировать на него должна система, автоматически блокируя IP-адреса, с которых производилось сканирование.
Однако, если речь идет об объектах с повышенными требованиями к информационной безопасности, то в политике безопасности может быть прописано, что администратор ОБЯЗАН реагировать на такие события. Это реагирование может быть путем взятия на заметку скомпрометированных хостов и проведением исследования инцидента в комплексе с другими событиями. А может быть путем отправки жалобы провайдеру. Провайдеры обычно охотно идут на встречу и делают замечания нарушителям или даже отключают их от Интернета.
Другое дело, если речь идет не о простом сканировании портов, а о проверке уязвимостей на открытых портах. В этом случае, если после обнаружения открытого порта, производится попытка эксплуатации уязвимости на нем — риск подобной атаки может быть весьма высоким. Реакция на такое событие ДОЛЖНА БЫЛА БЫ бЫТЬ достаточно жесткой, вплоть до обращения в соответствующие органы.
Илья Медведовский, Digital Security (ИМ):Сканирование портов не является непосредственным инцидентом безопасности. Сканирование должно являться для администратора безопасности сигналом, что к его системе, возможно, некто проявляет повышенный интерес. Что касается риска, то риск сканирования невелик, так как большинство сканирований оканчивается ничем: сканирование портов само по себе не означает последующей атаки системы.
Дмитрий Максимов, www.ptsecurity.ru (ДМ):В какой-то мере является, потому что сканирование портов может показать общий уровень защиты даже навскидку. Все это, конечно, условно, но определенные выводы можно сделать, хотя это и не всегда работает. Например, когда хост не пингуется и у него открыт только 80 порт, это одно, а когда у хоста наружу торчит порядка 20 открытых портов, включая NetBIOS и т.д., то это уже наводит на определенные мысли.
С. Гордейчик, www.infosec.ru/edu/ (СГ):Сканирование портов, несомненно, является инцидентом, требующим соответствующей реакции администратора. Однако риск и меры реагирования в большой степени зависят от того, по отношению к какому ресурсу производилось сканирование. Если это публичный ресурс, доступ к которому регламентируется не внутренней политикой безопасности предприятия, а общими правилами пользования сети, то я вижу следующие причины сканирования и способы реакции:
1. Подготовка атаки (предварительная разведка).
Реакция: попытаться определить используемый инструмент и определить полученную злоумышленником информацию. Если сканирование производилось сканером безопасности (т.е. в процессе сканирования проводилось определение наличия признаков уязвимостей), закрыть уязвимости и сообщить службе abuse провайдера.
2. Поиск proxy/relay (определение возможности рассылки СПАМа).
Реакция: просканировать свои публичные ресурсы на наличие такой возможности и устранить уязвимость.
3. Активность сетевого червя.
Реакция: просканировать сканирующий адрес, и, в случае обнаружения характерных признаков троянской программы, анонимного Proxy и т.д., сообщить abuse провайдера.
Само по себе сканирование портов публичного сервиса не является нарушением каких-либо норм.
Crime-research.org (CR):Инциндентом (т.е событием) однозначно является. Реакция — скорее всего взять на внимание сканирующий хост. Так как на этом этапе "нарушения работы авт. системы" маловероятны —то обращаться по этому поводу в суд не стоит (это приминительно к Украине , но, я думаю, и для России справедливо тоже).
Если же сканирование происходит часто и действительно наблюдаются НАРУШЕНИЕ РАБОТЫ сети (или сервера) — то обратится в соответствующие органы нужно, это даст им повод предпринять какие-нибудь действия. Опять же, все будет зависеть от масштаба инцидента (если организация крупная, а у нас такие находятся под крылом Службы Безопасности —то что-нибудь да и произойдет).
Риск этого инцидента зависит от вашей политики безопасности и ДОЛЖЕН быть минимальным. К примеру, если у вас не закрытая дыра в WIN RPC — то, конечно, информация об этом создает большую вероятность для дальнейшей аттаки.
Вопрос N2: Как вы считаете, сканирование портов может быть причиной возбуждения уголовного дела? Каковы перспективы такого дела?
(ЕК):В действующем Уголовном Кодексе РФ нет статьи, под которую подпадает "сканирование портов". Вот, кстати, именно на securitylab.ru недавно читал очень хорошую аналогию: двое встретили на улице третьего, посмотрели на него и избили. Третий подает в суд на первых двух, но не за то что его избили, а за то что ПОСМОТРЕЛИ на него перед избиением :) Такое дело обречено на провал.
(З):Само по себе сканирование портов однозначно не может быть причиной возбуждения уголовного дела, т.к. не наносит ощутимого ущерба.
(АЛ):На этот вопрос в свое время пытались ответить в FIDO, в эхе RU.SECURITY, но так ни к чему не пришли (хотя некоторые провайдеры без предупреждения отключают от Интернета за такие действия). УК РФ подразумевает наказание за доступ к ИНФОРМАЦИИ, а сканирование такой доступ не подразумевает. Это скорее доступ к ЭВМ. Т.е. по 272 статье посадить человека нельзя. А вот попробовать применить 274 статью вполне по силам хорошему юристу. Т.к. сканирование могло повлечь блокирование доступа к информации (если связь этих двух событий доказана). Хотя 274-я статья достаточно скользкая в юридическом плане и ее можно крутить как угодно.
(ДЛ):Сканирование само по себе — очень сомневаюсь.
(ГС):К сожалению, правовая база и судебные прецеденты в РФ не позволяют серьезно надеяться на успешное проведение уголовных дел по преступлениям в сфере информационных технологий. Чтобы суметь инкриминировать в данном случае 274 статью УК, понадобилось бы привлечь самых лучших юристов. Но может быть уже пора?
(ИМ):Сканирование портов не может быть причиной возбуждения уголовного дела. Что касается перспектив такого дела в российском суде, то, как и в любом деле, связанным с информационной безопасностью, перспективы такого дела выглядят достаточно туманными.
(ДМ):Вряд ли. В штатах процесс по сканированию был проигран, судья сказал, что сканирование портов равносильно разглядыванию витрины в магазине. Наверно я с ним соглашусь.
(CR):У нас в Украине перспективы возбуждения уголовного дела стремятся к 0. Насчет России — не думаю что ситуация много лучше. Нам трудно судить - так как аналитическая информация у нас отсутствует.
Антон Носик (АН):Что же касается разговоров об Уголовном кодексе, то они, честно говоря, достаточно наивны. Ежедневно к любому серверу приходят тысячи обращений от сканнеров портов. Все, что по этому поводу делает администрация серверов — настраивает адекватную защиту. Но стоило прийти одному запросу от Яндекса, как сразу поднимается вопрос о юридическом аспекте. Не пора ли отказаться от привычки "лаять на слона" и озаботиться борьбой с теми, кто нам действительно вредит и угрожает? Ежику ясно, что это не Яндекс, а именно те, с кем он пытается бороться.
Вопрос N3: Насколько эффективно бороться со спамом, сканируя порты на подозрительной системе? Каков критерий работоспособности подобных методик? Насколько распространен в мире подобный способ борьбы со спамом?
(ЕК):Очень эффективно. Все существующие спам-фильтры не решают проблемы спама на 100%. Они могут частично решить следствие, но не саму проблему. А проблема состоит в том, что спамеры в союзе с вирусописателями все чаще и чаще становятся виновниками крупных вирусных эпидемий, целью которых является создание распределенных сетей из множества "взломанных" при помощи червей машин. В дальнейшем такие машины как раз и используются для спам-рассылок, а также для организации новых вирусных эпидемий. Так вот чем больше таких машин будет выявлено и "забанено" — тем меньше будет спама. Если известен какой-либо другой, более эффективный метод выявления таких машин без сканирования портов — было бы интересно о нем услышать.
Мир далеко не единогласен во взгляде на данную проблему. Где-то спаммеров не могут привлечь ни к какой ответственности, даже зная их адреса и телефоны, а где-то их могут посадить пожизненно или оштрафовать на миллионы долларов.
(З):DSBL (наиболее эффективный на сегодняшний день RBL из списков с минимальным риском заблэклистить что-либо нужное) строится практически исключительно по результатом сканирований удаленных хостов на открытые порты, проводимых администраторами крупных почтовых служб. В общем случае зависит от реализации — сканированию должны подвергаться только "подозрительные" хосты, попадающие под какой-либо критерий, например, большое количество примерно одинаковых писем на разные адреса в единицу времени.
(АН): Насколько я понимаю, сканирование портов — осуществляемое в первую очередь спаммерами, а не борцами с ними — позволяет выявить open relays, доступные для спаммерского использования. Мне кажется, что при оценке такой деятельности имеет смысл отталкиваться от ее цели. Спаммеры, сканируя ваши порты, проверяют возможность использования ваших серверов для собственной рассылки. Люди, в обязанности которых входит борьба со спамом, могут захотеть проверить тот или иной хост на предмет наличия там open relay выборочно — по факту получения несанкционированной рекламной рассылки оттуда.
В мире распространен способ борьбы со спамом, основанный на недопущении почты с open relays. Для этого составляются "черные списки", которые впоследствии используются либо провайдерами, либо клиентским софтом (SpamPal, например). Бывают, однако, случаи, когда несанкционированная реклама приходит с сервера, в принципе закрытого для проведения массовых рассылок (например, эту рекламу разослал некий локальный пользователь вручную по ограниченному списку). Вносить ли такой сервер в "черный список", или правильней ограничиться жалобой его админу? Для получения ответа на этот вопрос, мне кажется, совершенно легитимно проверить, открыт ли на данном сервере sendmail для посторонних отправителей спама. Если открыт — место такому серверу в RBL. Если закрыт — санкции следует применять не к серверу, а к конкретному его пользователю, злоупотребившему своим доступом к системе.
(ДЛ):Насколько я понимаю, к подобной методике прибегают в первую очередь серверы, поддерживающие всевозможные стоп-листы в целях поиска открытых релеев, доступных всем желающим. Впрочем, дело здесь ограничивается обычно лишь проверкой 25-го порта, в полном сканировании ради борьбы со спамом я не вижу никакого смысла.
(ГС):Простое сканирование портов не дает никакой информации для борьбы со спамом. Поэтому, если борьба со спамом не является отговоркой яндекса для прикрытия действий отдельных личностей, самостоятельно проведших сканирование, то значит, по моему мнению, речь идет о методике, используемой сетевыми червями или спамерам. Т.е. производится проверка на открытые proxy и relay. Но какой смысл производить проверку ВСЕХ портов? Например, 135-го? Можно было бы произвести проверку стандартных портов и портов, начиная с 1024. Такая проверка без разрешения владельца сети хотя и неэтична, на мой взгляд, но была бы, по крайней мере, обоснована. Честно говоря, я в последнее время уже и не знаю, чего мне не нравится больше: спам или борьба с ним. Одними лишь техническими методами проблемы спама и сканирования портов не решить. Тем более если, борясь с одной проблемой, усугубляешь другую. Надеюсь, что события, повлекшие дискуссию по этой теме, не вызваны официальной политикой уважаемого мною Яндекса, а являюся инициативой нижнего персонала, в отношении которых уже сделаны соответствующие выводы. :)
(ИМ):Сама эта история выглядит достаточно странно. Борьба со спамом тут явно не причем; официальный Яндекс скорее всего тоже. Вероятнее всего, это частная инициатива одного из специалистов Яндекса.
(ДМ):Просто сканировать порты достаточно глупо, если эти порты потом не проверяются на наличие сервисов. Можно конечно найти порты, на которых обычно стоят трояны, но это мало что даст, если эти порты потом не проверять. А если уж проверять, то это уже не просто сканирование портов.
(CR):Я думаю,что сканирование ВСЕХ портов — это слишком. Слишком грубый подход, который тратит время администраторов, трафик и время . Проверить конкретный порт того почтовика, что послал "предположительно" спам на open relay и сам хост на существование — разумно. Насколько распростанен подход Яндеса — не скажу. Не занимался этим вопросом.
Думаю, что в США за такое дают по шапке. Насчет других стран — трудно сказать. Официальная точка такая — бороться со спамом нужно на законодательной почве. :)
(СГ):Черные списки были и остаются наиболее эффективным методом борьбы с невостребованными почтовыми рассылками. Однако публичные черные списки зачастую имеют собственную политику, которая может не совпадать с политикой предприятия (например, доверенный сервер может быть занесен в список в RBL, что может привести к сбоям в почтовом обмене и как следствие — нарушению доступности СЭП, т.е. финансовым потерям). Сами серверы, поддерживающие списки, могу стать объектом атаки (информация может быть модифицирована или стать недоступной). Кроме того, в последнее время используются все более и более изощренные методы рассылки СПАМа. Подмена заголовков received, c целю добавления в них SMTP-узлов, не содержащихся в RBL, рассылка СПАМа через HTTP/Connect/FTP/Socks Proxy, использование HTML и скрытых полей с целью обмана систем контекстной фильтрации и баз данных сообщений, классифицированных как СПАМ и т.д. Несколько крупных вирусных эпидемий было направлено именно на заражение компьютеров троянскими программами, которые в дальнейшем могли бы использоваться для рассылки СПАМа (именно это, имхо, и является причиной последних антиспамерских акций, а не сам СПАМ).
В связи с вышесказанным, определение доверенности узла, от которого пришло почтовое сообщение, кажется мне довольно эффективным методом.
Идея заключается в анализе журналов севера SMTP с целью определения доверенности серверов, с которых почта была передана во внутреннюю сеть. В случае если данный сервер не является доверенным и отсутствует в черных списках, производится его тестирование на предмет наличия Proxy/Relay/Trojan, и если были обнаружены признаки одного из перечисленного, хост заносится в соответствующую зону для игнорирования/дополнительной обработки сообщений от этого источника.
Так же сканироваться могут все узлы в цепочке Received. Дополнительным критерием при проверке доверенности узла может выступать наличие соответствующей MX-записи в системе DNS.
Таким образом, у каждого почтового сервера появляется свой RBL, динамически обновляемый и управляемый непосредственно администратором узла. Кроме того, данные этого списка могут быть опубликованы для использования доверенными узлами.
В качестве примера реализации можно рассматривать http:// www.drbl.ofisp.org/ .
Информацией о распространенности не обладаю, однако считаю, что это довольно эффективный и мощный механизм.
Вопрос N4 адресован к провайдерам: Как вы реагируете на жалобы на сканирование портов? Оговариваются ли последствия подобных инцидентов при заключении договора с вашими клиентами?
Zenon N.S.P:Общий ответ на ваш вопрос таков: подобные действия запрещены в пункте 6 Приложения 2 к Договору с пользователем:
«УСЛОВИЯ ПРЕДОСТАВЛЕНИЯ УСЛУГ
6. АБОНЕНТУ запрещается:
Осуществлять попытки несанкционированного доступа к ресурсам ПРОВАЙДЕРА и к другим системам, доступным через сеть Интернет.
...»
Но, тем не менее, каждый конкретный случай и каждая жалоба рассматриваются персонально.
Андрей Гасов, ЗАО "Элвис Телеком":На мой взгляд подобные действия полностью определены в документе "Нормы пользования сетью" (http://www.ofisp.org/).
Этот документ является неотъемлемой частью договора с конечным пользователем. Если поступают жалобы на сканирование портов нашими клиентами, мы выясняем, кто, что и зачем сканил и, если эти действия нарушают "Нормы пользования сетью", имеем вполне законное право прекратить предоставление услуг.
Мирон М. Рудник, MSM:Мы регистрируем на сканирование портов только нашего центрального узла. Если сканирование носит достаточно постоянный характер или может иметь потенциальную угрозу, мы связываемся с техническим персоналом провайдера (источника) и решаем с ним эту проблему.
Если к нам обращаются с жалобами на сканирование, которое осуществляет какой-нибудь из наших клиентов, мы предупреждаем клиента, если он конечный. Если же клиентом является провайдер услуг, переадресуем жалобу в техническую службу данного провайдера.
Постоянные жалобы на действия клиента могут привести к его отключению на основании пункта договора:
5.3 Абоненту запрещается:
1. Передавать в сеть информацию, оскорбляющую честь и достоинство Других Абонентов и обслуживающего персонала msm.ru.
2. Использовать предоставленный ему доступ в сеть msm.ru для несанкционированного доступа и порчи компьютеров, к которым возможен доступ через сеть msm.ru.
Денис В. Губанов, ЗАО "Диджитал Нетворк":Реагируем просто: отключаем и всего делов :) В договоре оговариваем подобные инциденты.
Зарубин Сергей, ЗАО "Демос-Интернет":В структуре Компании существует Группа реагирования на нарушения информационной безопасности. В соответствии с процедурой эскалации докладов, как абоненты компании, так и сторонние пользователи сети Интернет сообщают Группе об имеющихся несанкционированных обращениях или иных аномалиях в области информационной безопасности. Компания выполняет сбор и сохранение данных, реагирование на нарушения информационной безопасности.
При использовании услуг сети Интернет/Россия Абонент ЗАО "Демос- Интернет" обязуется соблюдать Регламент, в котором оговорены недопустимые действия и ответственность Абонента в случае его нарушения.
SecurityLab.ru
Сетевые решения. Статья была опубликована в номере 10 за 2003 год в рубрике sysadmin
