Современный веб состоит из множества разных технологий, которые предоставляют самые разные возможности… но ещё и создают немалое количество угроз. Современные браузеры давно стали самыми сложными приложениями на компе, обогнав по сложности даже ядро ОС (в Firefox в несколько раз больше строк кода, чем в ядре Linux или офисных пакетах). Мы проводим в браузере большую часть своего времени, так что не удивительно, что браузер находится под прицелом: его постоянно пытаются взломать, использовать в ботнете, пытаются украсть из него наши данные, прослушать его трафик, отслеживать посещаемые нами сайты и наши действия на этих сайтах.

Сейчас самое время сказать, что всё не так уж плохо, и со всеми этими проблемами можно справиться… но это не так. Из коробки браузеры уже делают немало: регулярно обновляются, стараются затыкать дыры в безопасности, внедряют новые технологии для защиты, предоставляют возможность расширять их функционал сторонними расширениями. Но серьёзной защиты из коробки нет, и вряд ли она когда-нибудь появится: она идёт в комплекте с усложнением интерфейса браузера и частичным отключением его функционала, что "ломает" сайты и вряд ли понравится обычным пользователям. Но самое печальное, что даже такой ценой невозможно полноценно защитить браузер — слишком уж он стал сложным.

Тем не менее, для усиления защиты браузера можно много чего сделать.

Как знают наши читатели, Qrator.Radar неустанно исследует глобальную связность протокола BGP, равно как и региональную. Так как «Интернет» является сокращением от «interconnected networks» — «взаимосвязанных сетей», наилучшим способом обеспечения высоких качества и скорости его работы является богатая и разнообразная связность индивидуальных сетей, чье развитие мотивировано в первую очередь конкуренцией.

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

В этот раз, мы поближе посмотрим на устройство интернет-сегмента Российской Федерации. Есть причины не сводить глаз с данного сегмента: согласно данным, которые предоставляет база данных регистратора RIPE, к РФ относится 6183 AS из 88664 зарегистрированных глобально, что составляет 6,87%.

Такой процент ставит Россию на второе место в мире по данному показателю, сразу после США (30,08% зарегистрированных AS) и перед Бразилией, владеющей 6,34% всех автономных систем. Эффекты, которые возникают вследствие изменений российской связности, могут наблюдаться в других странах, зависимых от или примыкающих к данной связности и, наконец, на уровне почти любого интернет-провайдера.

Как реализовать на Эликсир JSON API endpoint без каких либо фреймворков?

От переводчика:
В статье приведён пример очень простого веб-приложения, которое можно рассматривать как Hello, World! в создании простейшего API на Эликсире.
Код примера незначительно изменён для того, чтобы соответствовать текущим версиям библиотек.
Полный код примера с изменениями можно увидеть на GitHub.

Проблемы нового языка

Многие разработчики приходят в Эликсир из мира Ruby. Это очень зрелая среда с точки зрения количества доступных библиотек и фреймворков. И такой зрелости мне иногда не хватает в Эликсире. Когда мне нужна сторонняя служба, результат поисков подходящей может быть следующим:

TL;DR. В этой статье мы исследуем защитные схемы (hardening schemes), которые из коробки работают в пяти популярных дистрибутивах Linux. Для каждого мы взяли конфигурацию ядра по умолчанию, загрузили все пакеты и проанализировали схемы защиты во вложенных двоичных файлах. Рассматриваются дистрибутивы OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 и 7, а также Ubuntu 14.04, 12.04 и 18.04 LTS.

Результаты подтверждают, что даже основные схемы, такие как стековые канарейки и независимый от позиции код, ещё не всеми используются. Ситуация ещё хуже у компиляторов, когда речь идёт о защите от уязвимостей вроде столкновения стека (stack clash), которые попали в центр внимания в январе после публикации информации об уязвимостях в systemd. Но не всё так безнадёжно. В значительной части бинарников реализованы базовые методы защиты, и их число растёт от версии к версии.

