|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-===========-
-/dev/random-
-===========-
Темка немного избитая, потому вошла сюда:
Защита исходного кода perl-программ.
Довольно часто возникает эта проблема. Самый простой способ защиты, это, без сомнения, использование компиляторов, таких как "perlcc" для "Unix" или "perl2exe" для "Windows". Эти программы переводят исходный код в обычный выполняемый файл. Конечно, все было бы слишком просто, и статья бы закончилась или даже не начиналась. =) При использовании этого способа появляются такие проблемы, как:
1. огромный размер выходного файла
2. потеря мултиплатформенности
3. компиляцией, как таковой, здесь и не пахнет. Созданный выполняемый файл содержит полный интерпретатор perl и саму программу в зашифрованном виде, что и объясняет проблему #1.
4. уже существуют программы обратные этим. Т.е. вытаскивающие из бинарника исходный код.
Существует альтернативный вариант - зашифровать программу. Но, тут тоже есть свои недостатки:
1. код должен быть понятен интерпретатору, а значит и человеку.
2. потеря производительности
И, все-таки, мы рассмотрим второй способ. Чаще всего, да и проще всего, зашифровать код, запихнуть его в переменную, а в конце - расшифровать. Это можно сделать, например, так:
---------------
#!/usr/bin/perl
$var = '7072696e74202248656c6c6f2c20576f726c6421223b';
eval pack('H*',$var);
<>;
---------------
В данном примере код программы зашифрован целиком. Это обратимо и очень даже легко. Достаточно заменить оператор "eval" на "print" и код программы будет виден. Несколько сложнее, когда программа зашифрована кусками. Например так:
---------------
%var = ("abrakadabra" => "func");foreach (keys %var){*{$_} = *{$var{$_}}};
sub func
{
print "Hello, World!";
}
abrakadabra();
---------------
Сами видите, что программа стала более трудно читаемой. Конечно, применив шифрование списка имен, можно добиться очень высокой не читаемости кода. Конечно, все это можно исправить за 3 минуты, однако, если программа достаточно объемна, то и работа по ее приведению в читабельный вид будет огромна.
Наиболее интересны нам сейчас необратимые изменения, например, удаление лишних пробелов, переводов строк, комментариев, скобок, добавление мусора. Вот со скобками, например:
---------------
$a = (2)+1;
print (2)+1;
---------------
Первая строка и без скобок работает нормально, а во второй их надо обязательно оставить, чтобы не изменить результат.
Далее, начнем извращаться с идентификаторами. Не забудьте, что перл позволяет использовать функцию, скаляр, массив и хеш с одним и тем же именем.
Пример:
---------------
@r4t24swc=("Hello, World!");
%r4t24swc=("Hello, World!" => 1);
$r4t24swc=$r4t24swc[0];
r4t24swc($r4t24swc) if ($r4t24swc{$r4t24swc});
sub r4t24swc {print shift}
---------------
Затем, заменяем читабельные операторы на менее читабельные 8) :
---------------
@list = ("Hello World!");
for ($i=0;$i<=$#list; do {
$entry=$list[$i];
{
do {
print $entry;
} if (length($entry)==12);
}
$i++;
}) {}
---------------
И не надо забывать про "мусор" в коде, например такой:
---------------
$do_nothing = 12;
$abrakadabra = $do_nothing;
# Здесь много текста
$do_nothing -= $abrakadabra;
# Опять много текста
while ($do_nothing)
{
print "Abrakadabra\n";
$do_nothing=do_something($do_nothing);
}
---------------
Желательно, что бы бессмысленные операции были разные и подходили под вид программы.
При таких подходах к написанию программ, желающему получить исходный код придется руками разгребать весь код, тут уж никакие программы для разбора не помогут.
Хочется напомнить, что можно заюзать perl-код в коде shell-скирпта и наоборот, не забудте при этом добавить ключ -x.
Поскольку вопрос так и остается открытым, нам хотелось бы узнать ваши способы защиты perl-программ, так что, если у вас есть какие-то идеи и наработки, то ждем их на [email protected]
Как же меня тошнит.. больше не пойду на форум.. запиздят.. обзовут ламером.. расскажут о сцене.. Fuck you All.. (c) 1s7d
I JUST WROTE MY FIRST PERL PROGRAM!!!
IM SO FUCKING ELITE
FUCK YOU ALL
HAHAHAHAHAAHHA
FUCK YOU ALL!!!!!!!!!!!!!!!!!!!!!!!
uhm...
hello.pl?
(c) b0g zine
Итак, настало время поговорить о сцене.. НЕТ! Стой! Не листай дальше.. Да не ори ты, что тема избитая и тебя заебало ее слушать.. Сядь.. Успокойся.. Посчитай до 10.. Ну давай! Так.. тихо.. 0.. дальше.. 1.. молодец.. дальше.. 10.. аха.. 11, 100, 101, 110, 111, 1000, 1001.. Хватит.. А теперь спокойно поговорим о сцене.. Я все понимаю - девушка (парень) ждет, пиво стоит.. ничего.. перебьются.. Значит, сцена говоришь.. мдя.. сцена..
"как много в этом звуке, как мало в этом дела" (c) наверное я не первый
[..shit skipped..]
[..говорят, что здесь была неплохая статья о сцене, но я посчитал, что я не в праве выливать все то дерьмо, что я насобирал, на шляпы бедных securit'ов, поэтому, я предлагаю забыть о всей нашей нынешней сцене.. сцена мертва..]
Fuck you All,
I'm come..
And I want see you face,
I want say You: "Hi, ppl!
How are You? Sorry,
I tell you "Fuck You!"
But, I don't seek this ppl..
Законы Мерфи для информационной безопасности
Законы Мерфи для информационной безопасности Мерфология - область человеческих знаний, которая не только забавна и интересна, но и которая реально отражает многие аспекты человеческой деятельности. Всего из одного шутливо/правдивого закона Мерфи "если какая-нибудь неприятность может произойти, она обязательно случается", родилось целое направление, которое позволяет понять многие процессы в человеческом обществе. Существуют различные направления мерфологии - военная, медицинская, писательская, рекламная, бытовая и т.п. Но мне ни разу не приходилось видеть законов Мерфи для информационной безопасности. Кроме давно опубликованной статьи «Murphy's law and computer security» (http://www.insecure.org/stf/wietse_murphy.html) автора сканера безопасности SATAN Витса Венема, эта деятельность, которая становится все более и более важной, не нашла отражение в мерфологии. И я решил исправить это упущение и попытался собрать разрозненные наблюдения и замечания в одном документе. Какие-то из нижеприведенных тезисов являются следствием уже известных законов Мерфи, какие-то наблюдения и аксиомы не вошли в этот документ, т.к. полностью совпадают с законами из других направлений мерфологии. Однако некоторые наблюдения достаточно интересны и присущи только информационной безопасности. Что из этого получилось - решать вам.
PS. Предвидя очередные заявления «что за чушь», «какая ерунда», «бред сивой кобылы», «автор погорячился», «продажа своих продуктов любой ценой» и т.п. ответственно заявляю этот материал носит ЮМОРИСТИЧЕСКИЙ характер. Все вышеупомянутые высказывания взяты из форума SecurityLab ( http://forum.securitylab.ru/forum_posts.asp?TID=5133), посвященного обсуждению моей юмористической статьи «Почему сканер безопасности лучше чем администратор».
Основные законы:
* Если вас можно атаковать, вас атакуют (следствие основного закона Мерфи).
* Если 4 дыры устранены, то всегда найдется пятая.
* Не заявляй о своей неуязвимости и невзламываемости - всегда найдется кто-то, кто докажет обратное.
* Следствие - Если вы считаете свою сеть неуязвимой, то вы ошибаетесь.
* Любая программа содержит дыры.
* Следствие: даже системы защиты содержат дыры.
* Обнаружить все дыры невозможно.
* Если вы уверены, что написанная вами инструкция по правилам выбора паролей не может быть понята неправильно, всегда найдется сотрудник, который поймет ее именно так.
Наблюдения за пользователями:
* Экспертом по безопасности, как и знатоком футбола, считает себя каждый второй пользователь (не считая каждого первого).
* Каждый программист считает себя специалистом по криптографии и умению разрабатывать невзламываемые алгоритмы шифрования.
* Не усматривайте злого умысла в том, что вполне объяснимо обычной пользовательской ошибкой (следствие из бритвы Хеллона).
Законы построения системы обеспечения информационной безопасности:
* Система информационной безопасности никогда не строится в срок и в пределах сметы (следствие из закона Хеопса).
* Как бы хорошо не была написана политика безопасности всегда найдется используемая у вас технология, которая не нашла в ней отражение.
* Как только политика безопасности окончательно утверждена, она уже окончательно устарела.
* Любые издержки на построение системы информационной безопасности больше, чем вы ожидаете (следствие пятого закона Фостера).
Наблюдения о руководстве:
* Руководство всегда озадачивается безопасностью своей компании только после того, как ее уже взломали.
* Руководителем отдела защиты информации назначают либо отставного военного, либо бывшего милиционера, либо бывшего сотрудника 1-го отдела.
* Человек, знающий как и куда правильно потратить деньги на информационную безопасность, и человек, их выделяющий - это всегда разные люди.
* Исключение: исключений не бывает.
Наблюдения об атаках:
* Из всех атак произойдет именно та, ущерб от которой больше всего.
* Если вас атаковали один раз, не ждите, что на этом все и кончится.
* Атаки происходят тогда, когда администратор безопасности отсутствует на работе.
* Следствие - Стоит вам отлучиться на 5 минут, как именно в этот момент ваш босс не сможет закачать себе новую MP3-композицию из-за настроек МСЭ.
* Целью атаки будет именно тот сервер, падение которого нанесет наибольший ущерб (следствие закона избирательного тяготения).
* Если атака все-таки нанесла вам ущерб всегда найдется администратор, который скажет "я так и знал" (следствие закона Эванса и Бьерна).
* Если в вашей сети всего один непропатченный сервер, именно через него и начнется эпидемия очередного червя.
* Эпидемия червя начинается именно тогда, когда вы забыли продлить подписку на антивирусные базы или базы сигнатур атак.
* Если атака проходит незамеченной для администратора безопасности, значит вас ждет ловушка (основной закон для хакеров).
* Именно тот незначительный скан, который вы проигнорируете, будет предвестником массированной атаки.
* Об атаках всегда сообщается в прошедшем времени (следствие уотергейтского принципа).
* Из всех атак произойдет именно та, от который вы забыли защититься.
Наблюдения о хакерах:
* Сотрудники отдела защиты информации приходят и уходят, а хакеры остаются (следствие девиза Джоунза)
* Действия профессиональных хакеров можно предсказать, но Интернет полон любителей.
Наблюдения о консультантах по безопасности:
* Консультанты по безопасности - загадочные люди; сначала они выспрашивают все о вашей сети и ее безопасности, а потом приводят эту информацию в своем отчете, выдавая ее за титанический плод своих усилий (следствие второго закона Макдональда).
* Приглашенные эксперты по безопасности всегда кажутся лучше своих собственных.
* Если эксперт по безопасности знает, как называется атака, которой вы подверглись, это еще не значит, что он знает, как от нее защититься.
* Каждый способен сказать, что в вашей сети есть дыра, но не каждый способен найти ее.
* Виновным в неудачном внедрении системы защиты всегда оказывается внешний эксперт, приглашенный для консультаций.
* Приглашенный эксперт, обвиненный в неудачном внедрении системы защиты, обвинит вас в непредоставлении всей необходимой информации (закон противоположного обвинения).
* Стоимость услуг по обследованию корпоративной сети - величина, никак не зависящая от числа и квалификации экспертов, участвующих в обследовании.
Замечания по аутсорсингу:
* Передать свою безопасность на аутсорсинг - значит потерять контроль над сетью. Не передать – потерять контроль еще быстрее.
* Доступность аутсорсинга еще не показатель, что им надо воспользоваться.
Наблюдения о средствах защиты:
* Расходы на средства защиты информации стремятся сравняться с доходами от их внедрения (следствие из второго закона Паркинсона).
* Стоимость системы защиты информации всегда больше, чем вы запланировали (следствие пятого закона Фостера).
* Установив систему защиты, не ждите благоприятных отзывов от сотрудников.
* Ни одно средство защиты, введенное в эксплуатацию, не прошло тестирования.
* Ни одно средство защиты, прошедшее тестирование, не готово к вводу в эксплуатацию (закон противоположности).
* Чем больше функций в системе защиты, тем больше вероятность, что одна из них не работает так как надо.
* Если вы не уверены, работает ли ваша системы защиты, значит она не работает.
* Если ваша система защиты работает по расписанию, то вы обязательно забудете запустить ее в нужное время.
* Система, защищающая от самых современных атак, будет неспособна защитить вас от давно устаревших.
* Надежность системы защиты обратно пропорциональна числу и положению лиц, управляющих ею (следствие закона Уатсона).
* Если вы хотите создать централизованную систему управления средствами защиты информации, окажется, что все ваши средства выпущены разными производителями и не интегрируются между собой.
* Наличие сертификата соответствия на систему защиты еще не означает, что продукт соответствует классу защищенности, указанному в сертификате.
* Следствие - Это также не значит, что продукт вообще работает.
* Вывод - Это вообще ничего не значит.
* Система защиты блокирует доступ вашего босса в Интернет именно в тот момент, когда он думает об увеличении вашей зарплаты.
* Если вы приобрели большую партию электронных брелков или смарт-карт, то обязательно окажется, что более 50% ваших сотрудников являются женщинами, которым негде носить эти средства аутентификации (наблюдение Левашова).
Разные наблюдения:
* Когда администратор безопасности испытывает затруднения при обнаружении дыр, это значит, что он ищет не там, где следует.
* Нет ничего более приятного, чем отбитая атака хакеров.
* Если вы уверены, что в вашей сети нет бесконтрольно установленных и используемых модемов, то вы ошибаетесь.
* В отделе защиты информации всегда не хватает людей.
* Если после отпуска вы забыли свой пароль, отдых удался на славу.
* Именно в тот момент, когда вам нужно собрать доказательства несанкционированной деятельности, окажется, что регистрация событий не включена.
* Если вашу статью кто-то украл, то скорее всего это преподаватель какого-либо ВУЗа (пессимистическое наблюдение Лукацкого)
Об авторе:
Алексей Викторович Лукацкий, автор книг «Обнаружение атак», «Protect Your Information with Intrusion Detection» и др. Автор курсов «Технология обнаружения атак» и «Выбор системы обнаружения атак». Связаться с ним можно по e-mail: [email protected].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
