Author: admin

Сканер ConfigServer eXploit (cxs) – это инструмент, который выполняет активное сканирование файлов по мере их загрузки на сервер на наличие в них вирусов и вставок. Первоначальная установка с рекомендуемыми параметрами конфигурации включена в лицензию для защиты сервера от вирусов.

Сканер вредоносного кода

Активное сканирование может выполняться во всех текстовых файлах:

• Активно сканирует все измененные файлы в учетных записях пользователей с помощью демона cxs Watch независимо от того, как они были загружены
• PHP загрузки сценариев (через хук ModSecurity)
• Скрипты загрузки Perl (через хук ModSecurity)
• Скрипты загрузки CGI (через хук ModSecurity)
• Любой другой тип веб-скрипта, который использует HTML-форму ENCTYPE multipart / form-data (через хук ModSecurity)
• Загрузка Pure-ftpd

Активное сканирование файлов может помочь предотвратить использование учетной записи вредоносным программным обеспечением, удалив или переместив подозрительные файлы на карантин, прежде чем они станут активными. Это также может помешать загрузке скриптов PHP и perl, обычно используемых для запуска более злонамеренных атак и для отправки спама.

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

Обнаружение эксплойта включает в себя:

• Более 4000 известных текущих следов сценария эксплойта (в дополнение к стандартному обнаружению ClamAV)
• Известные вирусы через ClamAV
• Сравнение шаблонов регулярных выражений для определения известных / неизвестных эксплойтов
• Соответствие имени файла
• Подозрительные имена файлов
• Подозрительные типы файлов
• Бинарные исполняемые файлы
• Некоторые незаконные установки веб-программного обеспечения
• Пользовательские настраиваемые шаблоны регулярных выражений
• Всестороннее постоянное сканирование всех пользовательских данных с помощью демона cxs Watch – сканирование всех пользовательских файлов сразу после их изменения
• Ежедневная проверка новых следов эксплоита (Exploit Fingerprints)
• Проверка наличия старой версии популярных веб-скриптов (например, WordPress, Joomla, osCommerce)
• Проверка вероятности – сканирует скрипты и обрабатывая содержимое через алгоритм, который выдает вероятность того, является ли это эксплойтом
• Мониторинг файлов и каталогов, изменений и отправка отчета по электронной почте о деятельности
• Система репутации IP. Система использует множество блочных списков IP, собранных из информации, предоставляемой участвующими серверами. Этот двойной аспект предоставляет информацию, помогающую защитить сервер, используя репутацию IP для блокировки активных атак
• Основное обновление для сканирования скриптов. CXS теперь сканирует более 200 отдельных приложений, более 200 плагинов WordPress и более 200 расширений Joomla. Всего более 700!
• Простой мастер установки cxs для пользовательского интерфейса и конфигурации при первом запуске
• CXS Command Wizard для создания эффективных команд сканирования
• Новый интерфейс карантина через базу данных SQLite
• Cтатистика, для получения информации относительно того, что делает cxs
• Команда Wizard для настройки конфигурации cxs Watch, Modsecurity и FTP
• cxs Daily / Weekly Scan Wizard, чтобы создавать и изменять задания cron в файле /etc/cron.d/cxs-cron
• … и многое другое!

Веб-интерфейс пользователя:

В комплекте с интерфейсом командной строки cxs (CLI) используется веб-интерфейс пользователя (UI), который позволяет:

• Запуск сканирования
• Расписание и редактирование сканирования через CRON
• Составление команд сканирования CLI
• Просмотр, удаление и восстановление файлов из карантина
• Просмотр документации
• Установка и изменение значений по умолчанию для сканирования
• Редактировать часто используемые файлы cxs

Примечание. Cxs не является сканером руткитов, хотя он может помочь обнаружить руткиты, загруженные в учетные записи пользователей.

Хотите проверить свой сервер или защитить десятки сайтов от вирусов на сервере, обращайтесь office@itfb.com.ua

