Доброго времени суток, читатель!

22 апреля в GitLab выпустили релиз 12.10 и сообщили о том, что теперь CI-процесс может авторизовываться в Hashicorp's Vault через JSON Web Token (JWT), и для авторизации нет необходимости хранить токен для доступа к нужным policy в переменных окружения (или где-либо ещё).

Данная фича показалась нам полезной, поэтому предлагаем перевод соотвествующего туториала из официальной документации GitLab:

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

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

Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".

Ну ладно, про «полюбил» — это преувеличение. Скорее «смог сосуществовать с».

Как вы все знаете, с 16 апреля 2018 года Роскомнадзор крайне широкими мазками блокирует доступ к ресурсам в сети, добавляя в "Единый реестр доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено" (по тексту — просто реестр) по /10 иногда. В результате граждане Российской Федерации и бизнес страдают, потеряв доступ к необходимым им совершенно легальным ресурсам.

После того, как в комментариях к одной из статей на Хабре я сказал, что готов помочь пострадавшим с настройкой схемы обхода, ко мне обратились несколько человек с просьбой о такой помощи. Когда у них всё заработало, один из них порекомендовал описать методику в статье. Поразмыслив, решил нарушить свое молчание на сайте и попробовать в кои-то веки написать что-то промежуточное между проектом и постом в Facebook, т.е. хабрапост. Результат — перед вами.

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

Сейчас уже, наверное, больше половины серверов перебрались с http на https протокол. Зачем? Ну, это мол круто, секъюрно.

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

Почему решил написать

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

Я начал рыться в разных источниках, и оказалось, что в этой теме не так просто разобраться, и тут недостаточно просто прочитать пару статей на Хабре или Вики, при чем я нигде не встретил абсолютно исчерпывающего и понятного источника, чтобы сослаться и сказать — "Вот это Библия". Поэтому у меня это "немного разобраться" заняло кучу времени. Так вот, разобравшись, я решил поделиться этим, и написать статью для таких же новичков, как и я, или просто для людей, которым интересно зачем в строке URL иногда стоит https, а не http.

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

Шпаргалка по работе с пакетным менеджером Yum (Yellowdog Updater, Modified), который используется в популярных Linux дистрибутивах: RedHat, CentOS, Scientific Linux (и других). В целях экономии места вывод команд не представлен.

Оглавление

Команды
Опции Yum
Пакет Yum-Utils
Конфигурационные файлы
Плагины
Работа через прокси

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

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

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

Abstract: описание видов ребута, рассказ про sysrq, ipt_SYSRQ, ipmi, psu.

Как перезагрузить сервер? — Это вопрос, который обычно задают ну очень начинающим пользователям, которые путаются между halt, shutdown -r, reboot, init 6 и т.д.

Опытный администратор уточнит вопрос: «а что с сервером не так?» Разные виды отказов серверов требуют разных видов ребута — и неверно выбранный вариант приведёт к тяжелейшим последствиям, из которых визит в веб-морду IPMI/DRAC/iLO с целью «доперезагрузить» будет самым лёгким. Самым тяжёлым в моей личной практике была командировка эникейщика в соседний город. С целью «нажать ребут» на одиноко стоящем сервере.

В этой статье: что мешает серверу перезагрузиться и как ему помочь.

Начнём с теории ребута.

При выключении или перезагрузке сервера менеджер инициализации (в большинстве современных дистрибутивов — systemd, в эксцентричной Ubuntu 14.04 до сих пор upstart, в архаичном хламе — sysv-init) в определённом порядке посылает всем демонам команду «выключись». И большинство демонов (например, СУБД, вроде mysql) знают, как выключаться правильно. Например, закончить все транзакции, сохранить все несохранённые данные на диск и т.д. Для in-memory СУБД, наподобие redis, это и вовсе может быть критичным: не сохранил — потерял.

Старые системы иницализации ждали неограниченно долго каждый из инит-скриптов. Например, если «шутник» добавил вам в «stop» веточку «sleep 3600», то ваш сервер будет перезагружаться час с хвостиком. А если там цифра поболе, или просто программа, которая не хочет завершаться, то и ребут никогда не закончится.

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

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

Какие только не приходилось читать статьи про композитную метрику EIGRP. Как очень полезные, так и откровенно глупые. Давайте еще раз разберем, что к чему. Я постараюсь не жевать то, что уже было 10 раз пережевано, а указать на интересные, на мой взгляд, особенности и хитрости подсчета этой самой композитной метрики, в короткой статье. Вспомним кошмарную формулу:

Привет, Хабр! Упомянутая в заголовке тема всё ещё порождает множественные дискуссии и недопонимание между системными администраторами. В своей статье я постараюсь ответить на следующие вопросы:

