GF - Global Forum

Объявление

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.

Вы здесь » GF - Global Forum » Безопасность » Статьи, новости.

Статьи, новости.

Страница: 1

Сообщений 1 страница 4 из 4

1

  • Автор: Anton
  • Админ
  • Anton
  • Откуда: Россия
  • Зарегистрирован: 09-04-2008
  • Приглашений: 0
  • Сообщений: 1357
  • Уважение: +2
  • Пол: Мужской
  • Возраст: 38 [1986-04-29]
  • Провел на форуме:
    1 день 2 часа
  • Последний визит:
    04-06-2012 18:53:25

Выкладываем статьи, новости и всю полезную информацию.

2

  • Автор: Anton
  • Админ
  • Anton
  • Откуда: Россия
  • Зарегистрирован: 09-04-2008
  • Приглашений: 0
  • Сообщений: 1357
  • Уважение: +2
  • Пол: Мужской
  • Возраст: 38 [1986-04-29]
  • Провел на форуме:
    1 день 2 часа
  • Последний визит:
    04-06-2012 18:53:25

Броня для Висты: создание безопасного кода для Windows Vista

Автор: Николай Байбородин

О нововведениях в Windows Vista не говорил только ленивый. Набили оскомину и рассуждения о том, насколько трудно разработчикам софта обеспечить совместимость их программных продуктов с новой концепцией безопасности, реализованной в этой ОС. Но хватит нытья, пора заставить работать систему на себя, использовав средства обеспечения безопасности Windows Vista в своем ПО. Сегодня мы поговорим о том, как новая система помогает бороться с атаками на переполнение.

Новая концепция безопасности
По сравнению с Windows XP, Vista более устойчива перед такими ошибками (читай: атаками), как переполнение буфера. Ряд технологий позволяет избежать этой досадной неприятности или хотя бы смягчить ее последствия. Ты легко можешь реализовать поддержку всех этих новых средств защиты программного кода в своих проектах. При этом все, что от тебя потребуется, - это включить соответствующие опции компоновщика.

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

Мы рассмотрим такие технологии защиты от переполнения, как ASLR, случайная адресация стека и кучи, NX, GS и SafeSEH. Некоторые из них являются принципиально новыми, другие представляют собой улучшенные версии технологий, входящих в состав Windows XP SP2 и Windows Server 2003. Большинство из рассмотренных технологий имеют реализацию не только от самой Microsoft, но и от других производителей как программного обеспечения, так и железа.

Введение в ASLR
Технология случайного распределения адресного пространства, или ASLR (Address Space Layout Randomization), нацелена на то, чтобы защитить системный API от различной нечисти. Принцип действия этой технологии ясен уже из названия - случайному распределению подвергаются адреса загрузки системных библиотек, начальный указатель стека и начальный указатель кучи. В Windows XP все эти адреса были статичными и, соответственно, были хорошо известны создателям эксплойтов.

Если говорить откровенно - а у меня нет никаких причин излишне льстить парням из Редмонда, хотя... если они мне хорошо заплатят, то такие причины моментально найдутся (IMG:style_emoticons/default/smile.gif) - так вот если говорить откровенно, то в ASLR не было бы никакой необходимости, не будь архитектура операционных систем семейства Windows, мягко говоря, немного странной. Вот что я имею в виду. Все системные файлы в Windows-системах загружаются в память с заранее определенным смещением. Именно этой особенностью и пользуются авторы эксплойтов, поскольку всегда заранее точно известно, по какому адресу находится дырявая функция, для которой веселые парни приготовили маленький, но очень полезный патчик. Будь архитектуры Windows изначально ориентированы на случайное распределение адресного пространства, многих проблем удалось бы избежать.

ASLR включает в себя случайное распределение следующих элементов:

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

В общем виде атака на переполнение сводится к двум вещам: поиск участков кода, в которых возможно возникновение неотслеживаемых исключительных ситуаций, и поиск диапазонов адресного пространства, в которых может быть расположен вредоносный код с последующей передачей ему управления. Одним из обязательных условий успешного завершения атаки является идентичность адресного пространства программы на машине жертвы и адресного пространства программы на машине хакера. В результате случайного распределения адресного пространства в Windows Vista дырявый модуль, расположенный по определенному адресу, при следующей загрузке системы или на другой машине окажется совершенно в ином месте. Аналогично с модификацией кода через загрузку посторонних DLL – для того чтобы подцепить к программе свою библиотеку, хакеру нужно отыскать функцию LoadLibrary. Но при каждом запуске программы адрес, по которому она расположена, будет разный!

Возможно, у тебя возник вопрос о том, что произойдет в результате многократного перезапуска системы. Иначе говоря, как долго Vista сможет назначать загружаемым библиотекам и функциям неповторяющиеся адреса? На этот интересный вопрос есть вполне конкретный ответ. При каждой загрузке системной библиотеки или исполняемого файла происходит случайная адресация из 256 возможных вариантов. В результате шанс загрузить эксплойт по месту назначения равен 1/256.

