Речь пойдет о файлах primary.key, masks.key и header.key, которые лежат в директории ххххх.000 на флешке. Данные файлы входят в состав криптоконтейнера закрытого ключа электронной подписи криптопровайдера КриптоПро, формат которого нигде не опубликован. Целью данной статьи является чтение контейнера и преобразование закрытого ключа в формат, который может быть прочитан в библиотеке OpenSSL. Долгое время было распространено ошибочное суждение, что достаточно сделать нечто вида (primary_key XOR masks_key) и мы получим закрытый ключ в чистом (raw) виде, однако забегая вперед, можно утверждать, что в КриптоПро было применено более сложное преобразование, в худшем случае состоящее из более чем 2000 (двух тысяч) операций хеширования.

Стоит упомянуть о существовании утилиты P12FromGostCSP которая позволяет конвертировать ключ в формат P12, доступный для работы с OpenSSL, но утилита имеет следующие существенные недостатки:

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

Файл primary.key

Содержит 32 байта ключа в формате Asn1. Это только половина ключа, полный ключ получается при делении этого числа по модулю Q на маску. Поле, хранящее модуль Q в библиотеке OpenSSL имеет название order. Маска лежит в файле masks.key:

Содержимое: как сделать так, чтобы компьютер отвечал в интернете на все свои IP-адреса по всем своим интерфейсам, каждый из которых имеет шлюз по умолчанию. Касается и серверов, и десктопов.

Ключевые слова: policy routing, source based routing

Лирика: Есть достаточно статей про policy routing в Linux. Но они чаще всего разбирают общие, более тонкие и сложные случаи. Я же разберу тривиальный сценарий следующего вида:



Нашему компьютеру (серверу) доступно три интерфейса. На каждом интерфейсе шлюз ему выдал IP (статикой или по dhcp, не важно) и сказал «весь трафик шли мне».

Если мы оставим эту конфигурацию как есть, то будет использоваться принцип «кто последний встал, того и дефолтный шлюз». На картинке выше, если последним поднимется нижний интерфейс (241), то в него будет отправляться весь трафик. Если к нашему серверу придёт запрос на первый интерфейс (188), то ответ на него всё равно пойдёт по нижнему. Если у маршрутизатора/провайдера есть хотя бы минимальная защита от подделки адресов, то ответ просто дропнут, как невалидный (с точки зрения 241.241.241.1 ему прислали из сети 241.241.241.0/24 пакет с src 188.188.188.188, чего, очевидно, быть не должно).

Другими словами, в обычном варианте будет работать только один интерфейс. Чтобы сделать ситуацию хуже, если адреса получены по dhcp, то обновление аренды на других интерфейсах может перезаписать шлюз по умолчанию, что означает, что тот интерфейс, который работал, работать перестанет, а начнёт работать другой интерфейс. Удачной стабильной работы вашему серверу, так сказать.

Решение

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

Первым делом открыл Resource Monitor и взглянул на общую нагрузку. Процесс sqlserv.exe нагружал ЦП под 100% и формировал большую дисковую очередь, которая была за 300… при том, что значение выше единицы уже считается проблемным.

При анализе дисковой активности заметил непрерывные IO операции в msdb:

D:\SQL_2012\SYSTEM\MSDBData.mdf
D:\SQL_2012\SYSTEM\MSDBLog.ldf

Посмотрел на размер msdb:

SELECT name, size = size * 8. / 1024, space_used = FILEPROPERTY(name, 'SpaceUsed') * 8. / 1024
FROM sys.database_files

и включил режим «рука-лицо»:

name         size           space_used
------------ -------------- ---------------
MSDBData     42626.000000   42410.374395
MSDBLog      459.125000     6.859375

Файл данных занимал 42 Гб… Взяв небольшую паузу я начал разбираться в чем причина такого нездорового объема msdb и как побороть проблемы с производительностью сервера.

