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

Базы данных — это Святой Грааль для хакеров, поэтому их необходимо защищать с особой тщательностью. Это первая из серии статей, в которых мы дадим обзор best practice в обеспечении безопасности баз данных. Мы начнем с одной из самых популярных СУБД с открытым исходным кодом, PostgreSQL, и рассмотрим несколько уровней безопасности, о которых стоит задуматься:

Короткое резюме 10 постулатов по улучшению таблиц, опубликованных в Journal of Benefit Cost Analysis экономистом Jon Schwabish.

Проверьте свои финансовые и ежедневные отчеты - каждое ли из 10 правил Вы соблюдаете?

Куча (heap) — это не что иное, как двоичное дерево с некоторыми дополнительными правилами, которым оно должно следовать: во-первых, оно всегда должно иметь структуру кучи, где все уровни двоичного дерева заполняются слева направо, и, во-вторых, оно должно быть упорядочено в виде max-кучи или min-кучи. В качестве примера я буду использовать min-кучу.

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

Программы семейства GPG (GNU Privacy Guard) / PGP (Pretty Good Privacy) позволяют "прозрачно" подписывать и зашифровывать все типы цифровой информации. По своей сути, названные инструменты являются лишь удобной обёрткой, упрощающей практическое использование открытых алгоритмов асимметричной криптографии.

Рассмотрим приложение с открытым исходным кодом для работы с инструментарием GPG в графической оболочке — находка для новичков и тех, кто просто избегает загадочного черного окна командной строки. Благодаря кроссплатформенности Клеопатры, статья одинаково полезна для пользователей Windows, Linux и FreeBSD.

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

К счастью - эта проблема решена в современном мире разработки, если не полностью, то в большей мере. Нам на выручку пришел Docker.

Мы привыкли создавать некоторые элементы пользовательского интерфейса с помощью JavaScript, например аккордеоны, всплывающие подсказки (тултипы), усечение текста и т. д. Но, поскольку HTML и CSS постоянно получают новые функции, а старые браузеры больше не нужно поддерживать, мы можем использовать намного меньше JavaScript-кода для создания элементов пользовательского интерфейса и больше фокусироваться на логической части (проверки, обработка данных и т. д.). Специально к старту новых потоков по специализации Frontend-разработчик и Веб-разработчик делимся с вами несколькими хитростями.

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

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

После того, как в прошлой статье Как мигрировать Zabbix с MySQL на PostgreSQL с минимальным downtime я успешно перенес Zabbix с MySQL на PostgreSQL, встала необходимость сделать следующий шаг — мигрировать БД на TimescaleDB, т.к. ради нее все и затевалось.

У читателя может возникнуть вопрос: зачем нужна эта статья, если есть простой и понятный мануал?
Но проблема, как и в прошлой статье, скрыта в downtime. В мануале ясно написано:

The migration of existing history and trend data may take a lot of time. Zabbix server and frontend must be down for the period of migration.

Введение

1. Файрвол PF в ОС FreeBSD
2. Фильтрация трафика PF <- Вы здесь
3. FreeBSD. Трансляции, тэги и якоря в PF
4. FreeBSD. Условная маршрутизация средствами PF
5. FreeBSD. Путь сетевого пакета внутри ядра

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

В этот раз попробуем различные варианты более продвинутой фильтрации:

• Макросы в различных местах конфигурационного файла.
• Списки — набор параметров. PF раскроет его в отдельные правила.
• Правила, ограничивающие количество подключений с одного IP, их частоту.
• Таблицы. Это список IP адресов с которыми может сравнивать правило. Возможные варианты динамического заполнения. И проверку состояния наших таблиц.

1. Файрвол PF в ОС FreeBSD
2. FreeBSD. Фильтрация трафика PF
3. FreeBSD. трансляции, тэги и якоря в PF
4. FreeBSD. Условная маршрутизация средствами PF <- Вы здесь
5. FreeBSD. Путь сетевого пакета внутри ядра

Введение

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

В этой статье разберем возможности PF и FreeBSD в части продвинутой маршрутизации. Policy Based Routing (PBR), Source Based Routing (SBR), условная маршрутизация, маршрутизация на основе политик, все эти понятия, по сути, равнозначны и описывают одну возможность. Выбирать маршруты, либо таблицы маршрутизации для трафика на основе правил фаервола.

Можно, к примеру, отправить разные локальные сети через разных провайдеров, либо устроить распределение трафика между ВПН каналами. Рассмотрим оба эти варианта.

Для уменьшения файлов конфигурации и большей наглядности, в этой статье правила фильтрации будут максимально упрощены.

1. Файрвол PF в ОС FreeBSD
2. FreeBSD. Фильтрация трафика PF
3. FreeBSD. Трансляции, тэги и якоря в PF <- Вы здесь
4. FreeBSD. Условная маршрутизация средствами PF
5. FreeBSD. Путь сетевого пакета внутри ядра

Введение

В прошлых статьях мы разобрали, что такое PF вообще, общие принципы построения правил. Узнали о таблицах и способах фильтрации трафика PF. И создали конфигурационные файлы, которые способны защитить сервер в Интернет. В этой статье попробуем разобраться с NAT трансляциями и тэгами (tags). Еще пройдемся по якорям (anchors), их иногда называют еще закладками.

Думаю, объяснять, что такое NAT трансляции в общем случае не стоит. PF поддерживает три вида трансляций.

Anchors — это отдельные наборы правил PF, которыми, подобно таблицам, можно управлять динамически.

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

Часть 1
Часть 2
Часть 3
Часть 4

Mount namespaces изолируют ресурсы файловых систем. Это по большей части включает всё, что имеет отношение к файлам в системе. Среди охватываемых ресурсов есть файл, содержащий список точек монтирования, которые видны процессу, и, как мы намекали во вступительном посте, изолирование может обеспечить такое поведение, что изменение списка (или любого другого файла) в пределах некоторого mount namespace инстанса M не будет влиять на этот список в другом инстансе (так что только процессы в M увидят изменения)

Часть 1
Часть 2
Часть 3
Часть 4

В завершающем посте этой серии мы рассмотрим Network namespaces. Как мы упоминали в вводном посте, network namespace изолирует ресурсы, связанные с сетью: процесс, работающий в отдельном network namespace, имеет собственные сетевые устройства, таблицы маршрутизации, правила фаервола и т.д. Мы можем непосредственно увидеть это на практике, рассмотрев наше текущее сетевое окружение.

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

Сегодня мы поговорим об одном из способов организации бизнес логики - сервисном слое (он же service layer), когда и зачем его нужно применять, а также какие проблемы архитектуры он поможет решить. Примеры реализации будут показаны с использованием архитектурного паттерна MVC и фреймворка Laravel.