Организации сначала начали использовать облако в основном для тестирования и разработки, потому что это позволило разработчикам и тестировщикам (QA) быстро и легко развернуть тестовые виртуальные машины, не требуя вмешательства ИТ-администраторов или администраторов хранилищ. По мере того, как бизнес стал более осведомленным о облачных сервисах и возможностях, организации также начали использовать облако для более важных ИТ-функций, включая резервное копирование критически важных данных и использование облака в качестве сайта аварийного восстановления  disaster recover (DR).

Для базового уровня DR вы можете использовать облако в качестве места удаленного резервного копирования. Облачное резервирование позволяет вам выбирать данные, которые вы хотите защитить, а также выбирать время, на которое вы хотите сохранить данные резервного копирования. Поскольку объемы данных быстро растут практически для каждой организации, облачное резервирование позволяет не беспокоиться об управлении пространством, как например на более дорогом локальном хранилище SAN или NAS или с использованием специализированных резервных хранилищ; облачное резервное копирование также является отличным способом защиты от вымогательства. Облако отключено от вашей локальной инфраструктуры, и вы можете защитить свои резервные копии своей собственной аутентификацией, предоставляя им степень изоляции от ваших онлайн-процессов. Вы также можете хранить несколько копий облачного резервирования, гарантируя, что у вас есть резервная копия, с которой вы можете восстановить.

Возможности DR облака выходят далеко за рамки базовых резервных копий. Для DR большинство компаний ищут репликацию VM, чтобы улучшить свои возможности восстановления и сроки. Использование репликации для DR позволяет отказаться от длительного процесса восстановления, который обычно связан с резервными копиями. Вместо этого, используя репликацию, вы можете быстро перейти к реплике VM в облаке в случае сбоя. Эта копия VM может быть почти синхронизирована с целевой – и потеря данных при переключении – минимальна.

Чтобы установить репликацию VM в облако, вам необходимо выполнить следующие шаги:

1. Установите соединение между вашим локальным сайтом и поставщиком облачных вычислений. Обычно это VPN, но доступны другие решения.
2. Создайте резервную копию критически важных виртуальных машин. Исходная реплика VM может быть восстановлена ​​из резервной копии. В начале создается полная копия, это может занять длительное время. Эта начальная копия дает вам отправную точку для процесса репликации.
3. Внедрение технологии репликации виртуальных машин – Microsoft и VMware обладают базовыми возможностями репликации VM. Кроме того, существует несколько продуктов репликации третьего уровня, которые также предлагают более продвинутые возможности.
4. Выберите тип репликации. Репликация может быть синхронной или асинхронной. Как правило, репликация в облако использует асинхронную репликацию, чтобы избежать локальных проблем с задержкой.
5. Выберите интервал репликации. Интервал репликации определяет, как часто данные передаются из ваших локальных виртуальных машин в облако. Большинство продуктов репликации позволяют варьировать частоты в диапазоне от почти реального времени до 15 минут и более. Выбранный вами интервал зависит от ваших целей точки восстановления RTO и RPO.
6. Выберите количество точек восстановления. Большинство продуктов репликации также позволяют выбрать количество точек восстановления для создания. По сути, каждая точка восстановления позволяет восстановить реплику VM до более раннего момента времени. Важно понимать, что ваши требования к размеру хранилища увеличиваются по мере добавления точек восстановления.
7. Опционально расширить репликацию. Многие продукты репликации также позволяют создавать несколько реплик в разных местах для повышения безопасности и восстановления.
8. Начните репликацию. После настройки репликации вы можете запустить репликацию, которая начнет отправлять изменения с исходной виртуальной машины на виртуальные машины реплик. Некоторые продукты репликации поддерживают автоматический переход на резервный ресурс, в то время как другие требуют ручного переключения при сбое в случае сбоя.

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

Наша компания поможет реализовать репликацию в облако, office@itfb.com.ua

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

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

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

Изоляция и контейнеризация — не новые термины в вычислительных системах. Технология Linux Containers (LXC), появившаяся в ядре Linux ещё в 2008 году, легла в основу дальнейшей разработки контейнеризации. Она позволяет организовать изолированное использование ресурсов и пространств имён. Изначально Docker использовал LXC практически в неизменном виде.

