Как мы чуть не поседели 3 раза до того, как это стало мейнстримом: кризисы декабря и января

в 11:02, , рубрики: ddos, ruvds_статьи, Блог компании RUVDS.com, отключение питания, платежный шлюз, управление проектами, хостинг, цод

Как мы чуть не поседели 3 раза до того, как это стало мейнстримом: кризисы декабря и января - 1


Я обещал рассказать, что у нас случилось в ЦОДе и хотел дописать всё это к концу февраля. Дальше стало немного не до того, но всё же, раз обещал, рассказываю. Ха, тогда эти проблемы казались нам невероятно огромными.

Сначала в декабре мы потеряли один луч городского питания на ЦОД, а потом почти сразу — второй. И не только мы, поэтому с дизелями отрабатывали впритык. Потом у банка ККБ отозвали лицензию, из-за чего прилегло примерно 10% российской электронной коммерции, потому что кроме Вебмани он обеспечивал очень крупные платёжные шлюзы. И, наконец, у нас был брутфорс на RDP эпических масштабов.

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

Первая кризисная ситуация началась 18 декабря прошлого года достаточно заурядно: несколько серверов взяли и перезапустились. Когда мы начали разбираться, что же случилось, выяснилось, что сгорел «их» ИБП. Почему сгорел ИБП? Потому что был скачок напряжения на подстанции, подающей городское питание. Дальше у нас вообще пропал этот самый ввод, автоматика отработала штатно и перекинула нас на второй луч. Мы сразу же сделали тестовый пуск дизелей. Всё на первый взгляд выглядело довольно рутинно.

▍ Драма 18–29 декабря

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

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

Дежурный смены переключил питание на дизель. Соляра у нас нормальная зимняя, её никто не сливал и не воровал, поэтому воды в ней было не больше положенной нормы. Но запас топлива у нас на 9 часов работы на полной мощности. Дальше топливо нужно подвозить, и у нас есть контракт с компанией, которая это делает.

В районе 17:40 мы звоним и заказываем топливо, а нам отвечают, что в субботу ночью его никто не повезёт. И стоит рассчитывать на понедельник. Понедельник нас никак не устраивает, и такой подставы от поставщика мы просто не ждали. Оказывается, по будням они возят нормально, а вот в субботу ночью у них в голове не укладывается, как можно поставлять топливо в середину промзоны.

Один человек начинает искать, где взять ДТ ночью, а второй — куда его положить. Потому что мы можем привезти на территорию, условно, бензовоз, но слить его полностью не можем, потому что наше хранилище и хранилище соседнего ЦОДа на той же территории (мы временно объединили ресурсы хранилищ и электросети дизелей) не самые большие. В общем, начинаем искать варианты тары, потому что топливом, похоже, надо запасаться надолго: с учётом времени сбоя и масштаба спецэффектов наш прогноз ремонта был на понедельник–вторник.

Возникла ещё одна проблема: как я говорил, мы объединили ресурсы сетей с соседним ЦОДом, и наших дизелей хватило впритык. То есть мы включили вообще все мощности из имеющихся, включая тот дизель, который купили случайно на эмоциях. Он очень пригодился. Так вот, резерва у нас не оставалось — если бы одна из машин сломалась, то пришлось бы деградировать. Этой же холодной субботней ночью мы стали искать, где взять ещё один дизель на 0,4 МВт.

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

В какой-то момент уже думали, что возьмём бортовую «газель» и поедем на заправку за топливом с большими канистрами, но всё обошлось, и бензовоз с ДТ заехал на территорию, а мы смогли его разгрузить. Тут опять же очень помогли парни из соседнего ЦОДа: дежурный админ просто не сделал бы это руками, и без них нам бы пришлось выводить весь состав учредителей на разгрузку.

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

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

В итоге я понял, что нужно было не только регулярно включать дизель, но и проверять цепочку поставок ночью в праздники. Потому что это критично, а выходить самому и возить топливо от заправки к ЦОДу на «газели» как-то не очень вяжется с ИТ-бизнесом, знаете ли. Ну и ещё надо иметь наличные на случай срочной поставки: приличные конторы просто не могут обработать документы в такое время, договориться можно только с частником, по сути.

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

▍ Брутфорс RDP

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

