Выбрать язык


Выбрать язык | Show only


Русский | English


понедельник, 26 декабря 2016 г.

Как свести к нулю усилия банков и операторов по защите пользователей. Чехол-кошелек для телефона

Решил недавно купить чехол на телефон. Чехол-книжку, который бы и к телефону подходил, и не стыдно было бы при уважаемых людях достать, когда позвонят. Конские цены в московских магазинах и не особая срочность вопроса послали меня на AliExpress. Пока искал, наткнулся на определенный тренд в чехлах-книжках. Учитывая массовость и количество таких чехлов, подозреваю, что я очень сильно отстал от жизни, до сих пор используя телефон с кнопками, но современная тенденция мало радует. Мало того, что чехол-кобура, используемый мной много лет, сейчас дефицит, но меня как специалиста по ИБ больше озадачил тренд делать в чехле секцию, предназначенную для банковских карточек.

воскресенье, 25 декабря 2016 г.

Безопасность Интернета вещей (IoT): компоненты, подлежащие защите

Итак, почитав немного об IoT, я выделил основные компоненты Интернета вещей. Они принципиально не отличаются от таковых в более интеллектуальных решениях.
Попробуем рассмотреть потребность в их защите на примере обычного юзера Петровича, который осознал, что возможности Интернета вещей можно использовать в повседневной жизни. Типичный пример бизнес-пользователя, только бизнес свой, а сеть общая.
http://www.tcs.com/engineering-services/PublishingImages/IoT-Services.jpg

четверг, 22 декабря 2016 г.

Конференции по ИБ в 2017 году - процент маркетинга

В продолжение своей заметки интересно развить тему понижения процента рекламного контента в конференциях поИБэ в России. Неплохая традиция у Лукацкого составлять агрегированный список мероприятий. По крайней мере, часть интересующих меня событий компактненько располагается в одном месте. Взглянул на составленный им перечень-2017, и вспомнил 2016 год со своей колокольни.

воскресенье, 11 декабря 2016 г.

Интернет вещей (IoT) и безопасность людей

О безопасности Интернета вещей в последнее время разговаривают довольно много. Решил и я поучаствовать в этой публичной дискуссии из монологов. Уровень заметки начальный.

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

пятница, 9 декабря 2016 г.

Мечты аналитика SOC: теория и практика

Перед SOC Forum в Интернете тема соков так активно муссировалась, что заметка Лукацкого об одном дне из жизни аналитика SOC ожидаемо потерялась и не была мной прочитана. Но недавно мне её показали ребята на работе. Вкратце суть: перечислялись ожидания аналитика SOC от работы и реальность, с которой он столкнётся. Процент соответствия практике в заметке довольно высок, но, тем не менее, есть несколько пунктов, которые наводят на мысль, что образ аналитика был не срисован с реальных людей реальной профессии, а смоделирован на конференциях околосочной тематики.
Остановимся на спорных (на мой взгляд) моментах, о которых, судя по заметке, должны прямо мечтать те, кто идет в аналитики:
  • завершать текущие расследования в срок
  • готовить необходимую документацию (отчеты и т.п.)
  • успешно достигать поставленных KPI.

вторник, 15 ноября 2016 г.

О чем говорить заказчику на конференции по ИБ?

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

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

суббота, 12 ноября 2016 г.

О выступлениях заказчиков на российских конференциях по ИБ

Попалась недавно на глаза заметка Лукацкого о том, почему на российских конференциях по ИБ так мало выступлений от заказчиков. Вкратце все свелось к трём причинам:
  • Технологическая недоразвитость
  • Неумение выступать
  • Нежелание выступать
Предположим, доля истины в этих тезисах есть, в особенности по отношению к SMB/SOHO заказчикам, PR-часть бизнеса которых не основывается на конференциях по ИБ. 
Попробую ответить на озвученный вопрос как представитель крупного заказчика, которому всегда есть что сказать на подобных мероприятиях, но, тем не менее, на конференциях я выступаю гораздо реже, чем, возможно, стоило бы.

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

суббота, 29 октября 2016 г.

IPv6 Security: to NAT or not to NAT?

It was interesting article on SGNOG3 conference in Singapore presented with the topic Security in an IPv6 World: Myths and Reality.

In spite of a large useful information amount I found one slide pointed NAT as a "myth" of security. It also points that NAT can even reduce security and statefull firewall is a Bruce Willis for IPv6.


