Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 881 сообщений
Cообщения с меткой

администрирование - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Конструктивная админская лень или как я конфиг автоматизировал

Воскресенье, 12 Июня 2016 г. 22:34 (ссылка)

Здравствуйте!

Окрылён Вашим вниманием к первой моей статье: Исследование коммутатора Dlink после грозы, подумал написать цикл статей под общим названием (см. заголовок), если Вам дорогие коллеги, это интересно буду крайне признателен за комментарии.



Входные данные:

Имеются несколько мультисервисных сетей передачи данных размером в 1 город каждая (далее буду рассматривать один город и возможность масштабирования решения на все существующие и перспективу появления новых). итак структура примерно такая: MC-IC-mIC-HC, где

MC — узел города(магистральная подсистема города);

IC — узел агрегации (магистральная подсистема комплекса зданий);

mIC — ведомый узел агрегации;

HC — горизонтальная подсистема, узел доступа;



Задачи требующие решения:

Создание единой системы маркировки;

Генерация конфигурации на основе единого регламента конфигурация оборудования и данных об узле куда предполагается установка конфигурируемого оборудования;

Мониторинг пула IP адресов с целью выявления оборудования с нарушением регламента конфигурации, оповещение локального админа(системный администратор города в котором обнаружено оборудование с не регламентированными настройками).



Инструментарий:

ФИАС;

PostgreSQL;

Python;



В виду объемности работы хотелось бы узнать нужно ли Вам об этом рассказать.

В случае Вашего интереса буду выкладывать одну статью каждую пятницу. Первая статья цикла «ФИАС для администратора сети» почти готова.



Жду ваших комментариев.




Интересен ли Вам цикл статей на означенную тему?




























Проголосовало 7 человек. Воздержалось 6 человек.





Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.


Original source: habrahabr.ru.

https://habrahabr.ru/post/303128/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
itast

Качественный хостинг по доступным ценам

Понедельник, 30 Мая 2016 г. 17:01 (ссылка)

Компания ProHoster предоставляет качественный хостинг по самым низким ценам. Перечень услуг охватывает все сферы: безлимитный хостинг сайтов, бесплатный конструктор сайтов, игровой хостинг, vds windows, безабузные сервера, администрирование и все сопутствующие услуги. Современный хостинг - это услуга по предоставлению места для физического размещения информации на сервере. Сервер должен быть постоянно подключен к интернету. А так же это фактическое размещение оборудования заказчика на территории провайдера с беспрерывным доступом к интернету.
Все перечисленные услуги предоставляются квалифицированными специалистами с использованием современного оборудования. Безлимитный хостинг предоставляется по принципу "все включено". Хостинг оптимизирован под максимальную скорость, а значит все операции будут выполняться мгновенно. Есть услуга абузоустойчивые VPS - это те которые игнорируют жалобы на их содержимое. Если вы выбираете компанию ProHoster, то перенос вашего сервера с другого ресурса бесплатно. В подарок вы получаете один месяц услуг согласно выбранному тарифу бесплатно. Выбирайте профессионалов - это ваш первый шаг к успеху!


Метки:   Комментарии (2)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Атоматизация администрирования систем, обзор проблем и вариант решения. Из книги «PowerShell and WMI»

Суббота, 28 Мая 2016 г. 08:58 (ссылка)


Ниже перевод части главы 1 книги Powershell and WMI. Освещается направление развития информационных систем применительно к системному администрированию. Дается взгляд Ed Wilson на проблемы эксплуатационщиков, указывается направление снижения расходов на обслуживание инфраструктуры.



Solving administrative challenges

Спросите любого администратора Windows о его самых больших проблемах, и где-то в верхней части списка будет слишком много работы и нехватка времени чтобы сделать это. Они знают о средствах автоматизации, возможно даже осведомлены о возможностях WMI и Powershell, но не имеют времени чтобы освоить эти технологии. Это позорная ситуация, потому что принято считать, что 70% бюджета ИТ организации расходуется на то «чтобы все было в рабочем состоянии» (прим переводчика: в оригинале “keep the lights on.”). Автоматизация может значительно сократить эти 70%, за счет чего освободятся время и деньги для задач ниже по списку «проблем».



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



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

PowerShell является движком автоматизации от Microsoft, которая, помимо всего прочего, обеспечивает облегченный доступ к богатым наборам инструментов управления, доступных в WMI.

Читать дальше →

https://habrahabr.ru/post/301242/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Семантический разрыв «The Semantic Gap»

Четверг, 26 Мая 2016 г. 13:24 (ссылка)


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



Семантический разрыв



Есть 2 мира:

1. Мир, как мы его представляем.

2. Мир, как мы можем им управлять.



Разница между этими двумя мирами это то что называется семантическим разрывом.



Наша индустрия (прим переводчика: IT индустрия) борется с семантическим разрывом в течение многих десятилетий. Отличным примером семантического разрыва это запись в блоге «TechProsaic: VMWare Perl Toolkit versus Powershell V1 ToolKit», в котором показаны 20 строк кода на Perl необходимых чтобы сделать то же самое что делает один командлет «Get-VM».

Кто-то мог прочитать это бросить читать дальше со словами «PowerShell мощный, а Perl это дерьмо», он был бы прав и не прав. PowerShell мощный, но Perl не дерьмо. (снимите шляпу перед суперзвездой Larry Wall и его Perl, очень мало людей и технологий, которые имели уровень (положительного :-) ) воздействия на нашу отрасль как они. Этот мир хорошее место потому что рождаются такие хорошие парни как он!). Настоящей разницей между этими двумя примерами является семантический разрыв. Пример на PowerShell имеет очень небольшой разрыв между тем, что вы думаете и что вы печатаете чтобы решить задачу. Пример на Perl имеет очень большой разрыв.



В конце концов, семантический разрыв «контролируется» людьми, которые разрабатывают инструментарий. VMWare мог бы так же легко предоставить PowerShell скрипт, который имел бы столько строк как например на Perl или они могли бы прислать библиотеку для Perl или сценарий на нем, который обеспечивает семантику командлета Get-VM одной или парой команд.



Так почему же поставщики инструментария закрыли или не закрыли семантический разрыв? Ааа – это и есть тот самый вопрос!

Читать дальше →

https://habrahabr.ru/post/301834/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Еще раз о том, как не сделать из своей сети «решето»

Пятница, 13 Мая 2016 г. 10:38 (ссылка)

Здравствуйте! Я почти 10 лет работаю в сфере ИТ и ИБ, всегда интересовался практической безопасностью, в настоящее время работаю пентестером. За все время работы я постоянно сталкивался с типовыми ошибками в настройках и дизайне инфраструктуры. Ошибки эти чаще всего досадные, легко устранимые, однако быстро превращают сеть в полигон для взлома. Порой кажется, что где-то специально учат так настраивать, насколько часто они встречались. Это и побудило меня написать данную статью, собрав все самое основное, что может улучшить защищенность.



В этой статье я не буду рассказывать про использование сложных паролей, максимального ограничения прав доступа, смене учетных записей по умолчанию, обновлению ПО, и других «типовых» рекомендациях. Цель статьи – рассказать о самых частых ошибках в настройках, заставить администраторов и специалистов ИБ задуматься над вопросом – «а все ли в моей сети хорошо?», а также показать, как можно оперативно прикрыть те или иные типовые уязвимости, используя встроенные или бесплатные средства, не прибегая к дополнительным закупкам.



