Два математика из Стэнфордского Университета, Каннан Соундараджан [Kannan Soundararajan] и Роберт Лемке Оливер [Robert Lemke Oliver] (на фото выше) обнаружили ранее неизвестное свойство простых чисел. Выяснилось, что шансы на то, что за простым числом, оканчивающимся на 9, будет следовать число, оканчивающееся на 1, на 65% больше, чем шансы, что за ним будет следовать число, снова оканчивающееся на 9. Это предположение было численно проверено компьютерными методами для миллиардов известных простых чисел.

По словам Кена Оно, математика из Университета Эмори в Атланте, это предположение по сути противоречит ожиданиям большинства математиков. Ранее считалось, что простые числа в массе своей ведут себя достаточно случайно. Большинство теоретиков сошлось бы на предположении, что шансы иметь на конце одну из возможных для простых чисел цифр (1, 3, 7, 9) примерно равны для всех таких чисел.

Эндрю Грэнвиль [Andrew Granville] из Монреальского университета, заявил, что «мы занимаемся изучением простых чисел уже очень давно, и никто раньше этого не замечал. Это безумие какое-то. Не могу поверить, что кто-то смог до этого додуматься. Это выглядит очень странно».

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.

Привет, Хаброжители! Судя по большому числу откликов, тема б/у серверов приобретает все большую популярность. В этой статье мы хотим поделиться с нашими читателями конкретными кейсами, которые нам удалось успешно решить, используя бывшее в использовании серверное оборудование. Все примеры подкреплены цифрами, дабы избежать голословности.

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

Все мы в IT сталкивались с системами отслеживания ошибок — с так называемыми баг-трекерами, с issue-трекерами. Один из популярных продуктов такого рода — Atlassian JIRA.

На самом деле, Atlassian JIRA — это больше, чем просто система отслеживания ошибок. JIRA может использоваться довольно широко — в том числе и для управления проектами. Можно сказать, что JIRA — это система для отслеживания статуса задач. Задачи могут быть разными: это сбор требований, тестирование, непосредственно разработка и т. д. Я видел даже попытки подсадить на JIRA бухгалтеров — а что, мол, будет у нас agile-бухгалтерия!

На официальном же сайте JIRA описывается следующим образом:
JIRA is the tracker for teams planning and building great products. Thousands of teams choose JIRA to capture and organize issues, assign work, and follow team activity. At your desk or on the go with the new mobile interface, JIRA helps your team get the job done. В общем, основная идея JIRA в том, что она позволяет планировать работу.

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

Содержимое: как сделать так, чтобы компьютер отвечал в интернете на все свои IP-адреса по всем своим интерфейсам, каждый из которых имеет шлюз по умолчанию. Касается и серверов, и десктопов.

Ключевые слова: policy routing, source based routing

Лирика: Есть достаточно статей про policy routing в Linux. Но они чаще всего разбирают общие, более тонкие и сложные случаи. Я же разберу тривиальный сценарий следующего вида:



Нашему компьютеру (серверу) доступно три интерфейса. На каждом интерфейсе шлюз ему выдал IP (статикой или по dhcp, не важно) и сказал «весь трафик шли мне».

Если мы оставим эту конфигурацию как есть, то будет использоваться принцип «кто последний встал, того и дефолтный шлюз». На картинке выше, если последним поднимется нижний интерфейс (241), то в него будет отправляться весь трафик. Если к нашему серверу придёт запрос на первый интерфейс (188), то ответ на него всё равно пойдёт по нижнему. Если у маршрутизатора/провайдера есть хотя бы минимальная защита от подделки адресов, то ответ просто дропнут, как невалидный (с точки зрения 241.241.241.1 ему прислали из сети 241.241.241.0/24 пакет с src 188.188.188.188, чего, очевидно, быть не должно).

