Однажды мне стало интересно: а что будет, если отправить пакет с несуществующим транспортным протоколом? Не TCP, не UDP, не ICMP — вообще что-то выдуманное. Пропустит ли его ОС? Дойдет ли он хотя бы до сетевого интерфейса? Не зарежет ли его какой-нибудь промежуточный маршрутизатор? А вдруг он еще и быстрее обычного дойдет, потому что никто не знает, что с ним делать?
Ответа у меня не было. Так что я решил проверить.
Привет, Хабр! Сегодня расскажу, как я собрал сетевое хранилище NAS. Недавно оно понадобилось мне для дома, и я решил не покупать, а сделать свое. Тут не все так просто: есть разные варианты — «железный» и софтовый. В первом случае просто берем готовый NAS-сервер вроде Synology или QNAP, набиваем в него дисков — и все. Недешево, хотя в большинстве случаев это оправдано бесперебойной работой.
Но я не хотел тратиться, поэтому выбрал второй вариант — самостоятельную сборку на базе ПК. Выбор огромен — от Raspberry Pi до относительно недорогих HP ProLiant MicroServer. Я собрал на «железе», которое у меня было в запасе: HP ProLiant MicroServer Gen8, CPU Intel Celeron G1610T, 16 ГБ DDR3, 4 x 4 ТБ HDD. После сборки задумался о программном обеспечении. Его много — от готовых решений вроде TrueNAS, XigmaNAS, OpenMediaVault до самостоятельной настройки сервера с нуля на базе Linux или FreeBSD.
Я не искал легких путей (ведь я инженер!) и решил поэкспериментировать. Выбрал довольно экзотический вариант создания NAS при помощи операционной системы OmniOS. ZFS в ней поддерживается нативно, а сама она продолжает славные традиции своего предка — illumos. Это стабильность, поддержка ZFS, предсказуемое поведение в продакшене, а также простая, но гибкая модель управления сервисами (SMF). Плюс четкая структура пакетов и ориентация на безопасность и прозрачность исходного кода. Подробнее обо всем этом — дальше.
Расскажем, как мы сделали отказоустойчивый WireGuard-сервер в Yandex Cloud, раскинув его на три зоны доступности. Получилось просто, надёжно и без сложных кластеров.
Мы не рассматриваем настройку самого WireGuard, конфигурацию групп безопасности, настройку VPC, NLB и прочее. Вся логика сосредоточена на том, чтобы обеспечить автоматическое переключение между зонами при сбоях. Сеть VPN-клиентов — 172.28.90.0/24 — должны быть доступна с любой из трёх зон.
Тема BUM трафика имеет огромное значение в современном мире сетевых технологий. И не важно L3-only у вас, или единый L2 навсю корпорацию. BUM - используется в любом случае. Тем более, это имеет огромное и внутри сетей центров обработки данных. Вот хочу поговорить про это чуть побольше и подетальней, и естественно в разрезе EVPN-VXLAN.
Добро пожаловать, надеюсь будет интересно
Фото важных семейных событий и видео из путешествий, копии важных документов, музыка, фильмы, которых не найти на стримингах — многие задумывались, как сохранить все самое важное так, чтобы ситуация с не вовремя сломавшейся флешкой не обернулась потерей ценных данных навсегда. Кому-то для спокойствия достаточно Google Drive или Яндекс.Диска, но я решил пойти чуть дальше и построить собственное домашнее облако с приложениями Immich и Nextcloud.
Кстати, привет, Хабр! Я Денис Петухов, Python-разработчик в Cloud.ru и сегодня я расскажу, как построил облако в шкафу. По ходу дела дам практические рекомендации по архитектуре, выбору оборудования, приложений, настройке сети и даже приведу расчеты того, что выгоднее, и сколько электричества «съедает» домашняя хранилка в месяц.
На нодах доступа где наши клиенты создают туннели, для терминации HTTP трафика сейчас мы используем Traefik. Недавно мы столкнулись с проблемой, когда на 1 из доменов приходили тысячи запросов в секунду, и web server уходил в полку по CPU, страдал весь клиентский трафик на ноде в данном регионе, а пользователи жаловались на зависания и таймауты. Это история как мы внедрили fail2ban для блокировки ddos флуда по access логам.
Привет, Хабр! Я Роман Сафиуллин, руковожу отделом защиты информации InfoWatch ARMA. Мы занимаемся защитой инфраструктуры промышленных предприятий от киберугроз, и сегодня хочу поделиться с вами инструкцией по разбору промышленных протоколов на примере протоколов IEC104 и Fanuc Focas. В основе статьи – мой доклад на конференции Industrial++. Совместно с коллегами из отдела разработки ARMA – Сергеем Калдыркаевым и Алексеем Пуцем, собрали для вас немного цифр по атакам на промышленность, примеры интересной малвари и, собственно, туториал по разбору пром. протоколов.
Представьте, что нужно заменить двигатель самолета прямо в полете. Примерно в такой ситуации мы оказались, когда взялись за локализацию производственных систем одного российского завода. Черный ящик вместо системы управления, запароленный доступ, отсутствие документации и невозможность останавливать производство — весь джентльменский набор подводных камней после 2022 года.
Я Иван Балашов, в интеграторе К2Тех руковожу направлением цифрового производства и внедряю цифровые решения в промышленности. В этом кейсе расскажу, как мы собирали пазл из обрывков информации о настройках систем, внедряли российскую SCADA взамен западной, мигрировали функционал MES, и все это без остановки производства.
Если вы когда-нибудь окажетесь перед задачей импортозамещения критически важных производственных систем, эта история может дать представление о типичных подводных камнях и способах их обхода.
Всем привет! С вами Ксения Наумова. В Positive Technologies я исследую вредоносный сетевой трафик и совершенствую инструменты его анализа в экспертном центре безопасности. Недавно перед нами встала задача — создать ML-модель для обнаружения вредоносного ПО в сети. Причем распознавать она должна была не только уже ранее детектированное нами вредоносное ПО, но и совсем новые угрозы, которые появляются в большом количестве ежедневно. В качестве первого эксперимента решили сделать модель для работы с трафиком, который передается по протоколу HTTP, поскольку наши продукты успешно расшифровывают TLS-сессии, а внутри них частенько можно найти много интересного. В статье я подробно расскажу, как мы обучали модель, и поделюсь информацией о допущенных ошибках.
Всем привет, сегодня я хочу рассказать вам о своем опыте постановки PostgreSQL на сервере и какие при этом возникли сложности, а также о том как все это решилось.
Кратко, нужно использовать IP префиксы которые доступны внутри страны и недоступные из других стран, хотя это противоречит основному принципу интернета, что все ip-адреса должны быть доступны для всех.
Давайте рассмотрим интернет адреса с самого начала, есть публичные адреса и есть приватные адреса.
Например, адрес 1.1.1.1 это публичный, а адрес 10.1.1.1 приватный, он не маршрутизируется в Интернет. Многие компании используют такой адрес внутри своей сети.
Но есть также ещё одна категория адресов которые относятся к публичным, но никогда не используются обычными пользователями в интернете, такие адреса принадлежат какой-то корпорации или организации.
Эти адреса можно без опаски повторно использовать внутри страны и никогда не произойдёт пересечение с пользовательскими сервисами, потому что пользовательских сервисов на этих адресах нет. Ни один пользователь, скажем так, не пострадает. Если из-за рубежа кто-то направит DDoS атаку на такие адреса, то все атаки уйдут за рубеж, к основному владельцу адресов, при условии, если не объявлять такие адреса за рубеж по протоколу BGP.
Всем привет! На связиНиколай Едомский, руководитель группы сетевых инженеров в ЕДИНОМ ЦУПИС.
Представляю вашему вниманию четвертую статью из цикла «IPsecHub+».
В прошлой статье мы рассмотрели схему построения IPsec‑концентратора на основе так называемой эскалаторной топологии. А сейчас мы рассмотрим примеры более сложных сценариев, когда нужно выполнять регуляторные требования, пристыковать филиалы с пересекающимся адресным пространством, ну и тому подобное.
Как-то раз внутри корпорации Google появилась идея раздавать интернет с помощью воздушных шаров, парящих в стратосфере, — так родился Project Loon. Проект должен был обеспечить доступ к сети в отдаленных и труднодоступных точках, но после нескольких лет испытаний, триумфов и неудач его, к сожалению, закрыли. Правда, не совсем — некоторые наработки были реализованы уже в другом проекте под названием Taara. Об этом сегодня и поговорим.
Всем привет! На связи Николай Едомский, руководитель группы сетевых инженеров в ЕДИНОМ ЦУПИС.
Представляю вашему вниманию третью статью из цикла "IPsecHub+".
В предыдущей статье мы пришли к выводу, что желательно максимально сократить количество сущностей, которые участвуют в процессе добавления или удаления нового филиала.
Прежде всего, это нужно для максимального упрощения автоматизации процесса. Я думаю, вы согласитесь, что делать автоматизацию для Linux-машин - это одно, а для Linux-машин и какого-нибудь NGFW типа Fortigate - это совсем другое. Особенно если учесть, что этот NGFW обслуживает не только сервис стыковки по IPsec, а вообще всю компанию, и последствие ошибки в скриптах автоматизации - это не только падение IPsec-сегмента, но и других сервисов.
Первая часть: Ethernet, ARP, IPv4 и ICMPv4
Вторая часть: основы TCP и Handshake
В прошлом посте мы узнали о заголовках TCP и о том, как устанавливается соединение между двумя сторонами.
В этом посте мы изучим передачу данных по TCP и способ управления ею.
Также мы создадим интерфейс сетевого стека, который приложения смогут использовать для передачи данных по сети. Потом этот Socket API мы применим, чтобы наш пример приложения смог отправить простой HTTP-запрос веб-сайту.
В последний год в России наблюдается активное удаление VPN-приложений из официальных магазинов приложений. В середине марта 2025 года Роскомнадзор направил в Google 47 запросов на удаление VPN-сервисов из Google Play, что стало самым массовым потоком подобных запросов за последние полгода. Ранее, в июле 2024 года, Apple по требованию Роскомнадзора удалил из российского сегмента App Store более 100 VPN-приложений, включая такие популярные сервисы, как Proton VPN и NordVPN, а также наш AmneziaVPN. Мы ранее писали о том, что Apple один из главных провайдеров цензуры, и сейчас хотим дать подробные инструкции что можно сделать:
Всем привет! На связи Николай Едомский, руководитель группы сетевых инженеров в ЕДИНОМ ЦУПИС.
Представляю вашему вниманию вторую статью из цикла «IPsecHub+».
После того, как в первой статье цикла мы немного погрузились в специфику нашей технологической базы, давайте рассмотрим классический сценарий построения GRE‑over‑IPsec туннеля. Это будет первый шаг к реализации нашего решения «IPsecHub+».
И снова привет, Хабр! Продолжаю рассказывать, как мы с коллегами решали небольшую задачу по автоматизации управления списками доступов на пограничных маршрутизаторах. В предыдущей части речь шла о концепции хранения и представления данных. Теперь же погрузимся в пучину кода, который отвечает за проверку и отправку политик на сетевые устройства.