Инструкций-рецептов намеренно не прикладываю, так как многое ищется очень легко по ключевым словам.



1. Усильте безопасность инфраструктуры Windows



Не создавайте локальные учетные записи доменными политиками



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



Причина высокой опасности – сведения об этой учетной записи, в том числе ее пароль, хранятся в открытом виде в файле groups.xml, в ресурсе sysvol контроллера домена, который по умолчанию доступен ВСЕМ участникам домена на чтение. Пароль зашифрован, но шифрование симметричное, а ключ один для всех копий Windows, и написан в открытом виде в MSDN. Отсюда следует: любой пользователь может скачать этот файл, и путем простых манипуляций узнать пароль от распространяемой учетной записи. Обычно так распространяется учетная запись с правами администратора, и часто она создается без разбора везде…



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







Противодействие угону доменных учетных записей через mimikatz/wce



Администраторы, не связанные с пентестами и практической ИБ, редко знают про такие утилиты, как mimikatz и wce. Кратко об их работе – обладая правами локального администратора, можно извлечь из оперативной памяти билет доступа Kerberos, хеш пароля и даже сам пароль в открытом виде от учетных записей, которые недавно производили вход на этот хост. А так как администраторы совершают вход часто и много где, это приводит к высокому риску компрометации их полномочий.



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



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



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



Решение без дополнительных затрат: заводить для управления инфраструктурой даже не 2-3 учетные записи, как принято (надеюсь, у вас так?):



— для локальной работы;

— для администрирования серверов и ПК;

— для контроллеров домена,

а как минимум 4 учетные записи (а то и больше), в соответствии с условными «зонами доверия» в домене, и не применять их вне своей зоны. То есть, держать отдельные учетные записи:

— для работы со своей личной машиной;

— для входа на контроллеры домена и управлением ими.

— для серверов;

— для рабочих станций;

— для удаленных филиалов, если там оказался ваш домен, но при этом вы не уверены, что там происходит в конкретный момент времени;

— для зоны DMZ, если вдруг доменные хосты оказались в DMZ;

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



Запрет на ввод «тестовых» хостов в домен



По схожей причине (см. пункт выше) по возможности лучше не заводить общественные «тестовые» хосты в домен. Такие хосты наиболее часто встречаются в компаниях с подразделениями по разработке софта, «для ускорения» и экономии лицензии они часто не снабжаются антивирусами (которые, кстати, «ловят» нешифрованные mimikatz и wce), а все причастные разработчики и тестировщики имеют на них права администратора, с целью осуществления разных сомнительных действий. Используя свои администраторские права, они могут легко похитить доменные учетные записи других администраторов.



Детализация прав сервисных учетных записей



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



Обращение к SMB по именам и запрет использования NTLM



К файловым ресурсам (SMB) в домене лучше обращаться только через доменное имя, а не через IP. Помимо удобства администрирования, так вы явным образом заставите хост аутентифицироваться по протоколу Kerberos, который хоть и имеет свои недостатки, но является значительно более защищенным, чем протокол NTLMv2, который задействуется при обращении по IP файлового ресурса. Перехват NTLMv2 хеша опасен тем, что можно словарной атакой неспешно восстанавливать пароль пользователя оффлайн, то есть, никак не беспокоя атакуемую инфраструктуру. Очевидно, что это не заметно для администраторов, в отличие онлайн-атак по перебору паролей.



Касательно протокола NTLM (который без «v2») – он должен быть запрещен. Помимо атак по перебору паролей, можно использовать атаку типа «Pass-the-hash». Эта атака по сути разрешает переотправку хеша NTLM без изменения и попыток подобрать пароль на произвольный хост, где разрешен NTLM. Сам хеш может быть украден из другой сессии в ходе атаки. Если у вас разрешены оба протокола NTLM, возможна ситуация, когда атакующий может понизить предпочтение с NTLMv2 до NTLM, и хост-жертва выберет самую слабую аутентфикацию.



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



Блокировка механизма WPAD



Есть два механизма, которые включены по умолчанию, и в совокупности позволяют проводить атаку «человек по середине», причем практически не обнаруживая атакующего. Это механизм автоматического обнаружения прокси через специальное сетевое имя (WPAD), и механизм широковещательного разрешения имен LLMNR.



Через WPAD некоторое ПО (в домене это чаще всего служба обновлений WSUS и некоторые браузеры) выполняет поиск HTTP прокси, и готово при необходимости прозрачно авторизоваться на нем при помощи NTLM(v2). Таким образом, оно добровольно «выдает» хеш учетной записи, которая инициировала подключение. Его можно в последствии перебирать по словарю, и восстановить пароль. Либо применять атаку «Pass-the-hash», описанную выше, если не отключен NTLM (про это см. пункт выше).



Устройства выполняют поиск сервера WPAD через DNS, и, если это не сработает, задействуют широковещательный запрос LLMNR или NetBIOS. И тут атакующему уже значительно проще ответить на вопрос хоста, где же находится «правильный» сервер конфигурации прокси. Дополнительный негативный эффект — такой поиск прямо замедляет скорость подключения, так как тратится время на поиск прокси.



Решение – в групповых политиках запретить и автообнаружение прокси для ПО, и протокол LLMNR. На DNS адрес WPAD (wpad.domain.name) в DNS поставить заглушку. LLMNR это фактически имитация DNS на сегменте сети L2 путем широковещательных запросов. В доменной сети при нормально работающем DNS он не нужен. С NetBIOS все сложнее, он до сих пор используется во многих случаях, и его выключение может обрушить работу, так что здесь все же остается лазейка для навязывания WPAD.



Включение UAC на максимум



Не выключайте User Account Control (UAC), а лучше наоборот, установите его на максимум. UAC, конечно, реализован не очень удобно и не информативно, но вы не представляете, как обидно пентестеру получить формальную возможность удаленного выполнения команд от имени пользователя с администраторскими правами, но без фактической возможности выполнения именно привилегированных действий, которые как раз при «обычной» работе надоедают запросами о подтверждении. Обойти UAC или повысить права конечно, возможно, но это лишние препятствия.



Отключение скрытых файловых ресурсов



Хотя бы для машин администраторов, «важных» пользователей и серверов обязательно отключайте скрытые ресурсы $ADMIN, C$, D$, и т.д. Это первоочередная излюбленная цель любой сетевой malware и злоумышленников при получении более-менее привилегированных прав в домене.



Сетевые диски как ярлыки



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



2. Почтовая система. SPF



Ревизия содержимого SPF



Проверьте SPF-запись вашего почтового домена. А потом проверьте ее еще раз.



Многие недооценивают значимость этой записи, и при этом не понимают работу протокола SMTP. SPF запись показывает, какие ресурсы могут легитимно отправить почту от имени вашего домена. Для частного случая отправки писем на ваш домен от вашего домена (то есть, для внутренней переписки внутри вашего же домена) эта запись показывает, кто (т.е. конкретные хосты) может отправлять письма без авторизации, от имени любого пользователя. Чаще всего здесь делают две незначительные на вид ошибки, приводящие к огромным проблемам.



