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


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

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

Следующие 30  »
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)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Правила жизни сисадмина

Вторник, 01 Марта 2016 г. 13:43 (ссылка)

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







Так как мы являемся хостинг-компанией, то хотелось бы обратить свое внимание на ошибки связанные именно с этой сферой услуг. И как же, если не инженерам дата-центра — тем людям, которые поддерживают работу оборудования в режиме нон-стоп, не знать все изъяны своих рабочих моментов. Давайте попробуем вместе с Вами разобрать возможные варианты просчетов в нелегкой работе системного администратора. Ведь это поможет поднять уровень поддержки, и тем самым не наступать нам с Вами на те же самые грабли.



Думаю многие администраторы согласятся с тем, что иногда не так то и просто произвести нужную настройку сервера, а также довольно сложно осуществлять необходимую техническую поддержку оборудования в режиме 24/7. Представление того, как именно работают системные команды, наличие знаний для того, что бы «пофиксить» что-то, когда происходит поломка / сбой, или как контролировать производительность оборудования, а также корректно настроить резервное копирование, или как создать умный скрипт, который будет корректно работать — все эти умения и не только делают Вас хорошим системным администратором. Знание этих вещей и соблюдение основных правил поможет Вам поддерживать работу системы, а также сделает Ваших пользователей немножко счастливее.



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



Точка возврата







Не забывайте проверить, готовы ли Вы отменить действия, которые собираетесь сделать в данный момент? Даже для самых простых изменений Вы должны предусмотреть возможность вернуться к исходному варианту. Есть много способов, чтобы оставлять путь к отступлению и в случае необходимости возвращаться к исходной точке. Сделайте резервные копии файлов, которые Вы собираетесь редактировать. Обращайте внимание на любые проблемы с которыми столкнетесь в процессе работы. Обязательно проверяйте изменения на тестовом варианте и только после этого выпускайте их в мир.



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



Конец недели — не время для нововведений







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



Докопайтесь до истины







Всегда ставьте себе за цель детально разобраться в ситуации и определить истинную причину проблемы. Не стоит торопиться с выводами — проверяйте все последовательно и не спеша. Даже тогда, когда установить «диагноз» сразу не получилось — не опускайте руки и не вздумайте останавливаться, а продолжайте анализировать проблему. Если нужно — обратитесь за помощью к коллегам или тем специалистам, которые помогут найти в чем же все-таки проблема. И помните, тот кто ищет — всегда находит!



Аварийное восстановление







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



Разве плохо быть подготовленным к возможным вариантам перебоев в работе? Вы ведь можете стать настоящим супергероем в глазах своих же клиентов, если будет реанимировать работу их проекта или оборудования в два щелчка, без каких-либо танцев с бубном. Да, кто-то может сказать, что это приходит с опытом. Но разве у нас с Вами есть несколько свободных лет? Клиенты хостинга, как правило, не могут ждать даже час, а о годах там и не может быть речи. Потому советуем просчитать возможные варианты восстановления наперед и тем самым уберечь несколько своих нервных клеток от иногда «сердитых» и… еще раз очень «сердитых» клиентов.



Без тестирования никуда







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



Автоматизация







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



Документирование







Документируйте все то, что делаете регулярно. Ведь Ваши действия, могут быть не очевидными для остальных. Всегда помните о том, что Ваши коллеги не телепаты, и не умеют читать мысли друг друга. Если вопрос по запросу клиента не получилось решить во время Вашей смены, то найдите пожалуйста время оставить простые и понятные заметки к данному тикету, что бы у Ваших коллег не возникло никаких дополнительных вопросов, и они все сделала правильно. Да ведь можно позвонить и уточнить, — скажите Вы. И в некоторых непростых ситуациях скорей всего будете правы. Но ведь никто не станет отрицать, что несколько слов в «нотсах» к тикету могут уберечь Вас от ненужного звонка, когда Вы, например, решили это свободное время посвятить любимому человеку. Разве она или он будут рады, что в свой выходной день, который должен был быть только Ваш Вы еще отвлекаетесь и на работу? Подумайте об этом, до того как будете уходить со смены.