It is a point for discussion.

It is clear that NAT and other technologies is not a "secure all" button. It is a tool. One can use it in a right way and another may use it in a wrong way. So it is possible to increase and decrease security level using the same technology with different approach.

Let's examine firewall. It is a security device and it must make network safer if used. If you swap some L3 device in the network part to stateful firewall you don't become protected a lot with its' default functions. If you don't use ACL, uRPF and another features you can feel a false safety. This state of the false safety is a very harmful factor. It is the same situation as if some man buys a gun to protect himself but he can't shoot psychologically. The result may be more tragic than in the case of gun absense.

понедельник, 10 октября 2016 г.

Защита от DDoS подручными средствами. Часть 3. SNMP Amplification

По согласованию с редакцией журнала публикую свою статью "Защита от DDoS подручными средствами. Часть 3. SNMP Amplification" из номера 164-165 (июль-август 2016) выпуска журнала "Системный администратор".

Чтобы сделать свой вклад в защиту всемирного киберпространства от DDoS, совсем не обязательно покупать дорогостоящее оборудование или сервис. Любой администратор сервера, доступного из Интернет, может поучаствовать в столь благородном деле без дополнительных материальных вложений, используя только знания и немного времени.

Рассмотрим DDoS-атаки типа "усиление"(amplification) с использованием сервиса
SNMP.

четверг, 6 октября 2016 г.

Protect You and Others from DDoS. Make Your Network "Cleaner" Part 1. DNS Amplification

This article was published in the May issue of the "System Administrator" journal (Russian). Original text is also available in Russian.

If you want to make a contribution to the wold-wide cyberspace security and DDoS-protection it is not necessary to buy expensive equipment or service. Any Internet-faced server admin may participate in such a noble action with no additional money but time and knowledge investment only.

Let's analyze DDoS-attacks type "amplification" using DNS.

среда, 14 сентября 2016 г.

Ответ на вопрос читателей по защите от DNS Amplification

Задали недавно вопрос по моей статье: и чем же помогут твои рекомендации защититься от DDoS самому, а не только стать бесполезным для использования в качестве амплификатора при атаке на другого?
Хотя не быть амплификатором - тоже не каждому дано, судя по анализу статистики из Shodan тут и тут, но вопрос резонный. Попробую ответить.

пятница, 9 сентября 2016 г.

Как нельзя делать. Сводим безопасность HTTPS к минимуму

Вышло недавно мелкомягкое накопительное обновление KB3172605  как фикс к  KB3161608, в состав которого входит KB3161639. В последнем меняется приоритетность шифров в винде и по факту оно объявляет погаными наборы шифров, которые на серверах отнесены к категории Weak.

В общем, кто из админов веб-серверов не изволил усиливать шифры, теперь вынужден это делать для нормальной работы web-интерфейсов.

Последние годы идет всемирная тенденция перевода HTTP-сервисов на HTTPS как в Интернет, так и внутри компаний (ибо враги могут быть всюду).
Вспоминаем, что нам дает HTTPS:
  • Шифрование передаваемых данных. Уже не прослушаешь через WiFi чужие пароли, ибо HTTPS.
  • Достоверность легитимности посещаемого ресурса. Проверка равенства CN=FQDN, заверение всемирно доверенным центром, который произвел проверку заказа (если внешний ресурс) либо корпоративным CA (для внутренних ресурсов). При этом браузер будет показывать зеленый замочек, показывая, что все хорошо, и не будет ругаться. Мало кто не видел такую позитивную картинку: 
  • Предупреждение либо защиту от атаки MITM. Защита - в случае двусторонней аутентификации, при односторонней - предупреждение с возможностью отказаться, либо отказ (в зависимости от настроек ОС/ПО).

воскресенье, 21 августа 2016 г.

Защита от DDoS подручными средствами. Часть 1. DNS Amplification

По согласованию с редакцией журнала публикую свою статью "Защита от DDoS подручными средствами. Часть 1. DNS Amplification" из майского (2016) выпуска журнала "Системный администратор".

Чтобы сделать свой вклад в защиту всемирного киберпространства от DDoS, совсем не обязательно покупать дорогостоящее оборудование или сервис. Любой администратор сервера, доступного из Интернет, может поучаствовать в столь благородном деле без дополнительных материальных вложений, используя только знания и немного времени.