Проверка показала, что наибольшее количество методов защиты реализовано в Ubuntu 18.04 на уровне ОС и приложений, затем следует Debian 9. С другой стороны, в OpenSUSE 12.4, CentOS 7 и RHEL 7 тоже реализованы базовые схемы защиты, а защита от столкновения стека применяется ещё шире при гораздо более плотном наборе пакетов по умолчанию.

У нас в Phusion работает простой многопоточный HTTP-прокси на Ruby (раздаёт пакеты DEB и RPM). Я видел на нём потребление памяти 1,3 ГБ. Но это безумие для stateless-процесса…


Вопрос: Что это? Ответ: Использование памяти процессом Ruby с течением времени!

Оказывается, я не одинок в этой проблеме. Приложения Ruby могут использовать много памяти. Но почему? Согласно Heroku и Нейту Беркопеку, в основном раздутие связано с фрагментацией памяти и чрезмерным распределением по кучам.

OSSEC (Open Source Host-based Intrusion Detection System) – это хостовая система обнаружения вторжений. Если у вас появилась задача проверки контроля целостности файлов на ваших серверах, логирования различных действий на серверах, получения событий безопасности с ваших серверов (а также любых других) и оповещений об этих событиях, вывода различных отчетов и многое другое, то HIDS OSSEC — отличное решение под эти задачи. OSSEC может работать локально, по схеме агент + сервер и в гибридном режиме (агент->сервер->сервер). Мы будем рассматривать схему агент + сервер и работу в гибридном режиме.

Содержание

Установка OSSEC
Настройка конфигурационного файла OSSEC
Добавление агентов
Настройка конфигурационного файла для агентов
Email оповещения
Работа с агентами и получение отчетов
Вывод данных в другие системы
Работа OSSEC в гибридном режиме

Установка OSSEC

Установим на ОС Ubuntu 14.04 Установим необходимые пакеты для установки OSSEC:

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

Сложилось так, что потребовалось контролировать около 30 VDS-ок на Debian, которые мне благополучно «передали» под надзор (а я как бы больше программист, чем *nix-администратор). И первая мысль, что пришла в голову после базовых операций по смене и проверке доступов, была «Если я что-то упустил, хочу оперативно знать о подключениях». Есть рецепты (в том числе на Хабре) связывания события авторизации по SSH и почтовых уведомлений, которые я использовал как базу, но мне хотелось все-таки оперативности и некоторой информативности. В общем получил я в итоге вот такую «систему», которая в течение месяца вполне успешно работает и сообщает мне о любом факте авторизации.

1. С помощью мануалов по API-телеграм получен токен и чат-ид для бота уведомлений (тут распространяться не буду, это все легко и просто находится в 1-2 строке поисковика).
2. Создано два скрипта, код от которых будет размещен ниже. В принципе можно все сунуть и в один файл, но т.к. я хотел модульности, то я вынес в отдельный скрипт функцию отправки уведомления в телеграм-бота.
3. В два файла настроек добавил вызов скрипта регистрации события входа на сервер и перезапустил службу SSH.

На все про все уходит минут 5-10, не больше. Ну а теперь собственно техничка.

PS. Все выполнялось на Debian9 x 64 (если это важно).

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

Причины расхождения показаний разделил на три группы:

1. Подсчет
2. Сбор и хранение
3. Отображение

Игровой.
Но это не точно

Он, конечно, не претендует на звание «самого», но явно компактнее собратьев.

Представляю вам пошаговую инструкцию +заметки для сборки вполне себе компактного игрового ПК. Сразу говорю, что понятие «игровой» широкое, а я не богатый, так что тут не будет Core i9 и GTX 1080Ti, я собрал довольно скромную систему, впрочем, она мощнее, тише и меньше старой раз в 10.

Вместо вступления

