Делаем nginx как front-end к apache

Настраиваем nginx
Создаем файл конфигурации в директории: /etc/nginx/sites-available
server {
listen *:80; ## listen for ipv4
server_name ВАШ_ДОМЕН;
access_log /var/log/nginx/access.log;
# Перенаправление на back-end
location / {
proxy_pass ВАШ_ДОМЕН:8080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_connect_timeout 120;
proxy_send_timeout 120;
proxy_read_timeout 180;
}
# Статическиое наполнение отдает сам nginx
# back-end этим заниматься не должен
location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js|html|txt)$ {
root ПУТЬ_ДО_КОРНЕВОГО_КАТАЛОГА_САЙТА;
}
}

установка Apache, PHP, MySQL и ngin

Установка Apache
apt-get install apache2
[+mod_rewrite]
a2enmod rewrite

Установка PHP
apt-get install php5-cli

Установка MySQL
apt-get install mysql-server
apt-get install mysql-client-core-5.1
apt-get install php5-mysql

Установить nginx
apt-get install nginx
Конфиги -> /etc/nginx

установка nginx ubuntu

sudo apt-get install nginx

sudo nano /etc/nginx/sites-available/default


server {
listen 80;
server_name localhost;
access_log /var/log/nginx/localhost.access.log;

## Default location
location / {
root /var/www;
index index.php;
}

## Images and static content is treated different
location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|xml)$ {
access_log off;
expires 30d;
root /var/www;
}

## Parse all .php file in the /var/www directory
location ~ .php$ { Место ~. PHP $ (
fastcgi_split_path_info ^(.+.php)(.*)$;
fastcgi_pass backend;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name;
include fastcgi_params;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_intercept_errors on;
fastcgi_ignore_client_abort off;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
}

## Disable viewing .htaccess & .htpassword
location ~ /.ht {
deny all;
}
}
upstream backend {
server 127.0.0.1:9000;
}





sudo apt-get install php5-cli php5-common php5-suhosin

sudo apt-get install php5-fpm php5-cgi


sudo /etc/init.d/nginx restart
sudo /etc/init.d/php5-fpm restart

добавление и удаление автозагрузки ubuntu

sudo update-rc.d apache2 disable
sudo update-rc.d apache2 enable

Надёжный и безопасный Linux

После прочтения на Хабре недавних статей, посвящённых теме безопасности линукс систем, у меня возникло желание поделиться своей точкой зрения на этот вопрос.
Статья в целом рассчитана на начинающих администраторов, поэтому в ней изложены очевидные для хорошего специалиста вещи. Ценные дополнения и замечания приветствуются.
Копи-пейст выдержки из конфиг файлов я почти не буду приводить по трём причинам:

1. Это приведёт с излишнему разрастанию статьи
2. Маны и гугл никто не отменял
3. Пункт 2 очень полезен для развития специалиста

Итак, как повысить безопасность и надёжность сервера (да и рабочей станции) на базе линукс?



Эту задачу я разделю на 3 части:

1. (Про)активное обеспечение безопасности — ужесточение настроек системы и демонов. Сюда же относится настройка файрвола.
2. Пассивное обеспечение безопасности и надёжности — мониторинг системы.
3. Бэкапы

Ужесточение настроек системы

1. Отключить неиспользуемые сервисы/демоны. Внимательно просмотреть список процессов (например по команде ps -ef | less ) и определить те из них, которые вам не нужны. Убедиться в том, что они не нужны самой системе. Отключить.
2. Если это возможно, то изменить стандартные порты и интерфейсы на которых слушают оставшиеся сервисы и настроить дополнительные ограничения по безопасности средствами самих сервисов (т.е путем редактирования их конфигурационных файлов / добавления ключей к параметрам запуска).
   Проиллюстрирую на примере sshd. Здесь необходимо сделать следующее — изменить стандартный порт с 22-го на любой свободный, например на 6622. Запретить доступ под логином root. Жёстко задать список разрешённых для доступа имён пользователя. Разрешить sshd прослушивать только определённый адрес. Как вариант разрешить доступ только по ключу, но мне это не очень нравится
3. Iptables
   Настройка файрвола очень интересная тема, которой нужно посвятить отдельную статью.
   Основные принципы таковы:
   Файрвол должен работать по принципу белого списка, т.е всё что не разрешено явно, является запрещённым.
   Это достигается установкой политики файрвола по умолчанию командами iptables -P INPUT DROP, iptables -P OUTPUT DROP и iptables -P FORWARD DROP. После выполнения этих команд весь входящий, исходящий и транзитный трафик, для которого не создано разрешающих правил будет заблокирован, поэтому выполнять их следует с осторожностью.
   Перед тем, как хоть что-то делать с iptables настоятельно рекомендую изучить отличное руководство от Oskar Andreasson
   При его прочтении обратите внимание на цель (действие) LOG, которое позволяет записывать в лог различные данные по попадающим в систему пакетам. Это очень сильно помогает при первоначальном написании файрвола. Могу посоветовать примерно такой порядок настройки файрвола:
   a) Написать все нужные правила
   б) В конец каждой цепочки добавить правило логирования (оно будет отлавливать все пакеты, которые вы не учли в предыдущих правилах и записывать информацию о них в сислог)
   в) Включить файрвол
   г) Находить неучтённые вами соединения в сислоге и добавлять правила для них в файрвол.
   Пункт (г) повторять до исчезновения записей в сислоге.
   Понятно, что не следует бездумно добавлять всё, что появляется в сислоге т.к там будут видны и результаты попыток несанкционированного доступа.
4. SELinux
   Очень интересная и перспективная вещь. Ограничивает права процессов по доступу куда-либо. Каждое действие, которое разрешено делать процессу должно быть прописано в политике, сопоставленной с ним.
   Существует ещё одна аналогичная система — Apparmor (насколько я знаю она используется в ubuntu linux).
   Честно говоря с обеими системами я ещё не работал вплотную (поэтому рекомендаций особых дать не могу), частично использовал SELinux в одном проекте, но ввиду цейтнота по времени, в котором я тогда находился, пришлось временно эту задачу отложить. В скором времени однозначно вернусь к настройке SELinux т.к он мне весьма понравился.

Мониторинг

Взломы и аварии, как известно лучше предотвращать, чем устранять их последствия.
В этой связи очень актуальна грамотно настроенная система мониторинга, которая при первых признаках проблемы сразу подаст сигнал администратору.

1. Nagios
   Существует несколько крупных систем мониторинга (nagios, zabbix, cacti, munin).
   Я пробовал их все и в итоге остановился на Nagios. Очень удобная и гибкая в настройке система.
   Огромное количество плагинов для мониторинга, а если подходящего плагина нет, можно написать свой на любом удобном вам языке (я например использую для этого bash и python).
   Как минимум необходимо настроить мониторинг загрузки процессора, памяти, свапа, свободного места на диске, load average. Очень желательно мониторить доступность критичных сервисов (например apache, mysql, nginx, tomcat итд).
2. MRTG/RRD
   Динамику изменения различных показателей удобно просматривать на графиках, генерируемых с помощью MRTG.
   MRTG позволяет просмотреть в удобном виде зависимость различных системных параметров от времени.
   Например можно посмотреть то, как изменяются загрузка процессора и памяти в зависимости от времени суток. Рисовать графики можно практически для любых показателей — от температуры процессора, до количества запросов к базе данных. MRTG это инстумент, крайне полезный для анализа состояния системы.
   У MRTG есть несколько ограничений и недостатков, которые можно обойти воспользовавшись утилитой RRD от того же автора.
3. Smartd + smartmontools
   Позволяет мониторить состояние жёстких дисков и выявлять подозрительные показания на самом раннем этапе. Можно интегрировать в Nagios.
   Например отличное от нуля значение переменной Reallocated_Sector_Ct указывает на то, что на диске появились бэд секторы, причём появились уже давно т.к smart узнаёт о наличии бэдов только после того, как переполняется заводская remap таблица (тут могу немного ошибаться, теорию по этому поводу давно не обновлял, возможно у современных жёстких дисков бэды сразу видны через smart).
   Можно и нужно настроить smartd так, чтобы все подозрительные показания сразу же высылались по электронной почте администратору.