Преимущества контейнеризации с Docker

Абстрагирование приложения от хоста

Основная идея контейнера — полная стандартизация. Он соединяется с хостом через определённый интерфейс, и приложение внутри него не зависит от архитектуры или ресурсов хоста. Для хоста контейнер — это «чёрный ящик», и его содержимое не имеет значения.

Масштабирование

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

Управление версиями и зависимостями

Благодаря контейнерам разработчик привязывает все компоненты и зависимости к приложению, что позволяет работать с ним как с единым объектом. Для запуска приложения внутри контейнера на хосте не требуется установка дополнительных компонентов или зависимостей, достаточно иметь возможность запускать контейнеры Docker.

Изолированная среда

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

Использование слоёв

Легковесность контейнеров объясняется их многослойной структурой. Когда несколько контейнеров используют один и тот же слой, они могут пользоваться им без дублирования, что минимизирует использование дискового пространства.

Компоновка

Существует возможность описывать конкретные действия для создания нового образа. Таким образом, настройки среды можно писать как код и сохранять в системе контроля версий.

Недостатки контейнеров Docker

Тонкая настройка

При больших масштабах и нагрузке требуется очень точная и качественная настройка систем.

Обратная совместимость

Docker быстро развивается, и одним из минусов такого развития может быть ограниченная обратная совместимость в некоторых областях.

Удаление

Процесс удаления контейнеров Docker может занимать много времени и требует немалого количества операций ввода-вывода.

Производительность

Дополнительные надстройки на системе в любом случае приводят к увеличению нагрузки и расходу ресурсов.

Архитектура

Контейнеризация является надстройкой над ОС, что усложняет реализацию некоторых задач.

Поддержка

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

Вывод

Контейнеризация с Docker имеет свои достоинства и недостатки. Решение об использовании контейнеров должно приниматься исходя из конкретной задачи. Для некоторых задач без Docker не обойтись, а для других он может быть попросту лишним.

Рассмотрим преимущества и недостатки использования контейнеров на конкретном примере создания простого веб-сервера.

Установка веб-сервера без контейнеров
1	Развёртывание Vesta CSP и установка пользователей и доменных имён 1 сервер	2ч
2	Развёртывание Vesta CSP и установка пользователей и доменных имён 2 сервер	2ч.
3	Организация отказоустойчивости серверов	3ч.
4	Загрузка файлов сайта клиентом	2ч
5	Замена IP-адресов на NS-серверах	1ч.
	Итого	8ч
Установка веб-сервера с использованием контейнеров
1	Установка Proxmox	1ч.
2	Установка LXC-контейнеров, маршрутизация их сети и автобекапов контейнеров	3ч.
3	Развёртывание Vesta CSP, настройка доменов и установка пользователей	2ч
4	Аналогичная настройка резервного сервера	5ч.
5	Создание кластера нод Proxmox и настройка автомаиции	1ч
6	Установка, настройка прокси-сервера, балансировки нагрузки и отказоустойчивости	3ч.
	Итого	15ч.

Как вы уже заметили, время на реализацию с использованием контейнеров значительно больше.

Давайте разберём плюсы и минусы Docker для веб-сервера:

Плюсы	Минусы
Балансировка нагрузки пользователей (второй сервер не простаивает)	Усложнение инфраструктуры из-за маршрутизации трафика
Отказоустойчивость в случае падения одной из нод	Зависимость от прокси-сервера (в идеале их тоже делают 2)
Лёгкое восстановление полного бэкапа за счёт снапшотов	Снижение производительности на 2-4% за счёт контейнеризации
Хранилище повышенной стойкости ZFS	Необходима поддержка виртуализации KVM на стороне хостера
Возможность содержать в контейнерах тестовые/dev и прод-серверы	Стоимость решения и поддержки
Подключение неограниченного кол-ва таких нод	Время реализации
Повышение безопасности инфраструктуры

Как и говорилось выше, в зависимости от поставленной задачи, минусы Docker могут нивелировать все плюсы от использования контейнерной виртуализации. Можно сделать вывод, что для сайтов вполне достаточно простой архитектуры из двух серверов. Если же планируется значительный рост разработки, а также огромный приток посетителей за короткое время, в таком случае стоит рассматривать инфраструктуру с использованием Docker.