У меня был средненький 7-летний компьютер, и в какой-то момент он перестал мне нравиться, тогда я решил собрать новый. С удивлением обнаружил, что вышли новые камни у обоих производителей и решил: «наконец-то соберу mini-ITX.» И собрал. Немного заморочившись с питанием (относительно, конечно, но по меркам сборки ПК, где «купил и поставил», заморочился) получил очень компактный ПК. Сами посудите: 210*170*95 мм.

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

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

Облака, белогривые лошадки...

^{(откуда-то из интернета, впервые увидел тут.)}

Нагрузка на нашу систему сильно неравномерна: во-первых, в течение суток нагрузка меняется в 5 раз. Во-вторых, есть и ярко выраженная сезонность. Суточный максимум проверок после окончания летней сессии уменьшается в 10 раз! Зимняя сессия не столь яркая, но тоже не подарок. Плюс каждая последующая летняя сессия тяжелее (по числу проверок) и сложнее (новые технологии поиска и функциональность) предыдущей. Поэтому, с одной стороны, хочется иметь хороший запас по ресурсам, с другой – не платить лишнего во время спада активности. В сессию можно развернуть побольше серверов, а летом сократить объем потребляемых ресурсов. Очевидно, что это как раз случай облачных провайдеров. В этой статье я расскажу о различных аспектах взаимодействия с несколькими облачными провайдерами (AWS, ИТ-Град, MCS, YC). Если кому-то покажется, что это крик души, он не сильно ошибется. Итак, поехали!

Когда мы запустили в 2013 году Discourse, наши требования к серверу были высокими:

• 1 ГБ ОЗУ
• быстрый двухядерный ЦП
• быстрый твердотельный накопитель от 20 ГБ

Я имею в виду не дешёвый общий cpanel-сервер, а выделенный виртуальный частный сервер с такими характеристиками.

Нам этого было достаточно, потому что в течение следующего десятилетия Интернета мы писали на Ruby. Я сразу предсказывал, что цена аренды VPS с такими характеристиками упадёт до 5 долларов в месяц, и благодаря Digital Ocean это действительно случилось в январе 2018 года.

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


Но постойте… а что если вы сможете засунуть «в облако» свой компьютер?

На Хабре достаточно много статей про разработку игр, однако среди них очень мало статей, которые касаются “закулисных” тем. Одной из таких тем является организация доставки, собственно, игры большому количеству пользователей на протяжении длительного времени (год, два, три). Несмотря на то, что для некоторых задача может показаться тривиальной, я решил поделиться своим опытом хождения по граблям в этом деле для одного конкретного проекта. Кому интересно — прошу.

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

Нам потребуется 30 минут времени, паяльник, и внешний модуль Catalex-Micro-SD-Card-Module стоимостью 5 штук за 300 рублей — и вопрос снят.

Вот пошаговое руководство, как добавить SD-кард ридер на BFK3.1. Всё описываемое опробовано на практике. Использовался самый свежий на данный момент SDK 4.16, размещенный на официальном сайте «Байкала». В SDK версии 4.14 и младше это работать не будет.

Привет, Хабр! Не так давно возникла довольно типичная ситуация — руководство дало команду «Выбрать систему защиты данных от утечки». Основной критерий выбора — способность решить задачу не допустить утечек критически важной (по мнению руководства) документации, файлов и тому подобного. Как следовало из устного ЦУ руководителя, журналы и разная аналитическая функциональная оснащённость — вторична. Цитируя шефа, «для отлова злоумышленников мы можем и видеокамеры повесить, решайте задачу так, чтоб не разбираться с утечками, а исключить их». Разумеется, все прекрасно понимают, что 100% исключения риска утечек достичь нереально, поэтому — речь о минимизации риска утечки информации.

