LINUX.ORG.RU

Проблема с безопасностью, однако...


0

0

Честно говоря, я сперва запостил сообщение об этой проблеме в форум General, вот здесь http://www.linux.org.ru/jump-message.jsp?msgid=411790 но потом решил послать сообщение и в этот форум, поскольку здесь оно более по теме. Помогите, пожалуйста.

★★★

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

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

А как насчёт варианта с настройкой фильтра провайдера? Чтобы он рубил пакеты с внешними запросами на мою машину? В этом случае провайдер не будет считать такие запросы входящим трафиком? (И как вообще флудер может инициировать запрос на мою машину, если у меня нет реального IP)?

bsh ★★★
() автор топика
Ответ на: комментарий от ivlad

И кстати, только что связался с провайдером, так вот, он отрицает возможность флуда, поскольку у меня нет реального айпи, и к тому же, на файрволе провайдера заданы "антифлудинговые" правила фильтрации.

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

bsh ★★★
() автор топика
Ответ на: комментарий от bsh

В твоей локальной сети вряд ли есть пользователи способные на такое. Хотя у меня аналогичная ситуация и я при желании легко мог бы выбрать лимиты всех пользователей причем так, что в их log-файлах не было бы об этом ни строчки.

anonymous
()
Ответ на: комментарий от anonymous

>В твоей локальной сети вряд ли есть пользователи способные на такое

Это очень сложно? Нельзя ли в общем описать процедуру такого взлома?

Если это не взлом изнутри локалки, и не флуд, тогда что?

bsh ★★★
() автор топика
Ответ на: комментарий от bsh

Это совсем элементарно при наличии кое-какой специальной аппаратуры (именно аппаратуры, не программ). Описывать процедуру не буду - те, кто это знает (примерно 50%) и так поймут о чем я говорю, а наталкивать остальных на нехорошие мысли не хочется...

anonymous
()
Ответ на: комментарий от bsh

> А как насчёт варианта с настройкой фильтра провайдера?

никак. если ваш провайдер настроил фильтр у себя, то вышестоящий провайдер уже все равно принял трафик для вашего провайдера и выставит ему счет.

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

Никакой специальной аппаратуры тут не требуется, это ерунда. Флудер можно на коленке написать.

ivlad ★★★★★
()
Ответ на: комментарий от bsh

ну вероятностей масса. arp poison, например.

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

> Никакой специальной аппаратуры тут не требуется, это ерунда

ну-ну... данный человек определенно относится не к тем 50%-ам

> Такой флуд будет и незаметен и пройдет брэндмауэры с большой вероятностью

еще одно ну-ну....

вообще "флудить потом по соответствующим портам" во многих случаях занятие бессмысленное - хотя бы потому что и iptables nat и брандмуер IOS используют динамические наборы правил.

anonymous
()
Ответ на: комментарий от anonymous

для элитных хакеров повторяю по второму разу: диапазон портов, на которые производится трансляция, становится известным, если атакуемый, например, посетил сайт атакующего или, скажем, послал DNS запрос на сервер атакующего.

После этого в ответе можно флудить довольно долго, потому что iptables вообще не имеют понятия о application level state а в PIX ("брандмуер IOS" - это что-то непонятное, нет такого; есть PIX и есть IOS firewall feature set) оно куцое. "динамические наборы правил" - это вообще непонятно о чем.

Если у автора есть желание продолжать дискуссию, предлагаю привести конкретные примеры. Если таких примеров нет, по это, извините, пустой треп.

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

Не знаю бывают ли здесь "элитные хакеры", а лично у меня (и не хакер и не элитный...) ни малейшего желания продолжать дискуссию нет. По одной простой причине - я вижу, что Вы, уважаемый, не вполне владеете данным вопросом.
По поводу Cisco, попробуйте почитать вот это
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration...
Я при этом не говорю о других способах ограничения трафика, которые могут быть применены в данной ситуации.
Просто советую подумать над простым вопросом: единственный ли Вы такой "умный" человек, который в состоянии додуматься до DoS атаки аналогичной приведенной выше? Легко ли атаковать машину не имеющую публичного ip? Придумал ли кто-нибудь до Вас способы защиты от таких атак?

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

В заключение хочу добавить: насколько легко, по-Вашему, организовать атаку с собственного DNS сервера (или любого промежуточного узла потому что подмена ip тут, по понятным причинам, работать не будет).

P.S. Не надо высасывать из пальца надуманные угрозы - в жизни достаточно реальных.

anonymous
()
Ответ на: комментарий от anonymous

Я, конечно, не такой большой специалист, как oxinian :), но всё-же постараюсь ответить.