Наша команда профессиональных DevOps-администраторов имеет большой опыт во внедрении и поддержке контейнеризации, в том числе и Docker. Обращайтесь: office@itfb.com.ua

Какая часть компании является самой важной в наши дни? Отдел продаж? Управление? Разработчики? Точно никто не скажет. Но реальность такова, что ни одна из перечисленных групп не является незаменимой, может возникнуть лишь некоторое неудобство, если ключевой член команды уходит и его заменяют другим сотрудником. Если ваша ИТ-структура катится в тартарары, едва ли найдется компания, которая сможет поддерживать ее работо­способность, так как зависимость предприятий от ИТ только увеличивается. По этой причине у каждой компании либо уже предусмотрены процедуры вос­становления после аварийных ситуаций Disaster Recovery (DR), либо компания присматривается к тому, чтобы получить DR, но пока это дорого. Центры обработки данных, подключения, серверы, охлаждение, лицензии, элек­тропитание и многое другое— все это, как вы надеетесь, никогда не потребуется. Это весьма дорогой «ремень безопасности». Было бы здорово иметь какой-нибудь сер­вер, за который вы платите только тогда, когда реально используете его, то есть что-то, оплачиваемое по потребности.

Разработка и реализация стратегии построения отказоустойчивых, быстро восстанавливающихся систем, office@itfb.com.ua

Кроме шуток: большая часть «облачных» служб оплачива­ется по мере использования, они весьма привлекательны для применения в качестве решения DR. Существуют определенные повседневные эксплуатационные издержки, такие как система хранения, лицензирование и, может быть, некоторые приложения (виртуальные машины) для ключевых рабочих процессов. Но вы платите только за те прикладные приложения, которые вам реально приходится запускать в случае вос­становления после отказа в работе либо в режиме реального времени, либо в тестовом варианте.

Лучше всего я знаком с «облачными» службами Microsoft, поэтому хочу посмотреть, как можно использовать «облачные» службы этой компании для обычных сред. Суть в том, чтобы не думать о выборе какой-либо одной среды, это всеобъемлющее решение. Выберите подходящее решение для каждого приложения, а затем продумайте, как автоматизировать процесс вос­становления после отказа. Но ­пре­жде чем рассматривать восстанов­ление после сбоя как «облачную» службу, давайте посмотрим, как процедуры восстановления после сбоя выполнялись бы между разными местоположениями в локаль­ных сетях.

Прежде всего, выполняется обсле­дование важных для бизнеса систем, выясняется, от чего зависят эти системы (поскольку им приходит­ся быть взаимозависимыми), опре­деляются различные требования к доступности, включая то, какдолго они могут быть недоступны (опре­деляется целевое время восста­новления, Recovery Time Objective) и то, как много данных может быть утеряно (определяется целе­вая точка восстановления. Recovery Point Objective). Первое представ­ление может быть таким: «систе­ма должна быть доступной через 30 секунд, и я не могу потерять дан­ные». Но в реальности достижение этой цели может обойтись в 500 тыс. долл, в год, тогда как 15-минутная остановка в работе и потеря данных за последниие 5 минут будут стоить компании лишь 5 тыс. долл, от уте­рянного объема продаж. Не самое лучшее вложение.

Существуют многочисленные мето­ды защиты прикладных приложе­ний, которые можно перечислить в таком порядке предпочтений:

1. Репликация на уровне при­ложений, вроде SQL AlwaysOn, репликации между несколькими основными контроллерами доме­на, группы доступности Exchange Database Availability Groups и т.д. Имея под рукой эти технологии, вы получите полную видимость состояния репликации, контроль над репликациями, а приложе­ния будут защищены от любых отказов.
2. Репликация внутри гостевой операционной системы или репликация на уровне гиперви­зора, которая может дополни­тельно подключиться к службе мгновенных снимков VSS, чтобы предоставить периодические точки восстановления для при­ложений (экземпляры на опре­деленный момент времени для защищаемого прикладного при­ложения, которые могут быть восстановлены вместо недавнего состояния прикладного прило­жения).
3. Репликация на уровне хранили­ща данных.
4. Восстановление из резервной копии.

