Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Довольно интересно.
Хорошоя идея… походу она не залежится! )))
В качестве цента управления можно использовать поисковые системы, только это будет довльно медленная реализация, сильно зависящая от частоты индексации страниц поисковиками. Что я имею ввиду? Зараженные боты ищут, скажем, в гугле определенную фразу \ сигнатуру, затем по определенным правилам парсят страницу, где данная фраза \ сигнатура была найдена и получают команды. Благодаря этому можно вообщше не затрачиватся на выделенные абузоустойчивые сервера, так же это обеспечит децентрализованное управление…
>Основная проблема p2p заключается в том, что оно очень легко фильтруется нехитрым набором правил блокирующих udp пакеты и tcp пакеты вне разрешенного диапазона.
Не очень понятно, что мешает мне создать пакеты почти идентичные разрешенным, только с каким нибудь маленьким довеском, за счет которого будет сформирован скрытый канал? По-моему это гораздо проще и безопаснее чем палиться непонятными при просмотре логов заходы на социальные сети.
Не очень понятно, что мешает мне создать пакеты почти идентичные разрешенным, только с каким нибудь маленьким довеском, за счет которого будет сформирован скрытый канал? По-моему это гораздо проще и безопаснее чем палиться непонятными при просмотре логов заходы на социальные сети.
тем что трафик который идёт от клиента к серверу выдаёт сервер управления. В случае использования социальной сети сервер управления оставляет свои команды в блоге и его адрес тонет в куче пользовательского трафика. А насчет довеска давно есть не очень широко используемый метод дописывания в конец картинки куска трояна. Далее дроппер собирает из нескольких графических файлов один исполняемый и запускает.
Можете сами попробовать. возьмите например eicar, упакуйте его в zip и добавьте в конец картинки через far(append). Потом эту картинку проверьте антивирусом.
Можете сами попробовать. возьмите например eicar, упакуйте его в zip и добавьте в конец картинки через far(append). Потом эту картинку проверьте антивирусом.
Тот же самый skype не слишком легко фильтруется, хотя сокрытие своей деятельности и не является его основным функционалом.
P.S. А в чем заключается поддержка jabber'а компанией mail.ru?
P.S. А в чем заключается поддержка jabber'а компанией mail.ru?
Skype можно фильтровать, метод уже есть. достаточно надёжный :)
PS: Есть неофициальные данные что mail.ru агент будет поддерживать jabber.
PS: Есть неофициальные данные что mail.ru агент будет поддерживать jabber.
Кстати, а где можно почитать по поводу фильтрации skype?
SearchInform недавно анонсировали SkypeSniffer www.searchinform.ru/press-releases/full-text-search-press-releases-detailed.html?nid=94
кто-нибудь видел это дело живьем? Интересно как работает.
SearchInform недавно анонсировали SkypeSniffer www.searchinform.ru/press-releases/full-text-search-press-releases-detailed.html?nid=94
кто-нибудь видел это дело живьем? Интересно как работает.
Скайп по сигнатуре фильтруют пакетов, вот и все. www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6723/prod_white_paper0900aecd80633b0a.html например описывает для сиско девайсов.
Сервер управления оставляет адрес в блоге и все? А клиент к этому блогу не должен коннектиться с какой-то периодичностью? А логи обращения к блогу? Их при всем желании те кому очень надо всегда смогут найти. По-моему это тоже самое, что использовать какие-то промежуточные машины, которые уж точно никаких логов хранить не будут, для управления.
Все кому очень надо смогут найти, только вот никакой информации почерпнуть не смогут, ибо большинство данных будет зашифровано. Ручная фильтрация URL слишком трудоёмкий процесс, а уж отслеживание разрозненных подключений в логах прокси в общем потоке данных тем более.
Что значит зашифровано? Коннект сервака к блогу ведь будет записан в лог сервака на котором хостится блог?
Вы себе представляете объём логов к примеру хабрахабра? или жж? или flickr?
у меня 500 пользователей на проксе генерят ежедневно лог размером в 300-400 метров.
А насчет зашифровано — значит например используется Blowfish для шифрации контента, а сам контент лежит в base64 кодировке на странице пользователя.
у меня 500 пользователей на проксе генерят ежедневно лог размером в 300-400 метров.
А насчет зашифровано — значит например используется Blowfish для шифрации контента, а сам контент лежит в base64 кодировке на странице пользователя.
А если еще посыпать стеганографией — то всё. Пиши — пропало. =)))
я уверен, что все блоги хранят информацию о том, кто и когда написал какой пост(в смысле с какого айпишника) — тем более это не так много по объему. Совсем немного, ибо я знаю хостера одного совсем слабого сервачка, который хранит базу из айпишников более чем 5000 пользователей, которые посещали сайт за последние 5 лет.
Что такое «об том»? в заголовке? мб «о том»?
Большинство ботнетов организуется на пользовательских машинах имеющих прямой доступ в инет. В корпоративных сетях вероятность заражения меньше, но последствия могут быть тяжелее.
Администраторы по честному отрабатывающие свои деньги и мониторящие все происходящее в сети довольно легко могут блокировать те или иные функции ботнетов практически лишая их средств к размножению. Так например изоляция Conficker очень проста. Переводите хост на IP адрес с маской 255.255.255.255 посредством dhcp и бот просто напросто задыхается от отсутствия ресурсов, вторым вариантом является блокировка DNS (перевод запросов на другой сервер не имеющий доступа в инет с отключенной функцией forward dns lookups).
Для блокировки p2p в большинстве случаев достаточно отключить udp трафик.
В пользовательских сетях это сделать невозможно, т.к. это обычно противоречит правилам договора о предоставлении услуг связи.
Администраторы по честному отрабатывающие свои деньги и мониторящие все происходящее в сети довольно легко могут блокировать те или иные функции ботнетов практически лишая их средств к размножению. Так например изоляция Conficker очень проста. Переводите хост на IP адрес с маской 255.255.255.255 посредством dhcp и бот просто напросто задыхается от отсутствия ресурсов, вторым вариантом является блокировка DNS (перевод запросов на другой сервер не имеющий доступа в инет с отключенной функцией forward dns lookups).
Для блокировки p2p в большинстве случаев достаточно отключить udp трафик.
В пользовательских сетях это сделать невозможно, т.к. это обычно противоречит правилам договора о предоставлении услуг связи.
а как замутить свой ботнет?
не, я серьезно ))
[в образовательных целях, не для применения!] Во первых понадобится необходимое ПО, которое обеспечит необходимый функционал (в зависимости от требований — сокс-бот, ддос-бот, лоадер, формграбер, и т.д, либо «комбаин») а так же наиболее подходящий метод управления (централизованный \ децентрализованный). Затем понадобится связка эксплоитов, iframe-трафик и выделенный абузоустойчивый сервер. И под конец — нужны прямые руки, связку и билд бота нужно будет постоянно криптовать.
Благо в паблике все выше перечисленное уже довольно не актуально, можно купить на черном рынке, но цены довольно высокие.
Благо в паблике все выше перечисленное уже довольно не актуально, можно купить на черном рынке, но цены довольно высокие.
А о чём статья? Как управлять ботнетами? Так у меня например ни одного нет и, наверно, не будет — как и у подавляющего большинства посетителей хабра. Да и проблемы в их управлении, судя по всему, нет. Есть проблема в их подавлениии — вот бы об этом почитать было интересно.
Главное решения подавления ботнета довольно избита и проста — «не сиди под рутом».
Статья о том, что нас может ждать в будущем. Соответственно с указанными в статье вариантами, можно уже потихоньку продумывать механизмы противодействия (это со стороны сист. администратора). Либо можно начинать паниковать и биться головой об стену, что скоро админы забанят на работе соц. сети (для пользователей) :)
Эта бодяга будет вечной… Разумеется, антивирусные компании меньше всего заинтересованы в том, чтобы ботнетов просто не стало. Гораздо интереснее и выгоднее за ними бесконечно гоняться, время от времени поднимая панику среди юзеров.
IMHO надо было давно похерить практику безответственности разработчиков ПО — принцип «as is». (Между прочим, далеко не все его используют.)
Если софт взломали — надо бить производителя по кошельку. Если компания берёт деньги за софт и при этом он дыряв как дуршлаг и она не может обеспечить его безопасность годами — такая компания обязана разориться! Если компания выпускает софт «как бы» бесплатно (например, по бизнес-модели браузера Opera) и не обеспечивает его безопасность — то же самое. Выпуск дырявого софта рассматривать как преступление против сети и общества, и наказывать соответственно. Если даже это программист одиночка, абсолютно бесплатно выложивший свой софт «людЯм», и софт становится популярным (тысячи инсталляций) — изволь следить за безопасностью своего творения, или прекращай распространение т.к. наносимый им вред начинает превышать приносимую пользу.
Ответственность необходима! Иначе этот бардак с глючным и дырявым софтом, вирусами, ботнетами, etc. будет вечен.
IMHO надо было давно похерить практику безответственности разработчиков ПО — принцип «as is». (Между прочим, далеко не все его используют.)
Если софт взломали — надо бить производителя по кошельку. Если компания берёт деньги за софт и при этом он дыряв как дуршлаг и она не может обеспечить его безопасность годами — такая компания обязана разориться! Если компания выпускает софт «как бы» бесплатно (например, по бизнес-модели браузера Opera) и не обеспечивает его безопасность — то же самое. Выпуск дырявого софта рассматривать как преступление против сети и общества, и наказывать соответственно. Если даже это программист одиночка, абсолютно бесплатно выложивший свой софт «людЯм», и софт становится популярным (тысячи инсталляций) — изволь следить за безопасностью своего творения, или прекращай распространение т.к. наносимый им вред начинает превышать приносимую пользу.
Ответственность необходима! Иначе этот бардак с глючным и дырявым софтом, вирусами, ботнетами, etc. будет вечен.
Декларации далёкого от вычислительной техники и программирования человека… Софт, в котором не будет ошибок и производитель которого будет отвечать за дыры деньгами, будет стоить на порядки дороже.
Проблема ботнетов не в софте — проблема в людях, и даже не в них, а в том, что технологии обгоняют общественное сознание. Что нельзя выливать помои из окон все уже знают, что нельзя разбрасывать ножи и топоры около дома тоже все знают, а о том, что свой домашний компьютер опасней и ножа и топора, и помои из него льются -этого большинство не понимает.
Проблема ботнетов не в софте — проблема в людях, и даже не в них, а в том, что технологии обгоняют общественное сознание. Что нельзя выливать помои из окон все уже знают, что нельзя разбрасывать ножи и топоры около дома тоже все знают, а о том, что свой домашний компьютер опасней и ножа и топора, и помои из него льются -этого большинство не понимает.
ой, умора… :) ну да, дальше меня от вычислительной техники вообще некуда… :) лол. вы меня довели до слёз.
Знаете, насчёт «дороже». Я лично в этом не уверен. Оценивая «на глаз» стоимость безопасности моего софта я считаю что это не более 10% от общей стоимости продукта. А при правильно поставленных процессах — и того меньше. Вот скажите, сколько стоит гарантировать отсутствие дыр класса SQL-injection в коде большого проекта? Нисколько, если все SQL-запросы будут выполняться через специальные функции, гарантирующие экранирование параметров при подстановке их в запрос — в perl за это отвечает модуль DBI и надо очень постараться, чтобы допустить такую дыру. Аналогично и для абсолютного большинства других ошибок: можно поставить процессы разработки таким образом, что эти ошибки просто не будут возникать, а там, где их всё-таки сделали — код будет выглядеть очень нетрадиционно и бросаться в глаза. Вопрос не в цене, нет, говорю Вам это как человек совсем близкий к этому вопросу. Вопрос в том, что заморачиваться на безопасность тупо облом — и так покупают, и никакой ответственности за эти дыры никто не несёт.
Знаете, насчёт «дороже». Я лично в этом не уверен. Оценивая «на глаз» стоимость безопасности моего софта я считаю что это не более 10% от общей стоимости продукта. А при правильно поставленных процессах — и того меньше. Вот скажите, сколько стоит гарантировать отсутствие дыр класса SQL-injection в коде большого проекта? Нисколько, если все SQL-запросы будут выполняться через специальные функции, гарантирующие экранирование параметров при подстановке их в запрос — в perl за это отвечает модуль DBI и надо очень постараться, чтобы допустить такую дыру. Аналогично и для абсолютного большинства других ошибок: можно поставить процессы разработки таким образом, что эти ошибки просто не будут возникать, а там, где их всё-таки сделали — код будет выглядеть очень нетрадиционно и бросаться в глаза. Вопрос не в цене, нет, говорю Вам это как человек совсем близкий к этому вопросу. Вопрос в том, что заморачиваться на безопасность тупо облом — и так покупают, и никакой ответственности за эти дыры никто не несёт.
>Нисколько, если все SQL-запросы будут выполняться через специальные функции,
>гарантирующие экранирование параметров при подстановке их в запрос — в perl за это
>отвечает модуль DBI и надо очень постараться, чтобы допустить такую дыру.
Это высказывание показывает Вашу несостоятельность как perl-программиста. Именно такие методы защиты от ошибок и приводят к ошибкам.
>гарантирующие экранирование параметров при подстановке их в запрос — в perl за это
>отвечает модуль DBI и надо очень постараться, чтобы допустить такую дыру.
Это высказывание показывает Вашу несостоятельность как perl-программиста. Именно такие методы защиты от ошибок и приводят к ошибкам.
Хотя может быть я и поспешил — наверняка вы имели ввиду placeholder'ы?
Насчёт большинства других ошибок… Пока никому кроме Бернштейна не удалось поставить такой процесс, а Бернштейн пожертвовал модифицируемостью за безопасность. Пути написания безопасного софта известны, но цена — именно на порядки выше. Это и переписывание всех сторонних библиотек — никаких OpenSSL использовать не удастся, это поддержание своей личной системы защищённых DNS серверов, это модифицированные версии протоколов TCPIP. На практике нереализуемо.
Насчёт большинства других ошибок… Пока никому кроме Бернштейна не удалось поставить такой процесс, а Бернштейн пожертвовал модифицируемостью за безопасность. Пути написания безопасного софта известны, но цена — именно на порядки выше. Это и переписывание всех сторонних библиотек — никаких OpenSSL использовать не удастся, это поддержание своей личной системы защищённых DNS серверов, это модифицированные версии протоколов TCPIP. На практике нереализуемо.
Разумеется.
Кстати, вместо OpenSSL я использую MatrixSSL. DNS сервера — да, стоит djbdns везде включая домашную рабочую станцию. :) TCPIP правда пока не модифицировал — а что, уже надо? :)
И я не согласен насчёт «на порядки». Большая часть операций по обеспечению безопасности одноразовая. К примеру, переход на MatrixSSL в своих модулях я сделал один раз, и потом годами пользуюсь не тратя дополнительных усилий. Hardened на Gentoo тоже настроен был один раз, и теперь его поддержка на всех машинах занимает максимум 5% от общего времени при обновлении системы. Защита от SQL-инъекций тоже однократная — много лет назад разобрался с DBI, и теперь писать защищённый код нужно столько же времени, сколько и дырявый.
$dbh->do("UPDATE x SET a=?",undef,$a); Для php тоже вроде такие функции есть, только с менее удобным интерфейсом.Кстати, вместо OpenSSL я использую MatrixSSL. DNS сервера — да, стоит djbdns везде включая домашную рабочую станцию. :) TCPIP правда пока не модифицировал — а что, уже надо? :)
И я не согласен насчёт «на порядки». Большая часть операций по обеспечению безопасности одноразовая. К примеру, переход на MatrixSSL в своих модулях я сделал один раз, и потом годами пользуюсь не тратя дополнительных усилий. Hardened на Gentoo тоже настроен был один раз, и теперь его поддержка на всех машинах занимает максимум 5% от общего времени при обновлении системы. Защита от SQL-инъекций тоже однократная — много лет назад разобрался с DBI, и теперь писать защищённый код нужно столько же времени, сколько и дырявый.
Вы еще скажите, что ваш софт не содержит ошибок)
Ошибки — есть. Куда-ж без них. Они везде есть. К сожалению.
А вот дыр в безопасности, насколько мне известно — не содержит. А в случае если дыра обнаруживается:
А вот дыр в безопасности, насколько мне известно — не содержит. А в случае если дыра обнаруживается:
- — дыра закрывается не только там, где её нашли, но и в других местах (т.е. проводится аудит всего проекта(ов) на аналогичные дыры)
- — корректируется процесс разработки, чтобы гарантировать отсутствие такого рода дыр в будущем
Для того чтобы написать багоустойчивый софт нужно:
а) Более высокая квалификация программистов
б) Больше времени затратить на разработку
Из этого получаем намного более высокую стоимость продукта.
К томуже проблему это не решит, а лишь уменьшит.
В курпных проектах обеспечить отсутствие багов и уявзвимостей невозможно.
а) Более высокая квалификация программистов
б) Больше времени затратить на разработку
Из этого получаем намного более высокую стоимость продукта.
К томуже проблему это не решит, а лишь уменьшит.
В курпных проектах обеспечить отсутствие багов и уявзвимостей невозможно.
В курпных проектах обеспечить отсутствие багов и уявзвимостей невозможно.Отсутствие багов и в небольших проектах невозможно обеспечить. Даже программы типа hello world в определённых условиях глючат. :)
А вот с уязвимостями — другая картина. Обеспечить отсутствие определённого класса ошибок (вроде code-injection, SQL-injection, XSS) не сложно — достаточно корректно экранировать все данные (для этого высококвалифицированные программисты не нужны, нужно просто соблюдать простые правила при работе с данными). И одно это поднимет безопасность проекта на невероятную высоту, по современным меркам.
Статья — говно, Вы ничего не понимаете в ботнетах
ну вот, человек подвёл итог всех рассуждений ))))))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Будущее ботнетов или размышления об том, что нас может ждать.