Comments 40
LAPM это что такое? Всю жизнь был LAMP.
По поводу безопасности. Советую воспользоваться бесплатной утилитой nmap и посмотреть какими портами смотрит ваш сервер в мир. Вот например ваша машина которую вы настраивали.
Starting Nmap 6.40 ( http://nmap.org ) at 2016-09-28 17:13 KRAT
Nmap scan report for srv180-vps-st.jino.ru (81.177.165.220)
Host is up (0.13s latency).
Not shown: 985 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
1443/tcp closed ies-lm
49153/tcp open unknown
49154/tcp open unknown
49155/tcp open unknown
49157/tcp open unknown
49158/tcp open unknown
49159/tcp open unknown
49160/tcp open unknown
49163/tcp open unknown
49167/tcp open unknown
49176/tcp open unknown
49400/tcp open compaqdiag
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.0 — 3.9
Поменяйте стандартный порт 22 на другой свободный (посмотрите например файлик cat /var/log/security, там будет много роботов).
Также если есть боязнь потерять управление при смене порта ssh. поставьте бесплатную панель управления https://vestacp.com/ (например потерял подключение по ssh, можете подключиться через панель управления и рестартануть сервис или сменить порт на другой и поправить настройки файрвола). Ну и конечно поменять потом стандартный порт весты на другой.
Не было упоминаний про файрвол. Следует обратить внимание на безопасность. :)
Starting Nmap 6.40 ( http://nmap.org ) at 2016-09-28 17:13 KRAT
Nmap scan report for srv180-vps-st.jino.ru (81.177.165.220)
Host is up (0.13s latency).
Not shown: 985 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
1443/tcp closed ies-lm
49153/tcp open unknown
49154/tcp open unknown
49155/tcp open unknown
49157/tcp open unknown
49158/tcp open unknown
49159/tcp open unknown
49160/tcp open unknown
49163/tcp open unknown
49167/tcp open unknown
49176/tcp open unknown
49400/tcp open compaqdiag
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.0 — 3.9
Поменяйте стандартный порт 22 на другой свободный (посмотрите например файлик cat /var/log/security, там будет много роботов).
Также если есть боязнь потерять управление при смене порта ssh. поставьте бесплатную панель управления https://vestacp.com/ (например потерял подключение по ssh, можете подключиться через панель управления и рестартануть сервис или сменить порт на другой и поправить настройки файрвола). Ну и конечно поменять потом стандартный порт весты на другой.
Не было упоминаний про файрвол. Следует обратить внимание на безопасность. :)
А UDP порты не сканируете?
Поменяйте стандартный порт 22 на другой свободный
Так port knocking модно, да и старый добрый Fail2ban не забудем.
На счет «Весты» — тяжелая она и наверное избыточна в данном случае.
Менять 22 порт на другой — это не защита а игра в прятки.
Защита — это отключение парольного входа (только по ключу), отключение SSH для root, fail2ban.
Защита — это отключение парольного входа (только по ключу), отключение SSH для root, fail2ban.
Согласен. Забыл дописать про fail2ban и вход для root.
По защитам и безопасности есть отдельные статьи, где данные вопросы очень хорошо освящены. Своим комментарием я хотел показать, что даже после настройки (в которой ты уверен), нужно все равно перепроверить используя различные утилиты и проверять доступ извне.
По защитам и безопасности есть отдельные статьи, где данные вопросы очень хорошо освящены. Своим комментарием я хотел показать, что даже после настройки (в которой ты уверен), нужно все равно перепроверить используя различные утилиты и проверять доступ извне.
Очень не хватает пояснений почему такое большое количество настроек изменяется. Чем предложенные варианты лучше тех, которые установлены по умолчанию.
Читал-читал… Надеялся увидеть нафига ставить апач… Так и не нашел. А почему не nginx+php-fpm? И тогда уж не LAMP, а LNAMP?
ЕМНИП после установки sudo еще в конфиге нужно раскомментить %wheel группу… Хотя может уже и не надо.
Отказоусточивость — где? Безопасность? Порт ssh поменяли? Ну хотябы тогда уж в nginx включили бы naxsi…
Ах да, про firewall забыл… но это уже другая история :)
ЕМНИП после установки sudo еще в конфиге нужно раскомментить %wheel группу… Хотя может уже и не надо.
Отказоусточивость — где? Безопасность? Порт ssh поменяли? Ну хотябы тогда уж в nginx включили бы naxsi…
Ах да, про firewall забыл… но это уже другая история :)
Еще, почему порт 80? а где ssl?
А еще в nginx лучше модно upstream.
Ну и fail2ban уже упомянули выше
А еще в nginx лучше модно upstream.
Ну и fail2ban уже упомянули выше
> в конфиге нужно раскомментить %wheel группу
В CentOS 7 уже не нужно, эта строчка раскомментирована и так.
> Нафига ставить апач
Чтобы беспроблемно работали правила в .htaccess, в противном случае для каждой cms-ки придётся править конфиг nginx-а.
В CentOS 7 уже не нужно, эта строчка раскомментирована и так.
> Нафига ставить апач
Чтобы беспроблемно работали правила в .htaccess, в противном случае для каждой cms-ки придётся править конфиг nginx-а.
Спасибо
Я, конечно, тоже использую хабр как записную книжку, но не до такой же степени.
Обновить систему, при этом сохранить устаревшие версии пакетов:
[root@test ~]# yum update
на дворе был 2016 год, на Хабре учили обновлять центось :(
>Nginx, Apache
Зачем 2?
>Настраивать сервер как Вы уже поняли, будем первый раз, поэтому о актуальности статьи можно будет судить из комментариев.
Корелляции тут 0. :)
>Установим кодировку по умолчанию:
charset utf-8;
Вряд ли так стоит делать…
>Перенаправить запрос Apache:
proxy_pass http://localhost:8080/;
проксировать следует только php.
>Читать заголовок запроса клиента не более 10 секунд:
client_header_timeout 10;
Мобилки могут сказать привет :)
>client_body_timeout 25;
и
client_max_body_size 8m;
У клиента должна быть скорость интернета от 2,6 mbps.
>Если клиент не принимает ответ более 8 секунд, сбрасываем соединение:
send_timeout 8;
Опять мобилки :)
Забыли прописать хост по умолчанию… :)
>Отключаем обработку большого количества запросов в одном соединении:
KeepAlive Off
Почему?
>Подключить mimetypes:
<IfModule mime_module>
TypesConfig /etc/mime.types
Зачем, статику ж отдает nginx?
>Закрываем доступ к .htaccess:
<Files ".ht*">
Require all denied
Лучше на nginx закрыть…
Зачем 2?
>Настраивать сервер как Вы уже поняли, будем первый раз, поэтому о актуальности статьи можно будет судить из комментариев.
Корелляции тут 0. :)
>Установим кодировку по умолчанию:
charset utf-8;
Вряд ли так стоит делать…
>Перенаправить запрос Apache:
proxy_pass http://localhost:8080/;
проксировать следует только php.
>Читать заголовок запроса клиента не более 10 секунд:
client_header_timeout 10;
Мобилки могут сказать привет :)
>client_body_timeout 25;
и
client_max_body_size 8m;
У клиента должна быть скорость интернета от 2,6 mbps.
>Если клиент не принимает ответ более 8 секунд, сбрасываем соединение:
send_timeout 8;
Опять мобилки :)
Забыли прописать хост по умолчанию… :)
>Отключаем обработку большого количества запросов в одном соединении:
KeepAlive Off
Почему?
>Подключить mimetypes:
<IfModule mime_module>
TypesConfig /etc/mime.types
Зачем, статику ж отдает nginx?
>Закрываем доступ к .htaccess:
<Files ".ht*">
Require all denied
Лучше на nginx закрыть…
> Nginx, Apache
>> Зачем 2?
Ответил в начале статьи.
> Установим кодировку по умолчанию:
charset utf-8;
>>Вряд ли так стоит делать…
Почему?
По тайм-аутам поправил.
>Подключить mimetypes:
<IfModule mime_module>
TypesConfig /etc/mime.types
>>Зачем, статику ж отдает nginx?
У меня не запустился Apache без указания mimetypes
>> Зачем 2?
Ответил в начале статьи.
> Установим кодировку по умолчанию:
charset utf-8;
>>Вряд ли так стоит делать…
Почему?
По тайм-аутам поправил.
>Подключить mimetypes:
<IfModule mime_module>
TypesConfig /etc/mime.types
>>Зачем, статику ж отдает nginx?
У меня не запустился Apache без указания mimetypes
>Ответил в начале статьи.
Но на самом деле вы проксируете не только php… :)
>Почему?
Потому что достаточно указать мета-тег кодировки в html.
Возможны случаи (хз как сейчас), что клиент не будет обращать внимание на мета-тег при установленном хедере.
Тем более вы кодировку по умолчанию указываете на двух серверах.
Но на самом деле вы проксируете не только php… :)
>Почему?
Потому что достаточно указать мета-тег кодировки в html.
Возможны случаи (хз как сейчас), что клиент не будет обращать внимание на мета-тег при установленном хедере.
Тем более вы кодировку по умолчанию указываете на двух серверах.
В догонку.
Если client_body_timeout это между 2-мя операциями чтения, то увеличивать до 100 не нужно было. :)
Можно было оставить 25. :)
По умолчанию 60 сек.
Если client_body_timeout это между 2-мя операциями чтения, то увеличивать до 100 не нужно было. :)
Можно было оставить 25. :)
По умолчанию 60 сек.
Целый ряд вредных советов по настройке nginx, ни чем не обоснованных значений директив.
Можете привести несколько «правильных» примеров? Прочитаю в ближайшее время ваши публикации, посмотрел у вас тоже всё начиналось с минусовой кармы ))
Начните с того, что не трогайте настройки, которые вы до конца не понимаете как работают. Вот с какой целью вы выключили proxy_buffering? Это требуется в очень редких случаях, а в остальных ведет только к снижению производительности и расходу ресурсов. Зачем включили multi_accept? Зачем вообще трогали keepalive_timeout? Зачем спиливаете заголовки Range? Хотели защитить Apache, для этого есть директива max_ranges, хотя эта уязвимость была исправлена более 5 лет назад и если вы с тех пор не обновлялись, то у вас в любом случае проблемы. Вы также неправильно понимаете что содержится в переменной $proxy_add_x_forwarded_for. Указание localhost в директиве proxy_pass вместо явного IP-адреса, может приводить к тому, что он будет резолвиться в IPv4 и IPv6, при этом Apache у вас слушает только на IPv4. Остальные настройки тоже вызывают вопросы. К примеру, вы зачем-то зарезервировали место под хранение 10 000 файловых дескрипторов в каждом рабочем процессе на 3 минуты. Иными словами вы предполагаете, что ваш сервер будет практически непрерывно раздавать одновременно до 10 тысяч различных файлов. И это учитывая, что при этом вы установили максимально 1024 соединения на рабочий процесс.
В чем была цель написания данного материала? Статьи тут пишут для того, чтобы делиться знанием, а не незнанием. А вопросы в стиле "помогите разобраться, исправьте мои ошибки" — для этого существуют другие ресурсы. Те же списки рассылки, например. Существует платная поддержка, люди платят деньги, чтобы кто-то их консультировал, исправлял ошибки и обучал.
посмотрел у вас тоже всё начиналось с минусовой кармы ))
Вы меня с кем-то путаете.
А где сжатие трафика Nginx-ом?
Где настройки буферов проксирования?
> query_cache_size = 0
> innodb_log_buffer_size = 0M
???
> table_open_cache = 64
Для сайтопомойки то?..
Cтатистику базы анализировать надо, а не с потолка брать.
> access_log off;
На спичках сэкономили и убили статистику
> limit_rate 500K;
А потом зарезали времена взаимодействия с клиентом, да ограничили MaxClients 30 — пусть повисят подольше, да жрут побольше.
> memory_limit = 256M
щедро, не bitrix ли часом?
А где apc/opcache/xcache?
Где настройки буферов проксирования?
> query_cache_size = 0
> innodb_log_buffer_size = 0M
???
> table_open_cache = 64
Для сайтопомойки то?..
Cтатистику базы анализировать надо, а не с потолка брать.
> access_log off;
На спичках сэкономили и убили статистику
> limit_rate 500K;
А потом зарезали времена взаимодействия с клиентом, да ограничили MaxClients 30 — пусть повисят подольше, да жрут побольше.
> memory_limit = 256M
щедро, не bitrix ли часом?
А где apc/opcache/xcache?
В CentOS 7 Minimal по-умолчанию включен SELinux, который, по идее, пока вы не проставите правильный контекст для папок /website/* не даст вашим веб-серверам и php работать нормально.
Т.к. Вы несколько раз делаете акцент на безопасности, удивлен что о SELinux нем ничего нет.
Но главное, что Ваша инструкция не начинается как большинство, даже официальных: «1. Отключаем SELinux. 2...n Настраиваем»
Т.к. Вы несколько раз делаете акцент на безопасности, удивлен что о SELinux нем ничего нет.
Но главное, что Ваша инструкция не начинается как большинство, даже официальных: «1. Отключаем SELinux. 2...n Настраиваем»
P.S. Можно использовать Nginx с php-fpm, но есть такое мнение, что при правильно настроенном Apache особой разницы в производительности не наблюдается.
Если надо особо хитро настраивать apache чтобы не было разницы, то зачем нужен apache?
Имхо чем проще система (меньше «звеньев»), тем легче в обслуживании…
Я бы даже сказал, что правильно настроенный работает и без nginx :)
Это уже зависит от «религии» и нужд «приложения». Кто-то ставить nginx, кто-то apache. Но ставить оба, как-то не вижу смысла, разве что как ступень перехода от одного к другому.
Я лично стараюсь использовать по минимуму… Есть сервер, который отдает только статику, он на nginx и больше там ничего не надо, на сервере бекэнда стоит только node.js без каких либо других веб серверов, т.к. они там не нужны.
Я лично стараюсь использовать по минимуму… Есть сервер, который отдает только статику, он на nginx и больше там ничего не надо, на сервере бекэнда стоит только node.js без каких либо других веб серверов, т.к. они там не нужны.
не, ну так я и спросил у ТС — нафига там апач вообще? htaccess легко переписывается в nginx, есть простенькие онлайн конвертеры. для популярных cms легко найти примеры конфигов. Зачем этот жирный апач ставить? Я уже давно избавился от него на своих серверах. Ну не нужен он :) nginx просто проксирует запросы на бекенды и раздает статику. Дойдут руки — поковыряю openresty…
apache под nginx нужен для .htaccess на шаред хостинге.
Но это не случай автора, он .htaccess вроде отключил.
Но это не случай автора, он .htaccess вроде отключил.
Неплохой такой конечно ман для самых-самых маленьких)) а почему не XAMMP? лично мне нравится, все супер быстро, на nginxe наружу прокинул и наслаждайся. А почему CentOS? Сейчас VPS с огромным количеством осей на все вкусы есть. Хотя бы какое то обоснование да и конкретику по технологиям было бы интересно прочитать в тексте.
Кстати, ценнейший комментарий от shep насчет SELinix. Для начинающих, на кого ориентирована статья, это может стать преградой. Отключать SELinux — очень плохаяспорная мысль.
Добавьте для читателей простоту использования «ls -Z», «semanage fcontext -a -t httpd_log_t <путь-до-лога>», «restorecon -Rv». Для вас это, возможно, очевидно, но для новичков — вряд ли.
Потом, настройки firewall вообще не раскрыты, а между тем на CentOS 7 по-умолчанию стоит нетривиальный для новичков firewalld. Возможно, есть смысл его отключить и настроить iptables по-старинке.
SSH, независимо от порта, на котором он будет работать, использовать намного лучше с ключами. Раз вы работаете из Putty, хотя бы отметьте, что есть puttygen и как его едят.
Вопросы защиты всего описанного вами комбайна встанут сразу как только вы его подключите к интернет. Сразу, а не через 2 месяца.
fail2ban, на мой взгляд, крайне желательно поставить.
И да, новички хотят понимать, зачем им ставить сразу nginx и apache.
В общем, я бы разделил статью на части:
1. подготовка хоста с CentOS 7 под свой LAMP. Упор на безопасность.
2. собственно, настройка элементов LAMP.
3. политика резервирования всего этого хозяйства, восстановление после сбоя. rsync — ок. Конкретно, как? rsync через ssh — прекрасно. Как? И самое главное, пример (хотя бы на виртуалку) восстановления после сбоя.
С моей точки зрения, домашний LAMP неплохо делать на виртуальных машинах. На том же CentOS настраиваете kvm, создаете гостевую гигов на 30. И в нее уже все что вы описали, за что вам спасибо! И бекапить виртуалку и восстанавливать ее после сбоя в разы может быть проще.
Я сам такие статьи пишу для себя, как мануал для личного пользования, на хабр выложить не решаюсь, вот и сижу в ридонли. А вы молодец, решились. Удачи!
Добавьте для читателей простоту использования «ls -Z», «semanage fcontext -a -t httpd_log_t <путь-до-лога>», «restorecon -Rv». Для вас это, возможно, очевидно, но для новичков — вряд ли.
Потом, настройки firewall вообще не раскрыты, а между тем на CentOS 7 по-умолчанию стоит нетривиальный для новичков firewalld. Возможно, есть смысл его отключить и настроить iptables по-старинке.
SSH, независимо от порта, на котором он будет работать, использовать намного лучше с ключами. Раз вы работаете из Putty, хотя бы отметьте, что есть puttygen и как его едят.
Вопросы защиты всего описанного вами комбайна встанут сразу как только вы его подключите к интернет. Сразу, а не через 2 месяца.
fail2ban, на мой взгляд, крайне желательно поставить.
И да, новички хотят понимать, зачем им ставить сразу nginx и apache.
В общем, я бы разделил статью на части:
1. подготовка хоста с CentOS 7 под свой LAMP. Упор на безопасность.
2. собственно, настройка элементов LAMP.
3. политика резервирования всего этого хозяйства, восстановление после сбоя. rsync — ок. Конкретно, как? rsync через ssh — прекрасно. Как? И самое главное, пример (хотя бы на виртуалку) восстановления после сбоя.
С моей точки зрения, домашний LAMP неплохо делать на виртуальных машинах. На том же CentOS настраиваете kvm, создаете гостевую гигов на 30. И в нее уже все что вы описали, за что вам спасибо! И бекапить виртуалку и восстанавливать ее после сбоя в разы может быть проще.
Я сам такие статьи пишу для себя, как мануал для личного пользования, на хабр выложить не решаюсь, вот и сижу в ридонли. А вы молодец, решились. Удачи!
Sign up to leave a comment.
Установка и оптимальная настройка Nginx + LAMP (CentOS 7)