Сегодня любая средняя и крупная организация в своей работе опирается на ряд инфраструктурных ИТ-продуктов и набор бизнес-приложений. Безупречная работа инфраструктуры и бизнес приложений является принципиально важным условием для успешного функционирования организации. Соответственно, главной задачей ИТ-служб является обеспечение бесперебойного, безопасного и производительного доступа в режиме реального времени к данной корпоративной платформе.
Решение, при этом, должно отвечать ряду высоких требований: обеспечивать непрерывность бизнес-процессов компании, соответствовать строгим нормам безопасности, поддерживать высокую производительность ИТ-инфраструктуры и быть легко масштабируемым, чтобы в дальнейшем обеспечить необходимое расширение в соответствии с ростом организации.
За последние несколько лет эта самая корпоративная платформа из емких и тяжеловесных приложений, работающих исключительно на определенных типах и даже версиях операционных систем, трансформировалась в легкие, масштабируемые и кроссплатформенные web-приложения. Я не говорю только о больших веб проектах, форумах и других высокопосещаемых ресурсах. Современный бизнес переводит CRM, ERP и другие SAP и 1C подобные платформы на web. Причины, я надеюсь, всем понятны. Но остался один небольшой краеугольный камень, который современный бизнес, зачастую, игнорирует, а он, в свою очередь, напоминает о себе, когда происходит в лучшем случае остановка работы всего предприятия, в худшем — утечка или потеря конфиденциальной информации.
Так и в моем случае заказчик разбудил меня в час ночи с просьбой решить проблему, так как их платформа подверглась DDoS атаке, парализовав работу как всего предприятия, так и работу клиентов. Толковых инструкций и описаний как работает Netscaler нет, что послужило главным подспорьем написать статью.
Первое что пришлось сделать с web платформой заказчика — закрыть внешний сетевой интерфейс. Чтобы как-то снизить нагрузку, пришлось прописать пул IP адресов для доступа и тестирования снаружи. Затем был настроен веб сервер для ограничения количества одновременных сессий и запросов. Далее через GeoIP стали постепенно открываться страны. Затем пришлось перекомпилировать web сервер, чтобы добавить некоторый функционал для отражения атак. После был настроен failtoban, написаны десятки строк скриптов для cron. Времени заняло часов 16-20, но удручало то, что многие «заплатки» друг с другом конфликтовали и были «разбросаны» по всей системе. А атака, тем не менее, продолжалась: система то и дело отвечала ошибкой 503. Превентивных мер никто никогда не делал, соответственно отреагировать моментально не было никакой возможности. Это было проделано в качестве временной меры, чтобы с чувством и толком настроить все в одном месте — в Citrix Netscaler.
Netscaler — это многофункциональная платформа, позволяющая решить большую часть сетевых проблем или узких мест. Сей продукт можно сравнить с конструктором Lego, из различных деталей которого можно настроить универсального трансформера — он будет компактный и в то же время обладать всеми необходимыми инструментами для работы с траффиком. Netscaler может быть использован как в виде виртуального устройства VPX на всех современных гипервизорах, так и в виде физического устройства.
Прежде всего нам будет необходимо зарегистрироваться на сайте citrix.com. Если ваша компания уже использует Citrix, то скачать продукт можно под существующей учетной записью. Если нет, то выбираете Create Customer Account, заполняете обязательные поля, выбираете имя пользователя и пароль и вы уже залогинены под своей учетной записью, даже электронный адрес не надо подтверждать.
1. Заходим в раздел Downloads.
2. Выбираем NetScaler ADC, далее Evaluations and Trial Software из выпадающего меню, и жмем кнопку Find.
3. Разворачиваете секцию с тем релизом, где есть View All NetScaler Customer Trials.
4. Выбираете Try it FREE.
5. Заполняете форму и жмете Proceed to download.
6. На странице скачивания будут доступны образы под разные гипервизоры: выбираете тот, который подходит именно вам.
7. Устанавливаем Netscaler в нашем гипервизоре.
8. При первом запуске в консоли будет визард настроек. Нам необходимо указать некоторые данные. Netscaler не приемлет DHCP и логически имеет один интерфейс, не смотря что у него может быть несколько физических или виртуальных. Необходимо указать локальный IP адрес, который доступен в DMZ зоне. Я взял 172.16.0.100
9. Открываем в браузере страницу http://172.16.0.100 и входим в систему с логином/паролем nsroot/nsroot
10. Нас попросят указать временную зону, DNS и еще какой-то IP адрес. 172.16.0.100 — это адрес самого Netscaler. Subnet IP — адрес, который будет использоваться для работы с другими серверами и сервисами. То есть мухи отдельно — котлеты тоже: управляющий IP один, для работы с сервисами — другой. Вдруг у вас две DMZ зоны или vlan сети или сети с разными масками. Так как в моем случае сеть одна, я указал 172.16.0.101.
11. После пару кликов Next, вы попадете на вкладку Configuration.
1. Теперь необходимо скачать файл лицензии. Идем на страницу My Account, выбираем Activate and Allocate Licenses, кликаем в углу на ссылку Don't see your product? и вводим код лицензии, что мы получили на почту. Нажимаем два раза Continue и теперь видим с списках наш продукт. С этого момента начался отсчет действия лицензии.
2. Копируем в буфер Host Id (это MAC адрес нашего Netscaler) со страницы Configuration web-интерфейса Netscaler, и возвращаемся на сайт, где надо лицензию скачать.
3. Вставляем MAC адрес в поле Host ID, жмем Continue, потом Confirm, далее Ok и начнется загрузка файла с расширением LIC.
4. Готово, это и есть наша лицензия сроком на 90 дней.
5. Обновляем страницу интерфейса Netscaler (далее NS), авторизовываемся, нас опять попросят указать лицензию. Выбираем файл, загружаем и после успешной загрузки необходимо будет систему перегрузить, о чем будет информировать окно.
6. После перезагрузки во вкладке лицензирования будет список чего нам доступно в течении 90 дней.
1. Надо сразу уточнить, что для бесплатной пробы всегда доступна предыдущая версия. К сожалению, для полноценного управления и настройки через GUI необходима Java версии 7/45 x86. В новой версии NS можно работать с последней любой версией JRE. Если не хотите делать даунгрейд, то можно использовать командную строку. Все нужные команды будут в конце раздела. Для этого необходимо открыть терминальную SSH сессию к IP нашего NS с логином/паролем nsroot/nsroot.
2. Начнем с того, что у вас есть веб сайт, который надо защитить. У него есть свое доменное имя и присвоен IP адрес. Его родной IP адрес останется, но нам нужно зарегистрировать в NS виртуальный сервер. Для этого понадобится свободный IP адрес, который будет называться VIP, и через него будет происходить обращение пользователей к вашему настоящему web серверу. Если web служба внешняя, то IP внешний, если внутренний — соответственно. Возьмем к примеру 172.16.0.102.
3. Заходим в Traffic Management, затем в Virtual Servers и нажимаем кнопку Add.
Придумываем название, выбираем протокол HTTP, указываем VIP (виртуальный IP) и порт, на котором будут этот виртуальный сервер работать, нажимаем Create и затем Close.
4. Заходим в Servers, кликаем Add и указываем данные нашего web сервера. По сути нам необходимо дать название и указать IP адрес или имя. Порт не нужен, так как на сервере могут быть и другие службы и на разных портах.
5. Теперь нам надо связать наш виртуальный сервер с реальным в виде некого сервиса. Заходим в Services, опять кликаем Add, даем название, выбираем протокол, сервис и порт на котором наш сервер принимает соединения.
6. Осталось созданный сервис добавить в наш виртуальный сервер. Заходим в Virtual Servers, кликаем Open, ставим галочку в колонке Active и подтверждаем OK. После этого ваш Виртуальный сервер станет UP & RUNNING.
7. После всех изменений необходимо нажать иконку в виде дискеты для сохранения текущей конфигурации.
8. Открываем в браузере страницу http://172.16.0.102 и вуаля, открывается наш сайт. С первого раза не совсем понятно как это работает, поэтому разберем то что мы сделали:
а) создали виртуальный сервер, который будет работать на виртуальном IP адресе по HTTP протоколу через 80-ый порт.
б) добавили данные о нашем реальном сервере
в) указали, что на нашем сервере есть сервис HTTP на 80-ом порту
г) предложили нашему виртуальному сервере обрабатывать данные по конкретному сервису
д) сохранили конфигурацию.
9. Через командную строку
Наш виртуальный сервер работает. Если реальный сервер выдает HTML контент с условными ссылкам, то получится даже посерфить, в противном случае придется изменять все полные ссылки на условные или же изменять DNS сервера, если ссылки указывают на доменное имя. Допустим, вы имеете сайт, где ссылки прописываются полные, например <a href='http://www.domain.com/page1'>ссылка</a>, то необходимо переделать в <a href='/page1'>ссылка</a>.
Если быстро переделать нет возможности, то в DNS переназначаете A запись на www и головной домен на IP адрес вашего виртуального сервера, то есть на 172.16.0.102.
Первое что мы можем организовать — это GZIP компрессию. При этом компрессию на реальном сервере можно отключить. Нет, NS не будет распаковывать и заново запаковывать траффик, но с целью разделения процессорных ресурсов пусть web сервер занимается чем ему положено — выдавать готовый контент, NS забирает с сервера как есть, а конечному пользователю выдает уже сжатый по тем правилам, которые мы ему укажем.
1. В меню System > Settings > Configure basic features ставим галочку на HTTP Compression.
2. В веб интерфейсе идем по Traffic Management > Load Balancing > Services, выбираем сервис, кликаем Open, переходим во вкладку Advanced и галочкой указываем, что мы хотим сжимать траффик. Также можете указать и другие параметры, допустим максимальное количество клиентов и запросов.
3. С этого момента трафик наш сжимается согласно стандартным настройкам NS. Но сжимается не все. Допустим, некоторые веб сервера в своих настройках MIME указывают application/x-javascript для расширения js вместо text/javascript, соответственно сжатия не происходит. Мы можем эту ситуацию исправить, добавив свой полис.
Переходим в меню Optimization > HTTP Compression > Policies, нажимаем Add, кликаем Switch to Classic Syntax и добавляем новое правило.
4. Правило создалось, но пока оно не активно и не работает. Правой кнопкой мышки кликаем на правило, выбираем Policy Manager, выбираем вкладку Response, затем Default Global, кликаем Insert Policy и выбираем наше правило, поставив самый высокий приоритет.
5. Такие правила можно установить также на pdf, json и другие типы. Также можно указать какой минимальный размер сжимать, с каких подсетей, для каких браузеров и т.д. и т.п. Правила можно делать не глобальными, а для конкретного сервиса.
6. Через командную строку:
«Ну и что?» скажете вы. И будете правы. Все что было описано выше умеет делать стандартный web сервер. Что же касается защиты данных от взлома — стандартный сервер обучить нет никакой возможности. Всегда приходится уповать на правильность исходного кода, который в большинстве случаев мы сами не писали. И никто и никогда не может дать гарантий, что ошибок или недочетов в исполняемом коде нет.
В свое время, разрабатывая крупный интернет проект в небольшой команде, я серьезно озадачился защитой от SQL инъекций и написал API для доступа к базе данных. Я был спокоен за проект, до тех пор, пока не стал проверять что делают программисты из моей команды. Вместо того, чтобы передавать значения по ссылкам, они «собирали» по привычке SQL запрос, конкатенируя запрос со строковыми и числовыми переменными, не заботясь не то чтобы об экранировании, а даже банальной проверке переменных на валидность их значений. Что уж говорить о сайтах некоторых online-банков, где я за 10-15 минут находил по несколько SQL уязвимостей. А помимо этого есть еще и cross-site scripting, подделка cookie, формирование вредоносных JSON и XML запросов и т.д.
К нашей радости Netscaler борется с этим довольно таки успешно.
1. В меню System > Settings > Configure basic features ставим галочку на Application Firewall.
2. В меню Security > Application Firewall запускаем Application Firewall Wizard
3. Выбираем имя нашей конфигурации и тип Web 2.0
4. В Specify rule оставляем все как есть и нажимаем Next
5. В следующем диалоге отмечаем то, на чем наш web сервер работает.
6. В Select signature action оставляем все как есть.
7. В Select deep protections ставим галочки на первые 4 опции. Стоит отметить, что HTML Cross-Site Scripting по умолчанию запрещает передавать в GET и POST запросах любые HTML теги. Это не страшно, так как для любого правила можно установить фильтры и условия.
8. В Select deep actions надо поставить галочку на те опции, которые вы хотите блокировать. На начальном этапе рекомендуется не блокировать, а походить по своему сайту, инсценировать все возможные поведения пользователей и уже когда соберется статистика принять решение что блокировать, а где создать дополнительные правила. Все кроме cross-site скриптинга можно заблокировать сразу.
9. После создания правила надо его открыть и сделать дополнительные настройки.
а) выставить кодировку
б) создать страницу куда будет перенаправляться пользователь, если была попытка взлома. Обычно это головная страница, но можно создать отдельную с информацией, что ваши действия показались подозрительными и будут отправлены администрации, а в случае необходимости компетентным органам.
в) очень много остальных тонких настроек, описание которых можно найти в документации.
10. Теперь идем на наш сайт, открываем страницы с фиктивной SQL инъекцией http://172.16.0.102/?Search=00&q=CB506-67902' UNION SELECT aaa FROM aaa и наблюдаем как нас перекидывает на главную страницу.
11. Ставим в браузер плагин, позволяющий править cookie, исправляем парочку и обновляем страницу. Cookie на вашей стороне не изменяется, но они не передадутся на web сервер. NS кеширует все cookie, которые оригинальный сервер передал для сохранения. Если в следующем REQ запросе NS обнаружит несоответствие ранее установленных cookie, он их просто заблокирует.
12. Если вы поставили галочку на Block в разделе Cross-Site Scripting, то попробуйте GET или POST запросом передать HTML и также будете перенаправлены на заглавную страницу.
13. Не правда ли здорово? Если покопаетесь в настройках, то найдете очень много интересного и полезного для себя. Cookie можно для пущей безопасности кодировать, что пользователь не сможет и просто так подделать, потому как NS прежде чем передать их веб серверу будет декодировать свои ключом. Можно на типы или названия полей указать формат данных в виде регулярных выражений для проверки или экранирования. На определенные страницы или поля можно сделать исключения для проверки на HTML или SQL. При грамотно настроенном NS безопасность вашего сайта увеличится в сотни раз.
14. Через командную строку
Наконец мы подошли к тому, ради чего это все затевалось. Чтобы не углубляться в то, как защита работает, можно почитать статью Модуль nginx для борьбы с DDoS. Принцип один в один, только у меня не получилось в реальной ситуации запустить этот модуль как надо.
1. Идем в меню Security > Protection Features > HTTP DoS и по привычке нажимаем Add.
2. Кроме имени есть два поля, куда надо вставить значения. Давайте разберемся как их посчитать.
Первое поле Queue depth — это количественное значение пользователей, которые ожидают своей очереди на ответ сервера.
Предположим, у вас 86400 уникальных пользователей в сутки или 3500 в час или 60 в минуту или 1 каждую секунду.
Разумеется, ночью их нет, днем их очень много. Умножаем в 10 раз для пущей важности и получаем 10 пользователей в секунду. А вообще можно посмотреть статистику.
Допустим один пользователь, в среднем запрашивает 5-10 запросов за страницу (html, css, js, img и т.д.) и просматривает их по 5-10 секунд (вот почему AJAX рулит).
То есть сервер ориентировочно в пик своей нагрузки отрабатывает до 100 ответов в секунду.
Представим, что ваш web сервер способен отправить максимально 500 ответов в секунду, но получает 10,000 запросов в секунду, или в 20 раз больше.
Сколько реальных пользователей в данный момент испытывают проблему? Правильно, те же 10, остальные — это атака. Когда стоит начать паниковать? Сразу после 10? Хотелось бы, но минимальное значение 21, поэтому оставим его как есть. То есть как только в очереди на получение данных окажутся 21 или более сессий, включится автоматическая защита от атаки.
Теперь со вторым полем Client detect rate. Это процентное значение пользователей, которые будут проверяться на вшивость. Если мы поставим 1% на проверку, с автоматически включенной защитой, количество ответов от сервера будет только 5 (500 *0.01), в то время как 10000 будут ожидать своей очереди. Иными словами только 0.05% настоящих пользователей пройдут проверку. Тем не менее, если уровень проверки высокий (к примеру при 10% значение будет проверяться 1000 запросов), то это может забить весь исходящий траффик проверками и так уже перегруженный атакой, если ваш канал узкий. Но я бы поставил 30-35% чтобы сразу начать отбиться от атаки, так как канал очень толстый. Поле можно оставить пустым и в зависимости от ширины канала, который NS умеет измерять, количества запросов, ответов и других показателей, сам может варьировать уровень проверки.
3. Далее идем по меню Traffic Management > Load Balancing > Services, открываем наш сервис черер кнопку Open и во вкладке Policies/HTTP DoS вставляем только что созданный полис.
4. Через командную строку
Умеет эта штука очень много. Из того, что может понадобится для сайтов — это:
1. Разделение статического и динамического контента для снятия нагрузки.
2. Проксирование статического контента.
3. Кэширование динамического контента и сброс кэша по определенным условиями или времени.
4. Проксирование и кэширование mySQL и других реляционных баз данных в целях сокращения количества выборок.
5. Разделение трафика и контента по сетевым адресам, гео расположению и многим другим параметрам.
6. Шифрование траффика.
7. Работа в качестве DNS сервера.
8. По умолчанию NS уже имеет сетевую защиту, например от ICMP флуда и др.
Настраивается все довольно легко, хотя не всегда интуитивно. Инструкция доступна на сайте вендора. Почитать на русском об основных возможностях можно на сайте http://netscaler.kz.
Отсутствие информации на русском языке о данной платформе сильно сказывается на его распространенности в странах СНГ. Видимо поэтому наши современные сетевые администраторы недооценили возможности данного продукта.
Ведь не зря же два года назад компания Cisco официально объявила, что она прекращает дальнейшую разработку своего балансировщика ACE, и с недавних пор Netscaler является частью некоторых серий коммутаторов Cisco.
Спасибо!
Решение, при этом, должно отвечать ряду высоких требований: обеспечивать непрерывность бизнес-процессов компании, соответствовать строгим нормам безопасности, поддерживать высокую производительность ИТ-инфраструктуры и быть легко масштабируемым, чтобы в дальнейшем обеспечить необходимое расширение в соответствии с ростом организации.
За последние несколько лет эта самая корпоративная платформа из емких и тяжеловесных приложений, работающих исключительно на определенных типах и даже версиях операционных систем, трансформировалась в легкие, масштабируемые и кроссплатформенные web-приложения. Я не говорю только о больших веб проектах, форумах и других высокопосещаемых ресурсах. Современный бизнес переводит CRM, ERP и другие SAP и 1C подобные платформы на web. Причины, я надеюсь, всем понятны. Но остался один небольшой краеугольный камень, который современный бизнес, зачастую, игнорирует, а он, в свою очередь, напоминает о себе, когда происходит в лучшем случае остановка работы всего предприятия, в худшем — утечка или потеря конфиденциальной информации.
Так и в моем случае заказчик разбудил меня в час ночи с просьбой решить проблему, так как их платформа подверглась DDoS атаке, парализовав работу как всего предприятия, так и работу клиентов. Толковых инструкций и описаний как работает Netscaler нет, что послужило главным подспорьем написать статью.
Как все начиналось
Первое что пришлось сделать с web платформой заказчика — закрыть внешний сетевой интерфейс. Чтобы как-то снизить нагрузку, пришлось прописать пул IP адресов для доступа и тестирования снаружи. Затем был настроен веб сервер для ограничения количества одновременных сессий и запросов. Далее через GeoIP стали постепенно открываться страны. Затем пришлось перекомпилировать web сервер, чтобы добавить некоторый функционал для отражения атак. После был настроен failtoban, написаны десятки строк скриптов для cron. Времени заняло часов 16-20, но удручало то, что многие «заплатки» друг с другом конфликтовали и были «разбросаны» по всей системе. А атака, тем не менее, продолжалась: система то и дело отвечала ошибкой 503. Превентивных мер никто никогда не делал, соответственно отреагировать моментально не было никакой возможности. Это было проделано в качестве временной меры, чтобы с чувством и толком настроить все в одном месте — в Citrix Netscaler.
Netscaler — это многофункциональная платформа, позволяющая решить большую часть сетевых проблем или узких мест. Сей продукт можно сравнить с конструктором Lego, из различных деталей которого можно настроить универсального трансформера — он будет компактный и в то же время обладать всеми необходимыми инструментами для работы с траффиком. Netscaler может быть использован как в виде виртуального устройства VPX на всех современных гипервизорах, так и в виде физического устройства.
Установка и настройка виртуальных машин
Прежде всего нам будет необходимо зарегистрироваться на сайте citrix.com. Если ваша компания уже использует Citrix, то скачать продукт можно под существующей учетной записью. Если нет, то выбираете Create Customer Account, заполняете обязательные поля, выбираете имя пользователя и пароль и вы уже залогинены под своей учетной записью, даже электронный адрес не надо подтверждать.
Загрузка, установка и настройка Netscaler
1. Заходим в раздел Downloads.
2. Выбираем NetScaler ADC, далее Evaluations and Trial Software из выпадающего меню, и жмем кнопку Find.
3. Разворачиваете секцию с тем релизом, где есть View All NetScaler Customer Trials.
4. Выбираете Try it FREE.
5. Заполняете форму и жмете Proceed to download.
6. На странице скачивания будут доступны образы под разные гипервизоры: выбираете тот, который подходит именно вам.
7. Устанавливаем Netscaler в нашем гипервизоре.
8. При первом запуске в консоли будет визард настроек. Нам необходимо указать некоторые данные. Netscaler не приемлет DHCP и логически имеет один интерфейс, не смотря что у него может быть несколько физических или виртуальных. Необходимо указать локальный IP адрес, который доступен в DMZ зоне. Я взял 172.16.0.100
9. Открываем в браузере страницу http://172.16.0.100 и входим в систему с логином/паролем nsroot/nsroot
10. Нас попросят указать временную зону, DNS и еще какой-то IP адрес. 172.16.0.100 — это адрес самого Netscaler. Subnet IP — адрес, который будет использоваться для работы с другими серверами и сервисами. То есть мухи отдельно — котлеты тоже: управляющий IP один, для работы с сервисами — другой. Вдруг у вас две DMZ зоны или vlan сети или сети с разными масками. Так как в моем случае сеть одна, я указал 172.16.0.101.
11. После пару кликов Next, вы попадете на вкладку Configuration.
Регистрация и лицензирование
1. Теперь необходимо скачать файл лицензии. Идем на страницу My Account, выбираем Activate and Allocate Licenses, кликаем в углу на ссылку Don't see your product? и вводим код лицензии, что мы получили на почту. Нажимаем два раза Continue и теперь видим с списках наш продукт. С этого момента начался отсчет действия лицензии.
2. Копируем в буфер Host Id (это MAC адрес нашего Netscaler) со страницы Configuration web-интерфейса Netscaler, и возвращаемся на сайт, где надо лицензию скачать.
3. Вставляем MAC адрес в поле Host ID, жмем Continue, потом Confirm, далее Ok и начнется загрузка файла с расширением LIC.
4. Готово, это и есть наша лицензия сроком на 90 дней.
5. Обновляем страницу интерфейса Netscaler (далее NS), авторизовываемся, нас опять попросят указать лицензию. Выбираем файл, загружаем и после успешной загрузки необходимо будет систему перегрузить, о чем будет информировать окно.
6. После перезагрузки во вкладке лицензирования будет список чего нам доступно в течении 90 дней.
Настройка серверов, сервисов, политик, полисов и правил
1. Надо сразу уточнить, что для бесплатной пробы всегда доступна предыдущая версия. К сожалению, для полноценного управления и настройки через GUI необходима Java версии 7/45 x86. В новой версии NS можно работать с последней любой версией JRE. Если не хотите делать даунгрейд, то можно использовать командную строку. Все нужные команды будут в конце раздела. Для этого необходимо открыть терминальную SSH сессию к IP нашего NS с логином/паролем nsroot/nsroot.
2. Начнем с того, что у вас есть веб сайт, который надо защитить. У него есть свое доменное имя и присвоен IP адрес. Его родной IP адрес останется, но нам нужно зарегистрировать в NS виртуальный сервер. Для этого понадобится свободный IP адрес, который будет называться VIP, и через него будет происходить обращение пользователей к вашему настоящему web серверу. Если web служба внешняя, то IP внешний, если внутренний — соответственно. Возьмем к примеру 172.16.0.102.
3. Заходим в Traffic Management, затем в Virtual Servers и нажимаем кнопку Add.
Придумываем название, выбираем протокол HTTP, указываем VIP (виртуальный IP) и порт, на котором будут этот виртуальный сервер работать, нажимаем Create и затем Close.
4. Заходим в Servers, кликаем Add и указываем данные нашего web сервера. По сути нам необходимо дать название и указать IP адрес или имя. Порт не нужен, так как на сервере могут быть и другие службы и на разных портах.
5. Теперь нам надо связать наш виртуальный сервер с реальным в виде некого сервиса. Заходим в Services, опять кликаем Add, даем название, выбираем протокол, сервис и порт на котором наш сервер принимает соединения.
6. Осталось созданный сервис добавить в наш виртуальный сервер. Заходим в Virtual Servers, кликаем Open, ставим галочку в колонке Active и подтверждаем OK. После этого ваш Виртуальный сервер станет UP & RUNNING.
7. После всех изменений необходимо нажать иконку в виде дискеты для сохранения текущей конфигурации.
8. Открываем в браузере страницу http://172.16.0.102 и вуаля, открывается наш сайт. С первого раза не совсем понятно как это работает, поэтому разберем то что мы сделали:
а) создали виртуальный сервер, который будет работать на виртуальном IP адресе по HTTP протоколу через 80-ый порт.
б) добавили данные о нашем реальном сервере
в) указали, что на нашем сервере есть сервис HTTP на 80-ом порту
г) предложили нашему виртуальному сервере обрабатывать данные по конкретному сервису
д) сохранили конфигурацию.
9. Через командную строку
add lb vserver CRM-virtual-server HTTP 172.16.0.102 80
add server CRM-server 172.16.0.10
add service CRM-service CRM-server HTTP 80
bind lb vserver CRM-virtual-server CRM-service
save config
Компрессия и сжатие траффика
Наш виртуальный сервер работает. Если реальный сервер выдает HTML контент с условными ссылкам, то получится даже посерфить, в противном случае придется изменять все полные ссылки на условные или же изменять DNS сервера, если ссылки указывают на доменное имя. Допустим, вы имеете сайт, где ссылки прописываются полные, например <a href='http://www.domain.com/page1'>ссылка</a>, то необходимо переделать в <a href='/page1'>ссылка</a>.
Если быстро переделать нет возможности, то в DNS переназначаете A запись на www и головной домен на IP адрес вашего виртуального сервера, то есть на 172.16.0.102.
Первое что мы можем организовать — это GZIP компрессию. При этом компрессию на реальном сервере можно отключить. Нет, NS не будет распаковывать и заново запаковывать траффик, но с целью разделения процессорных ресурсов пусть web сервер занимается чем ему положено — выдавать готовый контент, NS забирает с сервера как есть, а конечному пользователю выдает уже сжатый по тем правилам, которые мы ему укажем.
1. В меню System > Settings > Configure basic features ставим галочку на HTTP Compression.
2. В веб интерфейсе идем по Traffic Management > Load Balancing > Services, выбираем сервис, кликаем Open, переходим во вкладку Advanced и галочкой указываем, что мы хотим сжимать траффик. Также можете указать и другие параметры, допустим максимальное количество клиентов и запросов.
3. С этого момента трафик наш сжимается согласно стандартным настройкам NS. Но сжимается не все. Допустим, некоторые веб сервера в своих настройках MIME указывают application/x-javascript для расширения js вместо text/javascript, соответственно сжатия не происходит. Мы можем эту ситуацию исправить, добавив свой полис.
Переходим в меню Optimization > HTTP Compression > Policies, нажимаем Add, кликаем Switch to Classic Syntax и добавляем новое правило.
4. Правило создалось, но пока оно не активно и не работает. Правой кнопкой мышки кликаем на правило, выбираем Policy Manager, выбираем вкладку Response, затем Default Global, кликаем Insert Policy и выбираем наше правило, поставив самый высокий приоритет.
5. Такие правила можно установить также на pdf, json и другие типы. Также можно указать какой минимальный размер сжимать, с каких подсетей, для каких браузеров и т.д. и т.п. Правила можно делать не глобальными, а для конкретного сервиса.
6. Через командную строку:
enable ns feature cmp
set service CRM-service -CMP yes
add cmp policy ns_cmp_javascript -rule "RES.HTTP.HEADER Content-Type CONTAINS javascript" -resAction COMPRESS
add cmp policy ns_cmp_json -rule "RES.HTTP.HEADER Content-Type CONTAINS json" -resAction COMPRESS
add cmp policy ns_cmp_pdf -rule "RES.HTTP.HEADER Content-Type CONTAINS application/pdf" -resAction COMPRESS
bind cmp global ns_cmp_javascript -priority 10001 -state ENABLED
bind cmp global ns_cmp_json -priority 10002 -state ENABLED
bind cmp global ns_cmp_pdf -priority 10003 -state ENABLED
save config
Защита данных
«Ну и что?» скажете вы. И будете правы. Все что было описано выше умеет делать стандартный web сервер. Что же касается защиты данных от взлома — стандартный сервер обучить нет никакой возможности. Всегда приходится уповать на правильность исходного кода, который в большинстве случаев мы сами не писали. И никто и никогда не может дать гарантий, что ошибок или недочетов в исполняемом коде нет.
В свое время, разрабатывая крупный интернет проект в небольшой команде, я серьезно озадачился защитой от SQL инъекций и написал API для доступа к базе данных. Я был спокоен за проект, до тех пор, пока не стал проверять что делают программисты из моей команды. Вместо того, чтобы передавать значения по ссылкам, они «собирали» по привычке SQL запрос, конкатенируя запрос со строковыми и числовыми переменными, не заботясь не то чтобы об экранировании, а даже банальной проверке переменных на валидность их значений. Что уж говорить о сайтах некоторых online-банков, где я за 10-15 минут находил по несколько SQL уязвимостей. А помимо этого есть еще и cross-site scripting, подделка cookie, формирование вредоносных JSON и XML запросов и т.д.
К нашей радости Netscaler борется с этим довольно таки успешно.
1. В меню System > Settings > Configure basic features ставим галочку на Application Firewall.
2. В меню Security > Application Firewall запускаем Application Firewall Wizard
3. Выбираем имя нашей конфигурации и тип Web 2.0
4. В Specify rule оставляем все как есть и нажимаем Next
5. В следующем диалоге отмечаем то, на чем наш web сервер работает.
6. В Select signature action оставляем все как есть.
7. В Select deep protections ставим галочки на первые 4 опции. Стоит отметить, что HTML Cross-Site Scripting по умолчанию запрещает передавать в GET и POST запросах любые HTML теги. Это не страшно, так как для любого правила можно установить фильтры и условия.
8. В Select deep actions надо поставить галочку на те опции, которые вы хотите блокировать. На начальном этапе рекомендуется не блокировать, а походить по своему сайту, инсценировать все возможные поведения пользователей и уже когда соберется статистика принять решение что блокировать, а где создать дополнительные правила. Все кроме cross-site скриптинга можно заблокировать сразу.
9. После создания правила надо его открыть и сделать дополнительные настройки.
а) выставить кодировку
б) создать страницу куда будет перенаправляться пользователь, если была попытка взлома. Обычно это головная страница, но можно создать отдельную с информацией, что ваши действия показались подозрительными и будут отправлены администрации, а в случае необходимости компетентным органам.
в) очень много остальных тонких настроек, описание которых можно найти в документации.
10. Теперь идем на наш сайт, открываем страницы с фиктивной SQL инъекцией http://172.16.0.102/?Search=00&q=CB506-67902' UNION SELECT aaa FROM aaa и наблюдаем как нас перекидывает на главную страницу.
11. Ставим в браузер плагин, позволяющий править cookie, исправляем парочку и обновляем страницу. Cookie на вашей стороне не изменяется, но они не передадутся на web сервер. NS кеширует все cookie, которые оригинальный сервер передал для сохранения. Если в следующем REQ запросе NS обнаружит несоответствие ранее установленных cookie, он их просто заблокирует.
12. Если вы поставили галочку на Block в разделе Cross-Site Scripting, то попробуйте GET или POST запросом передать HTML и также будете перенаправлены на заглавную страницу.
13. Не правда ли здорово? Если покопаетесь в настройках, то найдете очень много интересного и полезного для себя. Cookie можно для пущей безопасности кодировать, что пользователь не сможет и просто так подделать, потому как NS прежде чем передать их веб серверу будет декодировать свои ключом. Можно на типы или названия полей указать формат данных в виде регулярных выражений для проверки или экранирования. На определенные страницы или поля можно сделать исключения для проверки на HTML или SQL. При грамотно настроенном NS безопасность вашего сайта увеличится в сотни раз.
14. Через командную строку
enable ns feature AppFW
add appfw profile crm-appfw-profile -type HTML XML
set appfw profile crm-appfw-profile -cookieConsistencyAction block log stats learn
set appfw profile crm-appfw-profile -bufferOverflowAction block log stats
set appfw profile crm-appfw-profile -crossSiteScriptingAction log stats learn
set appfw profile crm-appfw-profile -SQLInjectionAction block log stats learn
set appfw profile crm-appfw-profile -startURLAction log stats learn
set appfw profile crm-appfw-profile -defaultCharSet utf-8
add appfw policy crm-appfw-policy true crm-appfw-profile
bind appfw global crm-appfw-policy 10
save config
Отражение DDoD атак
Наконец мы подошли к тому, ради чего это все затевалось. Чтобы не углубляться в то, как защита работает, можно почитать статью Модуль nginx для борьбы с DDoS. Принцип один в один, только у меня не получилось в реальной ситуации запустить этот модуль как надо.
1. Идем в меню Security > Protection Features > HTTP DoS и по привычке нажимаем Add.
2. Кроме имени есть два поля, куда надо вставить значения. Давайте разберемся как их посчитать.
Первое поле Queue depth — это количественное значение пользователей, которые ожидают своей очереди на ответ сервера.
Предположим, у вас 86400 уникальных пользователей в сутки или 3500 в час или 60 в минуту или 1 каждую секунду.
Разумеется, ночью их нет, днем их очень много. Умножаем в 10 раз для пущей важности и получаем 10 пользователей в секунду. А вообще можно посмотреть статистику.
Допустим один пользователь, в среднем запрашивает 5-10 запросов за страницу (html, css, js, img и т.д.) и просматривает их по 5-10 секунд (вот почему AJAX рулит).
То есть сервер ориентировочно в пик своей нагрузки отрабатывает до 100 ответов в секунду.
Представим, что ваш web сервер способен отправить максимально 500 ответов в секунду, но получает 10,000 запросов в секунду, или в 20 раз больше.
Сколько реальных пользователей в данный момент испытывают проблему? Правильно, те же 10, остальные — это атака. Когда стоит начать паниковать? Сразу после 10? Хотелось бы, но минимальное значение 21, поэтому оставим его как есть. То есть как только в очереди на получение данных окажутся 21 или более сессий, включится автоматическая защита от атаки.
Теперь со вторым полем Client detect rate. Это процентное значение пользователей, которые будут проверяться на вшивость. Если мы поставим 1% на проверку, с автоматически включенной защитой, количество ответов от сервера будет только 5 (500 *0.01), в то время как 10000 будут ожидать своей очереди. Иными словами только 0.05% настоящих пользователей пройдут проверку. Тем не менее, если уровень проверки высокий (к примеру при 10% значение будет проверяться 1000 запросов), то это может забить весь исходящий траффик проверками и так уже перегруженный атакой, если ваш канал узкий. Но я бы поставил 30-35% чтобы сразу начать отбиться от атаки, так как канал очень толстый. Поле можно оставить пустым и в зависимости от ширины канала, который NS умеет измерять, количества запросов, ответов и других показателей, сам может варьировать уровень проверки.
3. Далее идем по меню Traffic Management > Load Balancing > Services, открываем наш сервис черер кнопку Open и во вкладке Policies/HTTP DoS вставляем только что созданный полис.
4. Через командную строку
enable ns feature HttpDoSProtection
add dos policy crm-ddos-policy -qDepth 21 -cltDetectRate 33
bind service CRM-service -policyName crm-ddos-policy
save config
А что еще умеет Netscaler
Умеет эта штука очень много. Из того, что может понадобится для сайтов — это:
1. Разделение статического и динамического контента для снятия нагрузки.
2. Проксирование статического контента.
3. Кэширование динамического контента и сброс кэша по определенным условиями или времени.
4. Проксирование и кэширование mySQL и других реляционных баз данных в целях сокращения количества выборок.
5. Разделение трафика и контента по сетевым адресам, гео расположению и многим другим параметрам.
6. Шифрование траффика.
7. Работа в качестве DNS сервера.
8. По умолчанию NS уже имеет сетевую защиту, например от ICMP флуда и др.
Заключение
Настраивается все довольно легко, хотя не всегда интуитивно. Инструкция доступна на сайте вендора. Почитать на русском об основных возможностях можно на сайте http://netscaler.kz.
Отсутствие информации на русском языке о данной платформе сильно сказывается на его распространенности в странах СНГ. Видимо поэтому наши современные сетевые администраторы недооценили возможности данного продукта.
Ведь не зря же два года назад компания Cisco официально объявила, что она прекращает дальнейшую разработку своего балансировщика ACE, и с недавних пор Netscaler является частью некоторых серий коммутаторов Cisco.
Спасибо!