1. Что такое SID и каких он бывает типов?
2. Когда наличие двух и более машин с одинаковыми Machine SID будет порождать проблемы? Или, другими словами, когда всё-таки (не)нужно менять Machine SID?
3. Что такое Sysprep и нужен ли Sysprep для клонирования/развёртывания?

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



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

Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).

В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.



Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…

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

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

Что такое TACACS+

Terminal Access Controller Access-Control System Plus (TACACS+) — специальный протокол от Cisco для AAA (authentication, authorization, and accounting). То есть это протокол для централизованного управления доступом – чаще всего доступом именно к Cisco, но можно прикрутить что-то еще.

Итак, обычно поднимается один-два сервера с TACACS+ сервисом на 49 порту протокола TCP, а на всех устройствах настраивают его использование. Таким образом, когда пользователь хочет аутентифицироваться на свитче, роутере или другом устройстве, устройство пересылает его аутентификационные данные на TACACS+ сервер, где их проверяют, и принимается решение о разрешении доступа, о чём и сообщается в ответных пакетах



Удобно, централизовано. Можно настроить различные привилегии для различных пользователей на различных устройствах. Есть логирование доступа и действий на серверной стороне. Можно прикрутить поверх другую централизацию доступа, типа AD или LDAP'а. Есть open source реализации сервера (Cisco когда-то официально выложила код).

Как скрыть от посторонних конфиденциальную информацию?
Самое простое – зашифровать.
В Интернет и Интранет-сетях шифрацией данных управляет протокол SSL/TLS.
Солдат спит, служба идет.
Однако иногда возникает необходимость выполнить обратное – расшифровать перехваченный трафик.
Это может потребоваться как для отладки работы приложений, так и для проверки подозрительной сетевой активности.
Или в целях изучения работы SSL/TLS (очевидные, вредоносные цели не обсуждаются).

Как и при каких условиях можно расшифровать дамп SSL/TLS трафика в Wireshark?
Попробуем разобраться.

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

Использование ssh socks прокси совместно с MSF Reverse TCP Payloads

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

Один из моих любимых случаев (как и многие другие) это работа с OpenSSH Socks прокси. Удаленный ssh прокси дает возможность различными способами переадресовывать трафик через ssh туннель. Тем не менее существует главный недостаток в случае с socks прокси — вы «не можете» использовать сушествующие reverse tcp payloads, которые поставляются с Metasploit framework (и многими другими подобными инструментами). Однако, это не совсем так. Есть возможность для включения некоторых функций OpenSSH в целях обхода ограничений при использовании ssh перенаправления.

Многим из вас знаком Wireshark — анализатор трафика, который помогает понять работу сети, диагностировать проблемы, и вообще умеет кучу вещей.



Одна из проблем с тем, как работает Wireshark, заключается в невозможности легко проанализировать зашифрованный трафик, вроде TLS. Раньше вы могли указать Wireshark приватные ключи, если они у вас были, и расшифровывать трафик на лету, но это работало только в том случае, если использовался исключительно RSA. Эта функциональность сломалась из-за того, что люди начали продвигать совершенную прямую секретность (Perfect Forward Secrecy), и приватного ключа стало недостаточно, чтобы получить сессионный ключ, который используется для расшифровки данных. Вторая проблема заключается в том, что приватный ключ не должен или не может быть выгружен с клиента, сервера или HSM (Hardware Security Module), в котором находится. Из-за этого, мне приходилось прибегать к сомнительным ухищрениям с расшифровкой трафика через man-in-the-middle (например, через sslstrip).

Логгирование сессионных ключей спешит на помощь!

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

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

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

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

Со всеми сложностями, о которых идет речь выше, мы хорошо знакомы на собственном опыте: у нас имеется 10 точек присутствия с NS-серверами, расположенные в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное ПО, изменять конфигурцию и т.п. Мы решили все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями. Изучив имеющиеся решения, мы остановили свой выбор на Ansible.

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

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

Статей о взломе Wi-Fi в Интернете достаточно много, но большинство из них касаются режима работы WEP/WPA(2)-Personal, в котором необходимо перехватить процедуру «рукопожатия» клиента и Wi-Fi-точки. Во многих корпоративных Wi-Fi-сетях используется режим безопасности WPA2-Enterprise, с аутентификацией по логину и паролю — как наименее затратный способ. При этом аутентификация осуществляется с помощью RADIUS-сервера.



ОС клиента устанавливает соединение с RADIUS-сервером, используя шифрование при помощи TLS, а проверка подлинности в основном происходит при помощи протокола MS-CHAPv2.