Рассмотрим DDoS-атаки типа "усиление"(amplification) с использованием сервиса DNS.

EPICBANANA exploit for Cisco firewalls: checklist and fix

The article in Cisco blog with the EXTRABACON description has also information about EPICBANANA exploit executed via CLI.
Vulnerable devices list is much less that SNMP one and it consists of ASA 5500 series, ASA 5500-x series, PIX and FWSM.
Exploit is able to cause a denial if service condition or arbitrary code execution by invoking certain invalid commands in an affected device. But an attacker must:
  • Know ASA interface IP-address with ssh or telnet permission.
  • Know login and password.
  • Connect to the box from trusted IP-address.
So, it is not very hard-to-protect situation but this bug is also a bug.

суббота, 20 августа 2016 г.

EXTRABACON SNMP-exploit for Cisco firewalls - diagnostics, workaround and fix

There are lot of discussions about Shadow Brokers' published exploits NSA for a last time. But the situation became interesting when Cisco alerted to the information posted with exploits confirmation.
Cisco blog contains article about Shadow Brokers' exploits. It provides some clarity in the context of danger: to fear ot not to fear, who must be afraid of this, what is the topic of the fair and how to fear.
Additional thank to Maxim Zimovets (Cisco lvl80 engineer) for emergency analysis and vendor-side conclusion.

CLI-эксплоит EPICBANANA для Cisco - лекарство и проверка на будущее

В той же статье цискиного блога, где рассказывается об SNMP-эксплоите EXTRABACON, есть разъяснения на тему эксплоита EPICBANANA, который исполняется через CLI.
Список уязвимых устройств гораздо меньший: ASA серий 5500 и 5500-X, PIX и FWSM.
Суть уязвимости заключается в возможности вызвать отказ в обслуживании устройства либо исполнить произвольный код посредством отправки нескольких неправильных команд на скомпрометированное устройство. Но для этого хакер должен:
  • Знать IP-адрес интерфейса, на который разрешен управляющий доступ по telnet либо SSH.
  • Знать логин-пароль к устройству. 
  • Подключиться с разрешенного в конфигурации IP-адреса для управления.
Конечно, ситуация довольно предусматриваемая и не требующая сверхусилий для защиты, но, все же, баг есть баг.

пятница, 19 августа 2016 г.

SNMP-эксплоит EXTRABACON для Cisco - диагностика, заплатки и лечение

Наверное, в последнее время о продаваемых эксплоитах им. АНБ не говорил только ленивый. Но когда циска подтвердила, что таки да, 2 из них реально рабочие - стало совсем интересно. Конечно, об этом было и в новостях сесуритулаба, и на других ресурсах.
В цискином блоге есть статья о Shadow Broker'ских эксплоитах, вносящая ясность о том, стоит ли бояться, кому стоит бояться, чего бояться и как бояться. Похоже, моя заметка будет наполовину содрана с нее, но да простят меня мои читатели (все 5 или аж 6) за отсутствие количества авторских изюминок до стадии кекса. 
Ну и, конечно, отдельное спасибо инженеру Максиму Зимовцу из Cisco за оперативный анализ, в каких случаях и кому надо бояться.

вторник, 16 августа 2016 г.

NPTv6 (IPv6 NAT 6to6) security

Как я уже писал ранее, IPv6 разрабатывался с целью обеспечения всех нуждающихся IP-адресами. Естественно, в этом случае необходимость NAT на фоне концепции полной прозрачности адресации и общей математической эйфории "каждому юзеру по провайдерскому диапазону" смотрится довольно блекло. Это потом, когда возникает необходимость "спрятать" от Интернета IPv6-адрес интерфейса управления электростанцией, телеком-инфраструктурой, или ПК генерального директора - становится понятно, что старый добрый NAT 4to4 - не рудимент древней адресации, а вполне себе неплохой инструмент сетевой безопасности. Кроме того, процесс миграции всей сети на IPv6 - тоже не очень тривиальная задача. Необходимо обеспечить поддержку IPv6 на уровнях:
  • Клиента;
  • Сервера;
  • Сети L3-доступа;
  • Всех промежуточных сетевых устройств;
  • А чтобы пользователь меньше всего почувствовал, то еще и в DNS (AAAA-записи, RFC3596).



Так что, как ни крути, а NAT пригодится.

суббота, 6 августа 2016 г.

IPv6 security: NAT или не NAT?

