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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pilat, 24-й пункт непростой, если следовать только его части, то это реально чревато и DoS и нежелательными блокировками. А если всё продумано и предусмотрено, то попытавшийся положить сервер атакой на задержку входа (полагаю, вы имели ввиду, рассчитывая израсходовать ресурсы или их лимиты, многопоточно калбася скрипты, не дожидаясь ответа) очень быстро влетит в бан по порогу «Requests per second» на заслуженный отдых.

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