Защита веб-приложений на Perl

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

Не ленитесь, даже если вам очень некогда или очень не хочется, бэкапы ещё никому не мешали, а вот спасали не раз.

37.

Сделайте так, чтобы ваше приложение при обнаружении попытки взлома отправило вам уведомление (по почте, Jabber-у, ICQ и т.п., главное, чтобы оно доставилось мгновенно, SMS – неплохой вариант).

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

Если он действительно что-то нащупал, у вас будет шанс срочно принять меры, пока он не успел это поломать.

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

Чем раньше вы узнаете об уязвимости, тем лучше.

38.

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

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

Когда листинг где-то всё-таки включен, сделайте так, чтобы в robots.txt было запрещено ходить туда поисковикам (кроме случаев, когда индексация – это одна из целей).

39.

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

Самый интересный из них – возможность удалить комментарии.

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

Усложнить поиск уязвимостей столь лёгкой ценой – тоже полезное дело.

Кстати, этот же инструмент помогает и в обратном направлении: когда код страшен и нечитаем, можно попросить perltidy сделать из него версию, пусть и бездушным образом перестроенную, но всё-таки хоть как-то годную для понимания.

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

40.

Не позволяйте ломать вас через другие сервисы на этом же сервере.

Например, если у вас всё супернадёжно защищено в веб, но при этом поднят ssh, который доступен со всех IP на стандартном порту 22 и пароль у рута 123, то последствия однажды могут быть самыми печальными. Это же касается FTP и т.п.

Советы по административному доступу:

• Сажайте сервисы на нестандартный порт.

• Не давайте доступ учётным записям с очевидными логинами, такими как root, adm или совпадающим с никами администраторов.

• Тем учётным записям, кому разрешено админить сервер удалённо, задавайте страшные длинные неугадываемые пароли. Здесь справедливо правило № 24 о паролях.

• Определите список или диапазоны IP-адресов, с которых можно администрировать, о остальных доступ запретите. И лучше не в настройках сервиса, а сразу на фаерволе.

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

Комментарии

Pilat 2 января 2010 в 14:37

24. Принимайте меры против подбора пароля.

Задержка входа – простейший, но при этом уже достаточно неслабый способ. Сведет на нет ручной перебор и автоматический однопоточный перебор с одного компьютера.

только задосить такой сайт – дело минут.

DJ-Andrey-sXe 3 января 2010 в 06:32