«Я экспериментировал с задачами кубического представления в стиле предыдущей работы Эндрю и Ричарда Гая. Численные результаты были потрясающими…» (комментарий на MathOverflow)

Вот так ушедший на покой математик Аллан Маклауд наткнулся на это уравнение несколько лет назад. И оно действительно очень интересно. Честно говоря, это одно из лучших диофантовых уравнений, которое я когда-либо видел, но видел я их не очень много.

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


«95% людей не решат эту загадку. Сможете найти положительные целочисленные значения?»

Вы наверно уже видели похожие картинки-мемы. Это всегда чистейший мусор, кликбэйты: «95% выпускников МТИ не решат её!». «Она» — это какая-нибудь глупая или плохо сформулированная задачка, или же тривиальная разминка для мозга.

Но эта картинка совсем другая. Этот мем — умная или злобная шутка. Примерно у 99,999995% людей нет ни малейших шансов её решить, в том числе и у доброй части математиков из ведущих университетов, не занимающихся теорией чисел. Да, она решаема, но при этом по-настоящему сложна. (Кстати, её не придумал Сридхар, точнее, не он полностью. См. историю в этом комментарии).

Вы можете подумать, что если ничего другое не помогает, то можно просто заставить компьютер решать её. Очень просто написать компьютерную программу для поиска решений этого кажущегося простым уравнения. Разумеется, компьютер рано или поздно найдёт их, если они существуют. Большая ошибка. Здесь метод простого перебора компьютером будет бесполезен.

На работе я исследую безопасность ОС или программ. Ниже я расскажу об одном из таких исследований, результатом которого стал полнофункциональный эксплоит типа UAC bypass (да-да, с source-code и гифками).


Ах, да, в Майкрософт сообщили, они сделали вид, что им не интересно.
Алярм! Под катом около 4 мегабайт трафика – картинок и гифок.

Наиболее частым, применяемым способом удаленного доступа к внутренним ресурсам организаций является настройка VPN-соединения. Данная технология имеет ряд минусов таких как:

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

Я предлагаю рассмотреть замену VPN технологией, разработанной компанией Microsoft – DirectAccess. Это позволит расценивать удаленный компьютер в качестве компонента вычислительной сети организации, благодаря чему можно будет выполнять следующие операции по обеспечению информационной безопасности:

• применять к удалённому компьютеру групповые политики;
  
• подключаться к компьютеру, используя штатные средства – RDP, mmc, удаленный помощник;
  
• контролировать интернет трафик;
  
• применять DLP-системы;
  
• использовать централизованное управление антивирусной защитой;
  
• и другие средства доступные внутри домена.
  

DirectAccess я буду рассматривать совместно с Windows To Go. Windows To Go — это операционная система Windows 8 и выше, установленная на внешний USB-носитель со всем необходимым ПО. Установленную таким образом ОС можно загрузить на любом оборудовании соответствующем минимальным требованиям. При этом ПО и данные, на используемом компьютере не затрагиваются.

Доброго времени суток. Предыстория такова: десять лет назад мной была поднята инфраструктура сети салонов сотовой связи, распределенная по области. В качестве учетного решения использовалась система 1С: Предприятие 7.7 в режиме распределенной базы данных. Для обмена данными использовалась обычная сетевая папка windows, доступ к которой осуществлялся через туннель OpenVPN. И вот как-то неделю назад полностью остановился обмен информацией между центром и периферией. Почему-то сразу закралась мысль — неужели прошло десять лет (именно на этот срок делался корневой сертификат). Анализ логов подтвердил проблему, схема отлично себя зарекомендовала за эти десять лет, но пришел срок. И что же теперь, генерировать заново весь объем клиентских и серверных ключей/сертификатов??? Нет, можно поступить немного проще…

Долго искал, как безболезненно настроить SSL сертификат от Let's Encrypt на Microsoft Azure. В рунете с этим оказались проблемы, но на просторах большого интернета нашлась очень и очень годная статья, по которой мне удалось настроить это шайтанство. Думаю, для новичков, у которых проблемы с иностранными языками (бывает такое, но все мы учимся), перевод статьи пригодится.

За несколько лет сначала вынужденного, а потом и вполне занимательного администрирования 1С у меня накопился набор решений под большинство особенностей продукта. Предлагаю отложить в сторону высокие материи про кластеры и тюнинг SQL, и перетряхнуть запасы скриптов и механизмов, которые облегчают жизнь с 1С.

Будут как простые инструменты создания новых пользователей и мониторинга "все ли вышли из базы", так и более изощренные интерфейсы проверки целостности базы и ее перемещения.

Про HSTS на Хабре уже писали, этот механизм включен в генераторе конфигов для веб-серверов от Mozilla. Написать этот пост я решил за один день столкнувшись с недоступность сразу двух крупных сайтов из-за HSTS.