Допустим, у нас есть жутко полезная программа, состоящая всего из одной функции и нескольких строк кода, выводящих на консоль основные значения адресного пространства программы: адрес загрузки Kernel32.dll, адрес функции LoadLibrary и т.д. (исходник ищи на нашем диске).

Запустив ее на выполнение, можно увидеть в консоли примерно следующее:

Kernel32 loaded at 77400000
Address of LoadLibrary = 77A04E7D

Если теперь перезагрузить компьютер и снова запустить программу на выполнение, результат будет отличаться от предыдущего:

Kernel32 loaded at 77B30000
Address of LoadLibrary = 773A0E7D

Кстати, для того чтобы воспользоваться технологией ASLR, при компиляции проекта в Visual Studio необходимо выставить опцию компоновщика /dynamicbase.

Запрет на выполнение
Следующий инструмент защиты программного кода отличается своей бескомпромиссностью. Это технология NX (No eXecute). Для тех, кто не в теме, поясню. Согласно этой концепции, которая реализована, кстати, не только компанией Microsoft, но и другими авторитетными конторами и известна под разными именами, программный код условно делится на две части. Первой может быть передано управление, но она не может быть перезаписана произвольными данными. Вторая может перезаписываться, но запуск на выполнение здесь уже запрещен. То есть по отношению к участку программного кода одновременно не могут быть реализованы обе привилегии – на запись и на выполнение. Как говорится, одно из двух. И никаких компромиссов.

Нельзя сказать, что в Microsoft в этом плане изобрели что-то принципиально новое. Стек с защитой от выполнения реализован в солярке от Sun Microsystems на несколько лет раньше, чем в Windows. Ну а самыми первыми такой подход к организации структуры программного кода опробовали разработчики OpenBSD. Другими словами, NX есть не что иное, как широко известная технология DEP (Data Execution Prevention). Реализация же NX-защиты сводится к присвоению особых меток сегментам памяти, предназначенным исключительно для хранения данных. Обнаружив попытку выполнения кода, записанного в такой сегмент, система устроит хакеру большой облом.

Для того чтобы реализовать в программном коде поддержку NX, в свойствах компоновщика выставляй ключ /NXCOMPAT. Кстати, софт, компоновка которого осуществлялась с упомянутым выше ключом, может воспользоваться преимуществами технологии NX или другой аналогичной технологии не только в среде Windows Vista, но и в Windows XP со вторым сервис-паком. Именно в Windows XP, а не в WV, как пишут многие, Microsoft впервые реализовала NX.

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

Стек под угрозой

const unsigned char scode[] = ... //зло (IMG:style_emoticons/default/happy.gif)
typedef void (*RunShell)(void);

int main (int argc, char* argv[]){
char StackBuf[256];
RunShell shell = (RunShell)(void*)StackBuf;
strcpy_s (StackBuf, sizeof(StackBuf), (const char *)scode);
(*shell)();
return 0;
}

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

Сообщение об ошибке содержит в себе адрес, по которому возникло исключение. В моем случае это 0x0012fe98. Что это за адрес? Это адрес, по которому расположился массив StackBuf. То есть причиной исключения стала попытка интерпретировать секцию с данными как набор инструкций.

Я уже упоминал, что подобная технология разрабатывается не только Microsoft, но и другими компаниями, в том числе и производителями железа. Достаточно часто встречаются технологии, аналогичные NX, реализованные на аппаратном уровне. Так что можешь еще раз изучить возможности BIOS своей тачки и поискать в ней соответствующий пунктик. Кстати, в Windows Vista можно посмотреть, защищен тот или иной компонент системы (либо стороннее приложение) технологией NX, с помощью диспетчера задач, в котором теперь есть колонка Data Execution Prevention.

Флаг GS
Это еще одна опция, которая, будучи использованной при сборке программы, повышает ее надежность в среде Windows Vista. Фишка здесь в следующем. При использовании опции /GS в момент записи содержимого регистра EBP в стек между локальной переменной, записанной в стеке, и ее адресом не существует прямой и однозначной связи. Вместо этого соответствие устанавливается через специальный посредник – сookie.

Благодаря этому становится невозможным прямое обращение к стеку и изменение содержащихся в нем значений переменных.

Защита стека с помощью cookie

