\&название_процедуры
что является рекомендуемым.
strict refs
Похоже на strict subs, только действует на ссылки. Запрещает использовать имя переменной, на которую ссылается ссылка в виде строки. Допустим только особый синтаксис:
\$something
use strict без параметров включает все 3 описанных выше ограничения, что по мне самый классный вариант.
Важно хранить старые релизы, не менее важно иметь под рукой и несколько последних ежедневных бэкапов. Если в процессе разработки вы зашли в тупик или случайно что-то испортили, у вас будет копия, к которой можно будет откатиться. И это вместо того, чтобы тратить время и силы на починку или воссоздание испорченного.
Не ленитесь, даже если вам очень некогда или очень не хочется, бэкапы ещё никому не мешали, а вот спасали не раз.
Если вы получите уведомление вовремя, вы можете, не откладывая реакцию, пойти на сервер и прямо сейчас забанить человека по IP, либо ещё что-то сделать, проанализировать по горячим следам.
Если он действительно что-то нащупал, у вас будет шанс срочно принять меры, пока он не успел это поломать.
Хуже того, если он успел поломать, он мог поделиться рецептом со своими друзьями-взломщиками, чтобы и они смогли вдоволь похимичить.
Чем раньше вы узнаете об уязвимости, тем лучше.
Мало ли что вы туда положите. Для отладки ли, временно ли, в служебных целях не важно для чего или почему. Люди могут это найти, воспользоваться, словом, ничего хорошего.
Когда листинг где-то всё-таки включен, сделайте так, чтобы в robots.txt было запрещено ходить туда поисковикам (кроме случаев, когда индексация это одна из целей).
Самый интересный из них возможность удалить комментарии.
Сама по себе это не очень-то и защита, но если ваш проект отдаётся куда-то, где есть шанс попадания на рапидшару, что его будут против вашей воли изучать, ломать, пускай они читают сорцы без комментариев, в нечеловеческом виде, когда весь код без деления на блоки, в одну строчку, и т.п., как я это называю, в виде «перловой каши»).
Усложнить поиск уязвимостей столь лёгкой ценой тоже полезное дело.
Кстати, этот же инструмент помогает и в обратном направлении: когда код страшен и нечитаем, можно попросить perltidy сделать из него версию, пусть и бездушным образом перестроенную, но всё-таки хоть как-то годную для понимания.
Такой код, к сожалению встречается, например, автор сильно торопился или не предусмотрел, что код когда-нибудь придётся допиливать ему или коллеге. Вот тут-то perltidy и помогает. Не сказать, что он творит чудеса, всё-таки машинная обработки не заменяет осознанного форматирования, но обилие опций позволяет сформатировать исходники так, чтобы они стали более-менее в стиле человека, которому предстоит их править.
Например, если у вас всё супернадёжно защищено в веб, но при этом поднят ssh, который доступен со всех IP на стандартном порту 22 и пароль у рута 123, то последствия однажды могут быть самыми печальными. Это же касается FTP и т.п.
Советы
по административному доступу:
Сажайте сервисы на нестандартный порт.
Не давайте доступ учётным записям с очевидными логинами, такими как root, adm или совпадающим с никами администраторов.
Тем учётным записям, кому разрешено админить сервер удалённо, задавайте страшные длинные неугадываемые пароли. Здесь справедливо правило 24 о паролях.
Определите список или диапазоны IP-адресов, с которых можно администрировать, о остальных доступ запретите. И лучше не в настройках сервиса, а сразу на фаерволе.
Почему лучше резать на фаерволе, а не в конфигах? В случае с запретом на сервисе, он самостоятельно будет отказывать взломщику. Кроме того сервис в процессе авторизации может выдать своё название и версию, что даёт повод поискать уязвимости в этой версии. А в случае защиты на фаерволе, к сервису запросы не дойдут вообще. Никакого разговора между взломщиком и сервисом не состоится. Ещё лучше, чтобы с наружи не было разницы между зафаерволенным сервисом и ничем непрослушиваемым портом.
Комментарии
Pilat24. Принимайте меры против подбора пароля.Задержка входа простейший, но при этом уже достаточно неслабый способ. Сведет на нет ручной перебор и автоматический однопоточный перебор с одного компьютера.
DJ-Andrey-sXe 3 января 2010 в 06:32
Pilat, 24-й пункт непростой, если следовать только его части, то это реально чревато и DoS и нежелательными блокировками. А если всё продумано и предусмотрено, то попытавшийся положить сервер атакой на задержку входа (полагаю, вы имели ввиду, рассчитывая израсходовать ресурсы или их лимиты, многопоточно калбася скрипты, не дожидаясь ответа) очень быстро влетит в бан по порогу «Requests per second» на заслуженный отдых.
Мой друг как-то предложил идею хранить месяц истории попаданий в бан и если побывавший в бане IP снова возжелал покрошить сервер, то новый бан следует выдавать на более длительный срок. Например, вернулся после 5 минут выдаём 10, вернулся ещё раз 30, ещё 2 часа, ещё сутки. Ну, если уж делать, то что в веб-морде должен быть список банов с функцией преждевременного снятия, это, думаю, и так понятно.