Что такое HSTS?

HSTS (HTTP Strict Transport Security) — это механизм защиты от даунгрейд-атак на TLS, указывающий браузеру всегда использовать TLS для сайтов с соответствующими политиками. Стандарт описан в RFC6797, а политики бывают двух видов:

Динамические

Политика применяется из HTTP-заголовка Strict-Transport-Security при первом заходе на сайт по HTTPS, в нём указан срок действия и применимость к субдоменам:

Strict-Transport-Security: max-age=15768000; includeSubDomains;

Статические

Статические политики захардкожены в браузер и для некоторых сайтов включает привязку к вышестоящему CA, выпустевшему сертификат (например: google.com, paypal.com или torproject.org). Причем она может действовать только когда сайт открыт через TLS, разрешая незащищённое соединение, но блокируя MitM с подменой сертификата.

Список из Chromium используют все популярные браузеры (Firefox, Safari и IE 11+Edge) и добавить в него сайт может любой желающий, если веб-сервер отдаёт заголовок Strict-Transport-Security со сроком действия от двух лет и ключевым словом preload в конце:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

A Thief on the Run by Manweri

Привет, Хабр! В этом посте мы снова поговорим о проблеме подделки отправителя (или так называемом спуфинге). В последнее время такие случаи очень участились: подделывается все: письма со счетами за ЖКХ, из налоговой инспекции, банков и так далее. Решить эту проблему помогает настройка строгой DMARC-политики. Мы как почтовая служба проверяем все приходящие к нам письма на DMARC начиная с февраля 2013 года. Мы были первым в рунете почтовым сервисом, поддержавшим стандарты DMARC. Однако чтобы минимизировать число поддельных писем, этого, к сожалению, недостаточно. Главное, чтобы строгий DMARC был поддержан на стороне отправителя. Вот почему мы не устаем качать эту тему, ведем активную разъяснительную работу и всячески призываем всех включать у себя строгий DMARC.

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

Мы в 1cloud предоставляем услуги аренды виртуальной инфраструктуры и совсем недавно начали поставлять SSL-сертификаты от Сomodo, Geotrust, Rapidssl, Symantec и Thawte. Добавление такой возможности сподвигло нас к беглому анализу публикаций, которые затрагивали те или иные аспекты работы с SSL и выходили на Хабре за последние пару лет.

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

У каждого администратора однажды перестает отзываться некий сервер на другом конце города. В вечер пятницы приходится ехать по раскисшему весеннему городу, так как пациент недоступен через Интернет и вменяемого персонала рядом нет. Помню, как в один из таких случаев было обидно лицезреть "Press F1 to continue": вышел из строя ИБП и старенький ProLiant после перезагрузки считал, что «Power Supply Failed». Ну надо же было забыть отключить уведомление с ожиданием реакции в BIOS!

Но здесь будет не ода IPMI, а немного личных граблей и хитростей удаленного восстановления сетевого и серверного железа.

Microsoft Active Directory является стандартом в инфраструктуре, где требуется аутентификация пользователей и централизованное управление. Почти невозможно представить себе, как системные администраторы справлялись бы со своей работой без этой технологии. Однако использование Active Directory не только приносит большую пользу, но и налагает большую ответственность, требуя значительного времени и понимания процессов работы. Поэтому я предлагаю вашему вниманию несколько cтатей, которые расскажут, как успешно выполнять бэкап и восстановление Active Directory с помощью решений Veeam. В частности, я поясню, как Veeam помогает делать копии контроллеров домена (DC) или отдельных объектов AD и при необходимости восстановить их.

А начну я с того, что в сегодняшнем посте расскажу о возможностях бэкапа физических и виртуальных контроллеров домена, предоставляемых Veeam, и о том, что необходимо помнить во время бэкапа. За подробностями — под кат.

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

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

В итоге работа с БД может стать узким местом в производительности нашего приложения.

Чтобы избавить себя от подобного рода проблем, я предлагаю рассмотреть различные аспекты тестирования баз данных. К которым можно отнести нагрузочное тестирование и проверку производительности SQL Server в целом при помощи юнит-тестов.

Дисковый массив с нотками ретро.

На плечах RAID-контроллеров лежит ответственная задача — управление дисковой подсистемой, то есть всей информацией, хранимой на сервере. Именно они отвечают за работу дисковых массивов, позволяя повысить производительность сервера или надёжность хранения данных. Поэтому давайте поговорим о RAID-контроллерах, установленных в серверы вендоров «большой тройки», об их возможностях и особенностях.