Кроме того, возможен другой вариант, который часто оставляют без внимания, но его место в этом списке зависит от различных условий. Некоторые прикладные приложения не имеют фиксируемого состояния. Подумайте о ферме из 50 веб-серверов, работающих на IIS. Они просто обслуживают запросы, а актуальные данные сохраняются в базе данных. Я не беспокоюсь о состоянии веб-серверов. Таким образом, вместо резервного копирования у меня есть образ сервера IIS или настройки режима DSC для PowerShell, которые в случае аварии создают новую ферму из 50 серверов по шаблону. Такой подход позволяет избежать любого резервного копирования и производить запуск так же быстро, как и активацию процесса создания новых 50 экземпляров.

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

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

Теперь, при наличии «облака», стали доступны различные типы служб. Существуют виртуальные машины, работающие по принципу «инфраструктура как служба», Infrastructure as a Service; службы, предоставляющие платформы по модели Platform as a Service, однако они требуют, чтобы приложения были написаны для модели PaaS. Последнего, вероятно, нет в большинстве организаций, но ситуация изменится с появлением Azure Stack. Также существует служба про­граммного обеспечения, работающая по модели Software as a Service, такая как Office 365. Сегодня что-то типа Office 365 в случае аварийной ситуации используется редко, однако выполненный ранее переход к Office 365 не оставляет сомнений в эффективности этой службы во время аварийной ситуации. Если Exchange, SharePoint и т.д. пере­мещаются в «облако», то в случае аварийной ситуации вам не только не придется беспокоиться об этих службах, но они станут жизненно важными службами коммуника­ции, на которые вы сможете положиться и которые будут использо­ваться во время процесса восста­новления после сбоя.

Теперь давайте сосредоточимся на службах IaaS, которые обеспечи­вают использование виртуальных машин в «облаке». К «облаку» применимы те же самые варианты, что существуют для локальных сетей, но разница в затратах огромна. На уровне приложения виртуальная машина должна запускаться в Azure для того, чтобы использо­вать возможность репликации. Это означает возникновение издержек и ассоциированного хранилища данных, но дает наилучшую управ­ляемость и репликации. Это был бы хороший вариант для самых критичных баз данных, которые являются особо важными для деятель­ности компании, где дополнитель­ные затраты оправдываются, если нужен полный контроль и обзор репликации, а также обеспечение очень быстрого восстановления после аварийной ситуации и наименьшая потеря данных.

Можно использовать и другое средство для репликации. В Azure это служба Azure Site Recovery, которая отвечает за репликации на уровне гипервизора для виртуальных машин Hyper-V и репликации уровня гостевой операци­онной системы для виртуальных машин ESX и физических систем. Для применения этой технологии требуется лицензия ASR, которая выдается на каждую защищаемую копию операционной системы на месяц (также ее можно купить как часть комплекта Operations Management Suite) плюс хранилище данных, но здесь сложно посчитать издержки за вычислительные ресурсы до тех пор, пока вы реально не выполните восстановление после аварийной ситуации. Они не будут определены, пока не будут учтены издержки на ресурсы, основанные на Azure.

Уровень хранилища данных может использоваться для таких устройств, как StorSimple, которое представляет собой специализи­рованную систему, использующую Azure в качестве дополнительного уровня хранения данных как наи­менее доступное хранилище плюс хранилище данных для полных снимков экрана всего содержимого. В случае аварийной ситуации в Azure можно запустить виртуаль­ный StorSimple и предоставить данные. Повседневные эксплуатаци­онные издержки возможны только за хранилище данных в Azure. Кроме того, существует вариант простого развертывания виртуальных машин по шаблону, где состояние не является проблемой, и именно этим удобны менеджер Azure Resource Manager и наборы масштабирования VM Scale Sets. За 5 минут я могу развернуть 100-узловую ферму I IS без пред­варительных затрат на эксплуата­цию, если не принимать во внимание размещение на хосте одного образа шаблона.

