Для тех, кто досмотрел все сезоны новых и любимых сериалов, у нас есть кое-что поинтереснее — видео с Elasticsearch meetup в OZON.

0. Вступление

Цель данной статьи собрать в небольшую кучку основную информацию, минимально достаточную для того, чтобы начать работать с докер на ежедневной основе и удалить с рабочей машины локально установленные apache, mysql, virtualenv, python3, mongodb, memchaced, redis, php5, php7 и весь остальной зоопарк, который мы используем при разработке, и который зачастую еще и конфликтует между собой от версии к версии.

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

Сразу оговорюсь, эта статья так сказать «от новичка новичку», поэтому постараюсь подробно рассказать обо всех сложностях и вопросах, которые у меня возникли в процессе настройки окружения в Docker.

Добро пожаловать под кат!

Содержание первой части:


Содержание второй части:

2.1 — Введение во вторую часть. Смотрим на сеть и протоколы. Wireshark.
2.2 — Таблицы Firewall. Transport Layer. Структуры TCP, UDP. Расширяем Firewall.
2.3 — Расширяем функциональность. Обрабатываем данные в user space. libnetfilter_queue.
2.4 — Бонус. Изучаем реальную Buffer Overflow атаку и предотвращаем с помощью нашего Firewall'а.

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

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

Игорь Сысоев ( isysoev )

Меня зовут Игорь Сысоев, я автор nginx и сооснователь одноименной компании.

Мы продолжаем разработку open source. С момента основания компании темпы разработки существенно увеличились, поскольку над продуктом работает множество людей. В рамках open source мы оказываем платную поддержку.

Я буду говорить о масштабируемой конфигурации nginx, но это не о том, как обслужить с помощью nginx сотни тысяч одновременных соединений, потому что nginx для этого настраивать не надо. Нужно выставить адекватное число рабочих процессов или поставить его в режим «авто», поставить worker_connections в 100 000 соединений, после этого заниматься настройкой ядра — это гораздо более глобальная задача, чем просто настройка nginx. Поэтому я буду рассказывать о другой масштабируемости — о масштабируемости конфигурации nginx, т.е. о том, как обеспечить рост конфигурации от сотни строчек до нескольких тысяч и при этом тратить минимальное (желательно константное) время на сопровождение этой конфигурации.

Вчера была опубликована хорошая статья «Веб-дизайн. Каждому устройству свое представление». Несмотря на неплохие размышления, к сожалению, вывод в ней довольно глупый. А именно:

«Нужно определить, какими устройствами могут пользоваться ваши посетители, проработать и создать для этих устройств представление вашего сайта, определить устройство посредством проверки заголовков браузеров, и отправить наиболее подходящее представление.»

Почему это глупо

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



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств

Почти каждому, у кого есть сервера с привязанными к ним доменами, так или иначе приходится решать вопрос с почтой, как минимум с доступностью адресов вида webmaster/postmaster/abuse@domain.
Кто-то учит M4 и настраивает встроенный sendmail, кто-то использует сторонние сервисы ( например от Google ), кто-то — поднимает стандартную связку postfix+courier-imap+mysql ( ну или аналоги ).

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

Prerequirements

При написании этого руководства я предполагал, что пользователь способен взаимодействовать с *nix-системами посредством консоли, умеет устанавливать пакеты своего дистрибутива и владеет как минимум одним текстовым редактором для редактирования конфигов. В качестве примера я буду устанавливать пакеты на Arch Linux, поскольку это мой домашний дистрибутив.

Рассмотрим на примере WordPress способ усиления безопасности при помощи ограничения количества HTTP-запросов к форме ввода пароля. Это позволит оградить опубликованный блог от брутфорса (поиска и взлома пароля путем перебора всех теоретически возможных вариантов из определенного набора символов или подбора по словарю распространенных паролей). Данный способ, в принципе, можно использовать и для защиты других веб-приложений.

Задача может быть реализована в Nginx с помощью модуля ngx_http_limit_req_module [1], выступающем в роли фронт-энда к Apache или веб-сервера FastCGI, или же с помощью HAProxy [2, 3], выступающем в роли балансировщика нагрузки перед веб-серверами.

В обоих случаях алгоритм работы следующий. При аутентификации браузер обращается по адресу, содержащему в себе подстроку "/wp-login.php". Необходимо отследить ее и ограничить количество запросов с одного IP не затрагивая обращения по всем остальным адресам. Параметры блокировки необходимо подобрать таким образом, чтобы не создавать неудобств обычным пользователями. Особенно внимательно следует настраивать блокировки в том случае, когда формой авторизации пользуется большое количество пользователей с одного IP-адреса.

Данная статья является продолжением статьи по установке системы.
Наконец тем или иным образом у нас появился установленный Asterisk и FreePBX.

Опишу ситуацию немного подробнее для сравнения подойдет ли Вам наша схема работы. Мы небольшой интернет провайдер, нам нужна запись разговоров, очереди звонков на городские и мобильные телефоны, голосовое меню рассказывающее про акции с выбором в какой отдел попасть, и возможность быстро поставить перед всем этим сообщение об авариях на определенных улицах города, чтобы люди не перенапрягали тех поддержку, причем желательно бесплатно. Чтобы не покупать дорогие шлюзы мы решили сменить городские телефонные номера и купить пару номеров + десяток каналов у провайдера ip-телефонии. Кто то скажет что это ненадёжно и т.д. Только скажите- какая разница интернет провайдеру на городские телефоны, если у него упал весь интернет? Зато это дешево. Подключение нам обошлось всего то в 38 $, каждый телефонный номер в 2$ и линия в 1,2$ в месяц. После чего мы получили настройки даже без авторизации и к нашему ip адресу привязали аккаунт. Сразу хотелось бы оговорить как будет построена эта статья, чтобы не перегружать её тоннами скринов я опишу создание каждого элемента по одному разу(что советую проделать т.к. они понадобятся для ваших же последующих экспериментов), а потом уже распишу схему что на что ссылается в нашей схеме работы. Наверняка схема у вас будет другая, но зато сможете понять смысл. Описывать буду только те элементы, которые непосредственно понадобились при настройке.

Я уже довольно долгое время хочу формализовать все свои мысли, опыт, ежедневно применяемый на практике, и многое другое в одном месте и предоставить их общественности. Уверен, многим этот материал будет полезен. Он посвящен различным моментам в конфигурации серверного ПО Linux и безопасным подходам к созданию сайтов/приложений на php (все же это до сих пор одна из самых популярных связок, хоть её успешно и подвигают другие технологии. Но советы так же легко применимы и к веб-ресурсам на других технологиях).

Т.е. речь идет о типичной ситуации. Проект (стартап), купили под него сервер и разворачиваем на нем сайт. Бизнесу не нужно тратить лишних денег на сервера (поэтому будут выбраны наиболее производительные связки ПО), а так же нужно, чтобы все было безопасно, при чем бесплатно :)

В рамках программы по унификации установленных серверных систем встала задача по переделке почтового сервера. Вдумчивое изучение мануалов и руководств показало довольно любопытный факт – нигде не было найдено однозначно достоверного руководства или подобия Best Practice по развёртыванию почтовика.

Мануал пошаговый, основывается на внутренней документации компании и затрагивает совершенно очевидные вопросы. Гуру могут не тратить время, ноу-хау здесь нет – руководство является сборной солянкой и публикуется только потому, что все найденные руководства по развёртыванию почтовика напоминали картинку о том, как рисовать сову.