Также не забывайте добавлять комментарии к своим скриптам. Ведь тот скрипт, который Вы регулярно используете сейчас, после годика… второго «простоя» может стать таким загадочным даже для своего автора. И пожалуй, при этом не стоит жертвовать читаемостью ради краткости, так как возможно кому-то еще кроме Вас придется работать с данным кодом. Не используйте сокращения, которые понимаете только Вы. Заметки должны быть понятными даже Вашей бабушке :) Не стоит играть в одинокого бойца невидимого фронта, если Вы работаете в коллективе. Да, системные администраторы, как правило, по своей натуре «одиночки», но ведь умение работать в команде — очень важное качество для работы в современной компании, помните об этом.



Обращайте внимание на себя







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



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



Параноики еще в моде?!







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



Как правило пару минут времени сейчас помогут сохранить Вам целую вечность в будущем. Если, не дай Бог, сервер «упадет» и собственники проекта начнут терять, как они любят говорить — «миллионы», то как Вы думаете, чьи головы могут «полететь»? Да, рано или поздно серверы падают, но реально грамотный сисадмин просчитает не только возможные варианты ошибок со своей стороны, но и продумает всевозможные ошибки тех «умных» ребятах в дата-центре (хостинг провайдера), которые — тоже люди и могут банально ошибаться.



Иногда клиенты даже и не догадываются сколько усилий стоит вовремя «пнуть» инженера ЦОДа или верно «направить» его туда, куда нужно, чтобы обеспечить высокий аптайм работы оборудования. Да, зачастую администраторы «спасают мир» незаметно для обычных пользователей, но мы ведь и не претендуем на лавры «великих», а просто делаем свою работу. Делайте ее качественно, и плевать, если кто-то считает Вас параноиком, если при этом Вы будете настоящим гуру своего дела.



Инициативность







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



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



Безопасность







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



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



Лог файлы







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



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



Резервное копирование







Бэкапить нужно все и всегда. Бытует такое мнение, что системные администраторы, и не только они, делятся на 3 категории: тех, кто еще не делает бэкапы, тех, кто уже делает бэкапы и тех, кто уже делает и проверяет возможность восстановления.



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



Время бесценно для всех







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



Да, они могут не знать, что такое командная строка, могут вообще не представлять как правильно подключиться по FTP и в очередной раз об этом спрашивать. Но не спешите отправлять их в / за…(вставьте свой вариант), а постарайтесь повторно объясните тоже самое, но уже другими словами или дайте ссылку на информацию, где в доступной форме это описано. И неважно, что Вы уже предоставляли «вагон» ссылок — дайте ту, которая поможет клиенту понять. Будьте терпеливы и спокойны. Также запомните, тот клиент которого понимают здесь — никогда не уйдет от Вас, даже туда, где будет немного дешевле.



Информирование







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



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



Простота — залог успеха







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



Век живи — век учись







Движение — это не только жизнь, но и развитие. Если Вы не двигаетесь вперед, то Вы не просто стоите, а медленно «возвращаетесь» назад… в прошлое. Да, мы с Вами можем быть старомодными, а некоторым олдскул даже нравится. Но пожалуйста, не делайте такого в отношении технологий. Никогда не останавливайтесь в поиске и изучении новых решений. Всегда будьте в тренде, особенно в тех вопросах, которые напрямую касаются Вашей работы.



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



Баланс во всем







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



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







Как-то один из лауреат Нобелевской премии сказал: «Не ошибается лишь тот, кто ничего не делает! Не бойтесь ошибиться — бойтесь повторять ошибки!» Помните об этом и у Вас все получиться.



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

https://habrahabr.ru/post/278235/

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

Как установить Ubuntu без помех для работы

Понедельник, 28 Декабря 2015 г. 22:25 (ссылка)