Довольно интересную посмотрел презентацию по безопасности IPv6, описанную на конференции в Сингапуре SGNOG3 под названием Security in an IPv6 World: Myths and Reality

Несмотря на большое количество реально полезной информации, на одном из слайдов как "миф" указано то, что реализация IPv6 без NAT понижает уровень безопасности, а как "реальность" - то, что вас спасет stateful firewall, в то время как NAT может даже понизить уровень безопасности.


Собственно, это уже предмет для дискуссии.

Естественно, NAT, как и многие другие технологии, - не серебряная пуля, а исключительно инструмент, используя который можно сделать как лучше, так и хуже. 

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

четверг, 28 июля 2016 г.

Немаршрутизируемые в Интернет адреса (bogon networks) и безопасность

После прочтения заметки о даркнетах, у многих, наверное, возник вопрос: а какие именно IP-адреса не должны маршрутизироваться в Интернет и почему? И немалая часть публики, естественно, может ответить на этот вопрос, не задумываясь, но я, на всякий случай, перечислю список наиболее статичных диапазонов, которые IETF предписывает не использовать в глобальной сети Интернет. Зарезервированные диапазоны также называются Bogon/bogus networks. Официальный перечень описан в RFC6890, RFC5735 и некоторых других. Также по ссылкам (english) доступны описание и перечень bogon подсетей от Team Cymru.

суббота, 23 июля 2016 г.

Darknet + (Honeypot | ForensicLab) + (SDN | BGP)

Хотелось бы развить тему Darknet Project от Team Cymru в условиях современности. Возможно, у него и существует некоторая техническая взаимосвязь с тем Darknet'ом, о котором можно найти, загуглив ключевое слово (протоколы IPv4-маршрутизации все те же), но речь в моей заметке, все же, пойдёт не о подпольном Интернете с запретными продуктами.

суббота, 9 июля 2016 г.

If you are the smartest person in the room... да ладно?

Недавно встретил среди лайков-перелайков такую фразу:
"If you are the smartest person in the room, you are in the wrong room"
Естественно, в силу природного чувства юмора, я не преминул прокомментировать это утверждение следующим из него выводом: "So, the best room is the room where you are the most stupid person".

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

воскресенье, 3 июля 2016 г.

NANOG67: Безопасность TCP Fast Open

Преамбула
Интересно бывает проанализировать зарубежный технологический опыт, благо материалов в открытом доступе хватает. На прошедшей 13-15 июня 2016 в Чикаго конференции NANOG67 в программе присутствовала, пусть и не сверхинновационная, но очень полезная презентация "Network Support for TCP Fast Open" по проблемам использования TCP Fast Open (TFO). Спикер Christoph Paasch из Apple проводит анализ в контексте изучения веб-трафика для оптимизации ресурсов серверов.
Материал в открытом доступе, доступен как в виде краткого обзора, так и презентации, и даже видеозаписи. Кроме пользы материала, дополнительное уважение вызывает спикер, выступающий на инвалидной коляске.

суббота, 2 июля 2016 г.

PHDays: Противостояние окупается. Защита АСУ ТП

Как я уже озвучивал, Противостояние на PHDays явно имело своей целью сделать шоу, которое укажет миру на необходимость защиты промышленных систем управления. Поэтому и ГЭС остановили, оставив без света виртуальный город, и потом его же затопили. Поскольку это бизнес, то эффект от шоу должен в итоге выразиться в бюджетировании систем защиты АСУ ТП, экспертизы и анализа защищенности SCADA и т.п. 

пятница, 1 июля 2016 г.

Без интернета никуда. А как?

Навеяло недавно прочитанной новостью от Каспера, в которой говорится, что 41% россиян выходят в Сеть сразу по прилету в другую страну, рискуя своими цифровыми данными. 
Само собой, основную опасность представляет совокупность факторов:
  • наличие потенциально опасной точки бесплатного Wi-Fi, владелец которой, используя SSL strip либо MITM, сможет перехватить логины-пароли-пины-кредитки-итп;
  • невнимательность или низкий уровень понимания брешей безопасности пользователями.