Другими словами, в обычном варианте будет работать только один интерфейс. Чтобы сделать ситуацию хуже, если адреса получены по dhcp, то обновление аренды на других интерфейсах может перезаписать шлюз по умолчанию, что означает, что тот интерфейс, который работал, работать перестанет, а начнёт работать другой интерфейс. Удачной стабильной работы вашему серверу, так сказать.

Решение

Доброго времени суток, уважаемые хабравчане! В Elasticweb мы негласно ратуем за Nginx и, наверное, мы одни из немногих хостингов, которые не поддерживают Apache и .htaccess соответственно. В связи с этим, большое количество обращений в тех. поддержку связано с оказанием помощи в написании конфигурационного файла для Nginx. Поэтому мы решили собрать коллекцию полезных сниппетов и коллекцию готовых Nging конфигов для наиболее популярных CMS/CMF/Фреймворков на PHP.

Сумеречными зимними вечерами под песнь вьюги, укутавшись в овечий плед с бокальчиком «яблочной самогонки», я люблю почитывать логи на сервере. Авторизация по ключам упрощает сие, так что если в публичное помещение меня и не пустят, то сервер всегда рад приютить, старый чертяга.

В мире много чего происходит, у кого счастливое 200, кто-то недоуменно смотрит на 301, кто-то царапает похабщину на 403.

Но самый ценных мех — это исследователи. Это те, кто открывает новый для себя мир на основе своих знаний путем проб и 404.

Исследователи разработали недорогой способ обнаружения точного местоположения смартфона, работающего в LTE/4G сотовой сети. Эта разработка дает понять, что мобильные сети новых поколений так же уязвимы к некоторым типам атак, как и сети, работающие по прежним, уже устаревшим, стандартам связи и спецификациям.

Новая атака использует уязвимость в LTE протоколе. Этот стандарт к концу года будет обеспечивать связь для 1,37 млрд абонентов. Для проведения атаки требуется собрать систему из элементов, общая стоимость которых составляет около $1400. В качестве ПО используется Open Source софт. Система, узел NodeB, позволяет определить местонахождение телефонов, совместимых с LTE-стандартом, с точностью до 10-20 метров. В некоторых случаях это оборудование позволяет узнать и GPS-координаты устройств, хотя атака такого типа может быть обнаружена пользователем смартфона. Разработан и еще один способ определения координат смартфонов, при этом атаку практически невозможно обнаружить. Этот метод позволяет определить местонахождение заданного устройства в пределах пары квадратных километров.

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

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

И вообще вели себя вызывающе с точки зрения ИТ.

При этом объём кода, нужные мощности и сложность реализации процессов росли. Дело в том, что такая деавтоматизация требует очень нехилых вложений в ИТ. Сейчас объясню на примерах, в чём дело и зачем мы так странно делаем.

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

Несколько недель назад проект Zadarma опубликовал собственный API. Он позволяет интегрировать основные функции IP-телефонии и бесплатной облачной АТС.
Каждый может за считанные минуты создать бесплатную облачную АТС и подключить к ней интерфейс API, а через него уже интегрировать АТС со своими приложениями.
В статье публикуем список и описание методов, ссылки на классы и примеры, которые уже есть для работы (опубликованы PHP-классы). Нам крайне интересны ваши отзывы: для дальнейшего развития интерфейса API, интеграции с CRM и другими системами.

Ну, вот и клюнул петух, о котором я писал на Хабре еще год назад, в одно место наши непобедимые силовые структуры. Первым публично опозорилось Министерство обороны, которое, как раскопали (сайт огорожен Роскомнадзором) ребята из Анонимного Интернационала, не брезгует пересылать через публичные почтовые серверы документацию о наших грозных Искандерах и атомных подводных лодках. Для этого, правда, по утверждению хакеров им пришлось взломать те самые почтовые ящики на yandex.ru, mail.ru, gmail.com (а также, айфон и айпад) и выложить в паблик выдержки из переписки, чтобы министерство не смогло это просто так проигнорировать.
Свою публикацию весельчаки из «Шалтая» оформили в виде открытого письма в Департамент военной контрразведки ФСБ РФ:

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