Сразу скажу, это коснулось только тех машин, где не был нормально настроен файрволл. Это известная проблема VDS: в отличие от обычного хостинга, где файрвол лежит в зоне ответственности оператора, у нашего бизнеса каждый клиент делает с сервером что хочет. Есть инструкция, есть рекомендации, есть уведомления про то, что не надо отключать файрвол, есть подробные советы, как настроить доступ только со своих IP — но всё равно есть примерно около трети пользователей, кто вообще не понимает, зачем всё это нужно. Какой файрвол, о чём вы? Работает и ладно.

У нас было решение с ханипотами, которое достаточно хорошо работает. Вот пост про него. У нас был настроен самописный статистический анализатор трафика, который выделяет RPD-сессии (и другие, кстати, тоже) и может понять адрес источника — как раз на случай брутфорсов и других атак. Всё это работало, но работало для конкретных единичных случаев или маленьких ботнетов. Пришедший в гости оказался большим.

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

В 2004 году турецкий интернет-провайдер TTNet по ошибке анонсировал, что он является наилучшим маршрутом для всего трафика интернета. В итоге часть пользователей по всему миру потеряли доступ к части или ко всему интернету.

В 2008 году пакистанский интернет-провайдер попытался заблокировать YouTube при помощи BGP. Но из-за ошибки сделали недоступным YouTube на несколько часов по всему миру.

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

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

Поддержка сначала объясняла про настройку файрвола. Проблемы касались Win-машин, где такие ситуации обрабатываются не так очевидно, как в Linux. Потом решили в ответ на заявки предлагать устанавливать утилиту из нашей статьи про ханипоты (ссылка указана выше), для того чтобы автоматически добавлять плохие IP в исключения файрвола. Это чуточку помогло: обратившиеся пользователи, которых устроило такое решение, ставили её и получали слой защиты. Так или иначе это не сильно меняло ситуацию для нас, потому что необходимо было помочь всем пользователям одновременно.

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

▍ Отзыв лицензии ККБ

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

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

Наш шлюз выглядел сверхнадёжно: это Paymaster, который был системой Вебмани. Через него мы принимали карты, СБП, Вебмани, палку и прочие вещи. Примерно 10% российской электронной коммерции работает через этот шлюз: исторически он предлагает хорошие условия, берёт (точнее уже, брал) вполне адекватный процент и более-менее нормально интегрируется.

И пока не пришёл ЦБ и не раздал всем люлей, ничего не предвещало беды. Собственно, даже когда пришёл, речь шла про запрет переводов между кошельками и запрет пополнения кошельков на полгода. Это случилось 6 декабря, запрет вступил в силу с 7 декабря. До этого ЦБ запрещал QIWI платить иностранным интернет-магазинам, ЮMoney получила такое же предписание, но обе системы живы. Потом ЦБ отозвал лицензии у нескольких финансовых организаций за расчёты с онлайн-казино. Казалось, что это нас никак не должно коснуться.

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

11 февраля 2022 расчётный банк Вебмани (АО ККБ) внезапно перестал быть банком. ЦБ отозвал его лицензию.

В качестве причин Центробанк указал, что ККБ допускал нарушения законов в сфере противодействия отмыванию доходов, полученных незаконным путём, и финансированию терроризма. Кроме того, говорится в сообщении, банк нарушал регулирующие банковскую деятельность федеральные законы и нормативные акты Центробанка, из-за чего за последний год регулятор не раз применял меры, в частности — вводил ограничения на осуществление отдельных операций. Регулятор счёл, что ККБ на деле не осуществлял «традиционную банковскую деятельность», занимаясь услугами по электронной коммерции и не изучая непрозрачные источники денежных средств клиентов вместе с экономическим смыслом их операций.

В результате этого, как я говорил, примерно 10% российского E-COM остались без платёжного шлюза. И это по скромным подсчётам.

В 8 утра шлюз упал, час мы не принимали платежи, около 9 утра мы перешли на новый шлюз по картам, а в 9:30 по всем остальным способам оплаты тоже. В итоге потеряли 1 день платежей, но это, наверное, самая небольшая цена, которую мы могли заплатить. Я знаю, что у других хостеров были проблемы серьёзнее, но там хотя бы у каждого есть отдел разработки, способный быстро интегрировать. А вот у большого количества небольших компаний по стране такого удовольствия нет, и это для них может стать проблемой на месяцы.

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

▍ P.S

Знаю, у вас может быть много вопросов по текущей ситуации с e-commerce, железом и рынком хостинга в частности. Да и у нас за последний месяц историй набралось на целый пост, но его мы напишем чуть позже, когда выдохнем.

Автор: Никита Цаплин

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js