1) «~all» в конце SPF записи почтового домена. Не знаю почему, но большинство публичных мануалов рекомендуют оставить такую настройку. Такая настройка дает письму статус «не прошло проверку, но помечено как опасное и все равно доставлено» при отправке почты от ресурсов, прямо не указанных в SPF домена. Это говорит получателю, что решение о легитимности отправляемой почты перекладывается на жесткость настроек его спам-фильтра и других механизмов фильтрации. Далее, есть вероятность, что ваш собственный спам-фильтр настроен мягко (особенно часто это бывает с «публичными» пользователями компании, которые боятся «прозевать» письма), и это приводит к тому, что любой хост Интернета отправит вам же письмо от вашего же домена, и с некоторой вероятностью оно пройдет во входящие, а не в спам. Очень забавно видеть пользователей и даже ИТ-администраторов, беспрекословно выполняющих срочные указания от «важного начальства» из подобных поддельных писем при пентестах с социальной составляющей. Конечно же, не исключена ситуация со слабыми спам-фильтрами и у ваших контрагентов, и тогда уже вы будете делать им заманчивые предложения без своего ведома.



SPF для подавляющего большинства компаний должна содержать только –all в конце, разумеется, после тщательной сверки своего содержимого.



2) Бывает, что по ошибке в SPF корпоративного домена оказываются внешние адреса, через которые пользователи компании выходят в интернет. Последствия понятны – возможность нелегитимной отправки писем от кого угодно из корпоративного домена, куда угодно. Обычно администраторы в таких ситуациях говорят – «но у нас же есть авторизация на почте», напрочь забывая про сам механизм протокола SMTP.



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



Для борьбы с такими атаками дополнительно поможет система подписей DKIM, показывающая, кто есть на самом деле отправитель, но ее внедрение процесс не моментальный, поэтому начать стоит именно с настроек SPF – ужесточить ее и сделать полную ревизию по разрешенным адресам.



3. Дизайн локальной сети



Организуйте DMZ



Организуйте DMZ, и навсегда перестаньте «пробрасывать» порты из Интернет в основную сеть. Правильная DMZ эта та, ресурсы в которой с двух сторон закрыты файерволами (как от внутренней сети, так и от Интернет), а трафик разрешен крайне выборочно, и только минимально необходимый. На мой взгляд, настоящий специалист по ИБ должен думать, что его хост из DMZ по уже взломан, и оценивать риски исходя из этого. На такие мысли наводит тот факт, что в DMZ очень часто оказываются нестандартные приложения, которые несут специфичную бизнес-логику, ставятся подрядчиками на потоке, как вариант – делаются на заказ и очень плохо проверяются, например, на банальные для WEB уязвимости. Штатный специалист по ИБ чаще всего в состоянии создать DMZ, но не в состоянии проверить приложения на уязвимости. Исходя из этого и нужно действовать.



Типичный вариант правильно организованной DMZ и общий принцип движения трафика. Стрелки – направления инициации трафика из/в DMZ.







Бюджетный дизайн DMZ для параноиков, в которой каждый ресурс находится в отдельной изолированной сети, и ресурсы не «кушают» много трафика:







Что касается «проброса» портов, то помимо риска «взлома» сервиса, существует неявный риск сбора информации о внутренней сети. Например, в ходе пентестов зачастую видно порты RDP, которые были «скрыты» путем смены со стандартного 3389 на какой-нибудь 12345. Разумеется, они легко обнаруживаются сканерами, легко идентифицируются именно как RDP, но помимо простого обнаружения, они могут, например, предоставить информацию об имени компьютера и домена (путем просмотра сертификата службы RDP), или информацию о логинах пользователей.



Полностью изолированный гостевой WiFi



Гостевой WiFi должен быть максимально изолирован от основной сети (отдельный VLAN, отдельный провод от маршрутизатора интернет до точки доступа, и т.д.). Дополнительно, по возможности, выключайте гостевой WiFi в нерабочее время по расписанию на оборудовании.



Здесь есть один нюанс. Многие правильно выделяют гостевой WiFi в отдельный изолированный VLAN, но при этом зачем-то выдают клиентам адреса DNS серверов Active Directory. Наиболее рациональное оправдание – «чтобы работали ресурсы из DMZ по внутренним адресам». Однако, это является уязвимостью, и это хорошо помогает злоумышленнику при несанкционированном анализе внутреннего устройства сети, ведь запросы к DNS (PTR по внутренним диапазонам IP) обычно никак не ограничиваются.



Решение – создать легкий внутренний DNS сервер специально для WiFi, либо использовать публичные DNS в Интернет.



Не создавайте «корпоративный» WiFi на едином Preshared-ключе



Это очень частая проблема. Один ключ от WiFi часто живет годами, ведь «нельзя же беспокоить пользователей лишний раз». Это неизбежно снижает безопасность такой конфигурации до нуля с течением времени. Основные причины – текучка сотрудников в организации, кражи устройств, работа malware, возможность перебора пароля сети.



Решение: авторизация на WiFi только через WPA2-Enterprise, для того, чтобы каждый пользователь имел свои персональные, легко блокируемые учетные данные, которые контролируются централизованно. Если внутренняя сеть на самом деле не нужна для WiFi устройств, а нужен только Интернет, нужно сделать WiFi по типу гостевого. Сам дизайн аутентификации WPA2-Enterprise это предмет отдельной статьи.



Правильная сегментация сети



Максимально сегментируйте сеть на VLAN, максимально ограничьте широковещательный трафик. Об этом пишут все мануалы по дизайну сети, почему-то это редко кем соблюдается, особенно в малом и среднем сегменте компаний, но это крайне полезно как с точки зрения удобства администрирования, так и с точки зрения безопасности.



В любом случае обязательно нужно держать ПК пользователей отдельно от серверов, иметь отдельный VLAN для management-интерфейсов устройств (сетевых устройств, интерфейсов iLO/IMPI/IP KVM, и т.д.). Все это снизит возможности подделки адресов, упростит настройку сетевого доступа, снизит вероятность атак за счет широковещательных запросов, а значит повысит и стабильность работы.



На мой взгляд как безопасника (но уже чувствую летящие помидоры от сетевиков), количество VLAN для пользователей больше зависит от количества коммутаторов доступа и от количества условных групп пользователей по административному признаку, а не от самого количества пользователей. Имеет смысл сделать количество пользовательских VLAN на уровне числа коммутаторов доступа (даже если они собраны в стек). Так очень сильно ограничится широковещательный трафик, не будет «размазывания» одного VLAN по множеству коммутаторов доступа. Это не сделает для сети лишней работы, так как чаще всего трафик пользователей идет либо в серверный сегмент, либо в Интернет (т.е. в любом случае в сторону уровня ядра сети или уровня распределения), а не между самими пользователями. В таком случае легче отлаживать сеть, и предотвращать атаки, связанные с широковещательными пакетами.



Для малых сетей ситуация сильно отличается – зачастую сегментировать нечего, сеть слишком мала. Однако, во всех организациях, где появляется минимальных набор серверов, обычно вместе с серверами закупаются управляемые коммутаторы, иногда с функциями L3. Почему-то они используются как просто коммутаторы, зачастую даже без минимальной настройки, хотя настройка L3 для простой маршрутизации между 2-3 сетями очень проста.



Защита от ARP spoofing и поддельных DHCP серверов



Два механизма, на языке технологий Cisco: DHCP snooping и ARP Inspection, помогут расстроить разных шутников-пользователей и реальных злоумышленников. После их внедрения вы получите предотвращение появлений ложных DHCP серверов в сети (которые могут появиться как по ошибке — кто-то перепутал настольный «домашний» маршрутизатор форм-фактора «мыльница советская» с такого же типа коммутатором, так и в результате атаки), и атак типа «человек посередине» через ARP протокол. В сочетании с малыми размерами VLAN (предыдущий пункт) это отлично снизит возможный ущерб.