MITM в этом случае современные приложения заметят и спросят, доверять ли возникшему из ниоткуда сертификату (хотя и не всегда, как описали исследователи в статье о взломе хакеров на ZeroNights), SSL strip  также имеет определенные шансы остаться незамеченным.
Евгений Касперский в вышеупомянутой новости делится опытом использования VPN в таких случаях. 
«Я много путешествую, участвую во встречах, переговорах и конференциях по всему миру, совершая более 100 перелетов в год. И, конечно, мне приходится подключаться к публичным Wi-Fi-сетям, но в таких случаях я обязательно использую виртуальную частную сеть (VPN). Это отличный способ обезопасить себя, который я смело могу рекомендовать. Но и VPN не гарантирует 100% защиты, поэтому необходимо использовать качественное антивирусное ПО, своевременно обновлять все установленные программы и ни в коем случае не терять бдительность при входе в Сеть за рубежом», — советует Евгений Касперский, генеральный директор «Лаборатории Касперского».
Говорить, что я с ним согласен, было бы, наверное, смешно, ибо очевидно. 

суббота, 18 июня 2016 г.

IXIA ThreatArmor для SOC: экономическая эффективность

И снова анализ решения, предлагаемого IXIA. Не для рекламы, а для общего развития. На этом месте мог оказаться любой вендор, и еще окажется неоднократно. Хотя, учитывая количество постов, сгенерированное семинаром IXIA, могут закрасться подозрения.
IXIA предлагает ThreatArmor как некоторое устройство, которое топологически может быть установлено в двух местах корпоративной сети: на входе из Интернет (стык с пограничным роутером или firewall), и на входе в инфраструктуру ИБ с "внутренней" стороны.

Более подробно и официально рассказано на сайте производителя и дистрибьютора. Кроме того, я в своем блоге также описывал некий блиц-анализ работы этого решения с моей точки зрения.

Вкратце: ThreatArmor позволяет осуществлять фильтрацию по IP-адресам источника (со стороны Интернет в направлении корпоративных ресурсов) либо назначения (изнутри корпоративной сети в мир). База IP-адресов категоризируется по странам, видам вредоносных воздействий и т. п. командой Application and Threat Intelligence Team. Обновление происходит каждые 5 минут.

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

пятница, 17 июня 2016 г.

Bug Bounty: сканер против человека

Прочитал недавно новость на securitylab. Основой для нее была статья на csoonline.
Оспаривается эффективность программ Bug Bounty. Не то, чтобы я большой фанат этой программы или багхантер, который тянет одеяло в свою сторону, но с некоторыми утверждениями не полностью согласен.

Посмотрим, какие используются аргументы.

четверг, 16 июня 2016 г.

SNMP в мире ШПД как источник DDoS: найти и обезвредить

Ради интереса решил посмотреть, что расскажет шодан об устройствах мира, на которых стоят значения SNMP community по умолчанию (public, private etc).
Построил отчет, благо несложно и бесплатно.

Что радует - России в Top 10 нет. В ней на момент формирования отчета шодан насчитал 55 тысяч SNMP по умолчанию, что на 14.5 тысяч меньше, чем у Ирана, который на 10 месте.
Из 3.75 млн дырявых устройств 1.43 млн держит Бразилия - больше, чем остальной Top 10 вместе взятый.

вторник, 14 июня 2016 г.

PHDays CTF: "Противостояние" глазами "защитника" в журнале "Системный администратор"

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


PHDays CTF: "Противостояние" глазами "защитника". Часть 7. Выводы





Итак, описав в шести частях наше участие в противостоянии, неплохо было бы сделать выводы по результатам соревнований. Несмотря на то, что нас не победили, я понял, что нам еще есть куда расти как защитникам. Противостояние дало возможность поработать в считающихся нереальными условиях абсолютного админского косяка: default permit на пограничном firewall и неконтролируемое появление дырявых серверов в DMZ. Как некоторый итог, для проверки степени защищенности инфраструктуры необходим определённый checklist, с которым нужно сверяться.

DNS как источник DDoS: динамика латания дыры по миру


Ни для кого не секрет, что открытые резолверы DNS с неконтролируемой рекурсией - неиссякаемый источник DDoS-атак типа amplification (усиление).
В связи с желанием сделать мир чище, в частности, в противодействии DDoS без особых затрат, решил недавно поинтересоваться статистикой наличия открытых DNS-резолверов по странам и динамикой их закрытия.

вторник, 7 июня 2016 г.

ENOG 11. Доклады по защите от DDoS и моя статья в журнале