Недавно я прошел курс RedHat Rapid Track Course with Exam (RH200) и успешно сдал сертификацию RedHat Certified System Administrator (RHCSA). Это начальная сертификация в линейке сертификаций RedHat, и я решил, что рассказ о подготовке и сдаче этого экзамена будет полезен Хабрасообществу (подробных рассказов об этом на Хабре я не нашел). Сразу оговорюсь, что перед началом экзамена подписываешь документ, который запрещает разглашать информацию о том, что было на экзамене, однако не запрещено рассказывать, что было на официальном курсе подготовки к этому экзамену, что я и сделаю.

Оставлю за рамками вопрос, зачем получать эту сертификацию, лично я сдавал потому что

• мой работодатель предоставил мне такую возможность,
• при мониторинге вакансий по своей специальности я часто встречаю пометку, что официальная сертификация будет преимуществом,
• ну и для собственного ЧСВ конечно.

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

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

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

Всем привет! Сегодня хотел бы поговорить о стандартных ошибках, которые мы совершаем при настройке сетевого оборудования. Думаю, всем знакомо чувство, когда ты вводишь очередную команду в консоль и вдруг понимаешь, что консоль прекратила откликаться, а оборудование на другой стороне Земли (которое ты как раз и настраивал) больше не пингуется. В этот момент на секунду замирает дыхание, ты начинаешь отчётливо слышать биение своего сердца. Обострённый слух полностью сосредотачивается на телефонном вызове, который вот-вот раздастся. Организм съеживается и ты понимаешь, что это конец. Перебор, конечно же, не конец, а начало героического преодоления той ситуации, в которую ты себя только что загнал. А дальше будет подвиг, рассказ о твоём подвиге и, возможно, даже овации со стороны коллег. И самое главное, ты в очередной раз дашь себе зарок, что больше НИКОГДА так не будешь делать. Многие мне возразят, что это не про них и что они, настоящие профессионалы, такого не допускают. Это прекрасно, и я искренне рад за них. Но настоящими профессионалами не рождаются и не становятся в одночасье.

Недавно в моей жизни закончился период поиска новой работы. На одном из собеседований этого периода я узнал, что в мире появилась новая СУБД, разработчики которой обещают вот-вот затмить собой Oracle всемогущий. Заманчивое обещание тут же породило у меня желание попробовать это чудо заморской техники. Речь шла о корейской СУБД Tibero.

Загрузочная флешка с набором нужного софта — замечательный инструмент системного администратора. Казалось бы, что может быть лучше? А лучше может быть загрузочный сервер!

Представьте, вы выбрали в BIOS загрузку по сети и можете установить ОС/вылечить компьютер от вирусов/реанимировать диски/протестировать ОЗУ/etc с PXE Boot сервера, ведь это куда удобнее, нежели бегать с флешкой от машины к машине.
А в случае большого компьютерного парка, такой инструмент и вовсе незаменим.

Вот такое меню встречает нашу команду инженеров при загрузке с PXE



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

Демон инициализации systemd де-факто уже стал стандартом в современных Linux-системах. На него перешли многие популярные дистрибутивы: Debian, RHEL/CentOS, Ubuntu (начиная с версии 15.04). В systemd используется принципиально иной (по сравнению с традиционным инструментом syslog) подход к логгированию.
В его основе лежит централизация: специализированный компонент journal cобирает все системные сообщения (сообщения ядра, различных служб и приложений). При этом специально настраивать отправку логов не нужно: приложения могут просто писать в stdout и stderr, a journal сохранит эти сообщения автоматически. Работа в таком режиме возможна и с Upstart, но он сохраняет все логи в отдельный файл, тогда как systemd сохраняет их в бинарной базе, что существенно упрощает  систематизацию и поиск.

Хранение логов в бинарных файлах также позволяет избежать сложностей с использованием парсеров для разных видов логов. При необходимости логи можно без проблем переконвертировать в другие форматы (более подробно об этом будет рассказано ниже).
Journal может работать как совместно с syslog, так и полностью заменить его.
Для просмотра логов используется утилита journalctl. Об особенностях и тонкостях работы с ней мы расскажем в этой статье.