Таким образом, мы имеем целый ряд вариантов. Я использую различные технологии, поэтому в случае настоящей аварийной ситуации мой план восстановления будет сложным, со множеством шагов в разных системах. Azure Site Recovery предоставляет при­мер плана восстановления. План восстановления создается заранее, в нем определяется порядок вос­становления отказавших машин. PowerShell можно вызвать через Azure Automation, интегро рация с SQL AlwaysOn доступна, можно даже добавить шаг ожидания для мани­пуляций вручную, если нужно привести в действие что-либо во время реальной аварийной ситуации. Это занимает время, но в случае реальной аварийной ситуации выполняется одно задание, которое управляет всем процессом обработки отказа в работе (и последующим возвратом к состоянию до момента сбоя). Это важно в случае стрессовой аварийной ситуации, когда от сотрудников нельзя ожидать, что они будут выполнять какие- либо шаги вручную. Такая же технология используется для тестового прогона процесса обработки отказа в работе, но резервные копии развертываются в изолированной сети, чтобы она не пересекалась с производственной средой.

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

Веб сервер может быть построен на различном программном обеспечении, но зачастую в качестве фронтенда к apache и php-fpm используется nginx.

Легковестное и гибкое в настройке ПО имеет ряд преимуществ в следствии чего заработало такую популярность. В стандартный функицонал входят настройки для обеспечения базовой безопасности веб сервера в том числе защите от небольших ddos атак.

Для таких целей предназначены такие модули nginx, с подробным описанием можно ознакомится на официальных мануалах.

https://nginx.org/ru/docs/http/ngx_http_limit_req_module.html

https://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html

Модуль ngx_http_limit_req_module предоставляет возможность обработки медленных запросов, а также соростью обслуживания запросов с одного IP. Модуль ngx_http_limit_conn_module используется для ограничения количества запросов по определенным параметрам.

Таким образом используя данные модули можно отсечь медленные  запросы, так же ограничить количество запросов с одного ip тем самым защитить веб сервер. Данные лимиты помогают блокировать атаки без использования ботнета (сеть зараженных/подконтрольных атакующему устройств).

Веб-сервер будет пропускать ограниченное количество запросов, тем самым оставаясь “при памяти”. Так же будет адекватно реагировать с помощью request timeout. Ведь если запросы растягиваются во времени – то они забивают буфер, и тогда пользователи получают 503 ошибку сервера. Возможны так же другие ошибки из серии кодов ошибок 500.

Стоимт обратить внимание, при включении лимитов могут наблюдаются случаи замедления выдачи картинок на сайте (возможно даже не прогрузки). Поэтому значения остается подбирать только опытным путем. Это зависит от кэширования и собственно траффика на сайт, а также реализации програмной части кода сайта.

Пример конфигурации ограничения соединения с сервером с одного ip.

limit_conn_zone $binary_remote_addr zone=perip:10m;

Данная конфигурации отвечает за скорость обработки запросов

limit_req_zone $binary_remote_addr zone=perip:10m rate=1r/s;

Лимиты так же могут быть подобраны и опытным путь: поставили лимиты – запускаем тест-скрипт – смотри реакцию веб-сервера. Итерации повторям пока не добьемся нужного результата, а именно: сайт онлайн+картинки грузятся быстро+не ломается css, и в тоже время блокируются ddos атаки.

Наша компания предоставляет услуги по обеспечению защиты веб сервера, обращайтесь office@itfb.com.ua

Облако уже давно превратилось в экономичное средство резервного копирования для компаний любого типа. Однако разработать эффективную стратегию резервного копирования и восстановления в «облаке» не так легко. Да и подключиться к «облаку» не всегда просто. Встроенная функция резервного копирования Windows Server не обеспечивает прямого взаимодействия с «облаком», а многие «облачные» службы резервного копирования ограничены в своих воз­можностях или привязаны к определенному поставщику «облачных» услуг. Цель CloudBerry Ultimate Backup 5.7 — упростить резервное копирование Windows Server, настольных компьютеров Windows, систем SQL Server и Exchange в «облаке». При подготовке данного обзора была протестирована редакция CloudBerry Backup Ultimate.

