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

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

Товарищи, ставьте NGINX (хотя бы как прокси).
В случае использования apache только для php от него вообще можно безболезненно отказаться, за одно сэкономив памяти.
А его ни для чего другого в большинстве случаев и не используют.
Ну да, конечно. А как же всякие mod_perl, mod_python и прочие ruby?
Тыкните пальцем в того извращенца, кто использует apache для ruby :) Обычно — unicorn, thin, puma. Для питона uwsgi гораздо удобнее.
А как это спасет от подмены его бинарных файлов с места загрузки дистрибутива или с работающего сервера?
Ну по моему, апач не первый раз встречается в сообщениях об уязвимости.
Апач скорее всего ни при чём, сервер должен быть порутан: «We also don’t have enough information to pinpoint how those servers are initially being hacked, but we are thinking through SSHD-based brute force attacks.»
Дополнительно, IP-адрес, указанный в заголовках пакетов X-Настоящий_IP или X-Перенаправленный_на будет замещать клиентский IP как ключ для расшифровки
Какой странный способ перевода заголовков. Понятнее будет, если вы напишите как они выглядят, а в скобках укажете перевод.
Не ради минусов на харбре, но просто интересно, что такого в Apache, почему его нельзя заменить nginx? Реально интересует опыт тех, кто не заменил ещё Apache. htaccess понятно, но его можно эмулировать, но не факт при shared-хостинге. Но в этом случае можно использовать Apache 1.3.
Для подавляющего большинства заменять .htaccess просто лениво либо недостаточно знаний. И клали они на безопасность под видом «да кому я нужен».
В данном случае апач не причем. Точно такой же бэкдор можно сделать и для нгинкс. Если уже не сделали.
Я отвечал на вопрос, не более.
Никакого отношения указанный по ссылке руткит к nginx не имеет. Просто nginx-у не повезло быть установленным на том сервере.
Кстати, а как эмулировать htaccess?
Иногда бывает тяжело. Вот в этом случае blog.tavda.net/2012/03/microcosm-lighttpd-nginx.html я переделывал конфиг из lighttpd в конфиг nginx. В документации есть только пример .htaccess. Пришлось дополнить документацию. Благо, проект опенсорсный.
Учитывая, что бэкэндом зачастую выступает PHP и htaccess используется для управления поведения интерпретатора, то можно юзать .user.ini файлы.

Но в целом htaccess для nginx это всячески порицаемая практика.
Не нужно эмулировать, нужно переписать логику htaccess под nginx в секцию server {}, тем более обычно там что-то вроде:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php/$0 [PT,L]

которое замещается одной строкой

try_files $uri $uri/ /index.php?$query_string;
Расскажите кто-нибудь для тех, кто в танке: А как происходит подмена исполняемых модулей Apache?
Сложно представить, что сисадмин запускает на сервере (за работоспособность которого ему голову могут оторвать) «левые» програмки. А если бы был заражен репозиторий, то проблема коснулась бы не считанных сотен серверов, а прошлась бы по планете пандемией.
Согласно исходнику, репозиториев не касается, т.к. cPanel компилирует апач. Там же пишут, что заражение наиболее вероятно через брут ssh.
давайте не будем давать руту ssh
Я бы дополнил: «давайте не будем давать парольный ssh root-у».
У меня включен SSH руту, при этом используются ключи, а в качестве запасного варианта — 25-символьный пароль из букв разного регистра и цифр. Этого достаточно?
sshd не имеет ограничение на количество попыток входа. К примеру, вот количество таких попыток начиная с 21-ого числа у меня:
 for day in `seq 21 28`; do echo -n "$day: "; grep "Apr $day" /tmp/auth.log | grep failure | wc -l; echo; done
21: 1189

22: 1723

23: 1464

24: 1466

25: 6838

26: 751

27: 2822

28: 1228



25 символов конечно немало, но при современных мощностях это вполне посильная цифра для перебора особенно если пароль на сервере меняется не очень часто (а то не менялся со времен установки сервака). В общем есть хочется сохранять парольный вход, то стоит менять почаще пароль + использовать iptables, fail2ban или что-то другое для ограничение скорости коннектов, а то и бана адресов с неудачным входом.
Круто. Меня всегда воодушевляли люди, которые знают bash так хорошо.
Вы же не серьёзно, правда?:)

for day in `seq 21 28`; do echo -n "$day: "; grep -Ec "Apr $day.*failure" /tmp/auth.log; done
Конечно, достаточно! Современные растущие мощности не ускоряют подбор пароля к удалённому сервису; это не то же самое, что подбирать пароль к локальному файлу.

2-5 тысяч паролей в день у alekciy — это неделя только на то, чтобы проверить список самых популярных паролей, вроде «12345678», «555» и английских слов. sshd писали эксперты, он не даёт перебирать слишком быстро, а с fail2ban это становится ещё сложней.

25 символов — это даже лишка. Тепловая смерть вселенной (или технологическая сингулярность) наступит на порядки раньше. Если я верно помню расчёты, не-словарный пароль из 7 букв/цифр будет как раз на грани того, что можно перебрать за несколько лет, всё, что больше — безопасно.

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

Но в целом учитывая даже дефолтные настройки sshd (MaxAuthTries, MaxSessions, MaxStartups) и отсутствие других ограничительных механизмов, при рандомном пароле в 25 символов можно спать спокойно.
подкиньте такую цветовую схему для IDA :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Словакия
Сайт
www.esetnod32.ru
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре