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

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

Немного теории — наиболее применимая архитектура торрент трекера представляет собой — форумный движок, база данных форума, анонсер, отвечающий за работу с торрент клиентами, и база данных статистики, к этому можно еще приплюсовать хостинг картинок. Конечно если торрент трекер обслуживает одновременно до 30-40 тысяч раздач и в районе 500 активных пользователей в пике на форуме, то все это вполне уживается на одном сервере, в достаточно стандартной конфигурации, но вот дальнейший переход в высшую лигу, сопровождается разделением хранения и управления всего этого хозяйства.

Все это хозяйство хостится и крутится на 2-4 (возможно и более) серверах до определенного момента без последствий, пока однажды не пришли гости и не изъяли сервер(а). Практика показывает, что происходит это достаточно внезапно и владелец ресурса к этому не совсем готов.

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

«Бекап в облако»… Как красиво это звучит, и как симпатично предлагается на рынке! Я смотрю по сторонам, и удивляюсь: весь мир сходит с ума по онлайн-хранению документов. Dropbox, Wuala, Zumodrive, Box.net — выбирай, не хочу! Каждый отличается чем-то своим, каждый старается подвигнуть жить в своей парадигме, со своим клиентом, каждый уверяет в сохранности и неприкосновенности данных.

Последнее, правда, наводит на размышления. Я верю в искреннее желание авторов этих сервисов сделать все по уму, безопасно и просто красиво. Но я, при этом, понимаю, каким сильным может быть давление обстоятельств — то всплывает тема разбирательства с пользователями, которые хранят что-то не то (а судить, то или нет, почему-то хочет кто-то третий — и круг имеющих доступ к данным растет), то, как будто бы без причины, шифр оказывается расшифровываемым не только владельцем, то сервера сервиса оказываются не самым лучшим образом доступными. Все это заставляет меня задуматься, а есть ли смысл пользоваться чем-то внешним, по определению не самым надёжным, и хочу ли я успокаивать себя, что «не такая я важная птица, никому мои данным не нужны».

Введение | Tor | Tarzan и MorphMix | Малозатратная атака | Малозатратная атака на Tarzan и Morphmix | Принципы построения безопасных систем (заключение)

Для проверки на Tarzan и MorphMix мы взяли ту же модель атаки которая использовалась в Tor. Нападающему нужно две вещи: вредоносный узел и вредоносный сервер. В качестве вредоносного узла в обоих сетях (Tarzan и MorphMix) будет выступать отправитель. В терминологии Tarzan он называется Tarzan-клиент, в MorphMix — узел-инициатор.

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

Несколько часов назад довелось мне искать инфу об одном лекарстве. Первая же ссылка в гугле — то, что надо — на сайт для мамочек. Почитав немного, мозг понял, что текст левый, совсем не по теме. Но закладку закрывать я не стал — увидел знакомые символы =)
Вместо страницы красивеньким образом отдавался ее код, в plain text. Дальше — больше!

Сегодня мы начнем разговор о системах класса Identity Management. Как многие из вас знают, 1 июля закончился срок действия отсрочки вступления в силу федерального закона РФ от 27 июля 2006 года № 152-ФЗ «О персональных данных»

Соответственно, для управления персональными данными в ИТ крупные компании будут вынуждены внедрять специализированные системы класса IDM для управления информацией о пользователях своих корпоративных систем. Если раньше наблюдался некоторый дефицит квалифицированных кадров в этой области, то теперь этот дефицит примет катастрофические масштабы, так как гром грянул, и мужику положено начать креститься.

Дефицит кадров в этой специализированной области обусловлен тем, что специалист по IDM должен обладать сразу несколькими навыками в ИТ – он должен хорошо разбираться в устройстве различных систем информационной безопасности, иметь практический опыт системного администрирования, быть неплохим программистом для написания адаптеров и сценариев обработки данных, уметь описывать и ставить бизнес-процессы. И при этом он не должен беситься от огромного количества рутинной работы по выверке персональных данных. Могу практически со стопроцентной уверенностью утверждать, что таких людей в природе не существует. С этим фактом связана извечная головная боль сотрудников HR, которые вообще смутно себе представляют нашу специфику, а тут еще им приходится иметь дело с такой гремучей смесью несовместимых навыков.

Единственным выходом из ситуации является разделение работы минимум на двоих. Один может программировать коннекторы к системам безопасности, настраивать внутренние workflow, писать скрипты и заниматься развертываением. Второй должен работать с пользовательскими данными, описывать бизнес-процессы, заниматься документированием и продвижением идеи IDM в ИТ массы.

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

Я искренне надеюсь, что после прочтения данного материала у коллег прибавится ясности по данному вопросу, и многие программисты или системные администраторы смогут перейти в лагерь бизнес-аналитиков по IDM, чтобы составить достойную конкуренцию тем немногим работающим в этой области «звездам».

Введение.

Про SNORT было сказано много, но в большинстве статей речь идёт о SNORT, как о средстве тотального наблюдения за сетью, которое собирает все данные с сетевого интерфейса. В этой статье я расскажу как собрать конструкцию, в которой SNORT будет в режиме IPS следить не за всем трафиком на интерфейсе, а только за трафиком, который можно описать с помощью правил для iptables. Я не буду касаться настройки правил, речь будет исключительно о том, как на голой системе собрать SNORT для работы в режиме IPS и как подойти к защите им абстрактного сервиса. Так же будет описана сборка и запуск SNORT.

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

Для шифрования была выбрана распределенная файловая система Tahoe-Lafs, построенная на технологии p2p. Достоинство данной технологии, что файлы шифруются и записываются на ноды в виде кусочков (подобно bittorrent). А сохранять данные будем в программу wuala (облачную проприентарную файловую систему, аналог dropbox).

Вопрос безопасности всегда будет актуальным, особенно в Сети. По этому, чтобы в один прекрасный день не получить на своем ресурсе такую картинку нужно уметь проверять на предмет уязвимостей себя самого.

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

У статьи довольно низкий порог вхождения для понимания и использования, по этому, надеюсь, придется по душе многим. Раскрывается лишь базовый функционал программ.

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

Естественно, статью можно перевести и в технику взлома ресурсов. Но чтобы знать, как защищать — надо знать, как взламывать. Ответственность за приобретенные знания вы берете на себя ;)

И если вы, как разработчик, будете знать хотя бы некоторые принципы и техники, что используют хакеры — думаю вам станет чуть спокойнее за них (ресурсы) и результат вашей деятельности приобретет более высокий уровень

В статье отображен аудит базового уровня, сохраняем низкий порог для чтения и понимания.

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

Есть куда более полезная и подробная памятка по ssh от amarao, а эта статья пусть останется в том виде, в котором была написана в далеком 2011.

Этой заметкой я хочу показать, что использовать ключи для авторизации это просто.

Начнем с того, что нам понадобится PuTTY.
Идем на http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html и качаем следующее:
PuTTY — ssh-клиент
Pageant — агент для хранения ключей (зачем объясню позже)
PuTTYgen — генератор ключей

Год назад сотрудники факультета ВМК МГУ имени М. В. Ломоносова и компании Яндекс начали читать спецкурс по информационной безопасности, который растянулся на целый учебный год, и разбит на два тематических раздела: «Введение в информационную безопасность» и «Практические аспекты сетевой безопасности».

В порядке эксперимента курс сопровождала аудио- и видеозапись лекций, а также вики для размещения материалов по курсу. Закончив за лето обработку видеоматериалов, предлагаем получившийся видеокурс широкой публике, то есть вам. Все материалы опубликованы под лицензией CC-BY-SA 3.0.

Я.Видео: первая часть, вторая часть.

Два исследователя из Godai Group решили поставить эксперимент и проверить, сколько приватной информации можно собрать, если регистрировать домены с опечатками и поднимать на них почтовые серверы. Оказалось, что этот приём на редкость эффективен. На 30-ти «фальшивых» доменах за шесть месяцев скопилось 20 ГБ писем (около 120 000), отправленных компаниям из списка Fortune 500. Примерно 1% из этих писем содержат конфиденциальную информацию — логины и пароли сотрудников, информацию по сделкам, внутренним расследованиям и т.д.

120 тысяч писем — неплохой результат, учитывая пассивность метода сбора и абсолютную секретность. За полгода никто ничего не заметил.

Во всей индустрии информационной безопасности меня всегда смущало идейное противоречие между тем, чем занимаются люди, связанные с ИБ и тем, как они называют своё занятие.

Не существует объективных методов оценки безопасности информационной системы. Все существующие методы могут говорить либо об опасности (так нельзя, это нельзя, тут дыра), либо говорить о соответствии системы каким-то требованиям какого-либо сертифицирующего органа… И вот тут, внимание, следите за руками, соответствие этим требованиям называют критериями безопасности. Мол, прошла сертификацию на SFOD-12, значит безопасна. Главное — иметь бумажку. А авторам этой бумажки — надуться посолиднее, чтобы авторитетом доказать, что безопаснее некуда.

Причина — в неконструктивном смысле слова «безопасность». Что такое «безопасная система»? Это система, у которой нет части функционала (например, которая НЕ даёт доступа к информации, или которая НЕ предоставляет какую-то функцию). Таким образом, безопасная система, это система, в которой КРОМЕ описанного в ТЗ нет НИКАКОГО ДРУГОГО функционала.

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

Spoofed SYN — атака, при которой заголовки пакетов подделывается таким образом, что место реального отправителя занимает произвольный либо несуществующий IP-адрес.