Сегодня был на конференции ENOG 11, организованной RIPE NCC.
Логично, что меня как инженера по защите информации в большей части интересовала часть программы, посвященная защите от DDoS. На мероприятии, организованном RIPE, я был в первый раз, поэтому у меня были на счет содержимого докладов определенные ожидания. Но я нашёл, в том числе, и свою ошибку.

четверг, 2 июня 2016 г.

PHDays CTF: "Противостояние" глазами "защитника". Часть 6. Нестандартный метод защиты SSH

Глазами "защитника": как мы участвовали в Positive Hack Days CityF "Противостояние". 
Часть 6. Нестандартный метод защиты SSH
С частью 5 (описание хода сражения)  можно ознакомиться постом ранее.

- Почему нам нельзя перенастраивать сетевое оборудование, если мы его защищать должны? Без этого никак.
- А, вы телеком-защитники. Тогда вам можно, но сервисы должны быть доступны и чтобы не терялось управление. Иначе мы подойдем к вам и спросим: "Что за дела?". Если не сможете быстро починить - вернем к настройкам до начала соревнований, а вам выставим штрафные баллы. Поэтому с изменением сетевых настроек будьте аккуратны.
- Это не проблема. А если для обеспечения безопасности нам нужно будет развернуть трафик по-другому, завязать узлом, но при этом все будет работать?
- Тогда мы придем к вам с бумажкой - записать, что и как вы делали, интересно ведь.

- А зачем ты на Positive Hack Days решил Balabit использовать? Чем он там поможет?
- Будем админов мониторить. Они обещали периодически на серверах взводить дырявые сервисы.
- Ну, как знаешь.

Это два реальных разговора при подготовке к PHDays. До определенного момента я сам не думал, что они будут настолько плотно взаимосвязаны. Естественно, после разговора с организаторами я подумывал, что надо бы и удивить, раз грозился. По ходу соревнований вектор настроения потихоньку сдвинулся от первоначального желания в сторону "забетонироваться". Но чудесным образом получилось так, что в итоге они слились. И об этом пойдет рассказ.

пятница, 27 мая 2016 г.

PHDays CTF: "Противостояние" глазами "защитника". Часть 5. Сражение

Глазами "защитника": как мы участвовали в Positive Hack Days CityF "Противостояние". 
Часть 5. Сражение
С частью 4 (ограничения для защитников и SOC)  можно ознакомиться постом ранее.

Итак, ранее я описал суть соревнований, техническое обеспечение и процесс подготовки, а также определенные ограничения для тандема из "защитников" и SOC. Также, если интересно, мнение о взломе ГЭС.

Стоит приступить к описанию самого процесса противостояния - так сказать, битвы, которая длилась 29 часов - с 11:00 17 мая 2016 по 16:00 18 мая 2016.

Предварительно командами защиты и оперативного реагирования было проведено:
  • исследование сети;
  • инвентаризация инфраструктуры;
  • установка и преднастройка необходимых средств защиты;
  • реконфигуринг и патчинг дырявых серверов;
  • смена паролей, которые можно хотя бы запомнить.
Естественно, первое, что было сделано незадолго до начала - проверка работоспособности и инвентаризация ресурсов. Cразу же были обнаружены некоторые, доселе неизвестные нам, сервера, причем многие из них по факту скана оказались довольно дырявыми. Как я уже неоднократно писал, организаторы хотели шоу, и без таких фокусов было бы не очень весело.

воскресенье, 22 мая 2016 г.

PHDays CTF: "Противостояние" глазами "защитника". Часть 4. Ограничения

Глазами "защитника": как мы участвовали в Positive Hack Days CityF "Противостояние". 
Часть 4. Ограничения для команд защиты и оперативного мониторинга.
С частью 3 (мнение о взломе ГЭС)  можно ознакомиться постом ранее.

На официальном сайте конференции есть довольно пафосная цитата:
На этот раз вместо привычных соревнований CTF, мы устраиваем настоящие военные действия. События на площадке будут максимально приближены к реальности: на полигоне PHDays VI СityF развернется масштабная эмуляция городской инфраструктуры.
Вот насчет выделенного жирным и хотелось бы поговорить.

PHDays CTF: "Противостояние" глазами "защитника". Часть 3. Мнение о резонансном взломе ГЭС