Транспортные протоколы I2P были разработаны почти 15 лет назад, когда основной задачей было сокрытие содержимого трафика, а не факт использования того или иного протокола. DPI(deep packets inspection) и блокировку трафика в то время никто не принимал в расчет. Однако времена меняются и хотя существующие протоколы I2P по прежнему защищены довольно хорошо, возникла необходимость в новом транспортном протоколе, отвечающему на существующие и будущие угрозы, и, в первую очередь, DPI, анализирующий длину пакетов. Помимо этого, новый протокол использует самые современные достижения криптографии. Полное описание протокола здесь. За основу взят Noise, в котором в качестве хэш-функции используется SHA256, а в качестве DH (в терминологии Noise) — x25519.

Движение за свободное программное обеспечение (CПО) выступает за персональные и социальные свободы. Выступает за то, чтобы владелец и пользователь компьютера имел полный контроль над ним. Однако, большинство людей не видит проблемы в том, что ограниченное количество транснациональных мега-корпораций контроллируют компьютеры всех и каждого. Люди думают: «Apple и Microsoft знают, что надо делать, и они делают это хорошо. Зачем мне нужно свободное ПО?»

Принимая тот факт, что большинство людей игнорируют истинный смысл свободного ПО, как может движение за СПО сделать этот мир лучше?

Идея сделать независимый от корпораций P2P мессенджер не нова, однако разработка нового протокола и клиентских приложений для него достаточно дорогой и долгий процесс. А что, если использовать старый добрый XMPP, в котором уже все давно продумано и запилено?

Но это же не настоящий peer-to-peer, скажете вы, для работы XMPP нужен собственный сервер и домен. Это так, но мы можем запустить сервер на локалхосте, а для связи с серверами других пользователей использовать скрытый сервис в виртуальной сети I2P. Использование I2P избавит нас от необходимости платить за домен с хостингом, а так же защитит наши коммуникации от преступной онлайн-слежки.

Таким образом, получаем:

• Гибридный P2P мессенджер, который можно запускать и на пользовательских устройствах, и на полноценном сервере.
• Фичи, которых не хватает другим P2P мессенджерам: оффлайн сообщения, хранение контактов и истории "в облаке", работа нескольких клиентов с одним аккаунтом.
• Готовые клиентские приложения на любой вкус.
• За счет использования I2P, неуязвим для различных *надзоров (сори за мат).

Приступим же к реализации...

Проект Невидимый Интернет (далее просто I2P) представляет разработчикам платформу для разработки приложений с усиленными требованиями по приватности пользователей. Это виртуальная сеть поверх обычного Интернета, в которой узлы могут обмениваться данными и при этом не раскрывать свой настоящий IP адрес. Вместо IP адресов внутри Невидимого Интернета соединения происходят между виртуальными адресами, которые называются I2P Destination. Можно иметь сколько угодно таких адресов и менять их хоть для каждого соединения, они не предоставляют другой стороне никакой информации о настоящем IP адресе клиента.

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

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

Проблема текущих VPN решений в том, что их тяжело правильно настроить, дорого обслуживать, а так же в них полно legacy кода сомнительного качества.

Несколько лет назад канадский специалист по информационной безопасности Jason A. Donenfeld решил, что хватит это терпеть, и начал работу над WireGuard. Сейчас WireGuard готовится к включению в состав ядра Linux, он даже получил похвалы от Линуса Торвальдса и в американском сенате.

Заявленные преимущества WireGuard над другими VPN решениями:

• Простой в использовании.
• Использует современную криптографию: Noise protocol framework, Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24, HKDF и т.д.
• Компактный читаемый код, проще исследовать на уязвимости.
• Высокая производительность.
• Четкая и проработанная спецификация.

Неужели найдена серебрянная пуля? OpenVPN и IPSec пора закапывать? Я решил с этим разобраться, а заодно сделал скрипт для автоматической установки личного VPN сервера.

Зал дата-центра NORD-4 в 2016 году.

Вот пустой машинный зал в дата-центре. Думаете, стойку можно поставить в любое место? Если бы все было так просто!

Меня зовут Алексей, я занимаюсь capacity management в дата-центрах DataLine. Сегодня расскажу, что правильно расставлять стойки в зале – это целая наука, а иногда и искусство.

Что такое capacity management?

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

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