Ubuntu представляет собой простую и удобную операционную систему с открытыми исходными кодами, основанную на ядре Linux. Она содержит массу полезных программ для работы с Интернетом, документами, презентациями, графической информацией; позволяет осуществлять администрирование...Далее

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

Серверное администрирование. Управление ресурсами средствами PowerShell

Вторник, 02 Декабря 2015 г. 01:07 (ссылка)


Доброго времени суток.



Сегодня нашему администратору потребовалось отслеживать на сетевых ресурсах, сколько Гб использовали сотрудники в своих личных каталогах (дисковое пространство выделено путем подключения сетевого диска). Предполагаем, что предельно допустимый размер личного ресурса равен 1 Гб. В случае если этот размер превышает предел, необходимо сообщить администратору. Также необходимо контролировать резкое увеличение размеров личных ресурсов. Например, если личный каталог сотрудника увеличивается в размере на 200 Мб за неделю, то необходимо оповестить администратора.



Итак, код Powershell’a, который реализовал все вышеуказанные требования:



Функция отправки почты. Функция не унивирсальная, подстроена под задачу. Т.е. принимаем за факт, что тема сообщения, получатель не меняются. Меняется только тело, его то мы и задаем как входящий параметр для функции:



function EmailNotification($Mail_body)
{
$Sender = "audit@..."
$Receipt = "levitskaks@gmail.com"
$Server = "gmail.com.ua"
$Object = "DirSize: " + (Get-Date)
$SMTPclient = new-object System.Net.Mail.SmtpClient $Server
#Specify SMTP port if needed
$SMTPClient.port = 25
#Activate SSL if needed
#$SMTPclient.EnableSsl = $true
#Specify email account credentials if needed
$SMTPAuthUsername = "levitskaks@gmail.com"
$SMTPAuthPassword = "pass"
$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($SMTPAuthUsername, $SMTPAuthPassword)
$Message = new-object System.Net.Mail.MailMessage $Sender, $Receipt, $Object, $Mail_body
#-$Message.IsBodyHtml = $true;
$SMTPclient.Send($Message)
}




Переходим к основной функции. Входящие параметры:

— исходный каталог. Каталог в котором перечень каталогов под каждого сотрудника;

— предельно-допустимый размер в байтах;

— путь для сохранения лога работы;