Возникла задача пометить на удаление документы за 1 год. Эта операция выполняется перед бесследным удалением и включает выставление отметки и удаление движения по регистрам. Пробное удаление штатными средствами одного месяца заняло 4 часа. Это означало, что 12 месяцев удалялись бы 48 часов (2 суток). Забегая вперед, скажу, что прямым доступом к 1С документы удаляются за 30-40 минут. Обращение к MSSQL выполнялось через .Net framework и компонент .Net Bridge.

Определение имен таблиц MSSQL

Структура базы данных 1С весьма запутана и состоит из малозначимых для человека названий. 1С содержит функцию определения структуры хранения по имени объекта. В основу разработки положена эта функция ПолучитьСтруктуруХраненияБазыДанных, которая согласно русскому названию возвращает описание структуры. В этой структуре важны 2 поля Назначение, которое должно быть равно «Основная», и название таблицы ИмяТаблицыХранения.

Недавно вспомнилось мне, что есть такой сервис — StartSsl, который совершенно бесплатно раздаёт trusted сертификаты владельцам доменов для личного использования. Да и выходные попались свободные. В общем сейчас напишу, как в nginx настроить HTTPS, чтобы при проверке в SSL Labs получить рейтинг А+ и обезопасить себя от последних багов с помощью выпиливания SSL.

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

На сегодняшний день, далеко не каждый доволен используемой системой мониторинга ИТ инфраструктуры, а у некоторых она попросту отсутствует. Многие из них имеют явные проблемы с удобством использования, сложностью конфигурации и невысокой производительностью. Именно поэтому, предлагаю взглянуть на новый форк Nagios — Icinga 2, который готов порадовать нас модульной архитектурой, удобным web-интерфейсом, генерацией отчетов и превосходной скоростью работы!

Однажды возникла необходимость в подчинённом, в рамках имеющейся инфраструктуры центре сертификации для 'выездного' использования — создания временных технологических сертификатов во время различных разъездов. Необходимо было сделать его мобильным и разумно, для данных целей, защищённым. Приемлемым был признан вариант с загрузочной флешкой с каким-нибудь *nix + openssl и типовым сценарием использования — имеющийся под рукой компьютер перезагружаем, вставляем флешку, загружаемся с неё, работаем, вытаскиваем флешку, перезагружаем компьютер. Секретные ключи данного ЦС, его файлы конфигурации, ключевые файлы для двухфакторной аутентификации могут быть вынесены на отдельные носители.

Начался выбора дистрибутива *nix. Требования были следующие:

• дистрибутив должен быть поддерживаемым в актуальном состоянии, в том числе и OpenSSL
• наличие i386 версии. Гигабайты памяти нам не понадобятся, а вот возможность запуска на нетбуке с x86 Intel Atom будет полезна
• запуск системы из оперативной памяти, либо корректный запуск и работа с r/o разделов. В идеале, корректная работа с флешки при включенной защите от записи (при использовании Qumo серии Yin & Yan)
• возможность компактной инсталляции
• желателен достаточно большой срок поддержки релиза

В результате в финал вышли два дистрибутива — Alpine Linux и OpenBSD. Всё бы хорошо, и не было бы смысла писать эту статью, как ВНЕЗАПНО уточнились требования к операционной системе — потребовалась полная поддержка русского текста в Unicode в системной консоли. На ввод и на вывод.

Ну всё, приплыли. Оба финалиста выбыли из соревнования. Alpine Linux в силу используемой в нём компактной библиотеки C, а OpenBSD… ну, у неё другие сильные стороны. Однако это требование позволило иначе взглянуть на доступные дистрибутивы, и в фаворитах неожиданно оказалась FreeBSD. Консольный драйвер vt (ранее известный как newcons) поддерживает Unicode «из коробки», русские шрифты идут в комплекте, вышеописанные критерии в сумме исполняются достаточно полно. Бонусом можно реализовать возможность оффлайнового бинарного обновления системы на флешке.

