Midltown
Пользователи-
Публикаций
3 -
Зарегистрирован
-
Посещение
Репутация
0 NeutralИнформация о Midltown
-
Звание
Пользователь
Посетители профиля
Блок последних пользователей отключён и не показывается другим пользователям.
-
Предбиллинг. Разбираемся, как мобильные операторы хранят и обрабатывают наши данные
Midltown опубликовал тема в Анонимность и безопасность
Платная статья с хакера Содержание статьи Зачем предбиллинг телеком-операторам? Как усмирить зоопарк? Что в черном ящике? Приватность Мобильные операторы получают массу данных и метаданных, по которым можно узнать очень многое о жизни отдельно взятого абонента. А поняв, как обрабатываются и как хранятся эти данные, ты сможешь отследить всю цепочку прохождения информации от звонка до списания денег. Если же говорить о модели внутреннего нарушителя, то здесь возможности и подавно огромные, ведь защита данных вообще не входит в задачи систем предбиллинга. Для начала нужно учитывать, что абонентский трафик в сети телеком-оператора генерируется и поступает с разного оборудования. Это оборудование может формировать файлы с записями (файлы CDR, логи RADIUS, текст в ASCII) и работать по разным протоколам (NetFlow, SNMP, SOAP). И нужно контролировать весь этот веселый и недружный хоровод, снимать данные, обрабатывать и передавать дальше в биллинговую систему в формате, который будет предварительно стандартизован. При этом везде бегают абонентские данные, доступ к которым желательно не предоставлять посторонним. Насколько защищена информация в такой системе с учетом всех цепочек? Давай разбираться. Зачем предбиллинг телеком-операторам? Считается, что абоненты хотят получать все более новые и современные виды услуг, но нельзя постоянно менять для этого оборудование. Поэтому реализацией новых услуг и способами их предоставления должен заниматься предбиллинг — это его первая задача. Вторая — анализ трафика, проверка его корректности, полноты загрузки в абонентский биллинг, подготовка данных для биллинга. С помощью предбиллинга реализованы различные сверки и дозагрузки данных. Например, сверка состояния услуг на оборудовании и в биллинге. Бывает, абонент пользуется услугами при том, что в биллинге он уже заблокирован. Либо он пользовался услугами, но с оборудования не поступили записи об этом. Ситуаций может быть множество, большинство таких моментов и решается с помощью предбиллинга. Когда-то я писал курсовую работу по оптимизации бизнес-процессов компании и расчету ROI. Проблема с расчетом ROI была не в том, что не было исходных данных, — я не понимал, какой «линейкой» их мерить. Примерно так же часто бывает с предбиллингом. Можно бесконечно настраивать и улучшать обработку, но всегда в какой-то момент обстоятельства и данные сложатся так, что произойдет исключение. Можно идеально выстроить систему работы и мониторинга вспомогательных систем биллинга и предбиллинга, но невозможно обеспечить бесперебойную работу оборудования и каналов передачи данных. Поэтому и существует дублирующая система, которая занимается проверкой данных в биллинге и данных, ушедших от предбиллинга в биллинг. Ее задача — поймать то, что ушло с оборудования, но по какой-то причине «не легло на абонента». Эту роль дублирующей и контролирующей предбиллинг системы обычно играет FMS — Fraud Management System. Конечно, ее основное предназначение — вовсе не контроль предбиллинга, а выявление мошеннических схем и, как следствие, мониторинг потерь и расхождений данных с оборудования и биллинговых данных. На самом деле вариантов использования предбиллинга очень много. Например, это может быть выполнение сверки между состоянием абонента на оборудовании и в CRM. Такая схема может выглядеть следующим образом. С помощью предбиллинга по SOAP получаем данные с оборудования (HSS, VLR, HLR, AUC, EIR). Преобразуем исходные RAW-данные в нужный формат. Делаем запрос в смежные системы CRM (базы данных, программные интерфейсы). Производим сверку данных. Формируем записи-исключения. Делаем запрос в систему CRM на синхронизацию данных. Итог — абонент, качающий фильм в роуминге в ЮАР, блокируется с нулевым балансом и не уходит в дикий минус. Еще один пример использования — накопление данных и дальнейшая их обработка. Такой вариант возможен, когда у нас тысячи записей с оборудования (GGSN-SGSN, телефония): выбрасывать все эти записи в детализацию абонента — полнейшее безумие, не говоря уже о том, что мы адски нагружаем все системы таким количеством мелких данных. По этой причине подойдет следующая схема, которая разрешает проблему. Получение данных с оборудования. Агрегация данных на предбиллинге (ждем, когда соберутся все нужные записи по какому-либо условию). Отправка данных в конечный биллинг. Итог — вместо 10 тысяч записей мы отправили одну с агрегирующим значением счетчика потребленного интернет-трафика. Сделали всего один запрос к базе данных и сэкономили кучу ресурсов, включая электричество! Это всего лишь типовые схемы работы. Формат статьи не позволяет привести примеры более сложных схем (например, Big Data), но они тоже встречаются. Как усмирить зоопарк? Чтобы было понятнее, как это работает и где здесь могут возникнуть проблемы, давай возьмем систему предбиллинга Hewlett-Packard Internet Usage Manager (HP IUM, в обновленном варианте eIUM) и на ее примере посмотрим, как работает подобный софт. Представь большую мясорубку, в которую бросают мясо, овощи, буханки хлеба — все, что только можно. То есть на входе самые разные продукты, но на выходе все они приобретают одинаковую форму. Мы можем поменять решетку и получим на выходе другую форму, но принцип и путь обработки наших продуктов останется прежний — шнек, нож, решетка. Это и есть классическая схема предбиллинга: сбор, обработка и вывод данных. В предбиллинге IUM звенья этой цепочки называются encapsulator, aggregator и datastore. Тут необходимо понимать, что на входе у нас должна присутствовать полнота данных — некий минимальный объем информации, без которого дальнейшая обработка бесполезна. При отсутствии какого-то блока или элемента данных мы получаем ошибку или предупреждение, что обработка невозможна, так как операции не могут быть выполнены без этих данных. Поэтому очень важно, чтобы оборудование формировало файлы-записи, которые имели бы строго определенный и установленный производителем набор и тип данных. Каждый тип оборудования — отдельный обработчик (коллектор), который работает только со своим форматом входных данных. Например, нельзя просто так взять и закинуть файл с оборудования CISCO PGW-SGW с интернет-трафиком мобильных абонентов на коллектор, который обрабатывает поток с оборудования фиксированной связи Iskratel Si3000. Если мы так сделаем, то в лучшем случае получим исключение при обработке, а в худшем у нас встанет вся обработка конкретного потока, так как обработчик-коллектор упадет с ошибкой и будет ждать, пока мы не решим проблему с «битым» с его точки зрения файлом. Здесь можно заметить, что все системы предбиллинга, как правило, критично воспринимают данные, на обработку которых не был настроен конкретный обработчик-коллектор. Изначально поток разобранных данных (RAW) формируется на уровне энкапсулятора и уже здесь же может быть подвергнут преобразованиям и фильтрации. Так делается, если нужно до схемы агрегации произвести с потоком изменения, которые должны быть в дальнейшем применены ко всему потоку данных (когда он будет проходить через различные схемы агрегации). Файлы (.cdr, .log и прочие) с записями об активности пользователей-абонентов поступают как с локальных источников, так и с удаленных (FTP, SFTP), возможны варианты работы и по другим протоколам. Разбирает файлы парсер, с помощью разных классов Java. Так как система предбиллинга в нормальном режиме работы не предназначена для хранения истории обрабатываемых файлов (а их может быть сотни тысяч в сутки), то после обработки файл на источнике удаляется. По разным причинам файл не всегда может быть удален корректно. В результате бывает, что записи из файла обрабатываются повторно или с большим опозданием (когда удалить файл получилось). Для предотвращения таких дублей существуют механизмы защиты: проверка на дубли файлов или записей, проверка на время в записях и прочее. Одно из самых уязвимых мест здесь — это критичность к размеру данных. Чем больше мы храним данных (в памяти, в базах данных), тем медленнее мы обрабатываем новые данные, тем больше мы потребляем ресурсов и в итоге все равно достигаем предела, после которого вынуждены удалить старые данные. Таким образом, для хранения этих метаданных обычно используются вспомогательные БД (MySQL, TimesTen, Oracle и так далее). Соответственно, получаем еще одну систему, которая влияет на работу предбиллинга с вытекающими вопросами безопасности. Что в черном ящике? Когда-то на заре подобных систем использовались языки, которые позволяли эффективно работать с регулярными выражениями, — таким, например, был Perl. Фактически почти весь предбиллинг, если не брать во внимание работу с внешними системами, — это правила разбора-преобразования строк. Естественно, лучше регулярных выражений тут ничего не найти. Постоянно растущий объем данных и повышение критичности к времени вывода новой услуги на рынок сделали применение таких систем невозможным, так как тестирование и внесение изменений занимало много времени, масштабируемость была низкой. Современный предбиллинг — это набор модулей, как правило написанных на Java, которыми можно управлять в графическом интерфейсе с помощью стандартных операций копирования, вставки, перемещения, перетаскивания. Работа в этом интерфейсе проста и понятна. Для работы в основном используется операционная система на базе Linux или Unix, реже — Windows. Основные проблемы обычно связаны с процессом тестирования или выявления ошибок, так как данные проходят по множеству цепочек правил и обогащаются данными из других систем. Видеть, что происходит с ними на каждой стадии, не всегда удобно и понятно. Поэтому приходится искать причину, отлавливая изменения нужных переменных при помощи логов. Слабость этой системы — ее сложность и человеческий фактор. Любое исключение провоцирует потерю данных или неправильное их формирование. Обрабатываются данные последовательно. Если на входе у нас ошибка-исключение, которая не позволяет корректно принять и обработать данные, встает весь входной поток либо порция некорректных данных отбрасывается. Разобранный RAW-поток поступает на следующую стадию — агрегацию. Схем агрегации может быть несколько, и они изолированы друг от друга. Как если единый поток воды, поступающий в душ, пройдя через решетку лейки, разделится на разные потоки — одни толстые, другие совсем тонкие. После агрегации данные готовы к доставке потребителю. Доставка может идти как напрямую в базы данных, так и записью в файл и отправкой его дальше либо просто записью в хранилище предбиллинга, где они будут лежать, пока его не опустошат. После обработки на первом уровне данные могут передаваться на второй и далее. Такая лестница необходима для увеличения скорости обработки и распределения нагрузки. На второй стадии к нашему потоку данных может добавляться другой поток, смешиваться, делиться, копироваться, объединяться и так далее. Конечная стадия — это всегда доставка данных в системы, которые его потребляют. В задачи предбиллинга не входит (и это правильно!): мониторить, поступили и доставлены ли входные-выходные данные, — этим должны заниматься отдельные системы; шифровать данные на любой стадии. Далеко не весь поток поступающих данных подвергается обработке. Обрабатываются только те данные, которые нужны для работы. Тратить время на остальные нет смысла до того момента, пока они не понадобятся. Таким образом, из RAW-потока нужно брать только то, что нужно для схем агрегации. Из RAW (текстовые файлы, результаты запросов, бинарные файлы) парсится только необходимое. Приватность Здесь у нас полный расколбас! Начнем с того, что в задачи предбиллинга не входит защита данных в принципе. Разграничение доступа к предбиллингу нужно и возможно на разных уровнях (интерфейс управления, операционная система), но если мы заставим его заниматься шифрованием данных, то сложность и время обработки настолько увеличатся, что это будет совершенно неприемлемо и непригодно для работы биллинга. Зачастую время от использования услуги до отображения этого факта в биллинге не должно превышать нескольких минут. Как правило, метаданные, которые нужны для обработки конкретной порции данных, хранятся в БД (MySQL, Oracle, Solid). Входные и выходные данные практически всегда лежат в директории конкретного потока-коллектора. Поэтому доступ к ним может иметь любой, кому он разрешен (например, root-пользователь). Сама конфигурация предбиллинга с набором правил, сведениях о доступах к базам данных, FTP и прочему хранится в зашифрованном виде в файловой базе данных. Если неизвестен логин-пароль для доступа в предбиллинг, то выгрузить конфигурацию не так просто. Любое внесение изменений в логику обработки (правила) фиксируется в лог-файл конфигурации предбиллинга (кто, когда и что менял). Даже если внутри предбиллинга данные передаются по цепочкам обработчиков-коллекторов напрямую (минуя выгрузку в файл), данные все равно временно хранятся в виде файла в директории обработчика, и при желании к нему можно получить доступ. Данные, которые проходят обработку на предбиллинге, обезличены: они не содержат ФИО, адресов и паспортных данных. Поэтому даже если ты получишь доступ к этой информации, то персональных данных абонента отсюда не узнать. Зато можно поймать какую-то инфу по конкретному номеру, IP либо другому идентификатору. Имея доступ к конфигурации предбиллинга, ты получаешь данные для доступа ко всем смежным системам, с которыми он работает. Как правило, доступ к ним ограничен непосредственно с сервера, на котором работает предбиллинг, но так бывает не всегда. Если ты доберешься до директорий, где хранятся файловые данные обработчиков, то сможешь вносить изменения в эти файлы, которые ждут своей отправки потребителям. Часто это самые обычные текстовые документы. Тогда картина такая: предбиллинг данные принял и обработал, но в конечную систему они не пришли — пропали в «черной дыре». И выяснить причину этих потерь будет сложно, так как потеряна только часть данных. В любом случае эмулировать потерю будет невозможно при дальнейшем поиске причин. Можно посмотреть данные на входе и выходе, но понять, куда они делись, не получится. Злоумышленнику при этом остается только замести следы в операционной системе. -
Фиксим утечку трафика при разрыве связи с VPN
Midltown опубликовал тема в Анонимность и безопасность
Сегодня расскажу, как не спалить свой IP-адрес, если вдруг упал VPN. Я думаю ты догадываешься, чем это опасно. Ведь если это не предотвратить, то при падении vpn твой трафик начинает идти через твоего провайдера и ты палишь свой реальный IP. Если ты занимаешься чем-нибудь незаконным это очень плохо. От падения сервера vpn никто не застрахован, поэтому лучше позаботиться об этом заранее. Есть отдельные приложения, специально под эту тему, но лучше им не доверять. Такие проги находятся на всяких форумах, поэтому большие шансы того, что к прогам идет какое-то нехорошее дополнение. Поэтому я в этом вопросе использую настройку firewall. Покажу, как сделать это с использованием фаервола CОMОDО и ОpenVPN клиента. Также можно использовать другой фаервол, если каким-нибудь уже пользуетесь, настройка для него будет похожей. Для начала нам нужно узнать MАС адрес адаптера, который создан ОpenVPN клиентом. Для в консоли пишем ipcоnfig /all и ищем нужный нам адаптер. Обычно он называется TАP-Windоws Аdapter V9. Копируем его мак адрес. 1) открываем настройки CОMОDО Firewall, там создаем новую сетевую зону. Называем ее как-нибудь, например VPN. В этой сетевой зоне создаем новый адрес, тип MАC-адрес. Вводим MАC нашего ОpenVPN адаптера, который мы заранее нашли; 2) переходим в закладку "Набор правил" и там "создать новый набор из 3 правил": 3) выбираем приложения, для которых мы хотим применить этот набор правил. Это браузер, джаббер и т.п. приложения. В зависимости от того, чем пользуетесь. Вот и всё. Теперь если впн упал, то трафик не будет идти и мы не спалим свой реальный апишник. Это правило будет работать для любого конфига ОpenVPN, можно спокойно менять адреса впн и другие данные. В общем всем советую сделать. Быстро и просто) -
Как безопасно купить крипту и как хакеры могут её увести?
Midltown опубликовал тема в Анонимность и безопасность
Как хакеры могут украсть вашу криптовалюту и как этого избежать, как безопасно купить криптовлюту. На эти и многие другие вопросы ответил Алексей Маланов, антивирусный эксперт «Лаборатории Касперского». - Какие главные проблемы безопасности криптовалюты в 2018 году? - Те же, что и в прошлые годы. Пользователь может скомпрометировать свой криптокошелек или аккаунт на стороннем сервисе. Сам сторонний сервис (биржа, веб-кошелек и т.п.) может быть атакован и может потерять средства пользователей. В реализации криптовалюты могут вскрыться особенности, приводящие к потере средств или к обесцениванию валюты. - Как безопасно купить криптовалюту? - Здесь мы, со своей стороны, можем посоветовать придерживаться простых правил безопасности. Прежде всего, стоит скептически отнестись ко всем крайне заманчивым предложениям в сети. Ведь злоумышленники не дремлют. Только во втором квартале наша система «Антифишинг» 58 000 раз предотвратила попытки пользователей перейти на фишинговые сайты, имитирующие популярные криптовалютные кошельки и биржи. - Какие опасности могут подстерегать обладателя любой криптовалюты? - Воровство кошелька вредоносным кодом. Фишинговые сайты и компрометация логина-пароля для доступа к криптовалютным сервисам. Неудачные инвестиции в мошеннический или переоцененный проект. В частности, один из «любимых» сегодня приемов у злоумышленников — «бесплатные» раздачи криптомонет. Мошенники эксплуатируют имена новых, популярных ICO-проектов для сбора средств потенциальных инвесторов. Созданные ими фишинговые сайты порой появляются даже раньше, чем официальные сайты проектов. На этом фоне на данный момент самой популярной у мошенников криптовалютой, например, является Ethereum (ETH). По нашим довольно приблизительным подсчетам, за второй квартал этого года злоумышленникам, использующим тему ICO, удалось получить $2 329 317 (по курсу на конец июля 2018 г). - Как хакеры могут украсть вашу криптовалюту? Как можно этого избежать? - Право распоряжаться криптовалютой дает секретный ключ, который находится в файле-кошельке. Если ваш секретный ключ знает кто-то, кроме вас, то деньги уже не ваши, а общие. Злоумышленник может перевести их на свой кошелек. Если средства хранятся на бирже, то хакеры могут украсть деньги у биржи. Так, например, недавно мы обнаружили вредоносную операцию известной группировки Lazarus - атака получила название AppleJeus, и её целью стала криптовалютная биржа в Азии. При этом примечательно, что атакующие использовали две версии зловреда: для Windows и для macOS. В первую очередь владельцу криптовалюты необходима качественная антивирусная защита (на компьютере и на телефоне/планшете). Аппаратный криптокошелек дает дополнительную защиту, однако не является гарантией безопасности. Если говорить про сервисы, то нужно включить двухфакторную аутентификацию доступа к сервису. Мы также не рекомендуем держать средства на стороннем сервисе, чтобы его взлом не смог затронуть пользователя. - Как защититься от криптовалютного фишинга? - Пользоваться менеджером паролей. Такой менеджер сам убедится, что посещаемый адрес действительно тот самый (а не отличается, например, одной буквой), сам проверит, что сертификат сайта выдан этому сайту (нет никакого человека посередине), и только после этого подставит логин-пароль в поля ввода. При этом пароль будет сильным и уникальным, ведь его не нужно держать в голове. При регистрации на новых сервисах или при участии в ICO рекомендуем пользоваться качественным защитным решением с актуальными базами фишинговых сайтов в составе. - Как защитить свой криптокошелёк? - Об этом лучше позаботиться заранее. Мобильные ОС (iOS, Android) имеют архитектуру безопасности, сильно затрудняющую доступ одних приложений к данным других. Кроме того, у Apple строгие правила размещения приложений в AppStore, что сильно снижает риск установить вредоносное приложение. Либо использовать аппаратный кошелек – способы украсть секретный ключ с аппаратного кошелька (или обмануть хозяина) есть, но они довольно экзотичные, поэтому это наиболее надежный способ хранения криптовалюты на сегодняшний день. - О каких самых крупных кражах криптовалюты в истории вы знаете? - Смотря по курсу на какую дату считать. Если на момент кражи, то взлом японской биржи Coincheck и кража криптовалюты XEM на сумму более $500 млн остается крупнейшим. Но до 2014 года злоумышленники вывели порядка 650000 биткойнов с японской биржи Mt.Gox и по сегодняшнему курсу это, конечно, гораздо больше. Mt.Gox взломали в 2011, украли 80000 биткойнов (порядка $60000 по тому курсу), потом вновь - в 2014 и украли 850000 биткойнов ($473 млн). Однако позже 200000 нашлось. В 2015 взломали Bitstamp ($5 млн), потом LocalBitcoins, в 2016 - BitFinex (120000 биткойнов, $72 млн). В 2017 ломали Yapizon, Bithumb и Youbit (переименованная из Yapizon). Биржа майнинговых мощностей NiceHash была взломана в декабре 2017 на 4700 биткойнов ($64 млн). И наконец в 2018 Coincheck взломали на $530 млн в форме валюты XEM. - Насколько безопасна технология блокчейн? - Здесь есть несколько моментов: 1. Публичные блокчейны (криптовалюты) подвержены «Атаке 51%». В мае была осуществлена одна из самых крупных краж таким образом на сумму порядка $18 млн. Есть и другие потенциальные проблемы публичных блокчейнов, но они менее значимы. 2. Приватные блокчейны (не криптовалюты, их пытаются применять правительства и компании во всевозможных областях) в общем-то не дают каких-то уникальных преимуществ по сравнению с централизованными подходами. Новых специфичных рисков тоже не привносят – однако как и всегда, остается возможность несанкционированного доступа. 3. Отдельная тема – смарт-контракты. Это минипрограммы по управлению цифровыми активами. К сожалению, технология сравнительно молодая и еще достаточно сырая. В целом при принятии решения, использовать или не использовать блокчейн в вашем проекте, мы рекомендуем исходить из целей. Нужно иметь четкий ответ, почему именно блокчейн, а не централизованные традиционные технологии; какова модель угроз, и действительно ли блокчейн адресует эти угрозы. - Какие советы владельцам криптовалюты Вы бы дали? 1. Всегда проверяйте адрес веб-кошелька, не переходите по ссылкам, завлекающим в интернет-банк или в веб-кошелек. 2. Перепроверяйте перед отправкой адрес получателя (хотя бы первые и последние символы), отправляемую сумму и величину комиссии. 3. Запишите мнемоническую фразу, при помощи которой можно восстановить криптокошелек в случае, если вы его потеряете или забудете пароль. 4. При криптоинвестировании сохраняйте трезвую голову и принимайте взвешенные решения, не поддавайтесь панике, не спешите. 5. Не инвестируйте больше, чем вы готовы потерять. Диверсифицируйте свои инвестиции. 6. Используйте аппаратные кошельки криптовалют. 7. Используйте качественную антивирусную защиту.