Записывая для VPSVille три ролика по Graylog понял, что на хабре по нему только одна обзорная статья, а мануалы на любом языке запутаны из-за различной работы компонентов в разных версиях ПО. Потратив сутки на переваривание всей этой красоты пишу мануал: как настроить сервер Graylog для сбора событий из Windows и Linux.

Кто очень хочет понимать Linux, но не поймет с чего начинать — прошу ко мне на канал.



Вместо введения: Graylog это open source программное обеспечение, предназначенное для сбора логов в гигантских сетях их огромного количества источников различными способами. В нем можно удобно организовать сбор событий, фильтрацию, поиск, автоматизацию (всякие алерты) и т.д. Аналогичных средств множество, но Graylog предлагает нереальную производительность с использованием современных компонентов, удобную аналитику и красивый интерфейс.
Для работы ему нужна Java, конфигурацию он будет хранить в MongoDB, для поиска и хранения логов — использовать ElasticSearch. Про сбор информации из WIndows будет ниже, но спойлер — агенту больше не нужна Java.

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

В то время, как при производстве накопителей используется множество других метрик, чтоб описать и гарантировать должную производительность, на рынке систем хранения и дисковых накопителей, принято использовать IOPS, как сравнительную метрику, с целью «удобства» сравнения. Однако производительность систем хранения, измеряемая в IOPS (Input Output Operations per Second), операциях ввода / вывода (записи / чтения), подвержена влиянию большого множества факторов.

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

Начнем с того, что IOPS вовсе не IOPS и даже совсем не IOPS, так как существует множество переменных, которые определяют сколько IOPS мы получим в одних и других случаях. Также следует принять во внимание, что системы хранения используют функции чтения и записи и обеспечивают различное количество IOPS для этих функций в зависимости от архитектуры и типа приложения, в особенности в случаях, когда операции ввода / вывода происходят в одно и тоже время. Различные рабочие нагрузки предъявляют различные требования к операциям ввода / вывода (I/O). Таким образом, системы хранения, которые на первый взгляд должны были бы обеспечивать должную производительность, в действительности могут не справится с поставленной задачей.

В качестве предисловия. При общении с коллегами, отвечая на их вопросы о совместной настройке DNS и DHCP, часто отсылаю их к замечательной статье Шона Айви на Technet. К сожалению, аналогичного материала на русском языке я не находил. В очередной раз, устно переведя её знакомому, я решил оформить письменный перевод, чтобы иметь возможность отсылать к нему.

Привет всем, меня зовут Шон Айви и я US PFE (Premier Field Engineer). Моя специализация — операционная система Windows и службы Active Directory. Проще говоря, я специализируюсь на Active Directory и связанных с ней сетевых службах. Недавно, у трёх разных клиентов, я помогал SCCM-администраторам, у которых была проблема с установкой SCCM агента. В логе ccm.log значилась ошибка Failed to get token for current process (5). Мы обнаружили, что проблема была не в SCCM, а во взаимодействии DNS и DHCP. Как оказалось, другие службы тоже испытывали связанные с этим проблемы, просто либо демонстрировали иные симптомы, либо не демонстрировали их совсем. Давайте поговорим о том почему так получалось и как это можно предотвратить!

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

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

В чем отличие маршрута пакета от его пути?
Стандартный механизм маршрутизации пакетов в интернете — per hop behavior — то есть каждый узел в сети принимает решение куда ему отправить пакет на основе информации, полученной от протоколов динамической маршрутизации и статически указанных администраторами маршрутов.

Маршрут — это интерфейс, в который нам надо послать пакет для достижения какого то узла назначения и адрес следующего маршрутизатора (next-hop):

R1#sh ip rou | i 40.  
	 40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O        40.0.0.0/31 [110/3] via 20.0.0.0, 00:01:54, FastEthernet0/0
O        40.1.1.1/32 [110/4] via 20.0.0.0, 00:00:05, FastEthernet0/0

Что такое путь? Путь — это список узлов, через которые прошел (пройдет) пакет:

 1  10.0.0.1  16.616 ms  16.270 ms  15.929 ms
 2  20.0.0.0  15.678 ms  15.157 ms  15.071 ms
 3  30.0.0.1  26.423 ms  26.081 ms  26.744 ms
 4  40.0.0.0  48.979 ms  48.674 ms  48.384 ms
 5  100.0.0.2  58.707 ms  58.773 ms  58.536 ms

Путь пакета можно посмотреть с помощью утилит tracert в OC Windows и traceroute в GNU/Linux и Unix-подобных системах. (другие команды, типа tracepath мы не рассматриваем).
Многие считают что этих утилит один и тот же принцип работы, но это не так. Давайте разберемся.

На портале Channel9 доступна запись совместного вебинара Microsoft и Veeam Software «Что нового в Windows Server 2016», который мы провели 30 марта.