Бои без правил. Организуется поединок между бойцами Орком и Гоблином. Бойцы начинающие, но публика козырная и при деньгах. Влиятельный любитель таких боев, чиновник, крышующий организаторов, делает очень крупную ставку на то, что Гоблин победит. И тут Орк наносит хороший удар в корпус, после которого Гоблин "плывет". Судья, вопреки правилам, засчитывает это как удар в пах, отводя в сторону Орка со штрафным очком и предоставив время на восстановление Гоблина. В процессе быстро шепчет Орку: "Тебе нужно лечь. Папа сказал". И Орк, отлично понимая, что даже если он победит и заберет приз, то в будущем карьера бойца в этой организации для него закрыта, начинает быстро соображать, глядя на постепенно приходящего в себя Гоблина, как подставиться под "нокаутирующий" удар, чтобы было правдоподобно и убедительно для зрителя.


Уже на следующий день после конференции PHDays-2016 весь Интернет пестрел новостями о том, как школьник взломал электростанцию и как хакеры после успешного взлома остановили ГЭС и затопили город. 
Я участвовал в составе "защитников" телекома, поэтому мнение основано на анализе ситуации и аналогиях с моей колокольни, но без знания деталей взлома SCADA.

пятница, 20 мая 2016 г.

PHDays CTF: "Противостояние" глазами "защитника". Часть 2. Подготовка

Глазами "защитника": как мы участвовали в Positive Hack Days CityF "Противостояние". 
Часть 2. 
С частью 1 (общее описание и введение) можно ознакомиться постом ранее.

Итак, наша сборная команда защитников телекома в тандеме с JSOC защищала публичные сервисы на базе IP, характерные для оператора связи: личный кабинет, портал, сервисы отправки платных сообщений, прочий VAS и т.п. Конечно, неотъемлемой частью нашей задачи было обеспечение безопасности сетевого оборудования.

По поводу команды: нам пришлось работать с коллегами-конкурентами, с которыми мы до этого не были знакомы, и я, когда только узнал об этом, думал, что сначала мы, как в "Мстителях", пересобачимся друг с другом, определяя, кто круче, а потом начнем дело делать. К счастью, я оказался неправ, и причина банальна: у нас не было на это времени. Негласный принцип был такой: если ты крут - красава, молодец, мы в тебя верим, твой талант признаем и не оспариваем, РАБОТАЙ! А я просто пересмотрелся боевиков :)

четверг, 19 мая 2016 г.

PHDays CTF: "Противостояние" глазами "защитника". Часть 1. Описание

Глазами "защитника": как мы участвовали в Positive Hack Days CityF "Противостояние". Часть 1.

17-18 мая 2016 года на конференции Positive Hack Days в Москве проводился характерный для крупных событий по практической информационной безопасности конкурс Capture The Flag (CTF). В этом году организаторы несколько модифицировали состязание, придав ему формат "противостояния" сил добра и зла в виртуальном городе, как и анонсировалось на сайте конференции PHDays-2016.
Естественно, что желающих попробовать свои силы в конкурсе было немало. Участников разделили не на 2, а на 3 функциональных направления:
  • Хакеры - естественно, их целью было получить несанкционированный доступ к защищаемым ресурсам.
  • Защитники - как очевидно из названия, главной задачей является предотвращение взлома и/или быстрое устранение его причин и последствий.
  • SOC - оперативный мониторинг подозрительных событий информационной безопасности, оповещение "защитников", совместный анализ и реагирование на инциденты.
Поскольку я участвовал в этом соревновании в качестве члена команды "защитников" инфраструктуры телекоммуникационного оператора, то дальше расскажу о мероприятии глазами инженера по защите информации.

пятница, 22 апреля 2016 г.

Does DNS use TCP or UDP? RFC says...

Usually we mean DNS uses UDP port 53 but TCP port 53 is reserved for DNS too.
After some time the one question may become interesting for any specialist working with information technologies or information security:

When does DNS use UDP or TCP?

Answer is provided by  RFC5966, section 4. Transport Protocol Selection, where you may find such statements:
Most DNS [RFC1034] transactions take place over UDP [RFC0768].  TCP
[RFC0793] is always used for zone transfers and is often used for
messages whose sizes exceed the DNS protocol's original 512-byte
limit.
So, every request except zone transfer (query type AXFR) and the large message (more than 512 bytes) containing one is processed by UDP.
One can ask: "Why AXFR and large messages must use TCP?". The reason is ability to use UDP-based services with large responses for DDoS-attacks.
All general-purpose DNS implementations MUST support both UDP and TCP
transport.
It means that each DNS-server implementation must support both transport protocols.