Началось изучение возможности компактной инсталляции стандартными способами. Готовые наборы — tinybsd, nanobsd, picobsd произвели впечатление «старый, древний, ещё древнее». Одни только расчёты секторов, головок, цилиндров для разных типов флешек в picobsd… Прям времена MFM, RLL, ST-506…

Творения отдельных энтузиастов, различные miniBSD, easyBSD, mfsBSD выглядели поинтереснее, но в итоге всё равно было решено поиграть в доброго доктора Франкенштейна.

В данном примере мы сделаем загрузочную флешку с:

• компактной инсталляцией FreeBSD 10.1
• русифицированной системной консолью в Unicode
• корневым разделом, монтирующимся в памяти
• разделом для скриптов и файлов конфигурации нашего ЦС
• шифрованным разделом для секретных ключей ЦС
• FAT разделом для обмена с внешними системами запросами на сертификат и подписанными сертификатами
• возможностью оффлайнового обновления системы
• возможностью выбора ядра при загрузке (минимальное + GENERIC)
• возможностью выбора образа системы при загрузке (эталонный + обновлённый до последней версии FreeBSD)

Давайте сразу начистоту: никто не любит платить за софт много. И для некоторых «много» — это всё, что больше цены ежедневного обеда. Даже когда речь идёт о профессиональном ПО для профессионалов, если на горизонте возникает чуть менее платный конкурент с меньшим количеством функций, он сразу же привлекает к себе множество внимания, а в головах изумлённой публики возникает вопрос: «А может, в признанном лидере рынка действительно уже перебор этих самых функций, и платить за них нет никакой причины?». В качестве ответа, некоторые производители начинают искать новые, относительное честные методы отъёма денег у населения, и вводят подписочные сервисы, которые в первом приближении, позволяют платить за софт намного меньше.

Другой подход к проблеме — чёткое понимание, какой функционал нужен на уровне домашнего и/или лабораторного использования, а какой на уровне больших корпораций. И после того как дзен постигнут, весь “домашний” функционал становится бесплатным, а за остальное просят денежку.

Сегодня предлагаю вам рассмотреть именно вторую модель, выяснив, что же компания Veeam предлагает своим пользователям на безвозмездной основе и так ли этого мало для ежедневного личного использования. Пусть даже если из-под “личного” проглядывает небольшая купи-продай контора, или простихосподи, стартап, который считает, что «кровавый вендор» хочет слишком много денег за свои продукты.
Если сомневаетесь, что они дают действительно мощные инструменты, не прося ничего взамен и что вообще так бывает — добро пожаловать под кат.

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Что делать если вашего роутера не оказалось в списке поддерживаемых устройств OpenWRT? Конечно же сделать свой порт. Это можно сделать довольно быстро, если поддержка данной платформы уже реализована.
В этой статье я расскажу о процессе портирования прошивки в целом и о моем опыте портирования OpenWRT на ASUS DSL N12U.

Всем привет!

Продолжаем публиковать шпаргалки по настройке аудита различных систем, в прошлый раз мы говорили об AD habrahabr.ru/company/netwrix/blog/140569, сегодня обсудим файловые серверы. Надо сказать, что чаще всего мы выполняем именно настройки аудита файловых серверов – в ходе пилотных инсталляций у заказчиков. Ничего сложного в этой задаче нет, всего лишь три простых шага:

• Настроить аудит на файловых ресурсах (file shares)
• Настроить и применить общую и детальную политики аудита
• Изменить настройки журналов событий

Если у вас большое количество файловых шар, доступ к которым часто требуется сотрудникам – рекомендуем контролировать только изменения объектов аудита. Отслеживание всех событий может привести к тому, что в журналы будет попадать большой объем избыточных данных, которые не представляют особой важности.