Материал разбит следующим образом:

1. Введение
2. Примеры сессий
3. Проверка авторизации на сервере (LOGIN, PLAIN, CRAM-MD5), Base64
4. Проверка шифрования SSL/TLS
5. Анализ почтового трафика при помощи tshark. Расшифровка SSL/TLS
6. Ссылки на материалы

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

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

С этим банком у меня была договорённость о поиске уязвимостей и все мои действия были санкционированными. В тот вечер я уже потратил приличное время на поиск более-менее критичной уязвимости и так не найдя ничего стоящего, было уже отчаялся. Но тут мой взгляд зацепился за один параметр в череде запросов к серверу в момент авторизации. К слову, этот банк использовал передовую и очень надежную технологию авторизации, а именно двухфакторную авторизацию через смс. Так вот, параметр GET запроса, на который я обратил внимание, имел вид: go=/path/to/some/page
и формировался на стороне сервера для дальнейшей переадресации. Но проблемой было то, что путь для переадресации был относительным и добавлялся к домену сайта и поэтому я игнорировал этот запрос в своих предыдущих исследованиях. К тому же, что бы в нем существовала потенциальная уязвимость, должен был иметь место ряд факторов, а именно:
1). возможность при помощи значения параметра go
обеспечить переадресацию на сторонний домен
2). возможность на клиенте задавать значение этого параметра
3). и наконец, после авторизации при редиректе на сторонний домен должна передаться какая нибудь ценная информация

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

Сложилась ситуация, что участвую в проекте, который работает с достаточно большой нагрузкой. Как уже написал — 36 млн запросов в час. Я много чего прочитал и перепробовал за последний месяц, настраивая сервер; хотелось бы просто сжато и компактно выдать тезисно то, что работает хорошо в такой конфигурации.

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Месяц назад, просматривая мобильное приложение для интернет-банкинга от Альфа-Банка, решил проверить, насколько оно безопасно.



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

В настоящее время я получаю второе высшее образование по программе MSc Usability Engineering в Райн-Ваальском Университете Прикладных Наук (Германия).

Данная программа является единственной в Германии, полностью посвященной Usability и HCD. Кроме того, в качестве преподавателей как правило выступают Usability-эксперты, работающие на такие компании, как Samsung, Siemens, Wargaming, Porsche и другие. Более того, некоторые из преподавателей входят в рабочие группы по разработке стандартов ISO для Usability.

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

В этой статье мы опишем, как за несколько простых шагов превратить существующий нагрузочный тест, созданный при помощи Apache JMeter, в тестовый сценарий для HP StormRunner Load. Предположим, что вы создали и отладили библиотеку JMeter-тестов, и теперь хотите сымитировать большую нагрузку на ваш сервер, скажем, 10 тысяч пользователей. Сервера банков, страховых компаний, электронных магазинов и так далее сталкиваются с подобной нагрузкой ежедневно, но чтобы создать нечто подобное, пользуясь JMeter, вам, скорее всего, придется вручную устанавливать и конфигурировать десятки, если не сотни, удаленных машин. Это означает много часов работы, большие затраты на оборудование и постоянные усилия по сохранению тестовой среды для повторных запусков.

Мы предлагаем вам другое решение – запуск готовых JMeter-тестов с помощью HP StormRunner Load. StormRunner позволяет достичь нагрузки в десятки (и даже сотни) тысяч виртуальных пользователей без траты времени, денег и сил на создание собственной лаборатории. StormRunner – 100% облачный продукт, действующий по модели SaaS, так что создание удаленных машин, внедрение на них тестового программного обеспечения и сбор данных происходят автоматически, без какого-либо вмешательства пользователя.

/ фото KamiPhuc CC

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