Полезно вот что: если вы вдруг опечатались, Perl вас обругает, такая переменная не объявлена (компиляция будет остановлена). В обычном режиме Perl ”заботливо“ создаст для вас новую переменную с новым именем, таким, как вы опечатались.
И внутри у неё будет, разумеется, undef, что в выражении приведётся к нулю или пустой строке. При присваивании будет ещё хуже. Вам покажется, что всё хорошо (синтаксически-то всё безупречно), а на деле присваивание произойдёт мимо нужной переменной в новую.
• strict subs
Perl обычно не ругается, если вы присвоите переменной имя процедуры как есть, голое название без кавычек. А когда вы включите strict subs, Perl не позволит вам так сделать, вы обязательно должны будете либо заключить название в кавычки, либо использовать особый синтаксис:
\&название_процедуры
что является рекомендуемым.
• strict refs
Похоже на strict subs, только действует на ссылки. Запрещает использовать имя переменной, на которую ссылается ссылка в виде строки. Допустим только особый синтаксис:
\$something
use strict без параметров включает все 3 описанных выше ограничения, что по мне самый классный вариант.
Давайте коллегам читать код и тестировать новые фичи продукта. Практика показывает, что вы сами способны найти меньше ошибок, чем другой человек (лучше, чтобы это был опытный тестировщик), как минимум потому, что он не знает, что и как вы реализовали, и что вы могли не учесть.
Храните резервные копии проекта. ОБЯЗАТЕЛЬНО!
Важно хранить старые релизы, не менее важно иметь под рукой и несколько последних ежедневных бэкапов. Если в процессе разработки вы зашли в тупик или случайно что-то испортили, у вас будет копия, к которой можно будет откатиться. И это вместо того, чтобы тратить время и силы на починку или воссоздание испорченного.
Не ленитесь, даже если вам очень некогда или очень не хочется, бэкапы ещё никому не мешали, а вот спасали не раз.
Сделайте так, чтобы ваше приложение при обнаружении попытки взлома отправило вам уведомление (по почте, Jabber-у, ICQ и т.п., главное, чтобы оно доставилось мгновенно, SMS – неплохой вариант).
Если вы получите уведомление вовремя, вы можете, не откладывая реакцию, пойти на сервер и прямо сейчас забанить человека по IP, либо ещё что-то сделать, проанализировать по горячим следам.
Если он действительно что-то нащупал, у вас будет шанс срочно принять меры, пока он не успел это поломать.
Хуже того, если он успел поломать, он мог поделиться рецептом со своими друзьями-взломщиками, чтобы и они смогли вдоволь похимичить.
Чем раньше вы узнаете об уязвимости, тем лучше.
Во всём вашем проекте, кроме мест, где это действительно необходимо и чётко обоснованно, запретите листинг директорий.
Мало ли что вы туда положите. Для отладки ли, временно ли, в служебных целях – не важно для чего или почему. Люди могут это найти, воспользоваться, словом, ничего хорошего.
Когда листинг где-то всё-таки включен, сделайте так, чтобы в robots.txt было запрещено ходить туда поисковикам (кроме случаев, когда индексация – это одна из целей).
Консольный инструмент perltidy предназначен для форматирования исходников на перле. То, как текст будет отформатирован, определяется множеством параметров.
Самый интересный из них – возможность удалить комментарии.
Сама по себе это не очень-то и защита, но если ваш проект отдаётся куда-то, где есть шанс попадания на рапидшару, что его будут против вашей воли изучать, ломать, пускай они читают сорцы без комментариев, в нечеловеческом виде, когда весь код без деления на блоки, в одну строчку, и т.п., как я это называю, в виде «перловой каши»).
Усложнить поиск уязвимостей столь лёгкой ценой – тоже полезное дело.
Кстати, этот же инструмент помогает и в обратном направлении: когда код страшен и нечитаем, можно попросить perltidy сделать из него версию, пусть и бездушным образом перестроенную, но всё-таки хоть как-то годную для понимания.
Такой код, к сожалению встречается, например, автор сильно торопился или не предусмотрел, что код когда-нибудь придётся допиливать ему или коллеге. Вот тут-то perltidy и помогает. Не сказать, что он творит чудеса, всё-таки машинная обработки не заменяет осознанного форматирования, но обилие опций позволяет сформатировать исходники так, чтобы они стали более-менее в стиле человека, которому предстоит их править.
Не позволяйте ломать вас через другие сервисы на этом же сервере.
Например, если у вас всё супернадёжно защищено в веб, но при этом поднят ssh, который доступен со всех IP на стандартном порту 22 и пароль у рута 123, то последствия однажды могут быть самыми печальными. Это же касается FTP и т.п.
Советы по административному доступу:
• Сажайте сервисы на нестандартный порт.
• Не давайте доступ учётным записям с очевидными логинами, такими как root, adm или совпадающим с никами администраторов.
• Тем учётным записям, кому разрешено админить сервер удалённо, задавайте страшные длинные неугадываемые пароли. Здесь справедливо правило № 24 о паролях.
• Определите список или диапазоны IP-адресов, с которых можно администрировать, о остальных доступ запретите. И лучше не в настройках сервиса, а сразу на фаерволе.
Почему лучше резать на фаерволе, а не в конфигах? В случае с запретом на сервисе, он самостоятельно будет отказывать взломщику. Кроме того сервис в процессе авторизации может выдать своё название и версию, что даёт повод поискать уязвимости в этой версии. А в случае защиты на фаерволе, к сервису запросы не дойдут вообще. Никакого разговора между взломщиком и сервисом не состоится. Ещё лучше, чтобы с наружи не было разницы между зафаерволенным сервисом и ничем непрослушиваемым портом.
Комментарии
Pilat 2 января 2010 в 14:37
24. Принимайте меры против подбора пароля.
Задержка входа – простейший, но при этом уже достаточно неслабый способ. Сведет на нет ручной перебор и автоматический однопоточный перебор с одного компьютера.
только задосить такой сайт – дело минут.
DJ-Andrey-sXe 3 января 2010 в 06:32
Pilat, 24-й пункт непростой, если следовать только его части, то это реально чревато и DoS и нежелательными блокировками. А если всё продумано и предусмотрено, то попытавшийся положить сервер атакой на задержку входа (полагаю, вы имели ввиду, рассчитывая израсходовать ресурсы или их лимиты, многопоточно калбася скрипты, не дожидаясь ответа) очень быстро влетит в бан по порогу «Requests per second» на заслуженный отдых.
Мой друг как-то предложил идею хранить месяц истории попаданий в бан и если побывавший в бане IP снова возжелал покрошить сервер, то новый бан следует выдавать на более длительный срок. Например, вернулся после 5 минут – выдаём 10, вернулся ещё раз – 30, ещё – 2 часа, ещё – сутки. Ну, если уж делать, то что в веб-морде должен быть список банов с функцией преждевременного снятия, это, думаю, и так понятно.
KoXX 4 января 2010 в 02:55
Интересно, а главное познавательно Спасибо :)
Willie 7 января 2010 в 04:23
Ну наконец! Свежая инфа. Как раз доклад делаю по смежной теме
Zenon 8 января 2010 в 12:40
Спасибо. Очень понравилось :)
Vavila 8 января 2010 в 14:09
Да, а ведь написано действительно хорошо..
Paul 13 марта 2010 в 14:16
Вообще, если всё это реализовать, уйдёт очень много времени.
DJ-Andrey-sXe 13 марта 2010 в 21:26
Paul,
1) Не каждый проект требует выполнения всех пунктов подряд. Элементарно может не быть таких функций, которые потребовали бы именно такого типа защиты или специфика может освободить от выполнения многих пунктов.