4. Анализаторы логов
   Ясно, что вручную мониторить логи системы на предмет ошибок занятие неблагодарное.
   Для этой цели уже давно существует много анализаторов логов.
   Советую поставить сразу несколько систем и выбрать ту, что понравится больше.
   Начать можно с logwatch.
5. Remote syslog
   Как вы думаете, какова первая цель злоумышленника, проникшего в какую-либо систему?
   Цель — скрыть своё присутствие.
   Для этого он обязательно удалит все упоминания о своих действиях из логов системы (а также попробует подменить некоторые системные утилиты, но об этом ниже).
   Для того, чтобы защититься от негативных последствия удаления логов необходимо организовать их запись на удалённый сервер. Желательно, чтобы ssh доступ на этот сервер был невозможен (самому можно заходить через IP KVM) либо сильно затруднён, иначе ничего не помешает взломщику удалить хранящуюся там немодифицированную копию логов. На самом лог сервере удобнее всего хранить логи в какой-либо СУБД.
6. HIDS и NIDS
   HIDS мониторит состояние системы (логи, целостность системных утилит итд) и при подозрении на нарушение безопасности информирует об этом администратора. Она поможет в случае, если злоумышленник из предыдущего пункта подменит какую либо системную утилиту с целью скрыть своё присутствие либо обеспечить себе вход в систему. Например можно подменить утилиты ps, who, w, last с тем, чтобы администратор не мог видеть кто залогинен в системе в настоящий момент. Заменить утилиты iptables и sshd с тем, чтобы они позволяли злоумышленнику свободно входить в систему. Одним из примеров HIDS является OSSEC.
   HIDS конечно не сможет помешать таким действиям, но вполне сможет уведомить о них администратора.
   NIDS Если HIDS мониторит внутреннее состояние системы, то NIDS анализирует подозрительную сетевую активность (сканирование портов, попытки подбора паролей, различные атаки против сервисов системы итд). Наиболее известной NIDS является Snort.

Бэкапы

1. Как известно системные администраторы делятся на тех, кто не делает бэкапы, на тех, кто их уже делает и на тех, кто думает, что их делает.
   Это изречение наполнено глубоким смыслом.
   Бэкапы могут понадобиться во многих случаях, например после аппаратных проблем с системой, после её взлома, после некорректных действий администратора или разработчика.
   Можно условно разделить бэкапы на бэкапы файловой системы и бэкапы баз данных.
   Очень желательно иметь отдельный сервер для хранения бэкапов, в идеале ещё и находящийся отдельно от всего остального оборудования. Отдельно значит на расстоянии километров 5, не меньше.
   
   Для бэкапа написано много разнообразного ПО, но я предпочитаю использовать скрипты, написанные лично мной. Так я получаю полный контроль над процессом.
   Для бэкапа файловой системы проще использовать rsync с подходящими ключами. В большинстве случаев удобнее делать инкрементальный бэкап.
   Для бэкапов баз данных лучше всего использовать утилиты, предоставленные производителями СУБД, но в случае с mysql я немного отошел от этого правила.
   Стандартная утилита для бэкапа — mysqldump не очень хорошо ведёт себя при снятии бэкапа, а именно — она «лочит» таблицы на запись, запрещая писать в них в момент бэкапа (хотя в случае с innodb этого можно было бы вполне избежать, но mysqldump не умеет этого делать). Это очень актуально при использовании больших баз, размером хотя бы 10-20 Гб, где блокировка таблицы может длиться 10-20 минут. Кроме того восстановление больших баз из такого бэкапа занимает многие часы.
   В такой ситуации более разумно использовать систему master->slave.
   На бэкап сервере настраивается mysql slave для той базы, которую необходимо бэкапить. В дальнейшем бэкапы снимаются уже не с основной базы, а с её slave-а. В случае же аварии можно даже сразу не восстанавливать базу, а просто перенаправить все запросы на slave сервер, что позволит сильно сэкономить время. Для снятия бэкапов со slave сервера и для его первичной подготовки удобно использовать утилиту Innobackupex от компании Percona. Она например позволяет сделать бэкап, пригодный для последующего поднятия slave сервера без остановки основной базы (без блокировки её на запись).

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