Если такие функции невозможно настроить, как минимум стоит указать жесткую привязку MAC адреса шлюза сети с физическим портом коммутатора.



Port security



Если кабельная сеть и оборудование позволяют, настройте на коммутаторах доступа port security. Это хорошо защищает, хоть и не полностью, от подключения «левых» и «лишних» устройств, несанкционированного перемещения компьютеров в пространстве.



Противодействие «левым» устройствам



Даже с описанными выше защитными мерами (port security, dhcp snooping, arp inpection), возможно появление «левых устройств», причем, как показывает практика, наиболее вероятное устройство в этом случае – «домашний» роутер с функцией «клонировать MAC-адрес компьютера на внешний интерфейс». Поэтому, есть следующий шаг развития сетевой тирании – 802.1x. Однако, это уже серьезное решение, требующее хорошего планирования, поэтому возможен более простой способ выявления самовольных роутеров (именно выявления, а не пресечения). Здесь хорошо поможет анализ трафика на промежуточном звене сети на предмет параметра протокола IP — TTL. Можно сделать span порт на коммутаторе, зеркалирующий трафик в сервер со снифером, и анализировать этот трафик на наличие пакетов с аномальным TTL. В этом поможет банальный tcpdump/Wireshark. Трафик с таких роутеров будет иметь TTL меньше на 1, чем легальный трафик.



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



Удаленный доступ



При организации удаленного подключения к сети забудьте про протокол PPTP. Он, конечно, настраивается быстро и легко, но помимо наличия уязвимостей в самом протоколе и его составляющих, он плох тем, что очень хорошо виден сканерами сети (из-за работы на TCP на одном и том же порте), зачастую плохо проходит через NAT за счет транспорта на GRE, от чего на него жалуются пользователи, и по своему дизайну не содержит второго фактора аутентификации.



Чтобы внешнему злоумышленнику было удобнее работать, аутентификацию на таком VPN обычно привязывают к доменным учетным записям, не вводя второй фактор аутентификации, что часто и эксплуатируется.



Решение-минимум: использовать протоколы на UDP (либо свободно инкапсулирующиеся в UDP), которые не так видны при сканировании, с предварительной аутентификацией по PSK, либо по сертификату (L2TP/IPSec, OpenVPN, разные вендорские реализации IPSec). Обязательно нужно настроить перечень адресов и портов внутри сети, куда можно получить доступ, используя VPN.



Запретите прямой произвольный доступ в интернет для «пользовательской» сети



Прямой выход в интернет для пользователей – это зло, хотя с удешевлением каналов Интернет его становится все больше и больше, особенно в малых и средних компаниях. Многие администраторы ограничивают исходящие порты для пользователей на минимальный набор, вроде 80, 443, пытаясь экономить полосу. С точки зрения Malware и злоумышленников, это ничем не отличается от свободного доступа в Интернет.



На мой взгляд, всегда нужен прокси-сервер, пусть без кеширования и авторизации, даже в самых маленьких сетях, и запрет на прямой выход в интернет для пользователей. Основная причина — множество всяческой malware обращается на свои центры управления именно по HTTP(S), либо по чистому TCP c популярными портами (80/443/25/110…), но при этом она зачастую не в состоянии обнаружить настройки прокси в системе.



Возьмите под контроль IPv6



Если вы не интересовались использованием IPv6, повторите все действия по фильтрации трафика применительно к IPv6, либо запретите его. Ваша инфраструктура может неявно использовать его, но вы можете и не знать об этом. Это опасно проблемами несанкционированного получения доступа в сети.



Трафик в межфилиальных сетях



Если у вас под контролем крупная сеть с удаленными филиалами, и в ней настроен Site-to-Site VPN, не поленитесь максимально ограничить трафик, который идет к вам в центр, причем именно на центральном оборудовании, а не в филиалах. Не воспринимайте каналы с удаленными филиалами как «свою родную» сеть. Обычно в компаниях филиалы защищены меньше центра, и большинство атак начинаются именно с филиалов, как с «доверенных» для центра сетей.



Ограничение icmp ping



Ограничьте список адресов, которые могут «пинговать» важные сервисы. Это снизит обнаружение ваших хостов, хоть и ненамного. При этом не забудьте, что ping – это не весь протокол icmp, а только один вид сообщений в icmp, и не нужно его (icmp) запрещать целиком. По крайней мере, вам точно будут нужны для корректного взаимодействия со всеми сетями некоторые сообщения видов Destination Unreachable. Не создавайте полным запретом ICMP на своих маршрутизаторах так называемую MTU Discovery Black Hole.



4. Шифрование трафика



Сертификаты SSL для всего и везде



Не ленитесь защищать шифрованием все сервисы, куда можно пристроить SSL/TLS. Для хостов из домена Active Directory можно настроить AD Certificate Services, либо распространять сертификаты служб через групповые политики. Если нет денег для защиты публичных ресурсов, воспользуйтесь бесплатными сертификатами, например, от startssl.



Для себя, т.е. администраторов, всегда можно пользоваться легким самодельным удостоверяющим центром, например, easy-rsa, либо самоподписанными сертификатами. Вы же заметите, что на вашем внутреннем администраторском ресурсе внезапно возникла ошибка доверия к ранее одобренному сертификату?



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



Wildcard SSL сертификат



Если вы стали счастливым обладателем wildcard-сертификата (для доменов «*.ваш-домен»), не торопитесь его распространять по всем публичным серверам. Сделайте себе отдельный сервер (или кластер), к примеру, на Nginx, который будет «разгружать» от шифрования входящий трафик. Так вы сильно снизите количество каналов утечки закрытого ключа вашего сертификата, и в случае его компрометации, не будете менять его сразу на множестве сервисов.



5. Пару слов про веб-серверах на основе Linux



Linux-хосты чаще всего видно в роли веб-серверов, классической связки LAMP (Linux + Apache + Mysql + PHP, или любой другой скриптовый язык), которую чаще всего и ломают за счет дыр в веб-приложении, поэтому опишу самый минимум для данной связки, который относительно легко внедряется, и не требует большого опыта настройки и отладки (вроде мер типа SELinux/AppArmor).



Доступ к серверу



Не поленитесь запретить вход по ssh для root, настроить авторизацию только по сертификатам и сместить порт ssh куда-нибудь далеко со стандартного 22.



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

Если же наоборот, администратор один, то деактивируйте sudo (особенно в том случае, если у вас по каким-то причинам сохранился вход через ssh по паролю), и для администраторских задач используйте аккаунт root.



Ну и конечно, классика — не работайте под рутом.



Iptables



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



Правильно настроенный iptables, как и любой другой файервол, разрешает только минимально необходимое (включая исходящие соединения через цепочку правил output). На случай минимальной конфигурации Web-сервера в iptables будет не более 10 строк. По сложности, это значительно проще настройки firewall для доменного хоста Windows, где можно нечаянно запретить динамические RPC порты, доменные службы и другие важные для работы коммуникации, так как не всегда очевидна даже последовательность коммуникации. Поэтому, для настройки iptables под web-сервер не нужны особые знания по сетям, и можно настроить файервол значительно легче.



Противодействие повышению прав в случае взлома