Компания CloudBerry предлагает различные редакции специально для настольных компьютеров Windows, Mac, Linux, Windows Server, SQL Server и Exchange. CloudBerry не располагает собственным «облачным» хранилищем. Вместо этого с помощью CloudBerry Ultimate можно сохранять резервные копии в «облачных» хранилищах различных поставщиков, в том числе Amazon S3, Microsoft Azure, Google Cloud и др.

Благодаря наличию ряда важных функций CloudBerry Backup по праву может считаться весьма эффективной программой резервного копирования в «облаке». Во-первых, для большинства резервных копий CloudBerry не требуется места на локальном диске: резервное копирование может происходить непосредствен­но в «облако». В версии CloudBerry Backup Ultimate нет ограничений на объем данных в резервной копии. Поддерживается резервное копирование файлов, образов, SQL Server и Exchange. Для резервных копий образа формируются моментальные снимки тома на уровне блоков и пересылают­ся непосредственно в «облако». Во-вторых, с помощью CloudBerry можно архивировать только файлы, измененные со времени создания последней резервной копии, что позволяет уменьшить количество передаваемых данных. CloudBerry Backup использует службы теневого копирования томов (VSS) Microsoft, чтобы открывать файлы. В процессе резервного копирования на уровне блоков локальные блоки данных сравниваются с содержимым предыдущей копии в «облачном» репозитории, а затем в «облако» пересылаются только измененные блоки. Если резервное копирование выполняется в службу Amazon, то компонент, именуемый Synthetic Full Backup (SFB), может уменьшить количество передаваемых данных и сократить время полного резервного копирования. SFB копирует суще­ствующие блоки внутри «облака», что происходит очень быстро. Вы можете использовать CloudBerry для восстановления непосред­ственно на компьютер без опе­рационной системы (тот же или другой) из «облака» с помощью локального USB-устройства флэш-памяти. Резервные копии образа тоже можно восстанавливать в «облаке» как виртуальные машины.

Безопасность — чрезвычайно важное условие «облачного» резервного копирования, так как доступ к вашей резервной копии может означать потенциальный доступ ко всем конфиденциальным данным вашей компании. CloudBerry обеспечивает шифрование резервных копий с использованием 256-разрядных ключей AES на стороне источника, и при желании вы можете защитить резервные копии CloudBerry основным паролем. Все данные, отправляемые в «облако», могут быть зашифрованы с помощью SSL.

Технические требования

CloudBerry Backup Ultimate работает с большинством распространенных версий Windows Server и настольных операционных систем произ­водства Microsoft. Поддерживаемые операционные системы:

• Windows Server 2003, 2008

и 2008 R2, 2012 и 2012 R2, 2016;

• Windows 7, 8, 10.

Кроме того, CloudBerry поддержива­ет два самых популярных приложе­ния Microsoft Server: Exchange и SQL Server. Программа может архиви­ровать и восстанавливать серверы Exchange в «облаке». Поддержка Exchange 2010 и более новых версий также охватывает восстановление на уровне элемента. CloudBerry рас­полагает функциями «облачного» резервного копирования и вос­становления для баз данных SQL Server, позволяя выполнять полное, разностное резервное копирование и резервное копирование журнала транзакций.

Поддерживаемые версии Microsoft Exchange и SQL Server:

• Microsoft Exchange 2007, 2010, 2013, 2016;
• Microsoft SQL Server 2000, 2003, 2005, 2008, 2012, 2014, 2016 (в том числе Express).

Существует обширный список из более чем 30 служб «облачного» хранения, поддерживаемых функ­циями резервного копирования CloudBerry. К числу рекомендуе­мых поставщиков «облачных» услуг можно отнести следующие:

• Amazon S3 and Glacier;
• Microsoft Azure;
• Google Cloud Storage;
• Backbiaze B2;
• S3 Compatible;
• OpenStack;
• Google Drive;
• Wasabi;
• RackSpace;
• SoftLayer.

Продолжение обзора с следующей статье…