Появилась новость о всплеске попыток уволить именно в ИТшной сфере. На Хабре была хорошая статья в тему: Пришла пора расстаться с работой, где автор описывает план действий, если сотрудника хотят уволить.

Я же хочу раскрыть подробнее юридическую сторону дела: какие права есть у работников и как ими лучше пользоваться.

Как-то меня бывший работодатель склонял написать заявление по собственному желанию, шантажируя пунктом из трудового договора "выполнять иные поручения руководителя". Суть: назначить мне непрофильную задачку и на основании неудовлетворительного выполнения инициировать увольнение (в итоге я склонил работодателя расторгнуть договор по соглашению сторон, т.е. с выплатой компенсации). У меня уже был успешный юридический опыт в гражданских делах. И эта ситуация заставила меня изучить также опыт и в части трудовых отношений. Этим опытом и хочу поделиться.

В марте 2026 многие обсуждали ситуацию с доступом к изображениям из ЛС мессенджера MAX по ссылкам, сохранённым через WebArchive. Тогда же многих не устроил ответ компании.

К сожалению, ситуация хуже, чем кажется. Т.к. проблемы не видят не только в MAX, но и в других компаниях (столкнулся с этим, оповещая компании о похожих проблемах). В статье я расскажу, почему считаю ситуацию — проблемой для всех: пользователей, компании, багхантеров. И как связка «WebArchive + IDOR» может стать бомбы замедленного действия для компании.
Более того, эта ситуация — наглядный пример, как отлаженный механизм повышения безопасной разработки (что не найдут внутренние безопасники компании — отловят багхантеры) иногда даёт сбой.

История о том, как военкомат собирался применить ко мне ограничительные меры, несмотря на то, что в военкомат я явился (также был риск, что меня доставят в военкомат полицейские - для составления протокола). И как я обжаловал их намерения (на данный момент ограничения не введены и информации о таких намерениях тоже больше нет).

29.11.2025 я получил СМС от номера 117 с текстом: "Вам направлена повестка в военкомат. Ознакомиться: реестрповесток.рф".

По закону возможные ограничение за неявку по повестке (согласно статьи 7.1 Закона №53-ФЗ "О воинской обязанности и военной службе"):

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

На одной из предыдущих работ нужно было собрать свои достижения в области кибербеза. У меня были различные найденные уязвимости. Но, я даже не знал: были ли им присвоены CVE? Я этим не занимался. Занимались ли вендоры - не в курсе. Тогда я вспомнил ситуацию с выявлением мной уязвимости в антивирусе Agnitum и взгрустнул: CVE не был зарегистрирован. Год назад я вспомнил эту историю и задумался: а можно ли оформить CVE сейчас, спустя 12 лет после обнаружения уязвимости? Ситуация осложнялась тем, что вендора уже много лет как нет. И его сайта, конечно, тоже. Но, раз вы читаете этот текст - то мне это удалось (за этот кейс я попал в топ-10 Pentest award 2025 - номинация "Раз bypass, два bypass"). Но, путь занял почти год. И вот как это было (спойлер: помог сервис WayBack).

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

В статье покажу этапы, очень похожие на стадии принятия Кюблер-Росс (отрицание, гнев, торг, депрессия и принятие), которые я наблюдал у разработчиков в процессе нашего с ними общения. Мы пройдём путь от отрицания наличия проблемы, через благодарность за информирование (о проблеме) до негодования в адрес MITRE (и мой адрес, не стесняясь выражений). Помимо оформления CVE, за эту уязвимость я попал в Топ-10 Pentest Award 2025 (№9 Out Of Scope).

Дисклеймер: в статье приведены скриншоты из моих личных переписок с разработчиками. Публикация таких переписок одной из сторон не требует согласия другой (согласно законодательства РФ).

Решил и я в рамках конкурса рассказать о своём вкладе в развитие open source. Речь про open source блокчейн Hyperledger Fabric. Блокчейн активно используется в разных сферах: цифровые валюты центробанков (Беларусии, Нигерии), операторами информационных систем цифровых финансовых активов, электронное голосование, энергетика, здравоохранение и др.

В этой статье я расскажу как я:

обнаружил проблему;
создал свой первый open source: смарт-контракт для решения этой проблемы;
повлиял на создание патча для блокчейна Hyperledger Fabric, устраняющего проблему.

Многие компании не успевают оперативно устранять уязвимости. При этом время эксплуатации уязвимости после ее раскрытия сокращается. Существуют различные варианты попыток защиты\сокрытия сервисов от "любопытных глаз". Основные: использование нестандартного порта, 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;
‣ некоторые спорные практики защиты.

Тема трансграничных платежей и цифровых финансовых активов (ЦФА) последние годы активно поселилась в медиасфере. К сожалению, обсуждение в основном сводится к оценке финансовой выгоды и юридическим проблемам. Тогда как, существует ещё и проблемы безопасности, которые на сегодняшний день, на мой взгляд, во многом недооценены (хотя, осознание проблемы понемногу уже происходит: об этом начинают говорить публично). В публичной плоскости мало конкретики о безопасности в этой сфере. Между тем, рынок ЦФА растёт: за 3 года ожидается почти 8-кратный рост в РФ (до 500 млрд. руб). А мирового — более 8 трлн $ к 2029. Поэтому вопросы безопасности становятся всё более актуальными. Мне довелось пообщаться с некоторыми разработчиками, исследовать архитектурные решения некоторых корпоративных блокчейнов. Также, я часто сталкивался с устоявшимися заблуждениями относительно факторов риска, которые хотел бы развеять. На основании всего этого, а также своего разнообразного опыта (пентест, разработка, code review, в т.ч. в сфере блокчейна) хочу поделиться своим мнением о текущем состоянии безопасности финансовых решений на основе блокчейн технологий. И тех причин, которые за этим стоят. В примерах для описания проблем будет использоваться блокчейн Hyperledger Fabric. Но, во многих случаях пример может быть общим и для других корпоративных блокчейнов.