Отправьте Apache работать в chroot. Как вариант, сделайте отдельные разделы в файловой системе для /var/ и /tmp, смонтируйте их с флагами noexec,nosuid. Так вы защитите сервер от исполнения локальных эксплоитов в бинарном виде, которые могут повысить права атакующего. Запретите исполнение интерпретаторов скриптовых языков типа Perl, Python для «других пользователей» (chmod o-x), куда относится веб-сервер, если это не требуется веб-серверу и другим службам. Чем меньше в системе «других служб», а соответственно, пользователей под них, тем проще это сделать.



Пара слов о настройке web-сервера на примере Apache



Здесь перечислено то, что может сделать системный администратор для защиты веб-приложения, даже не зная специфики веб-программирования.



— Запретите наличие VirtualHost, который отвечает на запросы вида http(s)://ip-адрес/, даже если приложение на сервере одно. Так вы значительно снизите возможность обнаружения приложения.

— Запретите в конфигурации apache вывод ошибок (опции ServerSignature Off, ServerTokens Prod), это затруднит определение версии ОС и Apache.

— Установите через mod_headers опции для Cookies HTTP_only и Secure для вашего веб-приложения, даже если у вас веб-приложение делает это само. Это защитит вас от перехвата Cookies через прослушку нешифрованного HTTP и части атак XSS.

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

— Контролируйте, чтобы индексы директорий были выключены (опция «–Indexes» в настройках сайта или файлов .htaccess).

— Дополнительно сделайте basic-авторизацию на директорию с администраторской панелью сайта.

— Установите принудительное перенаправление с 80 порта на 443, если у вас есть настроенный TLS. Запретите устаревшие алгоритмы SSL (SSLProtocol all -SSLv2 -SSLv3), слабые алгоритмы шифрования и вариант его полного отсутствия через директиву SSLCipherSuite. Это защитит от атак на «понижение» уровня шифрования.



Проверить свою настройку SSL можно, например, через https://www.ssllabs.com/ssltest/



Настройте аудит системы



Включите и настройте auditd по показательным событиям (создание пользователя, изменение прав, изменение конфигурации) с отправкой уведомлений на удаленный сервер. Все взломы не производятся одномоментно, поэтому периодически осматривая логи, пусть даже и вручную, можно обнаружить подозрительную активность. Дополнительно это поможет при «разборе полетов» в случае инцидентов.



Ставьте только минимально необходимое в системе



ОС на основе Linux хороши тем, что можно гибко выключать/удалять ненужные компоненты. С точки зрения безопасности, в первую очередь, это относится к сетевым и локальным демонам. Если вы видите, что на вашем только что установленном сервере работают демоны, которые явно или косвенно не относятся к задаче данного сервера, задумайтесь – действительно ли они нужны. Для большинства случаев это всего лишь стандартная установка, и они легко и без последствий выключаются и/или удаляются. Например, не всем нужен RPC, который включен по умолчанию в Debian. Не ждите, пока под такие сервисы найдут уязвимости и сделают эксплойт, а вы забудете обновиться.



6. Самоконтроль



Даже не обладая навыками специалиста по тестированию на проникновение, можно дополнительно включить в самоконтроль минимальные «пентестерские» действия. Вам помогут:



Сканеры безопасности



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



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



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



Брутфорс учетных записей



Проверяйте учетные записи сотрудников на предмет слабых паролей. В минимальной комплектации в этом поможет файловый ресурс, доступный любому доменному пользователю после авторизации, и утилита THC Hydra. Сформируйте словари из паролей, которые подходили бы под вашу парольную политику, но при этом были бы простые, вроде «123QAZxsw». Количество слов в каждом – не более числа допустимых попыток авторизации в домене, минус 2-3 для запаса. И пропустите через брутфорс все учетные записи домена, уверен, найдете много интересного.

Разумеется, на эти проверки заранее нужно получить официальное (желательно, «бумажное») разрешение от руководства, иначе это будет походить на попытку неавторизованного доступа к информации.



Минутка юмора



Напоследок, пентестерская байка касательно паролей. Осенью 2015 года мы делали социальный пентест с применением фишинга – выманивали доменные пароли. У двух попавшихся пользователей пароль был «Jctym2015» («Осень2015»). Посмеялись, забыли. В ноябре 2015 года делаем подобный пентест в другой организации, никак не связанной с первой, опять те же пароли, и опять сразу у нескольких пользователей. Начали что-то подозревать, нашли в одной оранжевой социальной сети такое вот руководство к действию:








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

Original source: habrahabr.ru.

https://habrahabr.ru/post/283482/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
luunna

Техническая поддержка сайта

Понедельник, 02 Мая 2016 г. 13:22 (ссылка)
master-live.ru/podderzhka-i...sayta.html


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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Популярный плагин для WordPress содержит в себе бэкдор

Четверг, 17 Марта 2016 г. 15:09 (ссылка)

image



Специалисты в области информационной безопасности нашли бэкдор в плагине для WordPress, который вносил изменения в основные файлы платформы с целью дальнейшей авторизации и кражи пользовательских данных.



Первые признаки наличия бэкдора были замечены сотрудниками компании Sucuri, работающей в области обеспечения информационной безопасности web-сайтов. Один из их клиентов заметил файл со странным названием (auto-update.php), не существовавший до недавнего обновления плагина.



Речь идёт о Custom Content Type Manager (CCTM), популярном плагине для WordPress, предназначенном для создания произвольного типа постов. CCTM был доступен в директории плагинов на сайте WordPress в течение трёх лет и собрал себе довольно большую аудиторию – он установлен на более чем 10000 сайтов.



Версия 0.9.8.8 плагина Custom Content Type Manager содержит в себе вредоносный код



Плагин, выглядевший заброшенным последние 10 месяцев, за последние две недели загадочным образом изменил своего владельца, что сразу повлекло за собой создание и выпуск новой версии, за авторством его нового разработчика с никнеймом Wooranker. Но новая версия содержала лишь вредоносные обновления:




  • Был добавлен файл auto-update.php, способный загружать файлы с удалённого сервера на заражённый сайт.

  • Wooranker добавил файл CCTM_Communicator.php, который работал в паре со старым, ранее безопасным файлом данного плагина. Целью этих двух файлов было оповещение Wooranker'a о появлении недавно заражённых сайтов при помощи пинга к его серверу.

  • Помимо сбора информации на заражённом сайте, новая версия CCTM перехватывала логины и пароли пользователей при помощи WordPress, отправляя эти данные в зашифрованном виде на wordpresscore.com.



Модификации были выпущены как обновление 0.9.8.8 для Custom Content Type Manager, что позволило им легко распространиться при помощи включенной функции авто-обновления на сайтах или при установке самими пользователями.



Sucuri сообщает, что после получения украденных данных Wooranker пытался их использовать. Он вручную попробовал авторизоваться на одном из заражённых сайтов, но безуспешно, так как его владелец изменил URL на нестандартную ссылку. После неудачи Wooranker быстро сменил тактику. Он использовал бэкдор файла auto-update.php и вынуждал сайт жертвы закачивать и устанавливать файл c.php, который, в свою очередь, создавал другой файл: wp-options.php (WordPress использует wp-settings.php). Созданный файл должен был изменить основные файлы WordPress: wp-login.php, wp-admin/user-new.php, и wp-admin/user-edit.php.



Эти изменения позволяли хакеру контролировать действия пользователей над аккаунтами: создание, редактирование и их изменение, что позволяло перехватывать данные до их шифрования и красть полученную информацию.