function Check-Size-Directory ($dir, $GB, $Logpath) {




Определяем день недели в году. На момент написания скрипта была 47 неделя.

Также нас интересует выполнение проверки — раз в неделю в понедельник. Логика проверки следующая: в четную неделю сохраняется лог работы «0.log». В нечетную неделю сохраняем файл «1.log». Если дата изменения «0.log» больше даты изменения «1.log», то по логически определяем, что последняя неделя была четная. и сверяем в каком каталоге размер увеличился более чем на 200 Мб.



[Int32]$Monday = (Get-Date -UFormat "%w")
$Monday
[Int32]$Week = (Get-Date -UFormat "%W")
$Week
if ($week%2 -eq 0 -and $Monday -eq 1){

$LogPathFile = $LogPath + "\" + ($week%2).ToString() + ".log"
If (!(Test-Path -path $LogPathFile)){
Write-Host "Создали элемент"
New-Item -Path $LogPathFile -ItemType File
}
$ToFile = "" | Out-File $LogPathFile
Write-Host "Четная неделя"
Get-ChildItem -path $dir | %{
$dir_property = dir $_.FullName -recurse | where {-Not $_.PSIsContainer}| Measure-Object -Property length -Sum




Первая требуемая проверка: проверяем каталог на размер больше, чем 1 Гб.



 if ($dir_property.Sum -gt $GB){
$Mail_body+= "Размер каталога " + $_.FullName + " превышает размер в 1 Гб.`n"
$Mail_body+= "Размер каталога " + $_.FullName + " составляет " + (($dir_property.Sum)/1024/1024) + " Мб.`n"
$Mail_body+= "------------------------------------------------------------------------------------------`n"
$ToFile = $_.DirectoryName + " " + (($dir_property.Sum)/1024/1024) | Out-File $LogPathFile -Append
}
else {
Write-Host "Все хорошо с каталогом: " $_.FullName
}
}
EmailNotification -Mail_body $Mail_body




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



$ToFile = $_.DirectoryName + " " + (($dir_property.Sum)/1024/1024) | Out-File $LogPathFile  -Append




Определяем какой файл считаем новым, чтобы проводить сравнение с файлом недельной давности.



$Mail_body = ""
If ((Get-Item -Path $LogPath\0.log).LastWriteTime -gt (Get-Item -Path $LogPath\1.log).LastWriteTime){
$log_content = Get-Content (Get-ChildItem -Path $LogPath\0.log)
foreach ($data in $log_content)
{
$x = $data.split("|")
$xc1 = $x[0]
$xc2 = $x[1]
$log_content = Get-Content (Get-ChildItem -Path $LogPath\1.log)
foreach ($data in $log_content)
{
$y = $data.split("|")
if ($xc1 -eq $y[0]){
if(([Int32]$xc2 - [Int32]$y[1]) -gt 200){
$Mail_body += "Резкое увеличение размера каталога: " + $xc1 + "`n Размер на прошлой неделе составил: " + $y[1] + " Мб." + "`n Размер на текущей неделе составил: " + $xc2 + " Мб.`n"
}

}
}

}
EmailNotification -Mail_body $Mail_body
}
}




Проверка четности\нечетности недель проверяется делением по модулю полученной недели в году:



$week%2




Аналогичные проверки для нечетной недели:



    if ($week%2 -eq 1 -and $Monday -eq 1){
Write-Host "Нечетная неделя"
$LogPathFile = $LogPath + "\" + ($week%2).ToString() + ".log"
If (!(Test-Path -path $LogPathFile)){
Write-Host "Создали элемент"
New-Item -Path $LogPathFile -ItemType File
}
$ToFile = "" | Out-File $LogPathFile

Get-ChildItem -path $dir | %{
$dir_property = dir $_.FullName -recurse | where {-Not $_.PSIsContainer}| Measure-Object -Property length -Sum

if ($dir_property.Sum -gt $GB){
$Mail_body+= "Размер каталога " + $_.FullName + " превышает размер в 1 Гб.`n"
$Mail_body+= "Размер каталога " + $_.FullName + " составляет " + (($dir_property.Sum)/1024/1024) + " Мб.`n"
$Mail_body+= "------------------------------------------------------------------------------------------`n"
$ToFile = $_.Name + "|" + (($dir_property.Sum)/1024/1024) | Out-File $LogPathFile -Append
}
else {
Write-Host "Все хорошо с каталогом: " $_.FullName
}
}
EmailNotification -Mail_body $Mail_body
$Mail_body = ""
If ((Get-Item -Path $LogPath\1.log).LastWriteTime -gt (Get-Item -Path $LogPath\0.log).LastWriteTime){
$log_content = Get-Content (Get-ChildItem -Path $LogPath\1.log)
foreach ($data in $log_content)
{
$x = $data.split("|")
$xc1 = $x[0]
$xc2 = $x[1]
$log_content = Get-Content (Get-ChildItem -Path $LogPath\0.log)
foreach ($data in $log_content)
{
$y = $data.split("|")
if ($xc1 -eq $y[0]){
if(([Int32]$xc2 - [Int32]$y[1]) -gt 200){
$Mail_body += "Резкое увеличение размера каталога: " + $xc1 + "`n Размер на прошлой неделе составил: " + $y[1] + " Мб." + "`n Размер на текущей неделе составил: " + $xc2 + " Мб.`n"
$Mail_body
}

}
}

}
EmailNotification -Mail_body $Mail_body
}


}

}




Для запуска определяем входящие параметры и запускаем проверку.