Пусть у тебя частный адрес 10.0.0.1, ты стоишь в маскарадинге за гейтом с внешним адресом 12.0.0.1 (gate.good.com) и внутренним адресом 10.0.0.9.
Допустим, ты отправляешь DNS-запрос с 10.0.0.1 UDP:8276 на хост 13.0.0.1 (dns.evil.org) UDP:53.
Файрволл совместно с NAT'ом создают следующие динамические правила для твоего соединения:

NAT:
-----------------------------------------------+--------------------------------
--------
            original ip-packet                 |            new ip-packet                 
src_ip    dst_ip    ip_proto src_port dst_port |src_ip    dst_ip   src_port dst_port
-----------------------------------------------+--------------------------------
--------
10.0.0.1  13.0.0.1  udp      8276     53       |12.0.0.1  original 7921     original
13.0.0.1  12.0.0.1  tcp      53       7921     |original  10.0.0.1 original 8276
-----------------------------------------------+--------------------------------
--------

Фильтры:
--------------------------------------------------------------
if      src_ip    dst_ip    ip_proto src_port dst_port action 
--------------------------------------------------------------
in int  10.0.0.1  13.0.0.1  udp      8276     53       allow
out ext 12.0.0.1  13.0.0.1  udp      7921     53       allow
in ext  13.0.0.1  12.0.0.1  udp      53       7921     allow
out int 10.0.0.9  10.0.0.1  udp      53       8276     allow
--------------------------------------------------------------

Порт 7921 назначен маскарадингом.

Эти правила живут до тех пор, пока по ним что-нибудь бегает (неважно -- ответ от DNS-сервера, или флуд), и убиваются по таймауту.

Если кто-либо будет знать параметры соединения 12.0.0.1 UDP:7921 <-> 13.0.0.1 UDP:53, и будет знать, что это соединение является результатом работы NAT'а, то он может начать посылать на 12.0.0.1 UDP:7921 пакеты от адреса 13.0.0.1 UDP:53 с произвольным содержимым. Эти пакеты будут через NAT доходить до машины с частным адресом 10.0.0.1.
Узнать параметры этого соединения несложно, особенно если оно установлено с твоим сервером. ;)

Это ответ на вопрос "Легко ли атаковать машину не имеющую публичного ip".

Теперь как защищаться от таких атак. Только средствами поддержки прикладных протоколов для NAT'а и фильтров.

Если фильтры и NAT будут понимать, что в ответ на DNS запрос может приходить только 1 пакет с заданным содержимым, то никакой флуд в ответ не пройдёт, т.к. динамические правила будут убиты после получения одного-единственного пакета с корректным содержимым.

Аналогично всё это работает и для других протоколов.

Уф-ф-ф-ф. :(

anonymous
()
Ответ на: комментарий от anonymous

А нельзя ли хотя бы в общем обьяснить, как заставить фильтры и NAT понимать что в ответ на ДНС запрос может приходить только один пакет с заданным содержимым?

anonymous
()

Re:

Кстати, я выяснил, что с этого айпишника (192.123.41.41) шёл трафик в обе стороны с начала месяца с перерывами в некоторые дни. Причём даже тогда, когда я инетом вообще не пользовался. Например в один день по статистике провайдера, были соединения с тремя хостами, два из которых ДНС сервера (один моего прова, другой - вышестоящего прова), а третий - вот этот самый айпи. Вариант, что я вышел в онлайн, никакие страницы не открывал и его закрыл - нереален, и, если мне не изменяет память - в этот день я инетом не пользовался по причине очень плохой связи (мой провайдер переносил антенны). Я так понимаю, что вариант с трояном, самостоятельно выходящим в онлайн (то есть который сам способен запустить браузер, соединиться по ssl с провайдером, ввести пароль и логин и установить коннект) при условии физического отсуствия связи маловероятен. Я слышал про то, что можно узнать mac адрес сетевой карты другого компа, и прописать у себя, и если есть пароль и логин др. пользователя, злоумышленник может пользоваться инетом за счёт другого юзера, выдавая свои коннекты за чужие. Может это как раз тот случай?

Помогите, плиз, а то инетом пользоваться невозможно (вчера добавил 50 метров на счёт - сегодня счёт уже пустой). По некоторым причинам провайдера я сменить не могу, а он похоже, беспомощен в этой ситуации. Что можно сделать? Забанить этот злополучный айпишник? А что если имеет место быть подмена айпи в заголовках пакетов? Да и хотелось бы всё-таки узнать, в чём же причина?

bsh ★★★
() автор топика
Ответ на: комментарий от anonymous

Используя только правила фильтрации и NAT'а сетевого уровня этого сделать нельзя.

Ещё раз: нужна поддержка фильтрации и NAT'а для протоколов прикладного уровня.
Посмотри на CheckPoint FW.

anonymous
()

Результаты проверки chkrootkit

А вот здесь http://www.linux.org.ru/jump-message.jsp?msgid=416659 продолжение истории с воровством траффика. Очень хотелось бы найти ответы на вопросы, заданные мной в этой теме.

bsh ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.