Comments 55
This publication could cause conflicting feelings. Be critical of any posted information. Remember the Community Guidelines before posting your comment.
How to write and what to do?
- Don`t write offensive comments or get personal.
- Refrain from obscene language and toxic behavior, even in a veiled form.
- o report comments that violate the rules of the site, click the "Complain" button or fill out the feedback form.
What to do if: karma goes down, the account is blocked.
Действительно. В современном мире кажется невозможно быть абсолютно неуязвимыми, особенно когда у вас достаточно большая система. Куча компонентов, куча сторонних библиотек разных версий, куча людей работает в конце-то концов. И уязвимость может подкрасться откуда угодно, векторов атаки слишком много.
Поэтому респект и уважение тем, кто честно и по человечески говорит, что "да, взломали, разберемся, починим, будем на связи". Сразу больше симпатии появляется к таким компаниям в конце концов все там будем.
То что сообщили и признали - респект. В списке возможных причин почему-то не хватает банальных:
простые пароли
забытая монга (или что у вас там) голой задницей в сеть.
случайный disclose секрета для доступа к (whatever)
Первые две часто объединяют в "ошибка конфигурации", а второе в accidental disclose (как это по-русски? Случайное разглашение?)
И ещё, когда вы делаете утверждения в условиях тумана войны, надо быть точнее и менее резкими. Например, "Ещё раз: платёжные данные не утекли" правильно должно звучать как "мы не располагаем доказательствами или обоснованными предположениями об утечке платёжных данных".
Подписался на блог, чтобы послушать постмортем. Надеюсь, публичный и с подрбностями.
В каком-то смысле это всё тоже можно замести в категорию "неизвестный баг" (если сделано по недомыслию) или "сотрудник" (если умышленный бэкдор). Не буквально, конечно, но по сути отличия не сильно велики, имхо.
Коммит пароля в гит нельзя считать "багом", потому что нет того кода, в котором баг.
И монга голой задницей или слабый пароль на почему-то публично доступном инстансе БД (бэкапа?) - это тоже не "баг".
Давайте назовём это не багом, а технической недоработкой ¯\_(ツ)_/¯
Совершенно нормально классифицировать это как ошибки конфигурации.
И это запросто может быть не "в продакшене", а в стейджинге, например. Одна ошибка - и база вылита не туда при recovery. Повторная recovery восстановила "туда", а потереть с стейжинга забыли. Через N времени стейджинг поломали (и всем почти пофигу), а там продакшен-база. оп.
Давайте это назовем тем, чем это является - рукожопостью админов? :)
Это не bug, да. Это issue.Или, если больше нравится, defect. Конфигурирования. Не всё ограничивается кодом и проблемами в нём.
Я о том, что общая суть реакции здесь близкая к описанным случаям: "найти и исправить проблему в компьютерной системе" и/или "найти и привлечь к ответственности сотрудника-вредителя". Возможно, конечно, что-то упускаю.
А вот я думаю, в век конфигурации-как-кода такое стоит считать багом. Есть код — есть и баг ;) Есть даже коммит, в котором он был introduced.
Есть код, есть баг. При этом запощенный в plaintext в гите пароль не является ни кодом, ни багом.
security не может быть описано в виде функциональных требований, так что натягивать на секьюрити баги - это странно. Баг может иметь последствия в безопасности, но security issue запросто может быть не багом ни с какой точки зрения.
но security issue запросто может быть не багом ни с какой точки зрения.
формализуй - что такое баг. Баг ведь может быть и в конфигурации (если мы ее описываем как код). Так что не вижу смысла спорить - и баг требует внимания, и секурити ишью. И то может быть риском и привести к потерям, и то
Баг - жаргонное слово в программировании, обычно обозначающее ошибку в программе. (викисловарь)
Более глубокое: предполагая существование платоновской тотальной функции (идеального кода на идеальных данных), багом является отклонение результата выполнения реального кода от идеального.
Конфигурация читается программой и является её частью (константы вынесенные в отдельный файл и обрабатываемые в рантайме).
Однако, никакое из определений бага не будет считать багом закомиченный приватный ключ разработчика в гит, потому что этот файл не является ни конфигурацией, ни кодом; он не влияет ни в один момент времени на работу программы.
Грубо говоря, если рядом с платоновской тотальной программой положить приватный ключ от сервера, где эта программа запущена, то программа останется платоновской (и бага в ней нет по определению), а security issue есть.
Если гит в этом месте вызывает смущение - пусть это будет стикер на крышке ноутбука с паролем, написанный от руки. Бага тут нет (нет машинного кода и вообще нет байтов), а security issue всё равно есть.
Если гит в этом месте вызывает смущение - пусть это будет стикер на крышке ноутбука с паролем, написанный от руки. Бага тут нет (нет машинного кода и вообще нет байтов), а security issue всё равно есть.
это не секурити ишью в цифровом плане. Даже если б он был записан в блокноте внутри компа в виде файла. Это д********м. Типа является ли секурити ишью кража ключа RSA? Ну, такое. А вот - то что пароль в принципе можно подобрать - очень даже баг.
Хотя ладно, смысла спорить, повторюсь, не вижу, спасибо.
правильно должно звучать как "мы не располагаем
Нет, не правильно). Сертификация PCI DSS (Payment Card Industry Data Security Standard) как раз и нужна для того, чтобы в случае инцидента была возможность отвечать на такой вопрос с крайне высокой степенью достоверности, а не как вы предлагаете.
В сфере персональных данных (PII) я не видел чего-то подбного - только нормативные документы. Поэтому здесь все может быть сложно.
Вообще говоря, никакой PCI DSS вам не поможет, если у вас lateral movement на технологии, которую вы не видите (хотя думаете, что видите всё). Недавняя малваря с патчем pcap-фильтра для скрытия своего трафика - отличный пример.
Это вопрос вероятностей. Если из сертифицированной системы можно незаметно слить данные, то данный факт сам по себе уже тянет на настоящую сенсацию (встав на одну ступеньку с известными ограблениями банков).
Зависит от объёма, но в целом, если она не air-gapped, то существует много интересных побочных техник слива. Начиная с банального SSL с доверенным доменом (если у вас разрешён трафик до GH или условного hub'а, откуда вы знаете, это слив или апдейт качали?) и заканчивая редкостной стеганографией, типа влияния на счётчики скачивания с публичных сайтов. (вполне себе бит информации).
Мне нравится ход ваших мыслей. Но если говорить конкретно про данные, подпадающие под PCI DSS, то идея со счётчиками кажется не сильно правдоподобной. Если только крякеры не получили в свое распоряжение бекдор для доступа к самому счётчику или оборудованию, что уже тянет на теории заговора совсем другого порядка.
Почему? Берёте редкие объекты, и каждый из них - бит информации. Вероятность просмотра видео с 15 просмотрами за 3 года на ютубе стремится к нулю. Если там случилось +3 просмотра, то это уже вполне себе бит информации. То же касается редких пакетов на pipy, crates, npm и т.д.
Плюс коррекция ошибок. Я, конечно, утрирую, и проще через публичный же сайт заслать в условные комменты, но если сервер не air-gapped, то я не верю в возможность определить что именно спёрли с сервера (и с какого из). Обнаружить потом малварю или следы движений - да. А процесс тырения - нет. Потому что если это неавторизованный доступ, то первым делом смотрят куда сервер раньше ходил, потом отключают аудит и любую другую паранойю, и спокойно сливают по тем же маршрутам. Весь трафик давно шифрованный, так что понять слив нескольких сотен мегабайт почти невозможно.
В волшебном мире security-фей там полный закрытый периметр с побайтовым просеиванием проходящего, но IRL там будет херачить k8s/доркер, качающий гигазы с хабов, аптовые/rpm'ные апдейты, телеметрия с ping back библиотек, бегающий "налево" certbot за апдейтом, и ещё чёрт в ступе, а ещё миллионы exec'ов от условного ансибла.
В волшебном мире security-фей там полный закрытый периметр с побайтовым просеиванием проходящего, но IRL там будет херачить k8s/доркер, качающий гигазы с хабов, аптовые/rpm'ные апдейты, телеметрия с ping back библиотек, бегающий "налево" certbot за апдейтом, и ещё чёрт в ступе, а ещё миллионы exec'ов от условного ансибла.
ни черта. В нормальном мире делается так, что там кубер-докер, со своим внутренним докерхабом без возможности скачать всякую дичь снаружи, апт/rpm - тоже зеркалим к себе (это не спасает от дичи на 100%, но мы получаем внятные контроли) и все такое. cert-bot - да, ну, строим свой внутренний УЦ, а внешним клиентам отдаем периметр, в DMZ... со своими правилами работы, все логично и красиво, и даже не дохнет на куче трафика
И это работает, если у вас не было существенного lateral movement. Потому что, вопрос, что случится в тот момент, когда у вас будет малварь на хосте с кубом и на хосте с (условным) aptly? Правильно, они себе обеспечат транспорт.
И чем больше у вас всяких репликаторов, кеширующих серверов для pipy, мирроров и т.д., тем больше у вас периметр для атаки на "интернет-able" сервера.
Понятно, что если речь про одиночный инцидент это всё хорошо работает. Но если люди хотят утырить что-то, то они, очевидно, ищут пути.
Я не говорю, что так делать не надо (надо!), но утверждение, что мол, если PCI DSS L1 - то можно с уверенностью утверждать о том, утекли платёжные данные или нет, мягко говоря, не правда.
Мы сертифицированы по PCI DSS Level 1 и мы уверены в том, что все наши программы останавливаются после конечного числа шагов.
Я не говорю, что так делать не надо (надо!), но утверждение, что мол, если PCI DSS L1 - то можно с уверенностьюутверждать о том, утекли платёжные данные или нет, мягко говоря, не правда.
Я, кстати, не говорил, что если pci dss, то карточные данные нельзя утащить…
Можно, но это сделать сильно сложнее, чем если бы инфраструктура и процессы не были сертифицированы
Начиная с банального SSL с доверенным доменом (если у вас разрешён трафик до GH или условного hub'а, откуда вы знаете, это слив или апдейт качали?)
для этого на выход трафика делают прокси с полным логированием всех доступов (ну, ок, может только url записывают, без пейлоадов), а в мире k8s security - пишут фильтры на L7 (типа GET запросы разрешаем, хотя и через них пропихнуть можно данные, а POST, а тем более PATCH/UPDATE и прочие ни-ни - при чем с грануляцией по эндпойнтам)
Во-первых прокси - ещё более вкусная цель, чем одинокая нода куба.
Во-вторых, вы не можете в общем случае заставить весь софт снять с себя SSL. Если кто-то хочет SSL и имеет пиненый сертификат, то софт надо пересобирать, и это если сырцы доступны и программисты понимают где и что.
Вообще, на самом деле, спор сводится к тому, обладает ли команда знанием о софте, который запущен. Моё наблюдение говорит, что с каждым годом - всё меньшим и меньшим. Потому что строк кода всё больше, а человеков - меньше. Знание высокоуровневое и функциональное (мы знаем зачем оно в целом) и совершенно неличное, потому что рядом с "простыми библиотеками" оказываются массивные фреймворки, от которых, быть может, используется 3% возможностей (оставляя 97% в тени).
Во-первых прокси - ещё более вкусная цель, чем одинокая нода куба.
Логично. Но что проще защитить - 100500 узлов кубера или один единственный прокси? И что будет дешевле защищать?
В конце-концов речь ведь не только про предотвращение проблем, но и сделать так, чтобы мы их могли в принципе увидеть.
Во-вторых, вы не можете в общем случае заставить весь софт снять с себя SSL. Если кто-то хочет SSL и имеет пиненый сертификат, то софт надо пересобирать, и это если сырцы доступны и программисты понимают где и что.
Несомненно. Но никто не мешает и этот софт ограничивать. Или стараться пользоваться более понятным софтом с исходниками. Ещё вариант - для каждого такого «закрытого» софта со своим ссл и пиннингом сертификатов делать отдельную песочницу с четко означенным точками интеграциями с другими кусками инфраструктуры. Это, если делать хорошо. Если делать как обычно - в инфре зоопарк и «каждый может ходить куда угодно». Секурити группы в облаке? Не, не слышал
Ну, давайте простой пример. Кто вообще настраивает acl на ssh? Чтобы закрыть возможность ходить с сервера по ключу на другой сервер? А вообще делается легко - вряд ли человеки будут проксиджампиться через продовые сервера, у них выделенный бастион должен быть (отказоустойчивый), либо какие-то пам штуки с привольными возможностями вроде входа по токенам, а не паролям.
Видимо, узлы куба без выхода в интернеты защитить проще, чем прокси, которая в оном интернете голой задницей.
В прочной системе у вас не одна прокся, а кластер из проксей в каждом регионе, что выводит их в новую категорию по сложности. Кроме того, где они деплоятся? Ну, олдфаговый админ поднимет сервер. А новый - швырнёт в тот же куб, только с выходами в интернеты, то есть проблема всё равно вернётся к нодам куба, только кубов теперь больше.
Мы как именно сравниваем? Почему мы сравниваем "узлы куба без выхода в интернеты" и "прокси"? Когда очевидно, что узлы кубера с выходом в интернет - это просто черная бездонная дыра.
Лучше рилли прокси + узлы кубера отдельно
А новый - швырнёт в тот же куб, только с выходами в интернеты, то есть проблема всё равно вернётся к нодам куба, только кубов теперь больше.
когда это количество кубов было проблемой? Два кубера - один в DMZ, второй - во внутреннем периметре - очевидно УДОБНЕЕ для обслуживания и БЕЗОПАСНЕЕ, чем один кубер, распределенный по двум сегментам (еще и лови проблемы странные из-за этой сегментации). Админы как-то раньше с 1000-5000 ВМ справлялись, что - с 5-10 куберами не справятся?
А теперь вопрос: если это кубы одной версии и там zero day с RCE+LPE, то насколько два куба в DMZ устойчивее, чем один куб? Ну... как один человек на ютубе говорит "little movement on three, four is binding, and we have it opened".
"мы не располагаем доказательствами или обоснованными предположениями об утечке платёжных данных" - это для разговора профессионалов. Для широкрй общественности нужно проще выражаться, а то журналисты поймут все с точностью до наоборот.
Вы совершенно правы. И где мы находимся? Явно не в месте для "широкой общественности". Так что получить за чрезмерно оптимистичные заявления от профи - вполне заслуженно.
Позвольте не согласиться. Всё же хабр находится в интернетах, куда нынче вхож журналист. Если этот критерий недостаточен для "широкой общественности" — то полагаю, что ныне почившие Мегамозг и Гиктаймс таковыми являются. Если и они не — то, емнип, РФ считает Хабр СМИ. Даже включали в какой-то реестр социально значимых ресурсов, к которым положен доступ и без оплаченного интернета (интересно, что там нынче с этой инициативой...). Если и это не убеждает — что ж, я более бессилен. :D
Спасибо!
Естественно, простые пароли, забытую монгу, disclose секрета мы рассмотрели первыми. Плюс это части основных гипотез тоже. Простите, что я медленно отвечаю, сейчас немного не до того.
Результат: нас признали виновными в совершении административного правонарушения, штраф 60 тысяч рублей, решение вступило в силу. Что было: скомпрометировали одно из устройств сотрудников.
Сегодня в обед украинские хакерские телеграм-каналы сообщили, что осуществлён взлом в качестве «ответки за Новую Почту».
Я правильно понял ситуацию: "За то, что Петя побил Васю, мы побили Станислава"?
Сейчас так - кто до кого дотянулся, того и похакал... У меня личный веб-сервер висит дома, посмотрел сегодня логи - интенсивность попыток поломать с февраля раза в три больше стала, боты сканят уязвимости GPON-терминалов, роутеров, различных фреймворков...
Вот такие строчки по несколько сотен в час :( С голландских, китайских, немецких IP адресов...
85.202.169.228 - - [02/Jul/2022:18:12:36 +0300] "POST /GponForm/diag_Form?style/ HTTP/1.1" 404 153 "-" "curl/7.3.2"
185.7.214.104 - - [02/Jul/2022:07:57:37 +0300] "GET /_ignition/execute-solution HTTP/1.1" 301 169 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
Интересно, а есть смысл писать хостеру? Посмотрел, заметная доля с адресов хостера serverion.com идет, написал на abuse - пока тишина (да, наивный чукотский парень).
PS: У меня там чистая статика, ломать кроме сервера и nginx нечего ;)
А можете работать вообще без персональных данных, например, выдали qr-код тому, кто оплатил билет, и по нему сажают в автобус? Как билет на метро, примерно.
Что этому препятствует?
При перевозке железнодорожным, морским, внутренним водным и автомобильным транспортом перевозчик обязан формировать автоматизированные базы данных пассажиров, которые в соответствии с частью 5 статьи 11 Федерального закона от 9 февраля 2007 г. N 16-ФЗ "О транспортной безопасности" включают:
фамилию, имя, отчество пассажира;
дату и место его рождения;
вид и номер документа, удостоверяющего личность, по которому приобретается проездной документ (билет);
пункт отправления, пункт назначения, вид маршрута следования (беспересадочный, транзитный);
дата поездки.
Dura lex, sed lex.
Погодите, перевозчик, а не продавец билетов же?
Не отсебятина, а прикрытие зада руководителем. Завтра контролирующие органы могут предъявить: "А предоставьте записи о поездках, которые были 4 месяца назад. Как не можете? Это прямое нарушение ФЗ-..." И далее будут ачивки в вышестоящие, с разборками, которые по стоимости могут выйти сильно дороже текущего решения "на всякий случай храним год".
В общем случае Ст. 5 152-ФЗ
7. Хранение персональных данных должно осуществляться в форме, позволяющей определить субъекта персональных данных, не дольше, чем этого требуют цели обработки персональных данных, если срок хранения персональных данных не установлен федеральным законом, договором, стороной которого, выгодоприобретателем или поручителем по которому является субъект персональных данных. Обрабатываемые персональные данные подлежат уничтожению либо обезличиванию по достижении целей обработки или в случае утраты необходимости в достижении этих целей, если иное не предусмотрено федеральным законом.
Закон о транспортной безопасности не накладывает дополнительных условий, поэтому предположу, что максимальный обоснованный срок хранения может быть 3 года с момента окончания исполнения обязательств перевозчиком (исковая давность, на случай, если пассажир предъявит претензии), а минимальный, который я нашел - 1 месяц с окончания.
Нас взломали: часть данных билетов автобусов