Как известно, для обработки соединений NGINX использует асинхронный событийный подход. Вместо того, чтобы выделять на каждый запрос отдельный поток или процесс (как это делают серверы с традиционной архитектурой), NGINX мультиплексирует обработку множества соединений и запросов в одном рабочем процессе. Для этого применяются сокеты в неблокирующем режиме и такие эффективные методы работы с событиями, как epoll и kqueue.

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

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

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

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

Добрый день.

В завершение «недели NGINX», мы решили рассказать об очень интересной сборке «безопасной» версии NGINX китайской компании Neusoft, о которой не было замечено ни одной статьи на Хабре, а именно — SeNginx. В дополнение к этому, мы также расскажем вам о втором веб сервере, которому не уделяется так много внимания, как Nginx — Hiawatha Web Server, и постараемся сравнить Hiawatha с SeNginx в плане использования их для обеспечения безопасности вашего сайта или web приложения.



Отметим, что за 5 лет существования нашей хостинговой компании нам довелось повидать целый спектр атак различных уровней и типов на сайты и web приложения наших клиентов, а также поработать с London Metropolitan Police в поиске и поимке одного управляющего ботнетом. Сегодня DDoS атаки стали настолько частыми, что только за вчерашний день Arbor в одном из наших датацентров зафиксировал 49 DDoS атак 3/4 уровней мощностью до 20-25 Gbit/s (график 1 и график 2). И, хотя Arbor девайсы и могут при определенной настройке неплохо справляться с атаками 3 и 4 уровня, они практически бесполезны при атаках 7 уровня, целью которых является перегрузка ресурсов сервера, а также поиск уязвимостей в вашем приложении.

Самым бюджетным вариантом отражения атак 7 уровня являются различные варианты с использованием DNS RoundRobin + HaProxy, Nginx, Varnish Cache и т.д., которые либо позволяют рассредоточить атаку между несколькими серверами клиента, либо дают возможность обработать запросы ботов «в лоб» с помощью отдачи кешированной версии страницы. Данный подход, к сожалению, часто требует ручной настройки, постоянного мониторинга и редко эффективен при меняющихся типах атак.

Наглядное представление DNS RoundRobin + Nginx (источник):



После длительных поисков нами был найден отличный модуль к NGINX, написанный русскими программистами на Perl в 2012 году и позволяющий фильтровать ботов, которые заходят на ваш сайт в автоматическом режиме — Roboo (статья на Хабре). Модуль показал себя с наилучшей стороны, позволяя фильтровать сотни тысяч запросов от ботов с помощью NGINX с минимальной нагрузкой на сервер.

Раз уж тут у нас «неделя» nginx, например тут или тут, то попробую и я внести свою, так сказать, лепту. Речь пойдет про nginx 4 windows, а именно про более-менее официальную сборку для этой пропритарной, некоторыми не очень любимой платформы.

Почему Windows. Все просто, в корпоративном секторе Windows на сервере, да и на рабочих станциях — нередко обязательная программа. И от этих требований к платформе, например в ультимативной форме озвученных клиентом, никуда не денешься.
И раз уж имеем Windows, но не хочется мучиться с IIS, apache и иже с ними, если хочется использовать любимые инструменты, а nginx однозначно к ним относится, то приходится иногда мириться даже с некоторыми ограничениями на этой платформе. Вернее приходилось…

Хотя нужно заметить, что даже с этими ограничениями, nginx даст фору практически любому веб-серверу под windows по многим факторам, в том числе по стабильности, потреблению памяти, а главное производительности.

Спешу сразу поделится хорошей новостью — больше ограничений, критичных к высокой производительности, при использовании nginx под windows практически не существует, и последнее из критичных, с высокой долей вероятности, тоже скоро отпадет. Но по порядку…

Здесь описаны известные проблемы nginx 4 windows, а именно:

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

Я немного изменил порядок, т.к. именно в такой последовательности я разбирался с этими ограничениями, так сказать отсортировано «исторически».