void VulnerableFunc( const char* input, char* out )
{
// Готовим адресное пространство для локальных переменных
00401000 sub esp,104h
// Копируем секретный cookie в регистр eax
00401006 mov eax,dword ptr [___security_cookie (403000h)]
// Ксорим указатель вершины стека с помощью cookie
0040100B xor eax,esp
// Записываем результат в буфер
0040100D mov dword ptr [esp+100h],eax
char* pTmp;
char buf[256];

strcpy( buf, "Prefix:" );
00401014 mov ecx,dword ptr [string "Prefix:" (4020DCh)]
// Прячем аргументы функции за cookie
0040101A mov eax,dword ptr [esp+108h]
00401021 mov edx,dword ptr [esp+10Ch]

В качестве дополнительного бонуса от использования опции /GS мы получаем еще один уровень обнаружения переполнения стека. По утверждению представителей Microsoft, все исходники Windows Vista собраны с включенной опцией /GS. Так что делай выводы и пользуйся на здоровье.

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

Одна из разновидностей атаки на переполнение кучи заключается в заполнении ее большим объемом данных, после которого должна последовать не менее большая серия NOP’ов, что в конечном счете приведет к ошибке переполнения и передаче управления на шелл-код. Описанная технология достаточно стара и впервые серьезно посадила на измену пользователей по всему миру в далеком 2001 году в виде сетевого червя Code Red. С тех пор атаки на переполнение кучи стали более изощренными.

IT-сообщество осознало необходимость защиты кучи, и не только Microsoft, но и многие другие компании активизировали свою деятельность в этом направлении.

В довистовую эпоху (а не закрепить ли мне за собой авторские права на этот термин?) для защиты кучи приходилось сбрасывать в null все неиспользуемые указатели.

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

проверка валидности ссылок, связывающих с предыдущим и последующим элементом кучи;
случайное размещение блока метаданных (генерируется случайное число и ксорится с первоначальным адресом);
проверка целостности данных;
случайное размещение начального адреса кучи (работает только при использовании ASLR);
случайная адресация элементов, хранящихся в куче.
В том случае если проверка валидности ссылок, связывающих между собой элементы кучи, закончится неудачей, приложение будет аварийно завершено с целью предотвращения передачи управления на нелегитимный участок кода. В Windows XP при возникновении проблем со ссылками они просто игнорировались и выполнение программы не прерывалось. Это позволяло без особых усилий спровоцировать разрушение практически любого процесса.

Пример кода, подверженного атаке на переполнение кучи

char* pBuf = (char*)malloc(128);
char* pBuf2 = (char*)malloc(128);
char* pBuf3 = (char*)malloc(128);

memset(pBuf, 'A', 128*3);
printf("Freeing pBuf3\n");
free(pBuf3);
printf("Freeing pBuf2\n");
free(pBuf2);
printf("Freeing pBuf\n");
free(pBuf);

В Windows Vista, даже при отключенной опции terminate on corruption, обеспечивающей защиту кучи, при первой же попытке вызвать функцию free() из нашего примера выполнение программы будет прервано. На других системах, включая Windows XP и Windows Server 2003, проблема останется незамеченной. Однако радости в том, что процесс в лучших самурайских традициях скорее сделает себе харакири, чем даст себя опозорить грязному эксплойту, мало. Поэтому для того чтобы, обнаружив проблемы с защитой кучи, приложение не падало замертво, а отслеживало подобные инциденты и реагировало на них менее кровавым способом, верным решением будет использование опции terminate on corruption.

Для превращения программы из паникера–камикадзе в доблестного самурая необходимо добавить в функцию Main() или WinMain() несколько несложных строк:

bool EnableTerminateOnCorrupt()
{
if( HeapSetInformation( GetProcessHeap(),
HeapEnableTerminationOnCorruption, NULL, 0 ) )
{
printf( "Terminate on corruption enabled\n" );
return true;
}
printf( "Terminate on corruption not enabled - err = %d\n",
GetLastError() );
return false;
}

Естественно, при создании финального релиза отладочные функции printf() нужно будет заменить вызовом обработчика ошибок.

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

bool EnableLowFragHeap()
{
ULONG ulHeapInfo = 2;
if( HeapSetInformation( GetProcessHeap(),
HeapCompatibilityInformation, &ulHeapInfo, sizeof( ULONG ) ) )
{
printf( "Low fragmentation heap enabled\n" );
return true;
}
printf( "Low fragmentation heap not enabled - err = %d\n",
GetLastError() );
return false;
}

SafeSEH
И под занавес еще одна полезная опция. Наверняка, тебе уже приходилось иметь дело с такой фишкой, как Structured Execution Handler (SEH). SafeSEH, поддержка которой включена в Windows Vista, предоставляет собой еще более надежный механизм мониторинга динамических исключений. Эта опция компоновщика позволяет в момент вызова функции запоминать адрес, по которому этот вызов был осуществлен. После этого периодически осуществляется сравнение фактического адреса с тем, что запомнила система. И если обнаруживается несовпадение, значит что-то нарушило штатный ход выполнения программного модуля, и процесс тихо, без пыли и шума отправляется к праотцам.

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

Проще простого
Как видишь, вопреки сомнениям скептиков (весьма, кстати, обоснованных), Vista значительно продвинулась в плане защиты от атак на переполнение. Более того, все эти возможности доступны и тебе. Все, что от тебя требуется, – не полениться выставить соответствующие опции компоновщика. Конечно, можно попенять на некоторое снижение производительности, но... Будь откровенен сам с собой и признайся, что гораздо более серьезные накладные расходы тянет за собой код, написанный твоими же руками. Ведь времени на оптимизацию всегда не хватает, так же как и на обстоятельное тестирование. Так что, может быть, лучше, потеряв в производительности за счет повышения безопасности приложения, поискать эту производительность в другом месте?

3

  • Автор: Anton
  • Админ
  • Anton
  • Откуда: Россия
  • Зарегистрирован: 09-04-2008
  • Приглашений: 0
  • Сообщений: 1357
  • Уважение: +2
  • Пол: Мужской
  • Возраст: 38 [1986-04-29]
  • Провел на форуме:
    1 день 2 часа
  • Последний визит:
    04-06-2012 18:53:25

Методы защиты от DDoS нападений

-----------------------------------
Попасть под воздействие DDoS атаки – кошмарный сценарий для любого системного администратора, специалиста по безопасности или поставщика доступа. Обычно атака начинается мгновенно и без предупреждения и не прекращается со временем – система не отвечает, канал заблокирован, маршрутизаторы перегружены. Эффективный и быстрый ответ на нападение затруднителен и часто зависит от третих лиц, типа ISP провайдеров. В этой статье исследуется методы, которые должны использовать системные администраторы, если они когда-либо оказались в этой, довольно нежелательной, ситуации.
Обнаружение DDoS нападения
DDoS нападение распознать просто – замедление работы сети и серверов, заметное как администратору системы, так и обычному пользователю. Первым шагом в нашей защите мы должны идентифицировать тип трафика, который загружает нашу сеть. Большинство нападений DDoS посылает очень определенный тип трафика - ICMP, UDP, TCP, часто с поддельными IP адресами. Нападение обычно характеризует необычно большое количество пакетов некоторого типа. Исключением к этому правилу являются DDoS нападения, направленные против определенных служб, типа HTTP, используя допустимый трафик и запросы.

Чтобы идентифицировать и изучить пакеты, мы должны анализировать сетевой трафик. Это можно сделать двумя различными методами в зависимости от того, где исследуется трафик. Первый метод может использоваться на машине, которая расположена в атакуемой сети. Tcpdump - популярный сниффер, который хорошо подойдет для наших целей. Анализ трафика в реальном масштабе времени невозможен на перегруженной сети, так что мы будем использовать опцию "-w", чтобы записать данные в файл. Затем, используя инструмент типа tcpdstat или tcptrace, мы проанализируем результаты. Результаты работы tcpdstat, на нашем tcpdump файле:

DumpFile: test
FileSize: 0.01MB
Id: 200212270001
StartTime: Fri Dec 27 00:01:51 2002
EndTime: Fri Dec 27 00:02:15 2002
TotalTime: 23.52 seconds
TotalCapSize: 0.01MB CapLen: 96 bytes
# of packets: 147 (12.47KB)
AvgRate: 5.56Kbps stddev:5.40K PeakRate: 25.67Kbps

### IP flow (unique src/dst pair) Information ###
# of flows: 9 (avg. 16.33 pkts/flow)
Top 10 big flow size (bytes/total in %):
26.6% 16.5% 14.7% 11.6% 9.8% 7.6% 5.4% 5.4% 2.5%

### IP address Information ###
# of IPv4 addresses: 7
Top 10 bandwidth usage (bytes/total in %):
97.5% 34.1% 31.2% 21.4% 10.7% 2.5% 2.5%
### Packet Size Distribution (including MAC headers) ###
<<<<
[ 32- 63]: 79
[ 64- 127]: 53
[ 128- 255]: 8
[ 256- 511]: 6
[ 512- 1023]: 1
>>>>

### Protocol Breakdown ###
<<<<
protocol packets bytes bytes/pkt
------------------------------------------------------------------------
[0] total 147 (100.00%) 12769 (100.00%) 86.86
[1] ip 147 (100.00%) 12769 (100.00%) 86.86
[2] tcp 107 ( 72.79%) 6724 ( 52.66%) 62.84
[3] telnet 66 ( 44.90%) 3988 ( 31.23%) 60.42
[3] pop3 41 ( 27.89%) 2736 ( 21.43%) 66.73
[2] udp 26 ( 17.69%) 4673 ( 36.60%) 179.73
[3] dns 24 ( 16.33%) 4360 ( 34.15%) 181.67
[3] other 2 ( 1.36%) 313 ( 2.45%) 156.50
[2] icmp 14 ( 9.52%) 1372 ( 10.74%) 98.00
Как видно, эти простые утилиты могут быстро помочь определить тип преобладающего трафика в сети. Они позволяют сэкономить много времени, анализируя и обрабатывая зафиксированные пакеты.

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

access-list 169 permit icmp any any echo
access-list 169 permit icmp any any echo-reply
access-list 169 permit udp any any eq echo
access-list 169 permit udp any eq echo any
access-list 169 permit tcp any any established
access-list 169 permit tcp any any
access-list 169 permit ip any any
interface serial 0
ip access-group 169 in
Используя команду "show access-list", система покажет количество совпавших пакетов для каждого типа трафика:

Extended IP access list 169
permit icmp any any echo (2 matches)
permit icmp any any echo-reply (21374 matches)
permit udp any any eq echo
permit udp any eq echo any
permit tcp any any established (150 matches)
permit tcp any any (15 matches)
permit ip any any (45 matches)
Результаты просты, но эффективны – обратите внимание на высокое число ICMP echo-reply пакетов. Подробная информация может быть собрана о подозреваемых пакетах, добавляя в конец команду "log-input" к специфическому правилу. Это правило будет регистрировать информацию о любом ICMP трафике:

access-list 169 permit icmp any any echo-reply log-input
Маршрутизатор теперь более подробно регистрирует собранные данные (которые можно посмотреть используя "show log") о соответствующих пакетах. В пример ниже, файл регистрации показывает несколько пакетов, соответствующих правилу DENY ICMP:

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.72 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.154 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.15 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.47 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.35 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.59 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.82 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.56 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.84 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.47 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.35 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.15 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
%SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.33 (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
Обратите внимание на информацию, содержавшуюся в каждой строке: источник и адрес назначения, интерфейс и правило, которому оно соответствует. Этот тип детальной информации поможет определить нашу защиту.
Реакция
После того, как мы идентифицировали подозреваемый трафик, пришло время исследовать, как нам ответить на нападение. К сожалению, варианты несколько ограничены, потому что большинство DDoS нападений использует поддельные исходные IP адреса, которые вероятно сгенерированы случайным образом. Так что же нам делать?
Отслеживаем источник атаки
Первое, что приходит в голову, это попытаться "проследить" источник атаки. Однако DDoS, в отличие от традиционного DoS, исходит из множественных источников. Поэтому неплохо было бы определить транзитный маршрутизатор, через который проходят большинство пакетов. К сожалению, для этого потребуется сотрудничать с несколькими источниками, так как вы не способны исследовать пакеты на вышестоящих маршрутизаторах. Каждый участник процесса (главным образом ISP провайдеры) будут использовать очень похожие методы. Идентифицировав злонамеренный тип трафика, используя вышеописанные методы, будет создан новый список ограничения доступа. Добавив его к правилам, которые применены к интерфейсу, который посылает трафик атакуемому адресату, мы снова используем команду "log-input". Регистрация подробно запишет информацию об исходном интерфейсе и MAC адресе источника атаки. Эти данные могут использоваться, чтобы определить IP адрес маршрутизатора, отправляющего злонамеренный трафик. Процесс будет повторен на следующем маршрутизаторе в цепочке. После нескольких итераций, источник (или один из них) будет обнаружен. Тогда можно создать соответствующий фильтр, который заблокирует атакующего. Недостаток в этом методе защиты от DDoS нападения – время и сложность. Получение таких данных требует работы с несколькими сторонами, и иногда использование правового принуждения.
Ограничение допустимого предела (“rate limit”)
Лучший способ немедленной помощи, доступный большинству ISP провайдеров, должно быть “ограничение допустимого предела” злонамеренного типа трафика. Ограничение допустимого предела ограничивает пропускную способность, которую определенный тип трафика может потреблять в данный момент времени. Это может быть достигнуто, удаляя полученные пакеты, когда превышен некоторый порог. Полезно, когда определенный пакет используется в нападении. Cisco предлагает способ, который позволяет ограничить ICMP пакеты, используемые в нападении:

interface xy
rate-limit output access-group 2020 3000000 512000 786000 conform-action
transmit exceed-action drop
access-list 2020 permit icmp any any echo-reply
Этот пример поднимает интересную проблему, которая была отмечена ранее. Что, если злонамеренный трафик полностью законный? Например, ограничение SYN flood, направленное на Web сервер, отклонит и хороший и плохой трафик, так как все законные подключения требуют начального установления связи. Это трудная проблема, не имеющая простого ответа. Нельзя просто защитится от таких типов хитрых DDoS нападений, не принося в жертву часть законного трафика.
Фильтрация черной дыры
ISP провайдеры могут использовать другие способы защиты, которые зависят от изменения маршрутизации, типа фильтрации “черных дыр”. “Black hole” фильтрация отправляет злонамеренный трафик к воображаемому интерфейсу, известному как Null0 – подобный /dev/null на Unix машинах. Так как Null0 - не существующий интерфейс, трафик, направленный к Null0, по существу удаляется. Кроме того, эта методика минимизирует воздействие производительности, так как остальная часть сети остается устойчивой при тяжелых загрузках.

Важно отметить, что адресная фильтрация - не лучший способ защиты против DDoS нападений. Даже если вы заблокировали нападение на своем маршрутизаторе или межсетевой защите – все еще большие порции входящего трафика могут затруднить прохождение законного трафика. Чтобы действительно облегчить эффект от DDoS нападения, трафик должен быть блокирован в вышестоящей цепочке – вероятно на устройстве, управляемом большим провайдером. Это означает, что многие из программ, которые утверждают, что предотвращают DDoS нападения, в конечном счете, бесполезны для маленьких сетей и их конечных пользователей. Кроме того, это означает, что предотвращение DDoS нападения, в некоторый момент, не зависит от нас. Это печальная правда, понятная любому, кто когда-либо имел дело с проблемой.
Предотвращение
Если вы удачно защитились от DDoS нападения, удостоверьтесь, что вы используете следующие предосторожности, которые будут препятствовать вашей собственной сети участвовать в DDoS нападениях.

Нужно включить команду "ip verify unicast reverse-path" (или не Cisco эквивалент) на входном интерфейсе подключения восходящего потока данных. Эта особенность удаляет поддельные пакеты, главную трудность в защите от DDoS нападений, прежде, чем они будут отправлены. Дополнительно, удостоверьтесь, что блокирован входящий трафик с исходными адресами из зарезервированных диапазонов (то есть, 192.168.0.0). Этот фильтр удалит пакеты, источники которых очевидно неправильны.

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

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

inattack.ru

4

  • Автор: Anton
  • Админ
  • Anton
  • Откуда: Россия
  • Зарегистрирован: 09-04-2008
  • Приглашений: 0
  • Сообщений: 1357
  • Уважение: +2
  • Пол: Мужской
  • Возраст: 38 [1986-04-29]
  • Провел на форуме:
    1 день 2 часа
  • Последний визит:
    04-06-2012 18:53:25

Бронежилет для файрвола: как защитить свой файрвол и антивирус от набега малвари

Очень часто антивирусы и брандмауэры превращаются из охотников в жертвы. В борьбе с активной малварью еще и не такое случается. И хотя разработчики всячески пытаются защититься от посягательств со стороны зловредного кода, воздвигая целый комплекс средств противовоздушной обороны, при схватке с грамотно спроектированным зловредным кодом они обречены на поражение. Как усилить защиту уже существующих антивирусов/брандмауэров, не вмешиваясь в их машинный код и не ковыряя исходные тексты, которых у нас все равно нет? Реально ли это вообще? Еще бы!

Мужская часть населения еще помнит те давние время, когда антивирус (вместе со всеми базами и самой MS-DOS) умещался на одной «стерильной» дискетке с защитой от записи откуда его настоятельно рекомендовалось запускать. Запуск антивируса из-под зараженной операционной системы часто приводил к ложным негативным срабатываниям. То есть антивирус не находил даже известные ему вирусы, а все потому, что зловредный код слишком хорошо знал антивирус и модифицировал его код, отвечающий за распознавание заразы.

Современные антивирусы на дискету уже не влезают и вынуждены сражаться с активной малварью, в арсенале которой помимо многочисленных маскировочных методов имеется и оружие возмездия. Аналогичным образом дела обстоят и с персональными брандмауэрами. Их тяжело пробить снаружи (то есть с удаленной машины), но легко отключить локально, внедрившись в адресное пространство брандмауэра или поигравшись с элементами управления путем эмуляции клавиатурного/мышиного ввода (атаки типа WM_).

Конечно, разработчики всячески защищаются от нападок со стороны вредоносного кода (например, путем проверки целостности собственного тела). Однако получается у них не очень хорошо, и вообще создается впечатление, что они в первую очередь озабочены качеством детекции и количеством распознаваемых вирусов, то есть предпочитают нападать, а не обороняться. Вот только, вырвавшись вперед, они рискуют оказаться в плотном кольце окружения. «Независимые» обзоры также не уделяют защите никакого внимания, тестируя антивирусы/брандмауэры в лабораторных условиях.

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

Статья построена на основе анализа большого количества малвари. Мыщъх исследовал наиболее популярные техники противодействия антивирусам/брандмауэрам и разработал простые и эффективные «бронежилеты», пригодные для защиты уже существующих программ без какой бы то ни было их переделки. Поэтому не волнуйся: дизассемблер тебе не понадобится!
Стратегические ракеты межпроцессорного назначения

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

Порядка 80% зловредных программ открывают процесс-жертву API-функцией OpenProcess, получая (в случае успешного завершения операции) дескриптор процесса, передаваемый API-функции ReadProcessMemory. Последняя читает содержимое памяти процесса-жертвы и копирует его во внутренний буфер малвари, которая путем сигнатурного поиска пытается отловить все известные ей защитные программы (список активных процессов можно получить средствами TOOLHELP32). Если подобная программа обнаруживается, малварь смотрит в свою базу сигнатур, извлекая смещение машинных команд, которые надлежит нейтрализовать, что осуществляется путем перезаписи памяти жертвы API-функцией WriteProcessMemory. В большинстве случаев достаточно заменить пару условных переходов, навсегда отучив антивирус/брандмауэр ругаться грязными словами.

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

Внедрение в посторонние процессы осуществляется различными путями. Классический способ (работающий только в NT-подобных системах) — создать удаленный поток вызовом API-функции CreateRemoteThread или NativeAPI-функции NtCreateThread, однако перед этим необходимо забросить зловредный код внутрь атакуемого процесса. И тут хакеру на помощь приходят API-функции: AllocateVirtualMemory (для выделения блока памяти) или QueryVirtualMemory (для поиска уже выделенного блока, пригодного для внедрения) с последующим вызовом WriteProcessMemory.

Внедрение в стиле модерн апеллирует к манипуляциям с процессорным контекстом. Новые потоки при этом не создаются. Внутрь процесса-жертвы записывается зловредный код (и тут без WriteProcessMemory никак не обойтись!), а затем API-функциями GetThreadContext/SetThreadContext регистр-указатель команд перемещается на начало зловредного кода, длина которого обычно составляет несколько десятков байт — вполне достаточно, чтобы загрузить свою динамическую библиотеку или «открыть портал». Но это уже детали реализации.

Некоторые (между прочим, достаточно многие) антивирусы/брандмауэры перехватывают вызовы WriteProcessMemory/SetThreadContext и поднимают тревогу, если запись происходит в секцию кода. Однако этот перехват достаточно легко обойти: например, вызывать API-функции не с первого байта, эмулируя выполнение пропущенных команд; или же внедряться в область данных. Правда, при активном аппаратном DEP попытка внедрения в область данных ведет к исключению, завершающему работу атакуемого приложения в аварийном режиме.

Обойти контроль за SetThreadContext можно путем подключения псевдоотладчика (созданного малварью) к процессу-жертве API-функцией DebugActiveProcess, за которой не следит ни один известный мне защитный механизм; и хакер может преспокойно получать контекст потока в свое распоряжение через генерацию отладочных событий. Такой способ внедрения в антивирусы/брандмауэры встречается все чаще и чаще.

Примерно 10% зловредных программ лезут в следующую ветку системного реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs, добавляя туда свою динамическую библиотеку, которую операционная система будет проецировать на адресное пространство всех GUI-приложений, передавая ей бразды правления до их запуска. Практически все современные защитные комплексы следят за AppInit_DLLs и начинают жутко материться, если там обнаруживается новая DLL. Однако, если малварь хакнула AppInit_DLLs до запуска антивируса/брандмауэра, им остается только утереться, поскольку кто первый получает управление, тот царь и король.

Еще приблизительно 10% зловредных программ борются с защитами через оконный интерфейс. Что может быть проще! Находим окно по его заголовку (API-функции FindWindow или EnumWindows), добираемся до элементов интерфейсного управления и начинаем хачить их по своему усмотрению. Зловредный код может подавить появление нежелательных окон (например, сделав их невидимыми — API-функция ShowWindow), найти кнопку с надписью «Yes» и «надавить» на нее путем посылки соответствующих Windows-сообщений. Или же заблокировать все кнопки (API-функция WindowDisable). Наконец, можно забраться в настройки и отключить защиту, а чтобы пользователь ничего не заметил, каждый раз подсовывать ему поддельный экран. И это не фантастика! Такие вирусы уже есть, причем совсем не один, а написать их может даже школьник, едва осиливший Delphi и пролиставший по диагонали SDK.

Другой излюбленный объект атаки - файл \WINNT\System32\Drivers\etc\hosts, позволяющий сопоставлять IP-адреса с доменными именами и имеющий приоритет над DNS-сервером. То есть если малварь не хочет, чтобы антивирус обновлялся, то она просто добавляет в hosts-файл одну строчку, перенаправляя запросы к серверу обновлений куда-нибудь еще, например на локальный узел жертвы (которому соответствует адрес 127.0.0.1) или, что еще хуже, на сервер самого создателя малвари, распространяющий вредоносные обновления, которые содержат не только сигнатуры, но и машинный код. И хотя антивирусные базы в большинстве своем защищены цифровыми подписями и другими криптографическими средствами, при большом желании со стороны хакера их можно обойти.

Впрочем, пора уже разобрать несколько эффективных приемов обороны от всего этого безобразия.
Способ 1. Используем «бронежилет»

Малварь нужно бить еще на взлете. Самое простое, что можно только сделать, — это упаковать антивирус/брандмауэр достойным протектором, препятствующим сигнатурному поиску и внедрению в охраняемый процесс постороннего кода. Крутых протекторов сейчас как никогда много, взять хотя бы туже Themid'у (которая в просторечии завется Фемидой). Правда, на официальном сайте (wwworeans.com) лежит только демонстрационная версия…

Чем хороша Фемида? А тем, что перехватывает и блокирует следующие API-функции: NtAllocateVirtualMemory, NtCreateThread, NtQueryVirtualMemory, NtReadVirtualMemory, ZwTerminateProcess, NtWriteVirtualMemory. Префикс Nt означает, что мы имеем дело с NativeAPI-функциями, самыми низкоуровневыми системными функциями, доступными на прикладном уровне, что одним махом срубает до примерно 80% всей малвари. Конечно, если малварь работает на уровне ядра, то это другое дело, но и в этом случае ей придется изрядно напрячься, поскольку тело упакованного файла зашифровано и расшифровывается динамически по ходу его исполнения, тут же зашифровываясь вновь.

Без функции NtReadVirtualMemory малварь обломается с чтением содержимого защищенного процесса, а значит, не сможет отличить антивирус/брандмауэр от остальных программ. Запрет на создание удаленных потоков NariveAPI-функцией NtCreateThread не позволит внедриться в адресное пространство жертвы, тем более что NtWriteVirtualMemory все равно не работает. Ну и как бедная малварь должна копировать зловредный код?

Аналогичным образом обстоят дела и с другими атаками. Обработанный Фемидой файл практически неуязвим. Зачастую настолько неуязвим, что вообще неработоспособен. Фемида не самый корректный упаковщик, и простейший контроль целостности, выполняемый антивирусом/брандмауэром, тут же показывает, что с файлом что-то не то. Как следствие, антивирус/брандмауэр выдает на экран предупреждающее сообщение или вообще отказывается работать. В такой ситуации нам остается либо взять в лапы hiew и вырезать из антивируса/брандмауэра систему самоконтроля, которая нам только мешает, либо же, поигравшись с настройками протектора, выбрать компромиссный вариант, который и от малвари защищает и ругательств со стороны защиты не вызывает.
Способ 2. Зовем на помощь отладчик

Если примирить защиту с протектором никак не получается, имеет смысл обратиться за помощью к отладчику, например к бесплатно распространяемому OllyDdb. Просто загружаем защищаемую программу в Ольку (или прицепляется к уже запущенному процессу: «File -> Attach») и нажимаем <F9> (Run) для нормального продолжения выполнения программы без трассировки.

Что это дает? Во-первых, поскольку отладка в Windows нереентерабельна, то процесс, находящийся под покровительством Ольки, не может отлаживать никто другой, и попытки малвари зацепиться за него ни к чему не приведут. Так же Олька позволяет отслеживать появление новых потоков (как локальных, так и удаленных). Достаточно в меню «Options -> Debugging Options» взвести галочку «Break on new thread» во вкладке Event. Тогда отладчик будет останавливаться всякий раз при создании нового потока. И хотя антивирусы/брандмауэры активно создают свои собственные потоки в целях производственной необходимости (что очень надоедает), все-таки такая защита лучше, чем совсем никакой.

А если еще взвести и галочку «Break on new module» (DLL), то отладчик будет останавливаться при загрузке всякой динамической библиотеки. И хотя опять-таки антивирусы/брандмауэры могут подгружать библиотеки по ходу дела, обычно это происходит в строго определенных ситуациях при совершении пользователем тем или иных действий. Беспричинная загрузка DLL с вероятностью, близкой к единице, свидетельствует об атаке!
Способ 3. Используем биты NX/XD

Наконец, высший пилотаж — защита кодовых секций от внедрения. Работает только на процессорах с поддержкой битов NX/XD (то есть достаточно современных процессорах) и с XP SP2 с задействованным аппаратным DEP для всех приложений (по умолчанию DEP распространяется только на системные компоненты).

В отладчике нажимаем <ALT-M>, чтобы увидеть карту адресного пространства. Находим там модуль, имя которого совпадает с именем антивирусного процесса; видим секцию .text (реже CODE), щелкаем правой клавишей мыши, в контекстом меню выбираем пункт «Set Access -> Execute» - и все! С этого момента любая попытка чтения секции кода приведет к исключению, отлавливаемому отладчиком и блокирующему атаку. Напоминаю, что этот трюк действует только при соответствующей поддержке со стороны операционной системы и процессора (за подробностями отсылаю к своей статье, где все это описано). Правда, если антивирус/брандмауэр попытается подсчитать контрольную сумму кодовой секции для проверки собственной целостности, то его встретит жестокий облом. Впрочем, мы можем нажать <F9> для продолжения выполнения кода или на время снять запрет на чтение кодовой секции, только это все равно не спасет от малвари, модифицирующей стек или секцию данных. Но, к счастью, умной малвари в живой природе практически не встречается, и все больше приходится бороться со студенческими поделками.

Другая возможная проблема - антивирус/брандмауэр может не захотеть запускаться из-под отладчика, например, потому что доверху нашпигован различными антиотладочными приемами. Ну и что нам делать?!
Способ 4. Настраиваем права доступа

Хорошая идея — запустить антивирус/брандмауэр от имени администратора, а самим работать в пользовательской сессии. Тогда малварь, обладающая пользовательскими правами, просто не сможет открыть процесс защищенного приложения. Запуск программ от имени другого пользователя (в данном случае администратора) осуществляется штатной командой runas с ключами /profile и /env, копирующими профиль и среду текущего пользователя. Без этих ключей антивирус/брандмауэр, не найдя своих настроек, может просто не запуститься!

Запуск приложений от имени администратора - достаточно надежное средство защиты от посягательств на адресное пространство защищаемого процесса со стороны малвари, но! Эмуляция клавиатурного/мышиного ввода продолжает работать, что не есть хорошо. Как этому противостоять?! Увы, ответ обескураживающий. Даже со всеми нововведениями Windows Vista — никак. Единственная зацепка — заголовок окна. Большинство зловредных программ именно так и «палит» антивирусы/брандмауэры. Ну, изменить заголовок не проблема. Это умеет делать любой продвинутый твикер, например старый-добрый Customiser. Он же умеет двигать элементы управления (например, кнопки), изменяя их размеры. Зачем это нужно?! А затем, что более продвинутая малварь не смотрит на заголовок главного окна, а сечет раскладку дочерних элементов управления, поскольку положение и размеры элементов управления уникальны для каждого приложения, и их (в целях маскировки) рекомендуется слегка изменять. Customizer (как и большинство других твикеров подобного типа) позволяет сохранять профили изменений, автоматически восстанавливая их при каждом запуске и освобождая нас от необходимости делать эту рутинную работу вновь и вновь.
Способ 5. Защищаем hosts-файл

Следи также за файлом \WINNT\System32\Drivers\etc\hosts, удаляя посторонние записи. В принципе ничего не мешает грохнуть и сам файл hosts, поскольку очень мало пользователей использует его по назначению.

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

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

Автор: Крис Касперски

Страница: 1

Вы здесь » GF - Global Forum » Безопасность » Статьи, новости.