Многие компании не успевают оперативно устранять уязвимости. При этом время эксплуатации уязвимости после ее раскрытия сокращается. Существуют различные варианты попыток защиты\сокрытия сервисов от "любопытных глаз". Основные: использование нестандартного порта, fail2ban, ACL и tarpit (и их сочетание).
Есть ещё port knocking: как дополнительный фактор защиты - может снизить обнаружение сервиса, а не пытаться бороться с последствиями (брутфорс, эксплуатация), когда сервис уже обнаружен. Но, очень часто эта технология оказывается не используемой. Где-то из-за незнания технологии (хотя, статей хватает). Но, чаще из-за проблем на практике, которые мешают её внедрению:

‣ сложности использования технологией неподготовленным пользователям;
‣ фильтрация трафика (как на стороне клиента, так и сервиса);
‣ "раздувание" сгенерированных правил;
‣ несогласованность с другими отделами безопасности (трафик для port knocking может считаться зловредным).

Часто игнорирование port knocking приводит к тому, что задачи по безопасности пытаются решать другими технологиями. Что приводит к решениям, простота и эффективность которых вызывает вопросы. Усугубляется это частым отсутствием знаний в области наступательной безопасности: непониманием как атакующие могут обходить средства защиты. Я за годы работы пентестером и архитектором безопасности очень полюбил port knocking и нашёл варианты решить самые частые проблемы с его использованием. Ими и хочу поделиться.

Исходная задача: уменьшить количество несанкционированных обращений к сервису (в идеале - исключить полностью). При этом не мешая легитимным обращениям.

В статье обсудим:

‣ зачем (и как) пытаться убрать сервис из базы поисковиков (Censys, Shodan);
‣ использование нестандартного порта, fail2ban, ACL, tarpit и какие подходы используют атакующие для попытки обхода этих мер;
‣ варианты port knocking и практические проблемы их использования;
‣ "прозрачный" port knocking (не требующий от пользователей дополнительных действий, не подверженный фильтрафии трафика и согласующийся с сетевыми мерами безопасности);
‣ port knocking в docker контейнере: когда полезен и как его сделать;
‣ использование ipset для повышения эффективности port knocking;
‣ некоторые спорные практики защиты.

Силовые тренировки уже давно не инструмент для соревновательного бодибилдинга и пауэрлифтинга. Сегодня силовые — неотъемлемый инструмент здоровой и качественной жизни, в котором вы должны быть заинтересованы.

Только вот некоторые культурные и даже профессиональные мифы повышают порог вхождения в тренажерный зал. Взращивают ментальный барьер, к которому нужно морально готовиться, настраиваться и из-за этого постоянно откладывать начало тренировок. Один из таких барьеров — время. Многие думают, что тренировки обязательно должны быть продолжительными, чтобы быть эффективными. Второй барьер — утомление. Не редко можно услышать что-то из разряда “не устал = не потренировался”, “не болит = не растет”.

Сейчас я постараюсь показать и доказать, что это не так и можно действовать намного эффективнее, опираясь на науку об упражнениях, а не мифы. С помощью рационального подхода делать хороший результат ценой приемлемых усилий. Это не будет материал из разряда “фигура Апполона за 10 минут в день”, но кое-что более изящное, чем классический убийственный метод и подходящее вам — людям с полной занятостью, которым хочется ввести силовые в жизнь, чтобы поддерживать организм и получать от этого бонусы внешнего вида.

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

Я менеджер менеджеров, отвечаю за разные команды с разными фокусами. У каждой команды свои проекты. В каждом проекте есть по несколько Миро-досок, гугл-доков, доков в конфлюенсе, эпик в джире и еще горка ВАЖНЫХ ссылок!

Все это богатство надо как-то организовать и перестать, наконец, дергать в слаке коллег с вопросом: "А напомни, плз, ссылку на...".

Ключевые проекты

• Debian 8, ядро 4.19
• FRRouting (в версии 1.1 и более древних использовался Quagga)
• ISC-DHCP
• Keepalived
• StrongSwan
• OpenVPN
• PowerDNS
• Wireguard
• OpenNHRP
• Accel-ppp
• xL2tpd
• Squid
• mDNS-repeater
• IGMP-Proxy
• iPerf
• более детальный список в Release notes

Автоматическая, защищенная, распределенная, с транзистивными связями (т.е. пересылкой сообщений, когда нет прямого доступа между абонентами), без единой точки отказа, равноправная, проверенная временем, с низким потреблением ресурсов, full-mesh VPN сеть c возможностью "пробивки" NAT — это возможно?

Введение

Как вы знаете, Роскомнадзор (РКН) заблокировал технологию Encrypted Client Hello (ECH), а Cloudflare неожиданно принудительно включил её для всех пользователей. Это вызвало серьезные проблемы для тех, кто использует Cloudflare, особенно для пользователей из России. Решим эту проблему!

Если вам нужно отключить Encrypted Client Hello (ECH) для вашего домена на Cloudflare, выполните следующие шаги. Этот процесс включает проверку текущего статуса ECH, а затем его отключение через API Cloudflare.

В данной статье пойдёт речь об особенностях UEFI на примере переноса Debian Stretch с MBR на UEFI. Опишу так же разницу между MBR и UEFI, так как я её воспринимаю.

Кроме общей части, ключевая часть статьи про формирование GRUB EFI файла grubx64.efi во время grub-install и про то, что этот файл не так прост, как кажется на первый взгляд.

Во введении мы сказали, что async/await это про futures и задачи. В первой части мы рассмотрели futures и теперь пришло время задач. Благо, мы с ними уже встречались, хоть мы их так и не называли.

Сегодня был выпущен мажорный релиз v2rayN v7.0, а вместе с ним и моя серия коммитов, которые добавляют поддержку пресета "Россия".

Для его работы так же был создан российский источник geo файлов для v2ray/sing-box/etc.

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

Разберемся в преимуществах и недостатках каждой системы, а также настроим мониторинг гетерогенной Linux-Windows инфраструктуры средствами централизованного управления.

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

Туннели SSH — это зашифрованные TCP-соединения между клиентами и серверами SSH. Трафик входит с одной стороны туннеля и прозрачно выходит с другой. Изначально этот термин относился к туннелям на виртуальных сетевых интерфейсах TUN/TAP, однако сейчас так обычно называют проброс портов SSH.

Настраиваем fail2ban для защиты от перебора паролей на debian серверах с помощью инструмента автоматизации Ansible. Для мобильности сервер Ansible установим на OrangePi и сделаем его спряжение с мобильным телефоном.

Обзор

Всем привет! С вами Станислав, и это моя вторая по счёту статья на Хабре. Как вы возможно помните из моей первой статьи, я увлекаюсь программированием, и операционной системой ReactOS.

Но мои увлечения вовсе не ограничиваются этим. Сегодня я расскажу вам, как я буквально погряз в Матрице… Нет, это не про фильм, как вы возможно подумали, а про федеративную чат-систему, которая появилась в уже далёком 2014 году :)

Перед тем, как начать, рекомендую ознакомиться, что вообще Matrix из себя представляет. В кратце — это децентрализованный, федеративный, и открытый протокол обмена сообщениями, и в принципе любыми данными, с возможностью end-to-end шифрования (в том числе в комнате с несколькими людьми), и работающий поверх REST API (HTTP с JSON).

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

Серверы в опасности!

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

Это может быть перебор портов с целью найти открытые от какой-то компании, которая позиционирует себя борцом за безопасность, но которая собирает статистику открытых портов на будущее по всем доступным IP (например Censys).

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

Ну и собственно целевые атаки, во время которых ваши серверы в первую очередь тестируются на наличие открытых портов, а затем производятся атаки на найденные сервисы. Это может быть подбор эксплоитов для использования известных дыр или пока неизвестных 0-day, как и обычный DDoS.

Во всех этих сценариях используется предварительный перебор открытых портов. Скорее всего применение nmap или подобных утилит в каких-то скриптах.
Как защитить сервер от сканирования портов без CloudFlare и подобных прослоек?

В этой статье я хочу описать работу над проектом альтернативного списка заблокированных адресов Re:filter: проблему с которой я столкнулся будучи пользователем существующих списков заблокированных ресурсов, шаги к решению и полезные на практике результаты этой работы.

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