В прошлой статье я рассказал, как использование серверов времени (NTP и NTS) решает проблему манипуляцией временем транзакции в блокчейне Hyperledger Fabric (CVE-2024-45244). И к каким финансовым последствиям приводит атака на примере концепта вымышленного уязвимого смарт-контракта, имитирующего цифровой финансовый актив. Концепт-код для защиты от атаки был написан на Go. Поэтому он не применим для смарт-контрактов Hyperledger Fabric, написанных на других языках (Java, JavaScript, TypeScript). Поэтому, я решил сделать Оракул времени: смарт-контракт, который будет источником времени для других смарт-контрактов. Это позволит использовать оракул времени смарт-контрактами, написанными на других языках. Оракул времени доступен в исходном коде.
В этой статье убедимся, что оракул устойчив к атаке "человек посередине" (при использовании NTS). Для атаки будем использовать утилиты netsed (для подмены не зашифрованных данных) и mitmproxy (для подмены сертификата TLS). А также убедимся, что данные протокола NTP подменить возможно. Читатели, которые не знакомы с блокчейном Hyperledger Fabric, могут представить, что оракул времени - это некий API-сервис, возвращающий текущее время (посредник между клиентом и NTP/NTS сервером).

На Хабре ещё не было статей про безопасность смарт-контрактов блокчейна Hyperledger Fabric. Так что буду первым. Я занимаюсь исследованием безопасности этого блокчейна год. И сегодня хочу рассказать о довольно серьёзной проблеме: манипуляции временем транзакции (UPD 27.08.2024 уязвимости присвоен идентификатор CVE-2024-45244 после моего обращения в MITRE). По классификации, уязвимость попадает в OWASP Smart Contract Top 10: SC03:2023 Timestamp Dependence.

Рассмотрим:
- как атакующий может произвести манипуляцию временем транзакции;
- к каким финансовым последствиям может привести атака (на примере концепта вымышленного уязвимого смарт-контракта, имитирующего цифровой финансовый актив);
- какие способы защиты я предлагаю.

Также, обсудим, почему для корректной защиты от атаки может потребоваться не только изменение смарт-контракта, но и налаживание взаимодействия между командой эксплуатации смарт-контракта и администраторами сети. Статья предполагает хотя бы базовый уровень знакомства читателя с Hyperledger Fabric.

Привет, Хабр! Меня зовут Игорь Агиевич, я специалист по безопасности распределенных реестров в компании Positive Technologies. C 2021 года занимаюсь безопасностью в области блокчейн-технологий, в сфере ИТ работаю в общей сложности 17 лет.

В статье поговорим о проблемах безопасности блокчейн-проектов, пришедших из мира Web 2.0. В этой области отсутствует сложившаяся практика, поэтому в публичной плоскости крайне мало сведений о механизмах защиты, используемых этими проектами. Статья является более подробным вариантом доклада с прошедшего киберфестиваля Positive Hack Days 12 на эту же тему.

Опыт, накопленный при проведении пентестов, и понимание сетевых технологий помогли мне провести исследование атак на блокчейн-проекты, проведенных с использованием техник DNS hijacking и BGP hijacking.

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

? разберем, как злоумышленники проводили атаки на сетевом уровне (благодаря открытым данным восстановим многие шаги атак буквально по минутам);

? декомпилируем смарт-контракты (далее — контракты) атакующих;

? выясним, какие публичные механизмы защиты внедрили пострадавшие проекты и что с ними не так;

? попробуем улучшить механизмы обнаружения рассмотренных атак и защиты от них, а также рассмотрим обозреватели блокчейнов (выясним, как найти в блокчейне контракты злоумышленника, зная только один из них);

? поговорим о том, какие шаги необходимо предпринять держателям криптовалют, чтобы не стать очередными жертвами.

Не так давно компания MixBytes проводила конкурс, пройдя который можно было попасть на их курс аудитора смарт-контрактов.

Здесь публикую свой разбор этого теста.

• COVID-19: прогнозируем число больных коронавирусом (21 марта 2020)
• Коронавирус Novel nCOV/2019-nCoV/NCP/COVID19: Прогнозы, Статистика, Защита, Новости[4е переиздание, ред.05.04] (от 28 января 2020 с редакцией от 5 апреля 2020);
• О математике и пандемиях (от 28 марта 2020).

• сделан сильно раньше предыдущих (в 2013 году);
• сделал его… астролог.

1. Насколько точный прогноз?
2. Действительно ли прогноз был сделан заранее, а не по факту (и просто выдан позднее как «древнее пророчество»)?
3. Можно ли сделать подобный прогноз случайно? Какова вероятность сделать аналогичный прогноз случайно?
4. Какие ещё прогнозы делал автор, насколько они точные?

С чего всё началось

Новость

• 3.0(1d) (Available)
• 2.2(3b) (Available)
• 2.2(2e) (Available)
• 2.2(1f) (Available)
• 2.1(3f) (Available)
• 2.0(5g) (Available)

• 2.2(1d)
• 2.2(1c)
• 2.1(2a)

• 2.2(6c)
• 2.2(3e)

• ether2 — 192.168.2.0/24
• ether3 — 192.168.3.0/24
• ether4 — 192.168.4.0/24
• ether5 — 192.168.5.0/24
• wlan0 — 192.168.10.0/24

1. 9.5.3
2. 10.1.5
3. 11.0.1

• D-Link DIR-615, DIR-600 и DIR-300 (rev B)
• Netgear DGN1000B
• Cisco Linksys E1500/E2500
• Netgear SPH200D