суббота, 24 марта 2018 г.
Кто там? В Евросоюзе предложили скрыть данные владельцев доменных имен
Так, Корпорация по управлению доменными именами и IP-адресами (ICANN) предлагает исключить информацию о владельцах доменов (имя, адрес и др.) из WHOIS, чтобы привести принципы работы системы в соответствии с GDPR.
Разбираемся, зачем это нужно и кого затронет.
/ Pixabay / SplitShire / CC
Почему WHOIS «не дружит» с GDPR
GDPR заменит Директиву по защите данных ЕС, которая действует с 1995 года. Главная особенность нового постановления — ужесточение требований к хранению и обработке персональных данных.
Регламент значительно расширяет права физических лиц по контролю за собственной конфиденциальной информацией. Пользователи будут лучше осведомлены, как используются их персональные данные. Они смогут запрещать их обработку и активно пользоваться правом на забвение. GDPR предусматривает серьезные штрафы для компаний за нарушения новых правил — до 20 млн евро или 4% годового оборота организации.
Сетевой протокол WHOIS, который используют для получения регистрационных данных о владельцах доменных имен — имен/названий и контактной информации — «конфликтует» с постановлениями GDPR. В ICANN посчитали, что с точки зрения нового регламента эта информация считается конфиденциальной, соответственно ее публикацию в открытом доступе можно трактовать как нарушение новых правил обработки персональных данных.
/ Данные WHOIS о wikipedia.org
Что предлагает ICANN
Обязательства по администрированию WHOIS лежат на ICANN. Корпорация заключает соглашения с тысячами регистраторов доменов по всему миру и требует от них предоставлять достоверные данные. Сейчас ICANN принимает участие в подготовке новых положений GDRP и дает свои рекомендации. Одна из них поступила от президента и главного исполнительного директора ICANN Йорана Марба (Göran Marb).
Чтобы привести WHOIS в соответствии с GDPR, он предлагает три модели:
- Модель первая — работает только на территории Европейской экономической зоны. Персональные данные владельцев доменов будут скрыты, но к ним смогут обратиться те люди и организации, которые докажут необходимость получения этой информации. Эта модель незначительно отличается от действующей сейчас, однако не описывает критерии оценки правомерности доступа к ПД.
- Вторая — многоуровневая система, в которой большая часть данных закрыта, однако определенная группа лиц может получить к ним доступ после прохождения аккредитации.
- Третья — большая часть ПД скрыта. Получить к ним доступ можно только по решению суда. Эта модель отвечает основным идеям GDPR.
С точки зрения обычного пользователя, который хочет воспользоваться системой WHOIS, обращение к персональным данным владельцев доменных имен во всех трех случаях будет выглядеть так: вся информация закрыта, но есть анонимный адрес электронной почты. Через него письмо будет перенаправлено на реальный адрес владельца.
Сейчас WHOIS используется для связи с администраторами, разрешения технических вопросов, проведения сделок по продаже доменов, уточнения адреса компании. Этой информацией также пользуются правоохранительные органы. Например, данные владельцев доменов, с которыми связывают кибератаки, позволяют установить личность преступников.
Предполагается, что разработка системы аккредитации ляжет на плечи Правительственного консультативного комитета (GAC). Так, по мнению ICANN получится соблюсти закон и государственные интересы.
Также ICANN объясняет необходимость изменений тем, что WHOIS используется для рассылки спама, фишинга и совершения киберпреступлений. Основной ущерб эта деятельность наносит владельцам доменных имен, которые являются клиентами регистраторов. Поэтому последние заинтересованы в пересмотре действующей системы.
Недавно ICANN заявили, что больше не будут предъявлять судебные иски регистраторам, которые не публикуют персональные данные в WHOIS. Крупнейший регистратор доменных имен в мире — GoDaddy уже начал скрывать ПД. Вице-президент компании объяснил, что таким образом они защищают клиентов от спама.
Судьба инициативы
На прошлой неделе план ICANN был отвергнут Европейской комиссией. Это было сделано из-за того, что внесенные ICANN предложения базируются на неполной информации GDPR. При этом необходимость таких мер была недостаточно обоснована и не подкреплена статистикой или аналитической информацией.
Также причиной в отказе послужили опасения по поводу анонимных киберпреступлений. Данные WHOIS являются ключевым инструментом в борьбе с киберпреступностью. Модель, в которой правоохранительные органы должны получать разрешение на доступ к информации через суд, препятствует оперативному расследованию таких дел. Такую позицию занял центр киберпреступности Европола.
Анонимность владельцев доменов также скажется на юристах, работающих с вопросами интеллектуального права. Данные WHOIS помогают им находить людей, распространяющих пиратский контент. К базам WHOIS часто обращаются журналисты для проведения расследований. ICANN не разъясняет, смогут ли получить аккредитацию.
Хотя инициативу ICANN и отклонили, члены Европейской комиссии рекомендовали компании продолжить работу над новыми политиками. Поэтому, вероятно, обсуждение этого вопроса будет возобновлено в ближайшее время.
Несколько материалов из нашего корпоративного блога:
Конференция DEFCON 22. «Массовое сканирование Интернет через открытые порты». Роберт Грэхам, Пол МакМиллан, Дэн Тэнтлер
Просканировать Интернет достаточно просто – Вы садитесь перед компьютером, запускаете консоль с командной строкой и вводите адрес подсети. И Вы наблюдаете, как Ваш экран заполняется данными, а строки всё бегут и бегут дальше. В результате Вы получаете список открытых портов устройств с различными IP-адресами.
Для чего нужно сканировать Интернет в контексте защиты? Если Вас волнуют вопросы безопасности, это необходимо сделать, чтобы получить ответ на следующие вопросы:
- сколько компьютерных систем подвержены уязвимости Heartbleed (ошибка в криптографическом ПО, которая позволяет злоумышленнику прочитать память клиента или сервера и получить закрытый шифровальный ключ сервера)?
- сколько компьютерных систем можно использовать для усиления атак на NTP-серверы?
- сколько систем подвержены риску благодаря уязвимости роутеров D-Link?
- обзор всех используемых сертификатов SSL.
Существующие инструменты для нахождения уязвимости конкретных сетей и оборудования довольно медленные, но массовое сканирование позволяет Вам получить характеристики уязвимости свыше 100 000 устройств достаточно быстро. Важной проблемой, которую необходимо решить, является выявление оборудования, которое используется для связи с NTP-серверами при проведении DDOS-атак. Множество домашнего оборудования уязвимо из-за того, что в роутерах D-link недостаточно сильная защита. Достаточно посмотреть на сети D-link, чтобы увидеть, сколько ботнет-систем пользуются их уязвимостью. Сканирование SSL-сертификатов также полезно, потому что выявляет устаревшие сертификаты, подверженные ошибкам и уязвимостям. Так что сканирование всего, до чего можно «дотянуться», является важной задачей.
Сканирование Интернет нужно также в контексте профилактики. Оно помогает выявить Deepnet – множество Интернет-страниц, которые не видны поисковым системам. Эти страницы генерируются по запросам пользователей и могут нести в себе вредоносную информацию.
Попробуйте просканировать случайные порты, запустив команду массового сканирования "- banners", и в течение нескольких минут Вы обнаружите то, что можно взломать без труда.
В действительности сканировать Интернет полезно, потому что:
- это весело;
- это информативно (Вы можете увидеть, насколько мал Интернет, запустив команду сканирования 0.0.0.0/0, в Интернете имеется всего 65 тысяч портов);
- Это сделает Вас известным:
— выберите цель, например, систему управления Siemens;
— просканируйте для неё Интернет;
— создайте для неё конференцию компьютерной безопасности BlackHat Talk;
— пользуйтесь полученными привилегиями эксперта.
Что нужно знать для того, чтобы просканировать Интернет? Во-первых, нужно знать теоретическую часть физической инфраструктуры:
- пакеты данных имеют фиксированный размер:
— пакеты Ethernet вмещают в себя 44 байта;
— пакеты TCP SYN вмещают в себя 40 байт. - максимальные скорости 1 Гбит / с Ethernet:
— 476 Мбит / с для реального трафика;
— 524 Мбит / с для Ethernet соединения;
— 1488000 пакетов в секунду.
Это означает, что мы переплачиваем провайдеру из-за того, что он берёт с нас плату за гарантированную ширину пропускания, то есть за гарантированный, а не фактический объём данных. Это происходит из-за избыточного размера пакета. Если мы передаём 22 или 33 байта, они всё равно упаковываются в пакет размером 40 или 44 байта. Пользователь практически никогда не может достичь полной ёмкости передачи данный в 1 гигабит, потому что реально в секунду он передаёт не более 524 мегабит. Но из-за фиксированного переполнения пакетов данные имеют размер с запасом, и этот запас никак не используется. Но мы за него платим. Даже если у нас есть идеально настроенный свитч, мы всё равно не сможем воспользоваться полной пропускной способностью сети, и я не знаю, почему так происходит. Неразбериха имеется и в системе оплаты счетов за услуги Интернет.
Как формируются счета на оплату трафика у Интернет-провайдеров:
- некоторые обеспечивают нам максимальную скорость Интернет-подключения 1 Гбит / с;
- некоторые измеряют реальную пропускную способность рабочей сети, обеспечивая нас скоростью около 600 Мбит / с;
- некоторые Интернет-провайдеры не видят маленьких пакетов, таким образом, они фиксируют только входящий, а не исходящий трафик. Например, мы передали тонну информации, а заплатили за несколько мегабайт, которые скачали из сети;
- некоторые провайдеры вообще не измеряют объём трафика, и это представляет для нас особый интерес!
Например, в Германии есть клуб ССС, который обеспечивает пользователей скоростью 100 Гбит / с. Я не смог протестировать эту сеть, но возможно, в этом году я возьму с собой свою 10 гигабитную Ethernet-карту и проверю, так ли это на самом деле. Но проблема заключается в том, что когда мы отправляем слишком маленькие пакеты, мы тем самым нарушаем существующие договорённости между пирами одной сети.
Рассмотрим физическую инфраструктуру сети дальше.
Частные виртуальные сети VPN умеют подстраиваться под нагрузку маленьких пакетов. Ethernet борется с маленькими пакетами, и скорость свыше 500 Кбит / с часто затруднена. Если Ваш свитч способен работать с такой скоростью, это не означает, что остальные элементы инфраструктуры могут её поддержать. В этом случае может помочь отключение управления потоком данных Flow Control, при котором передатчик притормаживает передачу данных, если приёмник не готов их принять.
В некоторых случаях пакеты могут теряться – передача на скорости 500 Кбит / с не гарантирует, что все пакеты достигнут сети Интернет. Сканирование позволяет выявить порты, при использовании которых наблюдаются потеря пакетов. Вы можете использовать только те порты, которые обеспечивают одинаковый приём-передачу: если Вы отправляете 10 тысяч пакетов, то и получите тоже 10 тысяч пакетов. Поэтому я в основном использую скорость до 150 Кбит / с, а иногда даже 15 Кбит / с, это позволяет не задумываться о целостности пакетов.
Большой проблемой являются жалобы на злоупотребления, Abuse Complaints. Этот термин означает, что кто-то пометил Вас, как источник спама или другого вредоносного действия. Часто такое случается с компаниями, когда адресат не хочет больше получать от Вас письма, но не может отписаться от рассылки, потому что Ваша компания не сообщила ему ссылку для этого. Он помечает Вашу почту как спам, и это вредит общей репутации. Такое может произойти при сканировании сети. Вы можете получить Abuse Complaints, и ваш ISP серьёзно этим огорчится. Или Вы нарушите соглашение между пирами, Вам запретят играть роль пира. Однако существуют намного худшие вещи:
- сканирование угрозы Heartbleed сгенерирует Abuse Complaints на несколько недель позднее, и Вы всё равно получите удар по репутации;
- сканирование HTTP может отправить Вас в бан-лист fail2ban, то есть Ваш IP будет заблокирован;
- нарушение правил обнаружения угроз Snort Threat Rules может также создать множество жалоб Abuse Complaints.
Cуществующая методология мониторинга сети отслеживает входящий трафик. Если Вы используете сканирование, Ваш входящий трафик будет большим, и Вы попадёте под подозрение. Считается, что так можно отследить хакеров, хотя это всё равно, что искать потерянные в кустах ключи под уличным фонарём только потому, что там светлее.
К чему Интернет-провайдеры должны относиться серьёзно? К тому, что некоторые сети используют blackholing («маршрутизацию в некуда», когда пакеты такой маршрутизации будут удалены по причине «No route to host») для целой автономной сети AS.
Список исключений необходим при сканировании, так как мы не хотим сканировать чужие почтовые ящики и сегменты сети частного характера. Создание списка исключений производится с помощью задания параметров сканирования в командной строке:
/etc/masscan/masscan.conf
exclude = 224.0.0.0-255.255.255.255
exclude-file – exclude.ips
Важной вещью является создание публичного списка исключений. Мы бы очень хотели создать публичный список экспертов в области безопасности, но большинство из тех, кто присылает нам запрос на участие в программе, обычно просят убрать их из этого списка. Они боятся, что кто-то узнает их IP или адреса корпоративной сети и попытается их взломать. К счастью, сети BGP обладают всей этой информацией в публичном доступе, которая выложена в довольно изящном формате и доступна всем. Люди должны понимать, что сканирование Интернет принесёт им только пользу и никоим образом не затронет личной информации, которую они не хотят никому показывать. К сожалению, большинству приходится это доказывать, потому что они путают сканирование и хакерство. Да и вообще людям трудно поверить в то, что можно просканировать весь Интернет.
Например, компания имеет некую сеть, которую мы сканируем по их просьбе, но у них также имеется и подсеть, в которой хранится важная информация. Так вот, увидев, как проходит сканирование, они пугаются и говорят: «Вы сканируете даже скрытые сети, Вы видите диапазон портов и адресов, поэтому Вы можете нас взломать»!
Шесть месяцев назад произошла интересная история. Я сканировал сеть для одного заказчика, и его разбудили ночью звонком по поводу экстренной конференции, созванной из-за взлома сети. Он позвонил мне, и я вынужден был его успокаивать и объяснять, что сканирование не имеет никакого отношения к хакерской атаке, просто они нашли их уязвимости раньше, чем мы. Часто клиенты считают, что как только они дают нам разрешение на сканирование, тут же открываются какие-то бреши в защите, и туда сразу же лезут хакеры.
Ещё один случай был с одним парнем из Австралии. Он заметил, что мы при сканировании сети послали ему запрос на соединение в виде единственного SYN-пакета, и позвонил мне, мол, кто мы такие и на каком основании этим занимаемся. Я всё объяснил, сообщил ему адрес нашего сайта, где есть все регламенты и правила, сказал, что мы занимаемся этим абсолютно легально, по заказам клиентов. Он ничего не захотел слушать и принялся угрожать нам Интернет-полицией, что немедленно позвонит куда следует и нас всех арестуют. Просто какой-то сумасшедший, который не понимал, что если бы мы занимались сканированием незаконно, уже через час нас бы всех поймали, потому что мы действуем совершенно открыто.
Подобные жалобщики часто просто глупы. Они не понимают, что подавляющее большинство процессов, проходящих в сети, все порты, роутеры, свитчи, сессии постоянно открыты и не защищены никаким шифрованием. Просто иначе Интернет не смог бы работать вообще, если бы на каждое действие требовалось разрешение. Если человек боится, что данные его банковской карты могут украсть, ему лучше вообще не пользоваться Интернетом. И это происходит на фоне того, что люди не в состоянии просто сконфигурировать свои устройства так, чтобы закрыть имеющиеся бреши. Они оставляют их открытыми для всех и потом удивляются, что стали добычей хакеров. Хочу показать Вам полученное нами письмо такого содержания: «Инфраструктура финансовой группы Woori классифицируется как „оборудование объекта национальной безопасности класса А“ и несанкционированный доступ к этому оборудованию запрещён соответствующими законами и правилами». Эта компания расположена в Корее, и мы впервые узнали о ней из этого письма, потому что они не только отправили на нас жалобу, но и объяснили свои действия письмом. Я впервые встретил целую организацию, которая хочет иметь доступ в Интернет и при этом засекречивает всё своё оборудование. Зачем тогда вообще выходить в Интернет, если это невозможно сделать с закрытыми портами?
Важным аспектом для нашей работы является тесное сотрудничество с Интернет-провайдерами. Мы должны с ними дружить, иначе у нас не получится результативного сканирования. Мы предлагаем им бесплатные консультации по Интернет-безопасности, они помогают нам корректировать список поступающих жалоб. То есть провайдер разбирается, кто и почему на нас пожаловался, и отвергает необоснованные обвинения в наш адрес. Вместе с ними мы создаём проект SWIP – «Кто есть кто в Интернете» со списком проверенных IP-адресов, и заносим в наш «чёрный список» тех, кто настаивает, чтобы нас забанили за сканирование.
В качестве альтернативы, помогающей избежать некоторых недоразумений, можно создать анонимный виртуальный выделенный сервер VPS. Он обладает такими преимуществами:
- провайдеру VPS можно заплатить небольшую сумму в биткоинах;
- можно провести сканирование без всяких жалоб, так как Вы просто отключаете свой аккаунт от сети после проведения исследования, например VPS на хостинге Linode позволяет удалить аккаунт немедленно после оплаты $50;
- достаточное количество таких провайдеров благосклонно относятся к спамерам и доносчикам, работающим под прикрытием виртуальных серверов.
На что же похожа технология masscan?
Она похожа на утилиту nmap, которая предназначена для сканирования IP-сетей с любым количеством объектов и определения состояния портов и соответствующих им служб:
- все опции nmap можно разобрать по частям, кроме тех, про которые сказано: «эта опция nmap не поддерживается»;
- при использовании некоторых инструментов полезным является то, что выходные форматы данных близки к nmap;
- поддерживается много возможностей, таких как сканирование протокола передачи с управлением потоком SCTP или использование протокола пользовательских данных UDP в качестве полезной нагрузки nmap.
А вот чем masscan не похожа на nmap:
- режим Port-at-a-time вместо режима Host-at-a-time. Это означает, что результаты для каждого порта сообщаются сразу же, как он будет обнаружен, и эти результаты не объединяются друг с другом при помощи хоста. То есть нашей программе не нужно посылать запрос, получать ответ и тратить на это время. Нет необходимости хранить в памяти миллиард запросов и миллиард ответов, поэтому она работает быстрее.
- Она работает асинхронно: передаваемый массив создаётся из запросов, получаемый массив создаётся из откликов;
- она сканирует в 1000 раз быстрее.
Nmap является лучшим сканером – её скриптовый движок NSE очень гибок, а сканирование нескольких хостов выполняется без проблем. Masscan же предназначена для больших сетей, так как эта программа намного быстрее и лучше масштабируется.
Masscan имеет собственный TCP/IP стек:
- он работает параллельно с существующим стеком;
- по умолчанию имеет тот же адрес;
- служит для дублирования протокола сетевого уровня ARP и пакетов TCP RST.
Вот как производятся хакерские атаки с подменой адреса, так называемые спуфинг-атаки. Пусть у нас есть хост А – атакующий, хост V, на который нападают, и хост O, IP-адрес которого хакеры хотят использовать для атаки.
Хост А отправляет SYN-пакет хосту V, но обратным адресом указывает не свой IP адрес, а адрес хоста О. Атакуемый хост V отвечает хосту O пакетом SYN/ACK. Но хост О ничего не посылал хосту А и поэтому должен разорвать соединение пакетом RST. Предположим, что хост О не выслал такой пакет, потому что был перегружен, или выключен, или находится под защитой файервола, который блокирует пакеты SYN/ACK.
Если хост О не отправил пакет RST и не прервал начавшуюся атаку, хакерский хост А может взаимодействовать с хостом V, выдавая себя за хост О. Поэтому любой авторизатор, проверка капчи и прочее становится бесполезным, если файервол пользователя настроен неверно.
Таким образом, пакеты RST защищают IP-соединения от установки связи, то есть отвечают на пакеты SYN-отказом. С их помощью мы можем защитить от спуфинга различные IP-адреса, или установить защитный фильтр для определённого диапазона портов.
А теперь поговорим о командах, которыми управляется masscan.
Сканирование нескольких устройств производится таким образом, чтобы не нарушались протоколы безопасности:
- — — shard 1/50 используется, когда нужно просканировать несколько компьютеров;
- — — source-ip 10.0.0.32 — 10.0.0.63 расширяет диапазон сканирования до нескольких IP адресов на одном и том же компьютере;
- — — source- ip 0.0.0.0 – 255.255.255.255 не стоит использовать вообще! Вы просто не дождётесь никаких результатов, и Ваш компьютер зависнет.
Иногда для избежания проблем проводится ручная настройка соединения TCP/IP:
- — — source-ip 192.168.10.15;
- — — source-port 4444;
- — — router-mac 00-11-22-33-44-55 при — - router-ip 192.168.10.1.
Вот что делает команда проверки баннеров:
- устанавливает TCP соединение;
- выполняет эвристический анализ протоколов, то есть сканирует порт 443 на предмет SSH и HTTP, которые интернет адресует на этот порт.
В настоящий момент я использую что-то похожее на NSE-скриптинг, но скоро перейду на программирование на основе С.
Вы также можете использовать тестирование нагрузки. Это может «пробить» защиту файерволов и поэтому актуально для проверки их способностей обеспечить безопасность. В этом случае команды — - infinite, — - banners, — - sourse-ip <диапазон > являются полезными для быстрого сканирования большого количества устройств.
Обычно никто этим не пользуется, но в нашей программе существует возможность использования исходящих двоичных файлов, для этого используется команда:
– oB foo.scan вместо –oX foo.xml
Затем выполняется конвертирование:
masscan–readscan foo.scan –oX foo.xml
Данный способ обеспечивает более компактное сканирование. Кроме того, если в исходящих данных имеются ошибки, их легче поправить в двоичном формате.
Ещё одна полезная функция — это сканирование spoofing. IP-spoofing заключается в подмене IP-адреса в теле пакета так, чтобы ответный пакет перехватывался хакерским адресом. Эта технология используется хакерами для перехвата трафика между хостами в Ethernet-сетях.
Spoofing cканирование состоит в следующем:
- приём пакета одним IP-адресом, например, смартфоном под управлением Android;
- принимаемые пакеты обладают низкой пропускной способностью;
- отправка пакетов из дата-центра без исходящих фильтров, команда — - source- ip позволяет просканировать spoofing другого IP-адреса.
Вот как выглядят результаты сканирования. На первой картинке Вы видите окно нашей программы, на второй – результат её работы.
Результат проверки на угрозу Heartbleed показывает, что по состоянию на 10 апреля уязвимость была обнаружена в 600 000 систем, и в июле 300 тысяч систем всё ещё оставались уязвимыми, причём большинство из них составляли аппаратные устройства, то есть сами компьютеры, роутеры, веб-камеры и серверы. То есть Вы не увидите их уязвимость, если проверите их по DNS-именам, помогает только сканирование по IP-адресам. Мы просканировали также мейнфремы – большие отказоустойчивые серверы, например TN3270 Telnet –over-SSL через порт 992. Вы можете взглянуть на @mainframed767 и увидеть такие интересные вещи, как окно авторизации пользователя главного сервера IBM.
Третья картинка изображает результаты сканирования баннеров. Сейчас я попробую показать Вам нашу программу в действии. Для этого я открываю главное окно и командной строкой задаю адрес сервера, который хочу просканировать. В некоторых случаях сервер не отвечает.
Сейчас Пол попробует зайти под своим логином и продемонстрирует возможности сканирования.
Пол говорит, что если у вас возникнут какие-то вопросы по использованию программы, можно связаться непосредственно с ним и получить нужные объяснения. В качестве примера Пол приводит сканирование Интернет через сервер VNS 5900, которое занимает от 15 до 20 минут.
Преимуществом нашей программы является возможность получения списка уязвимостей без необходимости авторизации в сети или на каждом сетевом устройстве. Мы проверяем систему снаружи, а не изнутри. Использование масштабирования позволяет проверять огромные массивы Интернет-сети, в том числе облака, и это стоит меньше 16 центов в час.
Вот сейчас я задаю медленное сканирование сети defcon через порт 80 по 10 пакетов в секунду, и результат немедленно появляется на экране.
В данный момент мы видим, сколько в сети открытых незащищённых портов устройств с соответствующими IP-адресами. И хакер может использовать эти IP-адреса для своей spoofing атаки.
Эта процедура совершенно не мешает работе сети, которая подвергается сканированию, пользователь может запускать любые приложения. Итак, сканирование сети defcon заняло чуть больше минуты, и мы определили все существующие уязвимости, просто просканировав порт 80. Задавая размер пакета, можно ускорить или замедлить сканирование. Мы рассказали всё, что нужно знать о программе masscan, и если у Вас есть вопросы, пишите нам на электронную почту или твиттер @erratarob и paulm.
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас:Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
«Из Японии в Сингапур»: новый подводный кабель пройдет через 9 стран Азии
О подробностях проекта далее.
/ фото COMSEVENTHFLTCC
Характеристики кабеля
Протяженность кабеля будет равна 10,5 тыс. км — он соединит Японию, Южную Корею, материковый Китай, Тайвань, Гонконг, Таиланд, Камбоджу, Вьетнам и Сингапур.
SJC2 будет состоять из восьми оптоволоконных пар. При пропускной способности 144 Тбит/с скорость передачи данных на каждую пару составит 18 Тбит/с. Проект планируют завершить к четвертому кварталу 2020 года. Стоимость SJC2 пока не разглашается, однако известно, что в предыдущий кабель (SJC) инвестировали 400 млн долларов.
Для чего потребовался кабель
SJC2 дополнит SJC, который проложили в 2013 году. SJC и SJC2 будут «пересекаться» в Китае, Гонконге, Японии, Сингапуре и Таиланде, однако второй кабель подключит новые страны: Камбоджу, Южную Корею, Вьетнам и Тайвань.
Председатель SJC2 Линетт Ли (Linette Lee) считает, что строительство SJC2 — ключевой этап сотрудничества стран Азии в области цифровых технологий. Новый, более мощный кабель дополнит своего предшественника, первоначальная проектная пропускная способность которого была равна всего 28 Тбит/с. Система кабелей поможет обеспечить бесперебойную связь и уменьшит задержки для компаний экономически активного региона и их клиентов.
Один из представителей тайваньских операторов, председатель и CEO телекоммуникационной компании Chunghwa Telecom Ю Ченг (Yu Cheng) утверждает, что кабель SJC2 поможет организации обеспечить работу множества мультимедийных приложений при запуске 5G-сервисов в 2020 году.
Со стороны исполнителя проекта — компании NEC — комментарий дал Ацуо Кавамура (Atsuo Kawamura). Он подчеркивает, что SJC2 позволит справиться с последующим ростом требований к пропускной способности в регионе.
Почему NEC?
Можно предположить, что компания NEC была назначена на этот проект не случайно — её сотрудники имеют большой опыт в реализации подобных проектов.
В ноябре 2016 года компания завершила подводный кабель Asia-Pacific Gateway (APG), который соединил Китай, Гонконг, Японию, Южную Корею, Малайзию, Тайвань, Таиланд, Вьетнам и Сингапур. Скорость передачи данных по APG составляет 54 Тбит/с.
В мае 2017 года специалистам организации удалось осуществить передачу данных по подводному кабелю длиной 11 тыс. км на скорости 50,9 Тбит/с (по одному оптоволокну). Ученые использовали оптимизированный алгоритм модуляции opt32, который позволил получить спектральную эффективность в 6,14 бит/с/Гц. При этом они применили легированные ионами эрбия (EDFA) волоконно-оптические усилители.
А в 4 квартале 2019 года NEC планируют закончить прокладку системы кабелей, которая соединит Гонконг и Гуам. Её протяженность составит 3900 км, а её пропускная способность — 50 Тбит/с.
/ фото Naval Surface WarriorsCC
Другие проекты в Азиатско-Тихоокеанском регионе
Во втором квартале 2018 года завершится проект Trident. Этот подводный кабель соединит Сингапур, Индонезию и Австралию. Его пропускная способность составит 28 Тбит/с.
Еще один кабель — Hawaiki — соединит Австралию и Новую Зеландию с Гавайями и западным побережьем США к середине 2018 года. Общая протяженность кабеля составит 14 тыс. км, а пропускная способность — 30 Тбит/с.
Еще один проект, который должен завершиться в этом году – кабельная система Bay of Bengal Gateway (BBG). Она объединит Сингапур, Малайзию, Индию, Шри-Ланку, Оман и ОАЭ.
P.S. Свежие материалы из Первого блога о корпоративном IaaS:
P.P.S. Посты по теме из нашего блога на Хабре:
[Из песочницы] Пощупать нейросети или конструктор нейронных сетей
А теперь немного подробнее. С помощью этого конструктора можно создавать сети прямого распространения (Feedforward neural network) до 8 скрытых слоёв (плюс слой входов и слой выходов, итого 10 слоёв) в каждом слое до 30 нейронов (ограничение связано с тем, что всё это одновременно отображается на экране, если будут просьбы в комментариях выпущу версию без ограничений и визуализации). Функция активации всех нейронов – сигмоид на основе логистической функции. Также можно обучать получившиеся сети методом обратного распространения ошибки градиентным спуском по заданным примерам. И, самое главное, можно посмотреть на каждый нейрон в каждом отдельном случае (какое значение он передаёт дальше, его смещение (поправку, bias) – нейроны с отрицательным смещением белые, с положительным – ярко-зелёные), связи нейронов в зависимости от их веса помечены красным – положительные, синим – отрицательные, а также отличаются по толщине – чем больше модуль веса, тем толще. А если навести мышку на нейрон, то можно ещё посмотреть какой сигнал на него приходит, и какое конкретно у него смещение. Это полезно, чтобы понять, как работает конкретная сеть или показать студентам принцип работы сетей прямого распространения. Но самое главное – свою сеть можно сохранить в файл и поделиться с миром.
Далее будут инструкции по пользованию программой, встраиванию созданных сетей в свои проекты, а также разбор нескольких сетей, идущих в комплекте.
Как пользоваться конструктором
Для начала скачайте архив отсюда.
Распакуйте в корень диска D:\
Запустите NeuroNet.exe
Можете попробовать «Загрузить» какую-нибудь сеть, посмотреть на неё, нажать «Обучение», увидеть её точность, потыкать стрелки влево, вправо (по бокам), чтобы посмотреть различные варианты входных (левый столбец нейронов) и выходных (правый) данных, нажать «Стоп» и попробовать ввести свои входные данные (разрешены любые значения от 0 до 1, учитывайте это при создании своих сетей и нормализуйте входные и выходные данные).
Теперь как строить свои сети. Первым делом необходимо задать архитектуру сети (количество нейронов в каждом слое через запятую), нажать «Построить» (или сначала «Снести», затем построить, если у Вас на экране уже отображается другая сеть), нажать «Обучающая выборка», «Удалить всё» и ввести свои обучающие примеры, согласно инструкции на экране. Также можно указать на вход и на выход маленькие квадратные картинки (максимум 5х5 пикселей), из которых будут определены нормализованные значения яркости пикселей (не учитывая их цвет), для чего нужно нажать на «in» и «out» соответственно. Нажать «Добавить пример», повторить процедуру нужное количество раз. Нажать «Готово», «Обучение» и как точность станет удовлетворительной (обычно 98%), нажать «Стоп», иконку в виде дискеты (сохранить), дать сети имя и радоваться, что Вы сами создали нейросеть. Дополнительно можете устанавливать скорость обучения ползунком «Точнее/Быстрее», а также визуализировать не каждый 50й шаг, а каждый 10й или 300й, как Вам угодно.
Интеграция созданных сетей в свои проекты
Чтобы использовать свои нейросети в собственных проектах, я создал отдельное приложение
doNet.exe, которое нужно запускать с параметрами: «D:\NeuroNet\doNet.exe <название сети> <входные данные через пробел>», дождаться завершения работы приложения, после чего считать выходные данные из D:\NeuroNet\temp.txt
Для примера создано приложение 4-5.exe, использующее сеть «4-5» (об этой и других сетях ниже). В этом приложении подробно расписано как правильно запускать doNet.exe
Разбор сетей, идущих в комплекте
Начнём с классики – «XOR(Полусумматор)». Среди прочих, в частности, эту задачу – сложение по модулю 2 – в 1969 году приводили в качестве примера ограниченности нейросетей (а именно однослойных перцептронов). В общем, имеется два входа (со значениями либо 0, либо 1 у каждого), наша же задача — ответить 1, если значения входов разные, 0 – если одинаковые.
Далее «Количество-единиц». Три входа (0 либо 1 на каждом). Требуется посчитать, сколько было подано единиц. Реализовано как задача классификации – четыре выхода на каждый вариант ответа (0,1,2,3 единицы). На каком выходе максимальное значение, соответственно таков и ответ.
«Умножение» – Два входа (вещественные от 0 до 1), на выход их произведение.
«4-5» – На вход подаются нормализованные значения яркости пикселей картинки 4х4, на выходе имеем нормализованные значения яркости пикселей картинки 5х5.
Сеть задумывалась, как увеличение качества большой картинки на 25%, вышел же интересный фильтр для фото:
Вот собственно и всё, жду комментариев.
P.S. Если вылезает ошибка, попробуйте зарегистрировать от администратора с помощью regsvr32 файлы comdlg32, которые также есть в архиве.
Приглашаем на Front-end MeetUp в Райффайзенбанк
Приглашаем на первый открытый Front-end MeetUp 28 марта, организованный внутренним сообществом разработчиков Райффайзенбанка.
Наше внутреннее Front-end сообщество в Райффайзенбанке активно развивается. Мы знаем, как важно общаться с людьми из других команд и проектов, иметь возможность спросить совета, обсуждать только что появившиеся технологии и поделиться опытом. Именно поэтому мы открываем двери и приглашаем вас к нам в гости.
Мероприятие состоится 28 марта на площадке Райффайзенбанка в Нагатино, старт в 18:00.
В программе митапа запланировано 4 доклада:
18:00 Григоров Дмитрий Райффайзенбанк
Higher Order Components with Functional Patterns Using Recompose
18:30 Попков Алексей КонсультантПлюс
От jQuery до React
Как перестать есть лапшу и начать жить — описание текущих проектов- рассказ о проблемах и болях при таком раскладе — из чего мы выбирали и как пришли к стеку — как происходил(т) переход — где можно отстрелить ногу)
19:00 Алехин Сергей Topso.Ru
React, Mobx и ES7
- Библиотека React для создания клиентских GUI.
- Как с ней работать, используя объектно-ориентированный подход, без редьюсеров и через Mobx?
- Несколько слов о современном JavaScript ES7.
- Практические примеры.
19:30 Сычев Илья Райффайзенбанк
Cборка Docker+Nginx+CRA+Koajs+MongoDB за 10 мин
Формат митапа подразумевает общение. Ждем вас с вопросами и готовностью делиться своими историями, опытом и хорошим настроением.
Участие в мероприятии бесплатное, регистрация обязательная
Neoquest 2018: «Найти ихтиандра»
Недавно закончился очередной NeoQuest. Под катом разбор третьего задания, относящегося к области OSINT.
Все, кого интересует стеганография и поиск информации о человеке, добро пожаловать под кат.
Текст задания содержит ссылку на специальную форму, правильно заполнив которую, можно получить ключ:
Начинаем искать информацию. Все что нам известно это ник andr_ihtiandr. Попробуем посмотреть профиль человека с таким ником в наиболее очевидной базе персональных данных — Вконтакте: https://vk.com/andr_ihtiandr. Такой профиль действительно существует и там обнаруживается много интересной информации, например, такая картинка:
Вот и первый параметр для получения ключа. Организация, в которой работает andr_ihtiandr, это AtlanticNeoSecurity.
Также привлекает внимание информация «О себе»:
If you want to write to me, you should know that I use only encrypted messenger.
And sometimes I write interesting things on text storage site =)
Encrypted messenger это очевидно Telegram. В нем нашелся пользователь @andr_ihtiandr, на приглашение пообщаться он не реагировал :) Зато в его профиле обнаружилась еще одна интересная картинка:
На картинке есть логотип известного сервиса вопросов и ответов ask.fm. И конечно в нем обнаруживается профиль таинственного ихтиандра: https://ask.fm/andr_ihtiandr. Пролистав список вопросов, видим еще один параметр, нужный для получения ключа. Фамилия основателя оказалась Nobody.
Вернемся к данным из Вконтакте. Ихтиандр сообщает, что пишет интересные вещи on text storage site. Наиболее известный представитель подобных сервисов — Pastebin. Изучаем профиль пользователя с ником andr_ihtiandr: https://pastebin.com/u/andr_ihtiandr и находим единственную запись https://pastebin.com/fifeAE1q. Запись содержит картинку, закодированную в Base64:
Тут стоит вспомнить о простейшем способе стеганографии, когда внутрь jpg картинки прячут rar архив. Картинка действительно успешно открылась архиватором. Полученный архив содержал текстовый файл с подсказкой:
Ok, you found the image. It shows one story about Atlantis.и странную картинку:
What is next?
What exactly do you need from this story? Look inside!
Look inside так look inside. Открываем картинку в блокноте и после jpeg контейнера обнаруживаем очередную подсказку:
Нужно найти какой-то год, это и будет годом основания компании, который является очередным параметром для получения ключа.
Дальше нам поможет поиск по картинкам в Google. Оказывается, странная синяя картинка связана с новостью о том, что в 2009 году благодаря Google Ocean были якобы найдены останки Атлантиды. Бинго! год основания компании — 2009.
Последний шаг задания — найти фотографию того, кто спрятался на почти черно-белой картинке. Возвращаемся в профиль ихтиандра Вконтакте. Там как раз есть подходящая фотография:
Казалось бы, ничего необычного, но если внимательно приглядеться, можно заметить, что на ней желтым выделены буквы некоторых вывесок:
Ну ок, значит в форму надо загрузить фотографию котика. Например, из википедии.
Ключ получен!
пятница, 23 марта 2018 г.
[Из песочницы] Простая аутентификация на NGINX с помощью LUA
Доброго времени суток. В данной заметке хочу рассказать о простой аутентификации с помощь nginx и lua-скриптов.
Подняв у себя домашний сервер на ubuntu с plex и transmission и обзаведясь доменом, через который вывел это добро в большой мир, понял Я, что было бы неплохо обзавестись единой точкой аутентификации. Тем более nginx у меня уже был установлен (даже nginx-extras, что немаловажно, поскольку там есть lua).
Собравшись с мыслями, сформулировал требования:
- Отсутствие необходимости установки дополнительного ПО
- Отдельная страница аутентификации
- Сквозная аутентификация для всех сервисов за nginx
- Хотя бы минимальная защита от перебора
Вариант с nginx basic auth не устроил по причине отсутствия защиты от перебора, вариант с nginx auth PAM вызвал у меня недоверие по причине аутентификации по логину/паролю ОС. И оба варианта не дают возможности аутентификации через свою отдельную форму.
Алгоритм аутентификации довольно прост:
Ну что ж, приступим.
Для начала создадим lua-скрипт с некоторым функциями, которые понадобятся нам в дальнейшем:
-- Количество попыток для ip/32 и User-Agent
local ip_ua_max = 10
-- Количество попыток для ip/32
local ip_4_max = 50
-- Количество попыток для ip/16
local ip_3_max = 100
-- Количество попыток для ip/8
local ip_2_max = 500
-- Количество попыток для ip/0
local ip_1_max = 1000
md5 = require("md5")
counters = {}
counters["ip_ua"] = {}
counters["ip_4"] = {}
counters["ip_3"] = {}
counters["ip_2"] = {}
counters["ip_1"] = {}
-- Проверка числа попыток (is_cnt=false) и учёт неуспешной попытки (is_cnt=true)
function is_secure(ip, user_agent, is_cnt)
local md5_ip_ua = md5.sumhexa(ip..user_agent)
local md5_ip_4 = md5.sumhexa(ip)
local md5_ip_3 = ""
local md5_ip_2 = ""
local md5_ip_1 = ""
local cnt = 0
for i in string.gmatch(ip, "%d+") do
cnt = cnt + 1
if cnt < 4 then
md5_ip_3 = md5_ip_3.."."..i
end
if cnt < 3 then
md5_ip_2 = md5_ip_2.."."..i
end
if cnt < 2 then
md5_ip_1 = md5_ip_1.."."..i
end
end
md5_ip_3 = md5.sumhexa(md5_ip_3)
md5_ip_2 = md5.sumhexa(md5_ip_2)
md5_ip_1 = md5.sumhexa(md5_ip_1)
if is_cnt then
-- Учитываем неуспешную попытку
counters["ip_ua"][md5_ip_ua] = nvl(counters["ip_ua"][md5_ip_ua],0) + 1
counters["ip_4"][md5_ip_4] = nvl(counters["ip_4"][md5_ip_4],0) + 1
counters["ip_3"][md5_ip_3] = nvl(counters["ip_3"][md5_ip_3],0) + 1
counters["ip_2"][md5_ip_2] = nvl(counters["ip_2"][md5_ip_2],0) + 1
counters["ip_1"][md5_ip_1] = nvl(counters["ip_1"][md5_ip_1],0) + 1
-- Пишем в лог подробности неуспешной попытки
log_file = io.open("/var/log/nginx/access.log", "a")
log_file:write(ip.." "..nvl(counters["ip_ua"][md5_ip_ua],0).." "..nvl(counters["ip_4"][md5_ip_4],0).." "..nvl(counters["ip_3"][md5_ip_3],0).." "..nvl(counters["ip_2"][md5_ip_2],0).." "..nvl(counters["ip_1"][md5_ip_1],0).." "..user_agent.."\n")
log_file:close()
else
-- Проверяем число неуспешных попыток
if
nvl(counters["ip_ua"][md5_ip_ua],0) > ip_ua_max or
nvl(counters["ip_4"][md5_ip_4],0) > ip_4_max or
nvl(counters["ip_3"][md5_ip_3],0) > ip_3_max or
nvl(counters["ip_2"][md5_ip_2],0) > ip_2_max or
nvl(counters["ip_1"][md5_ip_1],0) > ip_1_max
then
return false
else
return true
end
end
end
-- Проверка логина/пароля
-- В данном примере просто сравнение с хэшом из файла, при желании в данной функции можно реализовать проверку логина/пароля где угодно (в БД например)
function sing_in(log, pass)
local auth_file = io.open("/etc/nginx/auth/pass","r")
for line in io.lines("/etc/nginx/auth/pass") do
if line == log..":"..md5.sumhexa(pass) then
auth_file:close()
return true
end
end
auth_file:close()
return false
end
-- Просто удобная функция
function nvl(val, def)
if val ~= nil then
return val
else
return def
end
end
-- Сохраняем функции в глобальном контейнере secure
local secure = ngx.shared.secure
secure:set("sing_in", sing_in)
secure:set("is_secure", is_secure)
secure:set("nvl", nvl)
Добавим инициализацию данного скрипта в глобальный конфиг nginx:
• • •
http {
• • •
# Объявляем глобальный контейнер
lua_shared_dict secure 10m;
# Инициализируем скрипт
init_by_lua_file /etc/nginx/lua/secure.lua;
• • •
include /etc/nginx/conf.d/*.conf;
}
Теперь создадим lua-скрипт для проверки cookie (шаги 2, 2.1, 3):
md5 = require("md5")
-- Адрес страницы аутентификации
local req_url_err = "https://auth.somedomain.ru"
-- Получаем токен из cookie
local sv_auth_ck = ngx.var.cookie_sv_auth
-- 2. Проверяем валидность токена
if sv_auth_ck == md5.sumhexa("ОЧЕНЬ_СЕКРЕТНАЯ_ОЧЕНЬ_ДЛИННАЯ_СТРОКА_НАПРИМЕР_КАКОЙ-НИБУДЬ_32-УХЗНАЧНЫЙ_ХЭШ|"..ngx.req.get_headers()["User-Agent"].."|"..os.date("%x", ngx.time())) then
-- Токен валиден
return
else
-- Токен не валиден (или отсутствует)
-- 2.1. Сохраняем в coockie url назначения
ngx.header["Set-Cookie"] = "sv_req_url="..ngx.req.get_headers()["Host"].."; path=/; domain=.somedomain.ru; Expires="..ngx.cookie_time(ngx.time()+60*60).."; Secure; HttpOnly"
-- 3. И возвращаем редирект на страницу аутентификации
return ngx.redirect(req_url_err)
end
Добавим проверку данным скриптом в конфиги внутренних сервисов:
server {
listen 443 ssl;
server_name plex.somedomain.ru;
access_by_lua_file /etc/nginx/lua/access.lua;
location / {
proxy_pass http://localhost:32400;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
ssl on;
• • •
}
Создадим страницу аутентификации:
И добавим для неё конфиг nginx:
server {
listen 443 ssl;
server_name auth.somedomain.ru;
access_by_lua_file /etc/nginx/lua/auth_access.lua;
location / {
default_type 'text/html';
root /var/www/html/;
index auth.html;
if ($request_method = POST ) {
content_by_lua_file /etc/nginx/lua/auth.lua;
}
}
ssl on;
• • •
}
В данном конфиге делаем проверку числа попыток аутентификации с помощью «auth_access.lua» (шаг 4, 4.2)
-- Берём из глобального контейнера secure нужные нам функции
local secure = ngx.shared.secure
is_secure = secure:get("is_secure")
-- Получаем ip адрес клиента
local ip = ngx.var.remote_addr
-- Получаем User-Agent адрес клиента
local ua = ngx.req.get_headers()["User-Agent"]
-- 4. Проверка количества попыток аутентификации
if is_secure(ip,ua,false) then
-- Проверка пройдена, удаляем невалидный токен
ngx.header["Set-Cookie"] = {"sv_auth=; path=/; domain=.somedomain.ru; Expires="..ngx.cookie_time(ngx.time()-60).."; Secure; HttpOnly"}
return
else
-- 4.2. Проверка не пройдена, возвращаем HTTP 403
ngx.exit(ngx.HTTP_FORBIDDEN)
end
И проверку логина/пароля с помощью «auth.lua» (шаг 5, 5.1, 2.2)
md5 = require("md5")
-- Берём из глобального контейнера secure нужные нам функции
local secure = ngx.shared.secure
sing_in = secure:get("sing_in")
is_secure = secure:get("is_secure")
nvl = secure:get("nvl")
-- Получаем ip адрес клиента
local ip = ngx.var.remote_addr
-- Получаем User-Agent адрес клиента
local ua = ngx.req.get_headers()["User-Agent"]
-- Адрес страницы аутентификации
local req_url_err = "https://auth.somedomain.ru"
-- Адрес назначения из cookie или дефолтный адрес, если в cookie адреса нет
local req_url = "https://"..nvl(ngx.var.cookie_sv_req_url,"somedomain.ru")
-- Проверяем наличие параметров POST-запроса, если их нет – редирект на страницу аутентификации
ngx.req.read_body()
local args, err = ngx.req.get_post_args()
if not args then
ngx.redirect(req_url_err);
end
-- 4.1. Читаем из POST-запроса логин и пароль
local log
local pass
for key, val in pairs(args) do
if key == "login" then
log = val
elseif key == "password" then
pass = val
end
end
-- Если логин или пароль пустые перенаправляем обратно на страницу аутентификации
if log == nil or pass == nil then
ngx.redirect(req_url_err);
else
-- 5. Проверяем валидны ли логин и пароль
if sing_in(log, pass) then
-- Если валидны, генерируем токен
local auth_str = md5.sumhexa("ОЧЕНЬ_СЕКРЕТНАЯ_ОЧЕНЬ_ДЛИННАЯ_СТРОКА_НАПРИМЕР_КАКОЙ-НИБУДЬ_32-УХЗНАЧНЫЙ_ХЭШ|"..ua.."|"..os.date("%x", ngx.time()))
-- 5.1. Записываем токен в cookie и удаляем оттуда url назначения
ngx.header["Set-Cookie"] = {"sv_auth="..auth_str.."; path=/; domain=.somedomain.ru; Expires="..ngx.cookie_time(ngx.time()+60*60*24).."; Secure; HttpOnly","sv_req_url="..ngx.req.get_headers()["Host"].."; path=/; domain=.somedomain.ru; Expires="..ngx.cookie_time(ngx.time()-60).."; Secure; HttpOnly"}
-- 2.2. Возвращаем редирект на страницу назначения
return ngx.redirect(req_url)
end
-- 5.2. Если логин/пароль невалидны, учитываем это в подсчёте неуспешных попыток аутентификации
is_secure(ip,ua,true)
-- 3. И возвращаем редирект на страницу аутентификации
ngx.redirect(req_url_err)
end
Теперь создадим файл с логином и паролем:
md5="`echo -n "PASSWORD" | md5sum`";echo -e "LOGIN"":`sed 's/^\([^ ]\+\) .*$/\1/' <<< "$md5"`" > ~/pass; sudo mv ~/pass /etc/nginx/auth/pass; sudo chown nginx:nginx /etc/nginx/auth/pass
Подставив вместо «LOGIN» логин, а вместо «PASSWORD» пароль.
Вот и всё, аутентификации реализована.
При добавлении сервисов, достаточно будет в конфигах указывать проверку по «access.lua»:
access_by_lua_file /etc/nginx/lua/access.lua;
Спасибо за внимание.
Разносим S3 бакеты по разным пулам в Ceph Luminous
Задача
Еще раз опишу задачу: в каждую ноду кластера установлено некоторое количество HDD и SSD дисков. Необходимо, чтобы можно было при создании S3 бакета указать на каких устройствах его хранить (HDD или SSD).
Разносим пулы по разным девайсам
Посмотрим текущие правила репликации. По дефолту там должна быть только запись «replicated_rule»:
ceph osd crush rule ls
Благодаря нововведению в Luminous Ceph умеет сам определять тип устройства и мы можем легко разделить их по разным правилам репликации:
ceph osd crush rule create-replicated replicated_hdd default host hdd
ceph osd crush rule create-replicated replicated_ssd default host ssd
Удалим старое дефолтное правило:
ceph osd crush rule rm replicated_rule
Теперь создадим новый дополнительный пул, в котором мы будем хранить S3 объекты и расположим его на SSD:
ceph osd pool create default.rgw.buckets.data.ssd 8 8 replicated replicated_ssd
А дефолтный пул с данными расположим на HDD:
ceph osd pool set default.rgw.buckets.data crush_rule replicated_hdd
Естественно можно сделать наоборот и расположить дефолтный на SSD.
Настраиваем Rados Gateway
Самая интересная часть, ради которой и писалась статья.
При новой установке кластер идет без дефолтного Realm. Не очень понятно почему так сделано. Создадим Realm «default» и назначим его дефолтным:
radosgw-admin realm create --rgw-realm=default --default
Добавим дополнительный placement для SSD бакетов в zonegroup default:
radosgw-admin zonegroup placement add --rgw-zonegroup=default --placement-id="ssd-placement"
И добавим дополнительный placement в зону default:
radosgw-admin zone placement add --rgw-zone=default --placement-id="ssd-placement" --data-pool="default.rgw.buckets.data.ssd" --index-pool="default.rgw.buckets.index"
У нас для хранения индекса всех объектов (и HDD и SSD) используется один пул «default.rgw.buckets.index», но можно создать отдельный пул для индекса.
Привяжем zonegroup «default» к realm «default» и закомитим изменения:
radosgw-admin zonegroup modify --rgw-zonegroup=default --rgw-realm=default
radosgw-admin period update --commit
Последний шаг— перезапустить Rados Gateway.
Теперь мы можем создать новый бакет на SSD (обратите внимание на двоеточие, без него не работало):
s3cmd mb s3://test --bucket-location=:ssd-placement
Или создать бакет с дефолтным размещением (в нашем случае на HDD):
s3cmd mb s3://test
Надеюсь, моя маленькая заметка сэкономит кому-то время при решении аналогичной задачи.
Криптовалюта и судебная практика. Просветление
Уже больше года продолжается наша борьба с питерскими прокурорами по обжалованию судебных решений о признании незаконной информации о биткоине и криптовалюте. Эти решения уже привели к блокировке множества криптовалютных сайтов. За год мы подали 4 жалобы от владельцев разных порталов криптовалютной тематики, и уже казалось, что несмотря на всю нелепость доводов надзорного органа, будет невозможно сломить порочную практику, созданную в северной столице. Однако события последних месяцев вселяют некую надежду на то, что ситуация начала меняться в лучшую сторону. Одно решение суда было отменено на уровне апелляции в Санкт-Петербургском городском суде. Другое в настоящее время находится на слушании в Верховном суде РФ.
Все судебные акты содержат один и тот же ничем не мотивированный и не аргументированный вывод о том, что криптовалюты, а точнее — биткоин, являются денежными суррогатами, выпуск и оборот которых запрещён российским законодательством (ст. 27 ФЗ «О Центральном банке РФ»). Также из иска в иск попадают совершенно надуманные конструкции, что криптовалюты незаконны, так как могут использоваться в «торговле наркотиками, оружием, поддельными документами и иной преступной деятельности». С таким же успехом прокуроры могут апеллировать к запрету продажи автомобилей, поскольку они способствуют росту смертности, травм и увечий.
Но если отвлечься от формалистских изречений, лишенных какого-либо смысла, но тем не менее вставленных в прокурорские иски скорее для придания им весомости, и просто внимательно всмотреться в каждый судебный документ, то даже после беглого прочтения текстов этих судебных решений становится понятно, откуда подобный вывод, формулировки и логика изложения перекочевали в судебные акты — из сообщения-предостережения Банка России о рискованности использования биткоинов при совершении сделок, которое было опубликовано 27 января 2014 г.
Вооружившись позицией ЦБ РФ, санкт-петербургские суды и прокуратура заключили, что лучше уж от греха подальше запретить информацию о криптовалютах совсем, — пусть даже без наличия на то каких-либо оснований. Напомним, правовой статус криптовалют до сих пор в России никак не определён, и даже Минфин с Центробанком, на документ которого ссылаются прокуроры, только совсем недавно определились с тем, как они видят госрегулирование криптовалют, но и это их «видение» пока никак законодательно не утверждено — соответствующий проект закона только внесён в Госдуму.
Ниже мы расскажем, как идёт обжалование трёх судебных решений о признании информации о биткоине запрещённой к распространению на территории России.
Localbitcoins.com
В июле 2016 года другой питерский суд вынес решение о блокировке международного p2p сервиса Localbitcoins.com, оператором которого является одноимённая финская компания. Администрация сервиса частных объявлений о покупке-продаже биткоинов узнала о блокировке своего сайта на территории России лишь в сентябре от пользователей сервиса, а выяснить основания блокировки удалось лишь после обращения к юристам “Центра цифровых прав”. Роскомнадзор внёс сайт финской компании Localbitcoins.com в Единый реестр на основании решения Приморского районного суда г. Санкт-Петербурга от 5 июля 2016 г. (дело №2-10224/2016).
Руководствуясь по сути всего одной правовой нормой, ст. 27 ФЗ “О Центральном банке РФ”, не имея легального определения денежного суррогата или хотя бы заключения валютного регулятора или независимого эксперта о содержании понятия “денежный суррогат”, судья Приморского районного суда Санкт-Петербурга всего за пару заседаний выяснила у районного прокурора все “необходимые” сведения об особенностях использования биткоина, пришла к выводу, что вообще все криптовалюты являются денежными суррогатами (хотя дело №2-10224 касалось только биткоина) и решила запретить распространение размещённой на сайте Localbitcoins.com информации о биткоине на всей территории России. Несмотря на наличие на сайте полной контактной информации компании Localbitcoins OY, к участию в деле её не привлекли, однако в нём по традиции пассивно участвовал Роскомнадзор, не заявляя никакой позиции либо пояснений по применению положений закона “Об информации”, в которых заложены основания для признания информации незаконной и подлежащей блокировке.
На восстановление срока на подачу апелляционной жалобы ушло два заседания (ждали ответ от центрального аппарата Роскомнадзора), которые закончились отказом со ссылкой на неуважительность причин пропуска срока и “обращение в суд значительно позже месячного срока, предоставленного законом на подачу апелляционных жалоб”.
Подав частную жалобу на определение Приморского районного суда Санкт-Петербурга от 17 января 2017 г., юристы «Центра цифровых прав» очень подробно описали порядок, которому следует Роскомнадзор для ограничения доступа к сайтам, обратили внимание апелляционного суда на сроки блокировки, а также на отсутствие уведомлений от Роскомнадзора. Всё же 13 апреля 2017 г. Санкт-Петербургский городской суд отказал финской компании в удовлетворении частной жалобы.
23 октября 2017 г. Президиум Санкт-Петербургского городского суда кассационную жалобу на указанные определения судов нижестоящих инстанций рассматривать на судебном заседании отказался, посчитав, что финская компания должна была узнать о нарушении своих прав в момент включения сайта в Единый реестр (т.е. даже до фактической блокировки). При этом в отказном определении суда кассационной инстанции отмечается, что для иностранной компании «в сети Интернет на сайте blocklist.rkn.gov.ru имеется возможность получить полную информацию о принятых мерах по ограничению доступа к сайтам и об основаниях таких мер». При этом, Роскомнадзор умалчивает, что доступ к сервису закрыт с иностранных IP.
Вторая кассационная жалоба, поданная в Верховный суд РФ, также не прошла фильтр аппарата суда. Верховный суд РФ очень лаконично отказал Localbitcoins OY в передаче кассационной жалобы на рассмотрение на заседании кассационной коллегии, сославшись на то, что не усмотрел существенных нарушений норм материального либо процессуального права при вынесении решений по делу сервиса Localbitcoins.com. В настоящее время ведется обжалование.
«Сорок криптообменников»
После того как районный прокуроры заложили основу для подобного рода решений, на тропу войны с криптовалютами вышла прокуратура Санкт-Петербурга по особо режимным объектам. Судя по всему, мы пропустили момент, когда Интернет признали особо режимным объектом.В этот раз это был оптовый иск на блокировку сразу 40 криптообменников.
После длительного обжалования, в котором мы представляли 2-х из 40 владельцев сайтов, в конце февраля 2018 Санкт-Петербургский городской суд отменил решение Октябрьского районного суда о запрете сайтов 40 криптообменников, которое было вынесено в мае прошлого года по требованию прокуратуры. Решение об отмене блокировки является небольшой, но очень важной победой, которая говорит о том, что городской суд по-крайней мере обнаружил системную проблему нарушения процессуального права при рассмотрении исков о признании информации незаконной. Дело было направлено на новое рассмотрение в Октябрьский районный суд в ином составе судей.
«Дело о сорока сайтах биткоин-тематики — квинтэссенция всевозможных нарушений, которые могут быть допущены при рассмотрени требований о признании информации в сети запрещённой!— прокомментировала тогда эту ситуацию медиаюрист Центра цифровых прав Екатерина Абашина. —
Прокуратура северной столицы без разбора заявляла, что на сайтах якобы выпускаются «денежные суррогаты», а по факту под раздачу попали информационные ресурсы, агрегаторы курсов криптовалют, онлайн-обменники. Ни прокуратора, ни суд первой инстанции не предприняли ни единой попытки связаться с владельцами сайтов, хотя возможность написать е-мэйл или запросить информацию у регистраторов доменов есть всегда. Уже на этапе апелляционного обжалования прокуратура предприняла достаточно нелепую попытку доказать, что контактной информации владельцев сайтов в открытом доступе не было, но это не сработало. Апелляционная коллегия воздержалась от оценки вопросов относимости биткоина к денежному суррогату и легитимности запрета на распространение информации о криптовалюте, но признала необходимость привлечения к участию в судебном процессе владельцев сайтов».
Bitcoininfo.ru
Летом 2016 года был заблокирован нишевый информационно-аналитический сайт Bitcoininfo.ru, на котором размещаются новости и материалы о криптовалюте биткоин. Роскомнадзор внёс Bitcoininfo.ru в реестр запрещённых сайтов на основании решения Выборгского районного суда г. Санкт-Петербурга от 18 июля 2016 г. (дело №2-10119/2016), которое было вынесено без участия администрации сайта. Судебное разбирательство о блокировке сайта, как водится, было инициировано местным районным прокурором, а администрация сайта узнала о судебном акте только после фактического ограничения доступа к нему (т.е. в момент исполнения судебного решения, когда месячный срок его обжалования уже истёк) — классика судебного жанра.
Юристы “Центра цифровых прав” добились восстановления пропущенного процессуального срока — апелляционная жалоба на судебное решение о блокировке сайта Bitcoininfo.ru была направлена на рассмотрение в Санкт-Петербургский городской суд. В апелляционной жалобе было указано на ряд серьезных «пороков» обжалуемого решения:
- администрация сайта Bitcoininfo.ru, которая очевидным образом является заинтересованным в данном процессе лицом, не была привлечена к участию к судебного разбирательству;
- в действующем законодательстве РФ нет запрета на распространение информации о криптовалютах, электронных деньгах и новых технологиях взаиморасчётов;
- сайт не предлагал осуществления на своей платформе каких-либо транзакций между участниками оборота криптовалют.
В этом деле высказался даже Роскомнадзор, обычно не имеющий никакой позиции в таких делах, так как в в контексте подобных дел он играет роль цифрового судебного пристава (исполняет решения судов, вносит сайты в реестр). Несмотря на существенные нарушения норм процессуального и материального права, Роскомнадзор поддержал решение суда о запрете распространения информации о биткоине и по сути выступил за запрет оборот биткоина в России. На фоне текущей на тот момент публичной дискуссии о возможностях легализации криптовалют в России подобная правовая позиция выглядела достаточно нелепо.
13 февраля 2017 года состоялось заседание в суде апелляционной инстанции (в Санкт-Петербургском городском суде), который отказал в апелляционной жалобе по причине того, что «владелец сайта и администратор доменного имени не является лицом, участвующим в деле, к участию в деле не привлекался вопрос о его правах и обязанностях судом не разрешался, а в заявлении прокурора Выборгского района Санкт-Петербурга ставится лишь вопрос об установлении правового состояния размещённого на сайте информационного материала, что имеет юридическое значение для включения информации в Единый реестр».
Президиум Санкт-Петербургского городского суд отказал в передаче жалобы для рассмотрения в заседании по тем же мотивам, что и апелляционная коллегия, после чего мы обратились со второй кассацией в Верховный суд РФ. Сначала консультант Верховного суда РФ решил по-простому вернуть кассационную жалобу, поданную адвокатом, потому что к жалобе не приложены копии дипломов, подтверждающих наличие у представителя юридического образования. Консультант суда ссылался на новый порядок, установленный положением Кодекса административного судопроизводства РФ, хотя обжалуемые судебные постановления были приняты в порядке Гражданского процессуального кодекса РФ, да и сослался в итоге не очень ловко — по правилам КАС РФ адвокату не требуется прикладывать копии своих дипломов.
После повторной подачи кассационной жалобы в Верховный суд РФ в ноябре 2017 г. материалы дела были всё-таки истребованы из Санкт-Петербурга и дело сайта Bitcoininfo.ru было назначено к рассмотрению на 21 марта 2018 г. Стоит отметить, что это первое дело о блокировке веб-портала, которое за 6 лет правоприменения закона «о черных списках сайтов» рассматривается в Верховном суде. И это вселяет в нас определенную надежду, что высшая судебная инстанция наконец проявила интерес как к весьма болезненному для российского общества вопросу о веб-цензуре, так и к теме правового статуса криптовалют.
Однако, 21 марта рассмотрения по существу так и не состоялось, а слушание по делу было перенесено на 20 апреля 2018 г. в связи с поздним направлением питерским прокурором возражения на жалобу и необходимостью изучения дополнительных материалов, а именно позиции ведущей профильной ассоциации РАКИБ и Интернет-омбудсмена Дмитрия Мариничева, которые в качестве amicus curiae представили суду заключение по поводу статуса биткоина.
РАКИБ заявила, что нельзя причислять информацию о криптовалютах к запрещенной к распространению.
В своем пояснении РАКИБ утверждает, что в законодательстве РФ отсутствуют нормы, на основании которых можно ограничить распространение информации о биткоине и криптовалюхах. Кроме того, отсутствуют нормы, ограничивающие оборот биткоина и криптовалют. До принятия нормативно-правовых актов в распоряжении предпринимателей, осуществляющих деятельность, связанную с криптоактивами, есть позиции госорганов, которые, несмотря на то, что не имеют силы прямого действия, могут служить ориентирами для участников рынка. Эти документы направлены на предупреждение о рисках по сделкам с криптовалютой, но ни один из них не упоминает об ограничениях или запрета оборота криптоактивов в РФ.
Законом также не предусмотрена ответственность за производство и хранение денежного суррогата. Уголовным кодексом преследуется изготовление, хранение, перевозка и сбыт поддельных денег — копий существующих дензнаков, а не производство собственной валюты.
Интернет-омбудсмен Дмитрий Мариничев также подтверждает, что в российском законодательстве не предусмотрено основание для ограничения распространения информации о биткоине и криптовалютах. Также ни КоАП РФ, ни УК РФ не содержат ни одной нормы, предусматривающей ответственность за распространение информации о криптовалюте «биткоин», либо об электронных средствах платежа или иных валютах помимо рубля. Даже норма авторства ЦБ РФ об общем запрете на введение на территории России денежных единиц помимо рубля и выпуск «денежных суррогатов» не предусматривает каких-либо ограничений на распространение информации о различных денежных единицах, платёжных средствах и технологиях, применяемых в современном мире, а также не определяет, что является «денежным суррогатом».
Мариничев также подчеркнул, что в настоящее время криптовалюта имеет неопределённый правовой статус в России, однако запрета на оборот и использование криптовалют российскими гражданами законодательно не установлено.
Интернет-омбудсмен считает, что до момента выработки российским законодательным органом специальных норм, определяющих статус криптовалют, в настоящее время следует ориентироваться на общий дозволительный метод гражданского права и руководствоваться нормативно-закреплённым принципом свободы договора (статьи 1, 421 ГК РФ).
Несмотря на то, что у Bitcoin нет обеспечения в золоте или иных валютах, как, впрочем, и у иных современных фиатных денег, всё же его можно обменять на фиатные валюты в обменниках, банкоматах и на биржах, которые легально функционируют во многих странах по всему миру. Также возможен обмен на токены за участие в определённом новом проекте, основанном на технологии распределённого реестра. Курс биткоина определяется по биржевому принципу на пересечении спроса и предложения.
Напомним, дело Bitcoininfo.ru — эта первая дошедшая до рассмотрения Верховным судом жалоба владельцев сайтов на решение о блокировке. Решение по этому процессу может стать прецедентообразующим для всех дел о блокировке сайтов о криптовалютах.
Мы надеемся на то, что Верховный Суд прислушается к мнению экспертов, и примет правильное решение, которое скажется положительно и на развитии криптовалют и на внедрении в нашей стране «цифровой экономики», а также создаст на уровне судебной практики ряд важных рекомендаций для судов по процедуре признания информации незаконной
Программа JPoint: из жизни разработчика
JPoint всегда славился хардкорными докладами. Которые, так уж получилось, в основном состоят из рекомендаций по написанию сборщиков мусора, компиляторов, и прочей жести, которую далеко не каждый может применить в повседневной жизни.
Но дело в том, что многим перформанс не интересен. Существует ещё множество проблем, которые куда важней, чем ускорение приложения на 1%. Поэтому больше половины докладов на этой конференции представляют собой вполне разумный материал, который каждый может попробовать использовать у себя.
Обзор программы докладов по перформансу делался в отдельном посте, — поэтому в этой статье мы не выбрасываем их вообще, но описания будут максимально краткими.
За более подробной информацией — добро пожаловать под кат.
Disclamer. Статья написана по впечатлeниям от содержимого программы на официальном сайте. Всё ниженаписанное — мои собственные мысли, а не цитаты из докладов. В тексте могут быть (и точно есть) неверные предположения и неточности.
Spring Framework 5.0 on JDK 8 & 9
Конференция открывается кейноутом, в котором Juergen Hoeller расскажет о новой, актуальной в этом году проблеме — запуске Spring Framework на JDK 9 и выше. В общем, этот доклад не просто про Spring, а про совместимость низкоуровневых фреймворков с JDK 9, который основан на практическом опыте разработки Spring.
Juergen — это создатель Spring и в данный момент — главный человек в нём (стал им после ухода Rod Johnson), ведущий разработчик и релиз-менеджер Spring Core с 2003 года. Кроме того, он архитектор в Pivotal — компании, известной по Cloud Foundry, Greenplum Database, дистрибутиву Hadoop под названием Pivotal HD и версии Greenplum для него под названием Hawq, и так далее. Такой набор уникальных факторов делает его доклады одними из лучших в мире Spring.
Один раз в год сады цветут: разбор семантики «exactly-once» Apache Kafka
Почти на любом докладе по Кафке так или иначе возникают вопросы про "exactly once"-семантику. Если вы ещё вдруг не знаете, что это такое, то добро пожаловать в наш мир! Интересный факт: понимание того, почему exactly once так важно, помогает легко отличить джуна от синьора. Кроме того, в доклде будет рассказано про влияние этого вопроса на соседние фреймворки — Kafka Streams и Kafka Connect.
Виктор является Solution Architect в компании Confluent, которая разрабатывает платформу на базе Apache Kafka. По сути, Виктор даёт информацию "из первых рук", только от него на русском языке можно услышать новейший эксклюзивный материал про внутренние механизмы работы Kafka и связанной экосистемы. Как лидер подкаста «Разбор Полётов», у него есть огромный опыт в объяснении сложных вещей легко, доходчиво и весело. Чуть позже я постараюсь записать и выложить на Хабр новое интервью с ним.
Хочется странного — web UI на Java для desktop-приложений
В описании доклада сказано: "Как показывает опыт ребят из GitHub и Slack, можно и нужно делать классные desktop-приложения на веб-стеке. Но есть одно но — вам нужно писать всё-всё-всё на JavaScript. Стоит ли напоминать, что далеко не все разработчики любят JavaScript? Возвращаясь к Java, мы попробуем подружить её с этими новыми безумными веб-технологиями для настольных систем и посмотрим, для каких задач применим такой подход".
Мне кажется, желание иметь современный десктопный Java UI на веб-технологиях — это не "странно", это мега актуально. Например, те кто использует десктопный GNU/Linux знают, как ужасно там всё выглядит (даже если поставить свежий KDE и Gnome с распоследними темами). Конечно, не у всех есть GNU/Linux, но давайте поделюсь болью. Писать нормальный UI под GNU/Linux очень сложно, Qt и тем более Gtk — это вещи не для всех, даже если забыть необходимость разбираться в C++ и Си. Писать его так, чтобы полученное запустилось на Windows и MacOS — ещё больней и сложней. В результате, существует, огромное количество наколенных поделок с плохо написанным UI, которые как бы и запускаются, но пользоваться ими душа не лежит. Появление Electron дало призрачную надежду улучшить ситуацию, но гораздо лучше было бы писать всё на Java — как минимум, такие приложения смогут не тормозить так ужасно (привет, Atom!). С нетерпением жду этого доклада.
Дколадчик — Юрий Артамонов, занимается архитектурой и фронтендом опенсорснго фреймворка CUBA Platform. У этого фреймворка есть своя IDE, которая оформлена в виде исполнимого файла под Windows/Linux/macOS, но весь интерфейс сделан на веб-технологиях. Это настолько необычно относительно того, что обычно рассказывают на Java-конференциях, что просто должно было попасть в программу.
Refactoring your code to Java 9 modules
Насущный прикладной доклад о том, что предстоит в ближайшее время преодолеть каждому, переходящему на свежие версии Java. Рассказывается о том, как пилить монолит, какие инструменты и паттерны при этом применять. Rabea Gransberger, большую часть времени пишет приложения на Eclipse RCP, и должна знать о подобных рефакторингах непонаслышке, если вы понимаете, о чём я.
Rabea — не только инженер в MEKOS, но и международный опытный докладчик, участник Программного комитета Java One, настоящая звезда.
Deep dive into the Eclipse OpenJ9 GC technologies
Хардкорный, доклад Charlie Gracie о сборщиках мусора внутри виртуальной машины Eclipse J9 (бывашая IBM J9). Эксклюзивный для России — раньше такого не было. Докладчик — архитектор этого продукта. Доклад, наиболее близкий к творчеству Алексея Шипилёва, в отсутствии самого Алексея (да простит он мне такую формулировку). Кроме того, подобные доклады продвигают разнообразие в мире виртуальных машин: на одной конференции собираются все звёзды VM-ного мира, и рассказывают свои истории.
Spring Framework 5: feature highlights and hidden gems
Juergen Hoeller, ведущий разработчик Spring Core, о котором мы уже говорили, рассказывает о новых фичах Spring Framework 5. Juergen расскажет о хайповых темах функционального и реактивного программирования в Spring, и коснётся ряда других менее знаменитых, но не менее полезных фичей. Это не просто пересказ ченжлога, с скорей выборка вещей, которые нравятся самому Юргену (читай — с которыми нужно познакомиться в первую очередь). Кроме того, доклад должен дать понимание о том, какие фичи будут вводиться в ближайших релизах (на момент написания этой статьи, в мавене последняя версия была 5.0.4, соответственно Юрген будет говорить о 5.1).
Тонкости машобуча вместе со Spark ML
Будет очень практичный доклад на тему, что нужно уметь и понимать джависту на типичном BigData + ML проекте:
- Как выбирать фичи;
- Как перекодировать фичи;
- Как скалировать;
- Как очищать и заполнять пропуски;
- Как оценивать качество кластеризации и бинарной классификации;
- Что делать, если классификация внезапно небинарная;
- Уметь делать кросс-валидацию.
И всё это на Java + Spark! Еще, будет рассказ о подводных камнях использования MLlib, особенностях реализации некоторых популярных алгоритмов, обсуждение open source-конкурентов и интеграции в существующие приложения.
Алексей Зиновьев — практикующий тренер в компании EPAM Systems, хорошо разбирающийся в больших данных — особенно в текстовых данных и больших графах. Рассказывает хороший доклад на популярную тему.
Профилируем с точностью до микросекунд и инструкций процессора
Хардкорный доклад Сергея Мельникова о профилировании с использованием perf, Intel Processor Trace, и других низкоуровневых средств. Хардкорный — но при этом сугубо прикладной, как Райффайзен повышает точность профилировки. новое слово в профилировании — впервые рассказан способ, как запрофилировать Java-приложение с точностью до микросекунд. Докладчик — спец по low-latency джавакоду и бывший перфоманс-инженер интеловских компиляторов.
Корутины в Kotlin
Хардкорный доклад о корутинах от создателя корутин — Романа Елизарова. Доступно о подходах к асинхронному вообще и программированию, Kotlin в частности. Докладчик — Роман Елизаров, разработчик Kotlin, спец по хайлоаду в биржах и банках.
Spring Boot и Xtend: сеанс чёрной магии c разоблачением
Андрей Когунь — эксперт по заказной разработке информационных систем с огромным стажем, работает в российской компании КРОК (известной по информатизации судов Москвы, устойчивой передаче данных в Аэроэкспрессе, работе с банками, заводами, и так далее).
Бытует мнение, что Spring Boot полон странной магии, но, если вы уже успели во всем подробно разобраться, не расстраивайтесь — много интересного и неожиданного можно добавить, если код приложения писать не на Java, а воспользоваться ее «улучшенной» версией.
Язык Xtend примерно так и позиционируется на официальном сайте. Со всем этим хайпом вокруг Котлина мы могли о нём забыть, но нет. Улучшения, прежде всего, позволяют писать меньше кода руками, а значит — делать это быстрее и с меньшим количеством ошибок.
В рамках доклада Андрей проведёт нас по разработке простого приложения на известных технологиях, таких как Spring Boot и Spring Data (Rest), с применением возможностей, которые предоставляет Xtend, в частности Active Annotations. Магии будет предостаточно, но, как мы увидим, всё можно держать под контролем, если выбрать правильный инструмент. Будут разоблачены основные фичи Xtend, базовый набор Active Annotations, как они работают, как и для чего можно написать свой процессор активных аннотаций и как его протестировать.
Developing Apache Camel and Java microservices on Kubernetes
Разработка на Java приводит к конкретной профдеформации. Зачастую люди так привыкают ко всяческим жирным application servers, что потом запуск даже простейшего приложения в докере вызывает когнитивный диссонанс, боль и отторжение. И тут нам спешит на помощью Claus Ibsen из RedHat, один из главных разработчиков небезызвестного Apache Camel.
Рандомный бесполезный факт: я сейчас слил репозиторий Camel из гита:
git clone https://github.com/apache/camel
find . -type f | sed -e 's/.*\.//' | sort | uniq -c | sort -n | grep -Ei '(java|class)$'
18077 java
А в вашем проекте есть 18 тысяч классов?
Ну так вот, Клаус расскажет как поднять с нуля Java-приложение, предназначенное для использования в облаке, и потом запустить под Kubernetes. Половина доклада — живая демонстрация. Вы же помните, что все участники конференции довольно скоро получают видео, и демки можно будет пересмотреть и повторить у себя?
Погружение в Интернет Вещей с Java 9
Медленно, но верно, Интернет Вещей проникает в жизнь каждого. Java уверенно удерживает позиции не только в качестве технологии бэкенда, но и как платформа для гейтвея. Java 9 в дополнение к модульности принесла целый букет функциональности, бесценной для разработки IoT-решений. В этом докладе обсуждается инструментарий, позволяющий строить компактные приложений для сбора и пре-процессинга потоковых данных на устройствах.
Александр Белокрылов в компании Oracle руководил раньше развитием продукта Java ME Embedded, а позднее одного из компонентов Oracle IoT Cloud Service. В 2017 году вместе с единомышленниками основал компанию BellSoft, которая выпускает бинарный дистрибутив OpenJDK для процессоров ARM: Liberica, разрабатывает решения в области анализа больших данных и IoT.
Аппаратная транзакционная память в Java
Хардкорный доклад Никиты Коваля про оптимизации с помощью аппаратной транзакционной памяти в новых процессорах.
Докладчик — инженер-исследователь в области многопоточности, верификации и анализа программ. Фанатично верит в будущее транзакционной памяти и заразил этим ПК.
Building scalable, back pressured services with Akka
Какая же Java-конференция теперь обойдётся без Akka? Асинхронщина и back pressure продолжают тревожить умы людей ничуть не меньше, чем в прошлом году, поэтому мы получим доклад по следующим темам:
- Прибивать к риквесту или писать асинхронищу;
- Что такое back pressure и как его делать, вплоть до сетевого уровня;
- Как сделать это конкретно на Akka HTTP и Akka Streams;
- Как всё это соотносится с уже существующими фичами типа CompletableFuture и Observable.
Рандомный бесполезный факт: вы уже заметили, что Observable помечен как @Deprecated, начиная с Девятки?
Докладчик — Christopher Batey, Senior Engineer в Lightbend. Lightbend раньше назывался Typesafe, и был основан Мартином Одерски, создателем Scala. Сейчас Lightbend делает саму Scala, Akka, Play Framework, и другие вещи в этой экосистеме. Кристофер там занимается разработкой Akka.
Идиоматичный Kotlin: от форматирования до DSL
Начать писать на Kotlin несложно, ведь он похож на Java. В этом докладе рассказывается о возможностях языка и стандартной библиотеки Kotlin, которые позволят выйти на следующий уровень и начать писать по-настоящему компактный и выразительный код. Сочетание этих возможностей позволяет строить на базе Kotlin такие DSL, которые позволят декларативно выражать сложные наборы инструкций. Будут показаны примеры таких языков и то, как можно делать их самим.
Докладчик — Дмитрий Жемеров из JetBrains, один из создателей Kotlin, руководящий группой, отвечающей за инструменты разработки на нём (плагины к IDE и системы сборки). Кроме того, Дмитрий — один из соавторов книги «Kotlin in Action» («Kotlin в действии»).
VMStructs: зачем приложению знать о внутренностях JVM
Хардкорный доклад Андрея Паньгина о кишках JVM. Докладчик — специалист по Java-хайлоаду в Одноклассниках, ранее работавший в команде HotSpot в Oracle, автор проектов one-nio, async-profiler, а также лидер по ответам в категории #JVM на Stack Overflow.
Как загубить производительность enterprise-приложения с помощью неэффективного кода
Доклад про то, как люди просаживают производительность своих программ, и что с этим делать. Несмотря на значок "смузи", этот доклад — про перфоманс, просто докладчик (перфоманс-инженер из Luxoft) его внятно объясняет.
Большие данные в современной биологии
День завершается эпическим кейноутом Михаила Гельфанда из «Высшей Школы Экономики». У Михаила огромный список регалий, например, он доктор биологических наук, член Academia Europaea, заместитель директора Института проблем передачи информации им. А.А.Харкевича РАН, и так далее, и тому подобное.
Чем же посвящён кейноут? С развитием высокопроизводительных экспериментальных методов молекулярная биология вступила на путь, по которому уже давно идут астрофизика и физика высоких энергий: она стала наукой, богатой данными. Вместо изучения отдельных генов и белков, теперь можно пытаться исследовать работу клетки в целом.
Однако за все надо платить: с одной стороны, в данных много шума, с другой, вместо конкретных биологических фактов объектом исследования становятся искусственные конструкты и модели; уровень абстракции зачастую превышает привычный и комфортный для биологов.
В этом кейноуте, на конкретных исследований последних лет будут обсуждаться проблемы и перспективы формирующейся новой науки — системной биологии и, в частности, то, как в ней могут использоваться современные методы анализа данных. При этом изложение будет элементарным со всех точек зрения и не требует каких-либо предварительных знаний.
Boot yourself, Spring is coming
Это огромный доклад в двух частях, занимающих два слота по часу длиной, разделённых перерывом (не обеденным, так что на перерыве контекст не успеет выветриться из головы).
Много лет назад, Java-программисты пользовались «new» для создания сервисов. Они проделывали огромное количество ручных действий и смешивали конфигурацию с бизнес-логикой. Они даже использовали копипасту. Было написано много строк убогого кода, который временами даже работал.
Потом появился Spring. С ним многое изменилось… Мы получили много «магии» из волшебного цилиндра Spring, код стал более чистым, простым и поддерживаемым.
И вот появился Spring Boot. С одной стороны, он решает тысячи ранее существовавших проблем: конфликты версий, задачи конфигурации, работа с инфраструктурными бинами, проблему настройки окружения, и, конечно же, запуск или деплой приложения, включая сборку jar/war-архивов… С другой стороны, Spring Boot добавил в наш волшебный цилиндр еще больше магии. В результате имеют место быть два сценария:
- Всё прекрасно работает, хотя никто не знает, как.
- Ничего не работает, и никто не знает, почему.
Этот доклад раскроет основные секреты магии Spring Boot. Вы осознаете основные принципы и конвенции, по которым работают типичные Spring Boot-приложения. Наша задача, чтобы вся магия из цилиндра превратилась для вас в куда более прозрачный процесс и вы смогли не только получать удовольствие, когда всё работает, но и понимали суть возникающих проблем и могли решить их без привлечения скорой помощи и других служб, доступных по срочным вызовам.
Доклад ведут два признанных эксперта по Spring — Евгений Борисов и Кирилл Толкачёв. Евгений, пройдя путь от простого программиста до архитектора и устав от рутины, ушел в свободные художники, его доклады широко известны (если кто-то ещё не смотрел "Spring-потрошителя", то вот вам часть 1, часть 2). Кирилл разрабатывает различные банковские API в Альфа-Банке, формирует принципы и наборы инструментов для работы с микросервисной архитектурой, и кстати — постоянный резидент подкаста «Разбор Полётов».
Рандомный бесполезный факт. Даже когда Кирилл просто приезжает на конференцию, не как спикер, он продолжает отвечать на вопросы. Каждый раз, когда мы берём интервью у Альфа-Банка, самый простой способ найти ответ на самые сложные вопросы — найти в толпе Кирилла и попросить рассказать о чём угодно. В частности, он спокойно топит не только за Spring, но например, за DevOps, Groovy и Gradle.
Кошмары разработчика и как их избегать
Вы когда-нибудь работали на легаси-проекте с тоннами исходного кода, но без единого юнит-теста? Или без continuous delivery? Напрочь отсутствовал статический анализ кода или даже просто code style? А в ответ на жалобы на всё это, вас просили не думать о золочении продукта или просто подождать, слишком много всего надо исправить до этого?
Будут разобраны типичные ошибки и изъяны, которые встречались докладчику во множестве проектов, а также объяснено, почему на эти моменты стоит обращать внимание. Цель доклада — помочь разработчикам таких проектов понять, почему это важно, а также мотивировать вводить не только такие базовые вещи, как стандарт кода, автоматические тесты (на всех уровнях), среда развёртывания, системы автоматической сборки и т.д., но и более продвинутые аспекты, которые так важны во всех проектах разработки.
Будет много жизненных примеров с поля боя.
Докладчик — Рустам Мехмандаров из Computas AS. Computer scientist, лидер JavaZone, лидер и член правления норвежской Java User Group — javaBin, один из основателей и организаторов Arctic IoT Challenge.
Реактивное программирование на Vert.x
Надоело отлаживать критическую секцию в сто первый раз? Хочется писать полезный код, а не решать проблему с гонками потоков? Может, стоит попробовать что-то новое? Vert.x совершенно не похож на старый добрый Spring и Java EE. В этом его сила, это таит сложности. Легко написать код, который тяжело поддерживать. С другой стороны, имея опыт, Vert.x превращается в удобный инструмент разработки. А как после этого запускать приложение на Vert.x в промышленной среде?
Про всё это расскажет Антон Ленок. Доклад будет полезен тем, кто хотел бы начать использовать Vert.x, но не знает, с какой стороны подойти. Антон — инженер в Сбербанк-Технологиях, разрабатывает серверную часть для Сбербанк Онлайн и внедряет разные приятные вещи: ELK, Docker, Kubernetes, и т.п.
ReadyNow — an "AOT" with profiling for Java
Хардкорный доклад Дугласа Хокинса про Ahead-of-time компиляцию в Azul Zing от главного разработчика этой функциональности.
Designing for modularity with Java modules
В первый день уже был доклад про модули, Rabea Gransberger рассказывала про рефакторинг монолитных приложений. Этот доклад — более архитектурный, рассказывающий о трейд-оффах между преимуществами и недостатками модулей, способах правильной организации архитектуры. Как делать расширяемые сервисы, как это работает с dependency injection, что делать с циклическими и опциональными зависимостями, как динамически загружать модули, и многое другое.
Докладчик — Sander Mak, работает в Luminis Technologies (компания в Нидерландах, занимающаяся облаками и девайсами), занимается разработкой масштабируемых приложений на Java и TypeScript. Написал книгу по теме доклада: "Java 9 Modularity" (O'Reilly).
От монолита к микросервисам
Хайп по распиливанию монолитов не утихает. Только что у нас было два доклада по модулям, и вот ещё один — но уже про микросервисы. Николай Арчаков — старший архитектор в Сбертехе. Он расскажет о нелёгком пути, пройденном разработчиками «Кредитной фабрики» Сбербанка от монолитной архитектуры к микросервисной. "Кредитная фабрика" — это система сквозного процесса обработки и принятия решений по кредитным заявкам, тот самый "энтерпрайз"" из палаты мер и весов, однако же они как-то справились.
Extreme scaling with Alibaba JDK
Хардкорный доклад про внутренности собственного JDK, которого делают в недрах Alibaba: про сборщики мусора, лёгкую многопоточность на корутинах, эффективный мониторинг, и весь связанный с этим ужас, который мы так любим (или нет?). Докладчик — Sanhong Li из Alibaba, ведущий разработчик их JDK.
На плечах гигантов: языки, у которых учился Kotlin
Андрей Бреслав возглавляет разработку языка Kotiln в компании JetBrains c 2010 года, занимается как дизайном языка и общим руководством проекта. Учитывая что на доклад в основном пойдут разработчики на Kotlin, вряд ли его нужно представлять. Андрей расскажет о языках, из которых были заимствованы идеи и концепции. В числе прочего, речь пойдет о Java, C#, Scala, Groovy, Python, Gosu и т.д. Будет продемонстрировано, как некоторые из этих идей были интерпретированы особым котлиновским способом. Некоторые языки наоборот, учатся на примере Котлина (Swift, Java, Hack, C#) — про это тоже будет пара слов.
«Умный» релиз мультимодульного проекта в один клик
Вы занимаетесь выпуском релизов многомодульных проектов в вашей команде? Делаете по несколько релизов в неделю, а порой и в день? Являетесь поставщиком артефактов для других команд? О, тогда этот доклад для вас! Будут рассмотены задачи, возникающие в процессе выпуска релиза проекта, обозначены возможные проблемы, а также представлен готовый разработанный инструмент для автоматизации данного процесса.
Владислав Гончаров — ведущий IT-инженер в компании Сбербанк-Технологи, занимается разработкой Платформы Поддержки Развития Бизнеса (ППРБ), про которую у нас уже были доклады.
Боремся с "Russian Hackers" с помощью Kafka Streams и Firehose API
Вот все говорят — русские хакеры. А был ли мальчик? В этом докладе мы попытаемся найти следы Cozy Bear, Fancy Bear и прочих медведей, анализируя поведенческие паттерны на платформе Bintray с помощью Apache Kafka и Firehose API. На реальном примере будет показано, как с помощью Kafka KSQL обрабатывать большие объемы поточных данных, которые в реальном времени отдает любой Firehose API, и как находить в нем зловредные (и не только) закономерности.
Никаких предварительных знаний о Kafka Streams, KSQL, Firehose APIs, Bintray или о Russian hackers не требуется!
Это второй доклад Виктор Гамова на этой конференции, совешенно отличающийся от предыдущего. На этот раз, вместе с ним будет Барух Садогурский. Барух — developer advocate в компании JFrog и (по его словам) делает в жизни ровно 3 вещи: зависает с разработчиками Bintray и Artifactory, пописывает для них код и рассказывает о впечатлениях в блогах и на конференциях, таких как JavaOne, Devoxx, OSCON, конечно же JPoint и Joker. На самом деле, Барух — один из самых популярных наших докладчиков, всё что он делает — попадает напрямую в топ.
The Eclipse OpenJ9 JVM: a deep dive!
Хардкорный доклад Tobi Ajila о внутренностях OpenJ9 (бывшего IBM J9) и его применимости к разработке облачных приложений от одного из разработчиков J9 и участников проектов Valhalla и Panama.
A craftsman’s guide to designing a clean architecture
В 2018 году микросервисы стали чуть ли не стандартом архитектуры современных приложений. Но также понятно, что всё это поднялось на диком хайпе. Переживут ли микросервисы хайп? Чтобы пережить всё это, Marcus Biel предлагает нам делать хорошую модульную архитектуру, про которую и будет рассказывать в докладе. Опять будут модули из свежих версий Java, будет обсуждение принципов сильного и слабого связывания, паттерн hexagonal architecture, и всё такое прочее.
Докладчик — Marcus Biel, известный Java-евангелист, создатель видеотуториалов и спикер на конференциях, входящий в разные списки лидеров мнений Java-мира, несущий слово Java со своего сайта Clean Code Academy.
Kotlin DSL: теория и практика
Написание тестов — не самое приятное занятие. Это долгий процесс, требующий большой концентрации и внимания… Однако, писать тесты всё равно надо. Как известно, с помощью Kotlin можно легко набросать DSL. В докладе рассказывается, как Kotlin DSL заменил билдеры и статические методы, что превратило добавление новых тестов и поддержку старых из рутины в увлекательный процесс.
В докладе разбираются основные инструменты из арсенала разработчика и то, как их можно комбинировать для решения задач тестирования. Докладчик проведёт нас по пути от проектирования Идеального Теста до запуска максимально приближенного к реальности, чистого и понятного кода на Kotlin.
Докладчик — Иван Осипов (из подразделения аутсорсинговых проектов Haulmont). Доклад будет полезен практикующим инженерам — и тем, кто рассматривает Kotlin как язык для комфортного написания компактных тестов, и тем, кто хочет улучшить процесс тестирования в своем проекте.
Статус проектов OpenJDK: прошлое, настоящее и будущее Java
Это мой доклад, информацию о докладчике можно прочитать в хабропрофиле :-) Кратко подведём итоги прошедшего года (выход Java 9 и Java 10, новая релизная политика) и обсудим основные направления развития OpenJDK: Graal/Truffle/Metropolis, Value Types, Valhalla, Panama, Amber, Loom, Shenandoah. Короче, всё то, про что я пишу посты на Хабре. Если повезёт, будут не только слайды, но и живые демки для неверующих, считающих что "они не видят смысла использовать Graal в повседневной жизни". Доклад будет полезен слушателям, желающим получить общую картину «поля боя» за свежую, современную и быстро развивающуюся Java.
Как сделать встроенный в JVM профайлер, который не боится AOT компиляции?
Хардкорный доклад Ивана Углянского про написание собственного профайлера для собственной JVM. Докладчик — один из разработчиков Excelsior JET.
Java EE 8 finally final! And now Jakarta EE?
Недавно Оракл удивил всех передачей JavaEE в Eclipse Foundation. Правда, этот проект уже не смог называться JavaEE и был переименован в JakartaEE. Кстати, я (olegchir) даже поучаствовал в конкурсе на новый логотип проекта.
В этом докладе David Delabassée расскажет о новых возможностях Java EE 8 и том, как всё это относится к JakartaEE. Дэвид — известный оракловский Java-евангелист, который участвовал в разработке Java ещё во времена Sun Microsystems.
Анализ программ: как понять, что ты хороший программист
После шока, вызванного теоремой Райса, мир стремится обрести почву под ногами и отчаянно придумывает способы пролить хоть небольшой свет на то, что происходит внутри программ. Data race detectors, model-checking, другие методы динамического анализа появляются один за другим. В это время статические чекеры, javac-плагины и другие тулы статического анализа тоже начинают поднимать голову. За горизонтом маячит мираж автоматической верификации. Наш герой пытается сделать поверхностный обзор этих штуковин, старается попробовать их в своей практике и в конце концов приходит к… [чтобы понять это, необходимо прийти на доклад!] Докладчик — Алексей Кудрявцев уже 10 лет занимается программированием IntelliJ IDEA в JetBrains.
Linux container performance tools for JVM applications
Хардкорный доклад о профилировании контейнеризированных приложений с использованием perf, async-profiler, BCC, и т.п. Докладчик — CTO компании Sela Group, Microsoft MVP и региональный директор, автор в Pluralsight и O'Reilly, консультант, тренер, и так далее, и тому подобное. Рассказывает лютый хардкор.
Приключения Сеньора Холмса и Джуниора Ватсона в мире разработки ПО
Завершающий кейноут Барух Садогурского и Евгения Борисова. У обоих спикеров уже были доклады сегодня — Барух весте с Гамовым рассказывал про Apache Kafka и Firehose API, а Евгений вместе с Кириллом Толкачёвым делали огромный доклад про Spring.
Это будет необычный доклад. В нём будут Холмс и Ватсон. Они раскроют несколько загадок, с которыми вы сталкивались, сталкиваетесь или будете сталкиваться при каждодневной разработке. Кишок сборщиков мусора и байткода не будет, зато будут инструменты, библиотеки и фреймворки, которые озадачивают рядовых разработчиков в каждодневной рутине, приводят к простою, профукиванию дедлайнов и затяжным депрессиям. Практически, в этом докладе Шерлок и Ватсон спасают ваш лоб от фейспалмов и граблей, на которые кто-то уже наступал.
Минутка рекламы. Напоминаем, что на JPoint всё ещё возможно зарегистрироваться. Билеты можно взять на официальном сайте конференции. Чтобы оценить качество докладов, можно посмотреть архив видеозаписей на YouTube.