Так как по сути SYN является частым инструментом "интенсивной конкурентной борьбы" и — в то же время — большинство решений DDoS mitigation показывают впечатляющую эффективность именно на этом виде атак, то и мы начнем c SYN-flood, рассмотрев spoofed-вид атаки, как самый грозный из них.

К функционалу программы добавлены 2 техники: SSL MiTM и SSL Strip.

Первая является старой классической техникой подмены сертификатов.
Позволяет перехватывать данные любого протокола, защищенного при помощи SSL.
Стандартно поддерживаются: HTTPS\POP3S\SMTPS\IMAPS.
Опционально можно указать любой дополнительный порт.

При перехвате HTTPS, сертификаты генерируются «на лету», копируя оригинальную информацию
с запрашиваемого ресурса. Для всех других случаев используется статичный сертификат.

Естественно, при использовании данного функционала неизбежны предупреждения браузера и другого
клиентского ПО.



SSL Strip — «тихая» техника для перехвата HTTPS соединений. Долгое время рабочая версия
существовала только под unix, теперь подобные действия можно проводить и в среде NT.

Суть в следующем: атакующий находится «посередине», анализируется HTTP трафик, выявляются все https:// ссылки и производится их замена на http://

Таким образом клиент продолжает общаться с сервером в незащищенном режиме. Все запросы на замененные ссылки контролируются и в ответ доставляются данные с оригинальных https источников.

Т.к. никаких сертификатов не подменяется, то и предупреждений нет.
Для имитации безопасного соединения производится замена иконки favicon.

Одно закономерное условие успешного перехвата — URL должен быть введен без указания префикса https.



Официальный сайт — sniff.su

Что такое Meterpreter?

Meterpreter — расширенная многофункциональная начинка (Payload), которая может быть динамически расширена во время выполнения. В нормальных условиях, это означает, что это обеспечивает Вас основной оболочкой и позволяет Вам добавлять новые особенности к ней по мере необходимости.

Первым, наиболее частым действием является внедрение в процесс explorer'a. Эту возможность предоставляет команда migrate:

meterpreter > migrate 1888 #1888 — PID процесса, вывести список процессов - ps
[*] Migrating to 1888...
[*] Migration completed successfully.

Далее, как правило, выполняется повышение привилегий до системных. Для этого существует команда getsystem, использующая уязвимость, которая была обнаружена во всех версиях Windows, начиная с версии 3.1:

meterpreter > getsystem
...got system (via technique 1).

Когда вы передаёте кому-то по почте или скайпу секретный текст/ссылку/пароль, то стоит предусмотреть дополнительные меры безопасности. А именно, подумать о том, что копия вашего сообщения хранится во многих местах: в логах почтового сервера, в истории сообщений Skype, в истории браузера. Как обеспечить секретность информации в таких условиях?

Оригинальный способ придумали разработчики сервиса One-Tme Secret. Их веб-приложение создано для вставки фрагментов текста и генерации одноразовых URI, которые срабатывают только один раз, после чего информация стирается с сервера. Принцип описывается известным выражением «после прочтения уничтожить». Вдобавок, серверы не хранят никакой информации о посетителях сайта и не ведут логов, если верить разработчикам, но они, вроде бы, порядочные ребята.

Кому-то сама идея публиковать что-то секретное на чужом сервере покажется странной (таким людям лучше вообще не пользоваться интернетом), но в определённом смысле передача секретной информации по HTTPS действительно безопаснее, чем передача незашифрованного текста через почтовые серверы. Да и вообще, генерация одноразовых URI может пригодиться в разных ситуациях.

P.S. Ещё один похожий сервис: TMWSD (This Message Will Self-Destruct).

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

Собственно сам продукт ничем по себе не интересен и полезен только администраторам сайта, т.к. позволяет редактировать наглядно страницы на сайте. Но меня он заинтересовал с точки зрения — на сколько безопасно его внедрение в CMS, особенно в связи с тем что он обладает набором функционала по UPLOAD'у картинок на сайты.

И о чудо, разработчики CMS на ровном месте совершили сразу несколько критических ошибок, сразу предоставив доступ к выполнению исходного кода на сайте!

Итак, что они же натворили?

Когда-то давно взбрела мне в голову идея: написать свой собственный поисковик. Было это очень давно, тогда я еще учился в ВУЗе, мало чего знал про технологии разработки больших проектов, зато отлично владел парой десятков языков программирования и протоколов, да и сайтов своих к тому времени было понаделано много.

Ну есть у меня тяга к монструозным проектам, да…

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

На данный момент у меня есть собственный, обучающийся поисковик от и до, со многими нюансами – подсчетом PR, сбором статистик-тематик, обучающейся функцией ранжирования, ноу хау в виде отрезания несущественного контента страницы типа меню и рекламы. Скорость индексации примерно полмиллиона страниц в сутки. Все это крутится на двух моих домашних серверах, и в данный момент я занимаюсь масштабированием системы на примерно 5 свободных серверов, к которым у меня есть доступ.