#Провериь каталог: не привышает ли он размер в 1 Гб
$GB = 1073741824
$dir = "D:\Program Files"
Check-Size-Directory -dir $dir -GB 107374 -Logpath "D:"




Результат проверки сообщение на почту:



Тема: DirSize: 11/27/2015 11:32:05

Дата: 27 Nov 2015 11:32:05 +0200

От: sizefoldres@gmail.com

Кому: levitskaks@gmail.com



Размер каталога F:\Shared\PrivateData\BRU превышает размер в 1 Гб.

Размер каталога F:\Shared\PrivateData\BRU составляет 1239.06250095367 Мб.





Размер каталога F:\Shared\PrivateData\Danпревышает размер в 1 Гб.

Размер каталога F:\Shared\PrivateData\Dan составляет 1670.62088680267 Мб.





Размер каталога F:\Shared\PrivateData\DYA превышает размер в 1 Гб.

Размер каталога F:\Shared\PrivateData\DYA составляет 7456.12028884888 Мб.





Размер каталога F:\Shared\PrivateData\GLU превышает размер в 1 Гб.

Размер каталога F:\Shared\PrivateData\GLU составляет 2198.93785953522 Мб.







Содержимое файла 0.log:



ActiveX|2.8662109375
AvPinTool|0.5712890625
BDE|10.4070873260498
drivers|6.512216567993
Drv for SecureТoken 337|0.129350662231445
eclipse-standard-kepler-SR2-win32|545.861120223999
flash|122.166826248169
FTP_Drive|0.252327919006348
Install|431.435597419739
Jabber|55.9909982681274
LibreOffice_4_3_4|215.234375
Liga9|336.688585281372
Mail (address_book)|0.141551971435547
nkicntInit|0.166786193847656
powershell_3.0|14.0534420013428
PowerShell_4_0|46.8222227096558
single|630.298968315125
Total Commander|6.67717361450195
WinImage|1.12846660614014
zabbix|1.37527465820313
Документация|0.584843635559
CSPKeyUtil.exe|0.89208984375
jdk-8u65-windows-i586.exe|181.22908782959
jre-8u65-windows-i586.exe|47.8077087402344
LimeActiveXCrypt.cab|5.14455604553223
npp.6.7.4.Installer.exe|7.59689044952393
SkypeSetupFull_6.21.exe|34.3624038696289
winapcupsd-3.14.12.exe|5.84123229980469




Содержимое файла 1.log:



ActiveX|2.8662109375
AvPinTool|0.5712890625
BDE|10.4070873260498
drivers|276.512216567993
Drv for SecureТoken 337|0.129350662231445
eclipse-standard-kepler-SR2-win32|545.861120223999
flash|122.166826248169
FTP_Drive|0.252327919006348
Install|431.435597419739
Jabber|55.9909982681274
LibreOffice_4_3_4|215.234375
Liga9|336.688585281372
Mail (address_book)|0.141551971435547
nkicntInit|0.166786193847656
powershell_3.0|14.0534420013428
PowerShell_4_0|46.8222227096558
single|630.298968315125
Total Commander|6.67717361450195
WinImage|1.12846660614014
zabbix|1.37527465820313
Документация|205.584843635559
CSPKeyUtil.exe|0.89208984375
jdk-8u65-windows-i586.exe|181.22908782959
jre-8u65-windows-i586.exe|47.8077087402344
LimeActiveXCrypt.cab|5.14455604553223
npp.6.7.4.Installer.exe|7.59689044952393
SkypeSetupFull_6.21.exe|34.3624038696289
winapcupsd-3.14.12.exe|5.84123229980469




Результат сравнения двух файлов:



Резкое увеличение размера каталога: D:\Program Files\drivers

Размер на прошлой неделе составил: 6.512216567993Мб.

Размер на текущей неделе составил: 276.512216567993 Мб.



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



Спасибо за внимание.

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

http://habrahabr.ru/post/272107/

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

Следующие 30  »

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

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

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