DNS использует UDP или TCP? Что говорит RFC

Как правило, считается, что DNS использует UDP port 53, но TCP port 53 также зарезервирован под использование для DNS.  
Со временем ответ на довольно примитивный вопрос начинает интересовать каждого специалиста, так или иначе имеющего отношение к информационным технологиям и безопасности: 

В каком случае DNS работает по UDP, а в каком - по TCP?

На этот вопрос отвечает действующий документ RFC5966, раздел 4. Transport Protocol Selection, в котором фигурируют следующие утверждения:
Most DNS [RFC1034] transactions take place over UDP [RFC0768].  TCP
[RFC0793] is always used for zone transfers and is often used for
messages whose sizes exceed the DNS protocol's original 512-byte
limit.
То есть, большинство DNS-запросов будет обрабатываться с использованием протокола UDP, исключение составляют трансфер зоны (Query type AXFR) и ответы сервера, превышающие 512 байт на одно сообщение. На вопрос "зачем" ответ простой: чтобы не использовались для DDoS.

All general-purpose DNS implementations MUST support both UDP and TCP
transport.
Это означает, что все реализации DNS-серверов в общем случае должны поддерживать использование обоих протоколов транспортного уровня: TCP и UDP.

воскресенье, 3 апреля 2016 г.

Routing and ACL direction

Sometimes I can see questions related to the ACL directions needed for the traffic filtering on the network equipment.

Let's suppose a case when PC is located in the network 10.0.10.0/24 and DNS server - in the 10.0.20.0/24 one. See the picture.

Маршрутизация и направление ACL

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

Рассмотрим на примере, когда ПК находится в подсети 10.0.10.0/24, DNS-сервер - в 10.0.20.0/24. См. картинку.

суббота, 2 апреля 2016 г.

Linux "show mac-address-table" analogue

Few days ago I could see a user question about Linux analogue for Cisco "show mac-address-table" command. He wo'nt use the "arp"or "arp -a" command for some hidden reasons. And I think it may be interesting for other users.

Аналог команды Cisco IOS "show mac-address-table" в Linux

Пару дней назад я увидел в Интернете вопрос о том, какой в Linux существует аналог команды Cisco IOS "show mac-address-table". При этом пользователь категорически не хотел пользоваться командой "arp" либо "arp -a". То ли с целью парсинга и вывода на третьи системы, то ли еще из каких побуждений. Естестенно, мне стало интересно, и свой вариант я опишу в этой, так сказать, "статье".

SPAN-aggregation and packet brokers. Protocol Stripping

Why you may need protocol stripping function?
As you know there are 7 OSI model levels. Each one adds some particular volume header to the packet. 

пятница, 1 апреля 2016 г.

SPAN-агрегация и пакетные брокеры. Удаление лишних заголовков, или Protocol Stripping

Зачем нужен этот функционал?
Как известно, у модели OSI 7 уровней, и каждый из них привносит в пакет свой дополнительный объем. В самом простом случае, на который рассчитаны все анализаторы сетевого трафика, пакет содержит MAC-адреса отправителя и получателя, затем идут IP-адреса. В то же время, по зеркалируемым линкам влета в ЦОД и уровня распределения может идти 802.1q-тегированный трафик либо MPLS с метками. Оба этих вида заголовка помещаются между заголовками канального и сетевого уровней. На моей практике случалось, что анализирующие устройства либо просто не понимали их и игнорировали (лучший случай), либо начинали неверно интерпретировать информацию более высокого уровня (худший случай, когда зашитые алгоритмы для увеличения пропускной способности устройства при вычислениях используют побитовое смещение относительно начала пакета). 
То есть, если у нас явным образом не стоит задача определения номера VLAN/VXLAN, метки MPLS, GTP и т.п., можно удалить их с помощью пакетного брокера.



четверг, 31 марта 2016 г.

SPAN-aggregation and packet brokers. Packets deduplication


One may ask: is it real to be so stupid implementing TAPs and brokers that packets are duplicated? Yes, of course, and it doesn't indicate architects' stupidity. E.g. we need the datacenter traffic analysis. So, it is necessary to mirror datacenter uplinks (no matter Internet or corporate) to have an incoming/outgoing traffic visibility, and aggregation/service layer links according to the datacenter network design. Inbound/outbound packet has no duplicates if it is going to some segment connected via dedicated physical lines, no router/firewall on a stick etc.