Раскрыл ли хакер свою личность?



На случай, если возможностей файла CCTM_Communicator.php становилось недостаточно, Wooranker создал собственный аналитический код на JavaScript, который загружался через плагин CCTM как поддельная версия jQuery.



Этот файл передавал информацию о новых заражённых сайтах на домен donutjs.com. В дальнейшем команда Sucuri вычислила, что все использованные в этой атаке домены принадлежали человеку под именем Вишнудат Мангилипуди, проживающем в Индии, городе Андрха-Прадеш, но его данные также могли быть украдены и маловероятно, что он — наш хакер.



Хоть и Sucuri не первыми заметили странное поведение плагина, но, в отличие от его пользователей, они поняли, что файл auto-update.php является бэкдором, а не простой уязвимостью в безопасности плагина.



Администраторы WordPress с установленным CCTM должны немедленно удалить его и откатить основные файлы WordPress до их стандартных версий. Если же приложение CCTM вам необходимо, то используйте его последнюю стабильную версию 0.9.8.6 (версия 0.9.8.7 имеет уязвимости).



Также обратите внимание на то, что уже вышла версия 0.9.8.9 CCTM, не содержащая в себе вредоносного кода и идентичная версии 0.9.8.6.



Источник





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/279539/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Архитектура Stack Overflow

Среда, 02 Марта 2016 г. 17:54 (ссылка)

image



Чтобы понять, как все это работает, давайте начнем с показателей Stack Overflow. Итак, ниже приводится статистика за 12 ноября 2013 и 9 февраля 2016 года:



статистика

  • 209,420,973 (+61,336,090) HTTP-запросов к нашему балансировщику нагрузки;

  • 66,294,789 (+30,199,477) страниц было загружено;

  • 1,240,266,346,053 (+406,273,363,426) битов (1.24 TБ) отосланного HTTP-трафика;

  • 569,449,470,023 (+282,874,825,991) битов (569 ГБ) всего получено;

  • 3,084,303,599,266 (+1,958,311,041,954) битов (3.08 ТБ) всего отослано;

  • 504,816,843 (+170,244,740) SQL-запросов (только из HTTP-запросов);

  • 5,831,683,114 (+5,418,818,063) обращений к Redis;

  • 17,158,874 (not tracked in 2013) поисков в Elastic;

  • 3,661,134 (+57,716) запросов Tag Engine;

  • 607,073,066 (+48,848,481) мс (168 часов) выполнения SQL-запросов;

  • 10,396,073 (-88,950,843) мс (2.8 часов) затрачено на обращение к Redis;

  • 147,018,571 (+14,634,512) мс (40.8 часов) затрачено на запросы к Tag Engine;

  • 1,609,944,301 (-1,118,232,744) мс (447 часов) затрачено на обработку в ASP.Net;

  • 22.71 (-5.29) мс в среднем (19.12 мс в ASP.Net) на формирование каждой из 49,180,275 запрошенных страниц;

  • 11.80 (-53.2) мс в среднем (8.81 мс в ASP.Net) на формирование каждой из 6,370,076 домашних страниц.





Вы можете спросить, почему существенно сократилась продолжительность обработки в ASP.Net по сравнению с 2013 годом (когда было 757 часов) несмотря на прибавление 61 миллиона запросов в день. Это произошло как и из-за модернизации оборудования в начале 2015 года, так и из-за некоторого изменения параметров в самих приложениях. Пожалуйста, не забывайте, что производительность – это наша отличительная особенность. Если Вы хотите, чтобы я более подробно рассказал о характеристиках оборудования – без проблем. В следующем посте будут подробные спецификации железа всех серверов, которые обеспечивают работу сайта.



Итак, что изменилось за прошедшие 2 года? Кроме замены некоторых серверов и сетевого оборудования, не очень многое. Вот укрупненный список хардварной части, которая обеспечивает работу ресурса (выделены различия по сравнению с 2013 годом):




  • 4 Microsoft SQL Servers (новое железо для 2-х из них);

  • 11 Web-серверов IIS (новое оборудование);

  • 2 сервера Redis (новое оборудование);

  • 3 сервера Tag Engine (новое оборудование для 2-х из 3-х);

  • 3 сервера Elasticsearch (те же, старые);

  • 4 балансировщика нагрузки HAProxy (добавлено 2 для поддержки CloudFlare);

  • 2 брандмауэра Fortinet 800C (вместо Cisco 5525-X ASAs);

  • 2 маршрутизатора Cisco ASR-1001 (вместо маршрутизаторов Cisco 3945);

  • 2 маршрутизатора Cisco ASR-1001-x (новые!).



Что нам необходимо, чтобы запустить Stack Overflow? Этот процесс не сильно изменился с 2013 года, но из-за оптимизации и нового железа, нам необходим только один web-сервер. Мы этого не хотели, но несколько раз успешно проверили. Вношу ясность: я заявляю, что это работает. Я не утверждаю, что это (запуск SO на единственном web-сервере) — хорошая затея, хотя каждый раз выглядит весьма забавно.



Теперь, когда у нас есть некоторые числа для понятия масштаба, давайте рассмотрим, как мы это делаем. Так как немногие системы работают в полной изоляции (и наша не исключение), часто конкретные архитектурные решения почти не имеют смысла без общей картины того, как эти части взаимодействуют между собой. Цель нашей статьи – охватить эту общую картину. Во многочисленных последующих постах будут подробно рассмотрены отдельные области. Это логистический обзор только основных особенностей нашего «hardware», а уже потом, следующих постах, они будут рассмотрены более детально.



Для того, чтобы Вы поняли, как сегодня выглядит наше оборудование, привожу несколько своих фото рэковой стойки А (в сравнении с ее «сестрой» стойкой B), сделанных во время нашего переоборудования в феврале 2015 года:



image



И, как не парадоксально, с той недели у меня в альбоме есть еще 255 фотографий (в сумме 256, и да — это не случайное число). Теперь, давайте рассмотрим оборудование. Вот логическая схема взаимодействия главных систем:



image



Основные правила



Вот некоторые всеобще применяемые правила, поэтому я не буду повторять их для каждой системы:




  • Все резервировано.

  • Все сервера и сетевые устройства связаны между собой, по крайней мере, 2 x 10 ГБит/с каналами.

  • Все сервера имеют 2 входа питания и 2 подвода питания от 2-х ИБП, подключенных к двум генераторам и двум сетевым линиям.

  • Все сервера между рэками A и B имеют резервированного партнера (redundant partner).

  • Все сервера и сервисы дважды резервированы через другой дата-центр (Колорадо), хотя здесь я буду больше говорить о Нью-Йорке.

  • Все резервировано.



В сети Интернет



Сначала Вы должны найти нас – это DNS. Процесс нахождения нас должен быть быстрым, поэтому мы поручаем это CloudFlare (в настоящее время), так как их серверы DNS ближе почти всех остальных DNS мира. Мы обновляем наши записи DNS через API, а они делают «хостинг» DNS. Но поскольку мы «тормозы» с глубоко укоренившимися проблемами доверия (к другим), мы также все еще имеем наши собственные DNS-сервера. Если произойдет апокалипсис (вероятно, вызванный GPL, Punyon или кэшированием), а люди все еще будут хотеть программировать, чтобы не думать о нем, мы переключимся на них.



После того, как Вы найдете наше «секретное убежище», пойдет HTTP-трафик через одного из наших четырех Интернет провайдеров (Level 3, Zayo, Cogent, и Lightower в Нью-Йорке), и через один из наших четырех локальных маршрутизаторов. Для достижения максимальной эффективности, мы вместе с нашими провайдерами используем BGP (довольно стандартный) для управления трафиком и обеспечения нескольких путей его передачи. Маршрутизаторы ASR-1001 и ASR-1001-X объединены в 2 пары, каждая из которых обслуживает 2 провайдера в режиме активный/активный. Таким образом, мы обеспечиваем резервирование. Хотя они подключены все к той же физической сети 10 Гбит/с, внешний трафик проходит по отдельным изолированным внешним VLAN, которые также подключены к балансировщикам нагрузки. После прохождения через маршрутизаторы, трафик направляется к балансировщикам нагрузки.



Я думаю, что самое время упомянуть, что между нашими двумя дата-центрами мы используем линию MPLS на 10 Гбит/с, но это напрямую не связано с обслуживанием сайта. Она служит для дублирования данных и их быстрого восстановления в случаях, когда нам нужна пакетная передача. «Но Ник, это не резервирование!» Да, технически Вы правы (абсолютно правы): это – единственное «пятно» на нашей репутации. Но постойте! Через наших провайдеров мы имеем еще две более отказоустойчивые линии OSPF (по стоимости MPLS — № 1, а это № 2 и 3). Каждое из упомянутых устройств быстрее подключается к соответствующему устройству в Колорадо, и при отказе они распределяют между собой сбалансированный трафик. Мы смогли заставить оба устройства соединяться с обоими устройствами 4-мя способами, но все они и так одинаково хороши.



Идем дальше.



Балансировщики нагрузки (HAProxy)



Балансировщики нагрузки работают на HAProxy 1.5.15 под CentOS 7, предпочтительной у нас разновидности Linux. HAProxy также ограничивает и трафик TLS (SSL). Для поддержки HTTP/2 мы скоро начнем внимательно изучать HAProxy 1.7.



В отличие от всех других серверов с двойным сетевым подключением по LACP 10 Гбит/с, каждый балансировщик нагрузки имеет по 2 пары каналов 10 Гбит/с: одну для внешней сети и одну для DMZ. Для более эффективного управляемого согласования SSL эти «коробки» имеют память 64 ГБ или больше. Когда мы можем кэшировать в памяти больше сессий TLS для повторного использования, тратится меньше времени на образование нового соединения с тем же самым клиентом. Это означает, что мы можем возобновлять сессии и быстрее, и с меньшими затратами. Учитывая, что RAM в переводе на доллары довольно дешевая, это – легкий выбор.



Сами балансировщики нагрузки – довольно простые устройства. Мы создаем иллюзию, что разные сайты «сидят» на различных IP (в основном по вопросам сертификации и управления DNS), и маршрутизируем на различные выходные буфера основываясь, главным образом, на заголовках хоста. Единственными «знаменитыми» вещами, которые мы делаем, является ограничение скорости и некоторые захваты заголовков (отсылаемых с нашего уровня веб-узлов) в сообщение системного журнала HAProxy. Поэтому мы можем делать запись метрик производительности для каждого запроса. Мы также расскажем об этом позднее.



Уровень веб-узлов (IIS 8.5, ASP.Net MVC 5.2.3 и .Net 4.6.1)



Балансировщики нагрузки регулируют трафик 9-ти серверов, которые мы называем «Primary» (01-09), и 2-х web-серверов «Dev/meta» (10-11, среда нашей площадки). Серверы Primary управляют такими вещами, как Stack Overflow, Careers и всеми сайтами Stack Exchange, кроме сайтов meta.stackoverflow.com и meta.stackexchange.com, которые размещены на 2-х последних серверах. Основное приложение Q&A само по себе многопользовательское. Это означает, что одно приложение обслуживает запросы для всех Q&A сайтов. Скажем по-другому – мы можем управлять всей сетью Q&A одним пулом приложений на одном сервере. Другие приложения, такие как Careers, API v2, Mobile API и т.д. размещены отдельно. Вот так выглядят основной и dev-уровни в IIS:







Вот так выглядит распределение Stack Overflow по уровню веб-узлов, напоминая Opserver (наша внутренняя dashboard):



image



… а вот так выглядят web-серверы с точки зрения нагрузки:



image



В следующих постах я коснусь того, почему мы так «сверхоснащены», но самыми важными моментами являются: кольцевое построение (rolling builds), операционный резерв и избыточность.



Сервисное звено (IIS, ASP.Net MVC 5.2.3, .Net 4.6.1 и HTTP.SYS)



В основе этих web-серверов лежит очень похожее «сервисное звено». Оно также работает на IIS 8.5 под Windows 2012R2 и отвечает за внутренние службы, поддерживая вычислительный уровень веб-узлов и другие внутренние системы. Здесь два крупных «игрока»: «Stack Server», который управляет Tag Engine и основан на http.sys (не под IIS), и Providence API (работает на IIS). Забавный факт: я должен установить подобие на каждом из этих 2 процессов, прописываясь на разные сокеты, потому что Stack Server просто «пробивает» кэши L2 и L3, когда с интервалом в 2 минуты приходят обновленные опросные списки.



Эти сервисные «коробки» выполняют ответственную работу по поднятию Tag Engine и внутренних API, где нам нужна избыточность, но не 9-ти кратная. Например, загрузка из базы данных (в настоящее время 2-х) всех постов и их тэгов, которые изменяются каждую n-ную минуту, не очень «дешевая». Мы не хотим загружать все это 9 раз на уровень веб-узлов; достаточно 3 раза и это обеспечивает нам достаточную «безопасность». Кроме того, на уровне оборудования мы конфигурируем эти «коробки» по-разному, чтобы они были более оптимизированы под различные характеристики вычислительной нагрузки Tag Engine и гибкого индексирования (которое также здесь работает). Сам по себе «Tag Engine» является относительно сложной темой и ему будет посвящен отдельный пост. Основной момент: когда Вы заходите на /questions/tagged/java, вы нагружаете Tag Engine, чтобы определить соответствующие запросы. Он делает все наше сопоставление тэгов вне процесса поиска, поэтому новая навигация и все прочее используют эти сервисы для обработки данных.



Кэш и Pub/Sub (Redis)



Здесь мы используем Redis для нескольких вещей и они вряд ли будут сильно изменяться. Несмотря на выполнение примерно 160 миллиардов операций в месяц, в каждый момент загрузка центрального процессора менее 2%. Обычно намного ниже:



image



С Redis мы имеем систему кэшей L1/L2. «L1» – это кэш HTTP на web-серверах или каком-либо работающем приложении. «L2» снижает скорость Redis и делает оценки. Наши оценки сохраняются в формате Protobuf через protobuf-dot-net от Марка Грэвелла (Marc Gravell). Для клиента мы используем StackExchange.Redis – собственно разработанный и открытый источник. Когда один web-сервер получает «промах кэша» (cache miss) L1, либо L2, он берет оценку из источника (запрос к базе данных, вызов API и т.д.) и помещает результат и в местный кэш, и в Redis. Следующий сервер, нуждающийся в оценке, может получить «промах кэша» L1, но найдет оценку в L2/Redis, экономя на запросе к базе данных или вызове API.



Также у нас работает много Q&A сайтов, поэтому у каждого сайта есть свое собственное кэширование L1/L2: по ключевому префиксу в L1 и по ID базы данных в L2/Redis. Более подробно этот вопрос мы рассмотрим в следующих постах.



Вместе с 2-мя основными серверами Redis (мастер/ведомый), которые управляют всеми запросами к сайтам, у нас также есть система машинного обучения, работающая на 2-х более специализированных серверах (из-за памяти). Она используется для отображения рекомендованных запросов на домашней странице, улучшения выдачи и т.д. Эта платформа, называемая Providence, у нас обслуживается Кевином Монтроузом (Kevin Montrose).



Основные серверы Redis имеют по 256 ГБ RAM (используется около 90 ГБ), а в серверах Providence установлено по 384 ГБ RAM (используется около 125 ГБ).



Redis используется не только для работы с кэшем – он также имеет алгоритм «publish & subscriber» (публикация и подписка), работающий так, что один сервер может разослать сообщение, а все другие «подписчики» получат его – включая нижерасположенных клиентов на ведомых серверах Redis. Мы используем этот алгоритм для очистки кэша L1 на других серверах, когда один web-сервер делает удаление для сохранения согласованности. Но есть и другое важное применение: websockets.



Websocket’ы (NetGain)



Мы используем websocket’ы для отправки пользователям в реальном времени обновлений, таких как уведомления, подсчет голосов, новое навигационное исчисление, новые ответы и комментарии и т.п.



Сами сокет-серверы используют необработанные сокеты, выполняемые на уровне веб-узлов. Это — очень маленькое приложение на вершине нашей открытой библиотеки: StackExchange.NetGain. Во время пиковой нагрузки у нас одновременно открыто около 500,000 параллельных каналов websocket. Это — множество браузеров. Забавный факт: некоторые из этих страниц были открыты более 18 месяцев назад. Мы не знаем почему. Кто-то должен проверить, живы ли еще эти разработчики.



Вот так изменялось на этой неделе число одновременно открытых websocket:



image



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



Поиск (Elasticsearch)



Спойлер: это не то, от чего можно прийти в восторг.



Уровень веб-узлов выполняет солидную поисковую работу по сравнению с Elasticsearch 1.4, который использует очень тонкий высокоэффективный клиент StackExchange.Elastic. В отличие от большинства других средств, мы не планируем выкладывать его в открытый доступ просто потому, что он отражает только очень небольшое подмножество API, которые мы используем. Я убежден, что его выпуск «в свет» принесет больше вреда, чем пользы из-за путаницы среди разработчиков. Мы используем Elastic для поиска, вычисления связанных запросов и советов, как формировать вопрос.



Каждый кластер Elastic (по одному такому есть в каждом дата-центре) имеет 3 узла, а каждый сайт имеет свой собственный индекс. Careers имеет несколько дополнительных индексов. Это делает нашу систему немного нестандартной: наши 3 серверных кластера немного больше «накачаны» всеми этими хранилищами SSD, памятью в 192 ГБ и двойной сетью по 10 Гбит/с на каждый канал.



Те же самые прикладные домены (да, мы здесь тронуты на .Net Core …) в Stack Server, на котором установлен Tag Engine, также непрерывно индексируют элементы в Elasticsearch. Здесь мы применяем некоторые уловки, такие как ROWVERSION в SQL Server (источник данных), сравниваемый с документом «последней позиции» в Elastic. Так как он ведет себя как последовательность, мы можем просто использовать и индексировать любые элементы, которые изменились с момента последнего прохода.



Главной причиной того, что мы остановились на Elasticsearch вместо чего-то подобного полнотекстовому поиску SQL, является масштабируемость и лучшее распределение денег. SQL CPU достаточно дорогие, Elastic же дешевый и сегодня имеет намного лучшие характеристики. Почему не Solr? Мы хотим искать по всей сети (сразу много индексов), но это не поддерживалось Solr во время принятия решения. Причиной того, что мы еще не перешли на 2.x, является солидная доля «types», из-за которых нам надо будет все переиндексировать для обновления. У меня просто нет достаточно времени, чтобы когда-нибудь составить план и сделать необходимые для перехода изменения.



Базы данных (SQL-сервер)



Мы используем SQL Server как наш единственный источник достоверной информации. Все данные Elastic и Redis получают от SQL-сервера. У нас работают 2 кластера SQL-серверов под AlwaysOn Availability Groups. У каждого из этих кластеров есть один мастер (выполняющий почти всю нагрузку) и одна реплика в Нью-Йорке. Кроме этого, еще есть одна реплика в Колорадо (наш дата-центр с динамическим копированием). Все реплики асинхронные.



Первый кластер – набор серверов Dell R720xd, у каждого 384 ГБ RAM, 4 TB PCIe SSD и 2 x 12 ядер. На нем установлены Stack Overflow, Sites (имеет дурную славу, я объясню позже), PRIZM и базы данных Mobile.



Второй кластер – это набор серверов Dell R730xd, у каждого 768 ГБ RAM, 6 TB PCIe SSD и 2 x 8 ядер. На этом кластере стоит все остальное. Список «всего остального» включает Careers, Open ID, Chat, наш Exception log и некоторые Q&A сайты (например, Super User, Server Fault и т.д.).



Использование CPU на уровне баз данных – это то, чего мы предпочитаем иметь в минимальном количестве, но, фактически, в данный момент оно немного повысилось из-за некоторых проблем с кэшем, которые мы сейчас решаем. Сейчас NY-SQL02 и 04 назначены мастерами, 01 и 03 – репликами, которые мы сегодня перезагрузили после обновления SSD. Вот как выглядят прошедшие 24 часа:



image



Мы используем SQL довольно просто. Ведь просто – это быстро. Хотя некоторые запросы могут быть безумными, наше взаимодействие с SQL само по себе – просто классика. У нас есть одна «древняя» Linq2Sql, но все новые разработки используют Dapper – наш выложенный в открытый доступ Micro-ORM, использующий POCOs. Позвольте сказать по-другому: Stack Overflow имеет только 1 хранимую в базе данных процедуру, и я намереваюсь перевести тот последний кусок в код.



Библиотеки



Хорошо, позвольте нам переключиться на что-то, что может непосредственно помочь Вам. Некоторые из этих вещей я упомянул выше. Здесь я предоставлю список большинства открытых .Net-библиотек, которые мы поддерживаем для использования во всем мире. Мы выкладываем их в открытый доступ, поскольку они не имеют никакой ключевой ценности для бизнеса, но могут помочь миру разработчиков. Я надеюсь, что Вы их сочтете полезными:




  • Dapper (.Net Core) — высокопроизводительный Micro-ORM для ADO.Net;

  • StackExchange.Redis – высокопроизводительный клиент Redis;

  • MiniProfiler – малообъемный профайлер, который мы используем на каждой странице (поддерживает только Ruby, Go и Node);

  • Exceptional – регистратор ошибок для SQL, JSON, MySQL, и т.п;

  • Jil — высокопроизводительный (де) сериализатор JSON ;

  • Sigil – помощник генерации .Net CIL (когда C# не достаточно быстрый);

  • NetGain — высокопроизводительный сервер websocket ;

  • Opserver — контрольная приборная панель, опрашивающая напрямую большинство систем и также получающая данные от Orion, Bosun или WMI;

  • Bosun – система мониторинга серверных СУБД, написанная на Go.



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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/278391/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<администрирование - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda