Как стать автором
Обновить

Комментарии 47

Спасибо!
На самом деле к php в данной статье привязка минимальна, буквально 2 момента с fix_pathinfo и location /index.php.
Но вторая часть будет посвящена архитектуре сайта именно на php (хотя и там многие моменты переносимы абсолютно на любой язык разработки).
Так что рекомендации выше можно смело использовать и совершенно на другом окружении.
С RoR у меня опыт есть, но он не велик. А с ASP еще меньше. Так что я бы еще поднабрался опыта там (сейчас приоритетной RoR). А может, кто-нибудь другой поделится схожими советами для RoR / ASP.Net
>А может, кто-нибудь другой поделится схожими советами для RoR
скоро будет :)
очень ждём!
Буду ждать :]
К сожалению не могу плюсануть, но очень хочу похожую статью про asp.net/win.
А, случаем, оф. маны по этому поводу не читали на сайте майкрософта?
Спасибо за содержательный рассказ. К связке nginx+php-fpm тоже пришёл экспериментальным путём — очень доволен. Автор, а планируется ли материал по анти-спам защите? В особенности — почты. А то перекопал кучу форумов, перепробовал несколько технических решений, а в итоге заработал понимание того, что я ничё в этом (exim/sendmail/etc) не понимаю, и полную кашу в голове. Думаю, такие вопросы мучают не одного меня :)
Спасибо. По поводу антиспама — на Хабре множество статей на эту тему, при чем очень скомпонованных, с примерами и т.п.
Думаю, если есть «каша» — то лучше разобраться с ней самому или написать авторам в личку.
НЛО прилетело и опубликовало эту надпись здесь
Абсолютно верно, исправил.
А все же не умолчите, чем делаете мониторинг системы и error.log?..
Вообще что-то я упустил еще new relic и некоторые другие моменты, сейчас добавлю.
Тут зависит от архитектуры приложения. Нужно так заворачивать location, чтобы можно было даже не использовать сторонние анализаторы логов. Постараюсь развернуть этот вопрос во второй части.
да, большое спасибо.
НЛО прилетело и опубликовало эту надпись здесь
Расскажите про ситуации.
Если сравнить количество тех же эксплойтов, вышедших для апача за последний год-два и для nginx'a, то у апача было проблем больше.
НЛО прилетело и опубликовало эту надпись здесь
Количество эксплойтов, найденных под Windows, например — большое, но это говорит только о том, что она более известна хакерам.

Учитывая разницу в распространенности винды и никсов на серверах — это говорит о кривости архитектуры винды и незаинтересованности МС делать защищенную систему. Системы с открытым исходным кодом хакерам известны очевидно намного больше, чем проприетарные. А эксплойтов на порядки меньше.

ЗЫ: Лично мне интересно какие такие правила для mod_rewrite нельзя настроить под nginx.
НЛО прилетело и опубликовало эту надпись здесь
Вы делаете сейчас очень распространенную ошибку. Причем я Вам на нее указал в первой строчке моего предыдущего коммента… ОС, более распространенная где? На клиентских машинах — тут, да, windows более распространена. Но мы вроде не про клиентские. А на серверах — тут юниксы в большинстве. И согласитесь, владельцу ботнета намного выгоднее пополнять ряды ботов из ВДСок и серверов, с соотвствующими мощностями и каналами, чем из клиентских машин. А эксплойтов по-прежнему меньше под никсами.
НЛО прилетело и опубликовало эту надпись здесь
«это банально сложнее, там не работают механизмы заражения, требующие, чтобы пользователь нажал кнопочку «Да, установить»»

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

" и самих серверов на порядок меньше, чем клиентских машин. Посему и до сих пор куда как эффективнее строить свой ботнет на клиентских машинах."

Только вот опять же мощности, а особенно каналы на серверах и клиента различаются на порядки, да и включены они постоянно.

"«А эксплойтов по-прежнему меньше под никсами.» — и как Вы их считали?"

Оттолкнулся от этих ваших слов.

«Количество эксплойтов, найденных под Windows, например — большое, но это говорит только о том, что она более известна хакерам.»
НЛО прилетело и опубликовало эту надпись здесь
Из недавнего поста про датацентры гугла:
Все эти системы являются закрытыми и кастомизированными — Google объясняет это тем, что закрытые и кастомизированные системы очень устойчивы против внешних атак и в них значительно меньше уязвимостей

Security through obscurity — это тоже неправильно, но атаковать вслепую сложнее, чем по известным уязвимостям.
Читаю, думаю «надо Белову дать ссылку, понятно что все знает, но тут просто как чек-листом можно пройти — проверить». А потом дохожу до строки автора)
this awkward feeling when people recommend you to read your own articles :)
Соглашусь :3
НЛО прилетело и опубликовало эту надпись здесь
Да, очень спасает, когда много сайтов на одном сервере.
Уважаемый автор, не планируете ли написать нечто подобное, но для связки Апач — Томкат? Уж очень мало русскоязычной информации на эту тему
Спасибо большое за изложенный опыт!
круто, серверная безопасность обычно лежит на плечах админов — надо и самому разобраться
Отличная статья! Радует, что всё больше и больше начало появляться простых и доступных статей по ИБ для конечного пользователя.
Есть такие ресурсы как stumbleupon, surfingbird, которые показывают твой сайт во фрейме, и если заблокировать всё, то будет неочень.
НЛО прилетело и опубликовало эту надпись здесь
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT # ssh
SSH все же лучше с 22-го порта убрать. Еще вы не упомянули такую чудесную софтину, как fail2ban.
Замечательный мануал у вас получился.
Опередили.

Еще бы, если все совсем серьезно, можно использовать port knocking. От себя посоветую делать «открывающий» порт между двумя «закрывающими», например, закрываем — 1499,1501, а закрываем по открываем, тогда даже при полном сканировании портов (от которого можно и отдельно закрываться) ssh злоумышленником обнаружен не будет.
Использование дефолтных портов само по себе не представляет опасности, если уверены, что в системе нет откровенно слабых паролей (или аккаунтов с именами = паролю). Для блокировки назойливых брутеров и чтобы не лицезреть засорённые логи, да, fail2ban вполне эффективен + можно ограничить доступ определёнными подсетями и/или странами (geoip).
Удобство же дефолтных портов состоит в том, что при подключении не надо явно указывать альтернативный порт, в особенности если часто подключаетесь посредством ручного набора команд.
Вы уверены в 100% невозможности обнаружения 0-day в openssh той версии, которая стоит у Вас на сервере? И зачем нужен частый ручной набор команд?
На моей памяти, конкретно в OpenSSH уже очень давно ничего смертельного не встречается. Да и если кто надумает целиться в конкретные системы, то смена номера порта уже никак не поможет. Случайным же любителями что-нибудь взломать (сюда же можно отнести и любителей массового сканирования интернетов на известные уязвимости) серьёзный 0day обычно недоступен.

И зачем нужен частый ручной набор команд?

Когда у вас десятки *nix серверов, то так или иначе нужен. Скрипты или алиасы в шелле что ли создавать для всего?
«Да и если кто надумает целиться в конкретные системы, то смена номера порта уже никак не поможет. „

А если смена номера порта+защита от портскана? ssh — отличается от того же nginx'a тем, что пашет из-под рута и плохо ограничивается RBAC'ом () Взлом его рутование системы. Соотвественно, представьте себе, что человек держит “веб-ресурс», на котором есть ssh ngninx+php-fpm. nginx не из под рута, очевидно, php-fpm тоже, да еще и в чруте. И более менее доступный способ компрометации сервера остается взлом ssh.

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

«Скрипты или алиасы в шелле что ли создавать для всего?»

Да, скрипты или алиасы. Они ж как раз нужны для работы для автоматизации однотипной работы.
пашет из-под рута

более менее доступный способ компрометации сервера остается взлом ssh

Вы, похоже, не в теме. Для начала разберитесь, как вообще OpenSSH сервер устроен, privelege separation не просто так придумали. Мне доводилось глубоко ковыряться в исходном коде 3.x и 4.x, никаких опасений данное ПО у меня не вызывает, тем более разрабатывают его те же серьёзные люди, что и OpenBSD. Стоит только заметить, что во всех современных дистрибутивах собственно аутентификация пользователей по умолчанию осуществляется через PAM, если уж даже предполагать наличие уязвимостей на этапе до успешной аутентификации.
Чего больше стоит опасаться, так это уязвимостей в Exim, используемом как MTA по умолчанию в Debian-based дистрибутивах, тем более что громкие случаи уже были. Менять порты в данном случае не вариант, поскольку нужно принимать внешнюю почту.

Но вообще, поверьте, «получение рута» — далеко не самоцель адекватных взломщиков в подавляющем большинстве случаев, равно как и повышенный интерес к уязвимостям в сетевых сервисах, работающих без ограничения привилегий.
Во-первых — всем спасибо за отзывы! Вторую часть по разработке постараюсь сделать не менее полезной. И если статья будет выходить большой, тогда может будет и третья часть.
Во-вторых, обновил топик, добавил информацию про new relic (must have), на который я буду опираться во второй части, а так же добавил хак для nginx'a для защиты от CSRF.
Киньте ссылку по корректной установке прав для веб-разработки
Правила для «location /index.php» понятны, а для остальных файлов?
Имеет ли право на жизнь конструкция вида
location / {
location ~ .*\.(php)?$
{
deny all;
}
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
try_files $uri /index.php$uri;
}

?
Тоже очень интересует этот вопрос. Как запретить запросы ко всем PHP-файлам, кроме index.php? Может кто-то подсказать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации