Статья ULF/УЛЬФ - Унифицированый Формат Логов | Unified Log Format

[KijomBa]

Эх моя идейка(( Гребаная нехватка денег на реализацию((
Хочу сервис с автопокупкой, автообработкой логов. Внутри модульная система для добавления новых схем обработки, автооценка логов для продажи, софт для автоотработки крипты, ещё и с партнер програмой, сотней операторов стилаков, ЛК для ручной отработки, ЛК для траферов, внутренний магазин для траффа и не только.... Так что бы на сотне серверов, хайлоад все дела, бесконечный поток денежек.

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

 

[peacemaker]

Эх моя идейка(( Гребаная нехватка денег на реализацию((
Хочу сервис с автопокупкой, автообработкой логов. Внутри модульная система для добавления новых схем обработки, автооценка логов для продажи, софт для автоотработки крипты, ещё и с партнер програмой, сотней операторов стилаков, ЛК для ручной отработки, ЛК для траферов, внутренний магазин для траффа и не только.... Так что бы на сотне серверов, хайлоад все дела, бесконечный поток денежек.

Ну тогда зачем изобретать, вступай к нам в ряды, сделаем вместе, в команде веселее У нас opensources платформа!

 

[corax]

KijomBa
Забудь ты о json, будет супер-пупер круто если у всех стилеров хотя бы для Passwords.txt будет единый формат вида

URL: 
Username: 
Password: 
Application:
Username_element:
Password_element:
Submit_value:

Три последних нужны для нормального чекера, а 100500 скриптов одного и того же. Я пытался как-то сделать либу, которая бы искала нужную форму, задолбался и бросил. Ищешь input type="password", затем поднимаешься вверх в поиске инпута логина, у всех он, бл#ть, по-разному называется, хрен угадаешь. Так вот нужные инпуты хром хранит рядом с паролем.

Изобретать свой формат не надо, есть msgpack/protobuf.

Протокол принятия файла надо оставить за малварщиком, просто сделать для него прототип.

- Приняв данные от стилака, нам необходимо их поместить в БД либо на диск.
Тут необходимо решить какой формат позволит с минимальными затратами кода и ресурсов это реализовать.
Нам нужно спарсить поступающие данные, собрать статистику, и поместить на хранение.

Ничего на диск дропать не надо. Допустим мы принимаем лог по HTTP в архиве zip. У нас есть multipart-форма и имя файла перед получением непосредственно самого body. Задача проверить на уник и залить в бд.

Формат хранения в бд - я не вижу никаких проблем с SQL, где у тебя не TEXT/INTEGER, там https://www.postgresql.org/docs/current/datatype-binary.html
То есть Passwords.txt/Cookies.txt мы храним в таблице вида

CREATE TABLE Passwords (Id INTEGER, Url TEXT NOT NULL,Username VARCHAR(128) NOT NULL, Password ...)

, всякие wallet.dat и прочее храним в блобе связывая по ID.

Никакой статистики на этом этапе не производится, это задача решается на фронте.

3. Дальнейшая обработка сторонним софтом

Для этого нужен удобный поиск и экспорт части/всего лога каким он был залит в панель. Да можно и апи сделать в два хендлера:
/search/<query>
/export/<id>
Где твой софт стучить в твою же панель, получает архив и уже чёт там делает.

 

[marmalade]

Окей, тода возникает вопрос к самому формату, имеет ли смысл паковать всё в джейсон, если в дальнейшем мы будем заливать всё в Скьюл БД?
Для начала думаю над пройnись по всем шагам где униф формат может пригодиться:
1. Сбор с клиента - тут джейсон не лучшая идея, лишний оверхед по размеру, так же вопрос с самим Джейсон обработчиком.
Если брать Натив Вин32, там встроенных функций нет, придётся использовать готовые либы или писать самому.
Думаю есть смысл создать спецификацию для бинарного формата, позволяющюю используя минимальный инструментарий упаковывать всё средствами ВинАпи.(Опять так ине последняя инстанциия, лишь мои размышления, всё к обсужению)
2. На стороне панели, тут есть пара вопросов:
- Отправка упакованных данных со стороны клиента, прием и распарс в панеле.
Тк это малварь, этап отправки должен решаться самим разработчиком ибо тут и детекты и безопасность и др.
Что касается панели, прием, декрипт данных так же ,либо остается на плечах разрабов, либо можно реализовать модульным путём, разные алгоритмы, стенография и тд
- Приняв данные от стилака, нам необходимо их поместить в БД либо на диск.
Тут необходимо решить какой формат позволит с минимальными затратами кода и ресурсов это реализовать.
Нам нужно спарсить поступающие данные, собрать статистику, и поместить на хранение.
Соответственно формат должен предосnавлять определённую информацию о логе, и удобный вид данных для непосредственного помещения их в базу.
3. Дальнейшая обработка сторонним софтом
Тут два варианта пока:
- запрос БД по апи, и дальнейшая обработка
- и чтение лога с диска (опять таки нужен формат для хранения лога на диске)
В случае с джейсоном тут просто, тем же питоном открываеться файл и на ходу преобразуеться в Пайтон обьект с которым можно работать непосредственно, то же с другими языками. озможно есть смысл сделать спецификации для каждого случая, на диске храним в одном виде, в БД суём в другом, для ручной обработки третий вид.

Пока такие наброски, опять же прошу высказывать своё мнение и идеи. Открытый стандарт в одни руки не делается)
Тут надо всем форумом решать

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

 

[KijomBa]

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

Забудь ты о json, будет супер-пупер круто если у всех стилеров хотя бы для Passwords.txt будет единый формат вида

Если абстрагироваться от Джейсона, БД и тд.
Что мы имеем?
- Набор кей-валью значений (Айди, гео, дата и тд)
- Массив строковых значений (Пароли, куки)
- И в финале бинарные данные произвольного формата(Файлграббер, крипто кошели)

Сам стандарт не должен описывать поголовно каждое поле, как я делал в статье.(должно но немного по другому)
К примеру тот же RFC, там описываеться сам протокол, но реализация на плечах юзеров этой спецификации.
То же самое со стандартом С++ к примеру, в нём описаны требования, компиляторы же являються реализацией.
У нас так же.
В стандарте нужно описать требования которым нужно следовать при работе с логами.
Реализация же будет в дальнейшем, тут уже не столь важно какая БД, какой язык и где мы используем эти данные.
Соответственно выделяем эти правила.(для примера возьмём RFC-793 TCP protocol)
(В дальнейшем нужно схожий документ с полной спецификацией, пока что нужно обсудить всё)
1. INTRODUCTION
ULF -унифцированный формат логов. Выполняет роль единого формата данных для уже существующего и создаваемого ПО в сфере работы с логами.
1.1 Мотивация
Упрощение разработки нового ПО. Унификация с целью дальнейшего более эфективного развития сферы.
1.2 Scope/Область применения
Преднаначен для применения в разного рода утилитах так или иначе работающих с Логами.
1.3 Про этот документ
Данный документ преставляет собой спецификацию обязательную для выполнения любой реализацией данного формата.
1.4 Интерфесы
Так как спецификация описыает формат данных, интерфейсов как таковых здесь нет.
1.5 Operations (тут не совсем понял, пока не могу сформулировать относительно нашего формата)
2. PHILOSOPHY
Ну тут много не напишешь, главное пожалуй предоставление единого формата, которое позволит создавать софт ориентируясь на него, а не на конкретную реализацию
3. FUNCTIONAL SPECIFICATION собственно сама спецификация?
3.1 Данные которые должны присутствовать в логе это:
- Данные браузеров
-- Логин, пароль, юрл
-- Кукисы
-- СС
Опционально:
-- Автозаполнения
-- История
-- Закладки
- Системная информация
-- Данные юзера, айпи, гео..(Тут скорее всего обязательно, остальное опционально)
-- Железо пк
-- Список запущенных процессов
-- Список установленного софта
-- Данные о тиме/источнике трафа/метка или тег
- Крипто кошельки
- Файлы с файлграббера
- Файлы произвольных приложений
3.2 Формат данных
- Логин, пароль и юрл - представляют собой строковые значения, должны храниться в формате связанной группы, в обьекте, массиве либо структуре.
- Куки - строковые значения, 7 строк в связанной группе.(строка с ТАБами, обьект, массив)
- Автозаполнения - строковые значения, храняться попарно имя-значение.
- СС - строковые значения, 4 строки вв связанной группе (обьект, массив)
....
TODO: пока так, но думаю должно быть более понятно о чем я.
Основные задачи стандарта так же унифицировать формат файловых данных с трёх последних пунктов.

Так как это стандарт по аналогии с РФС выше, тут есть как обязательные к выполнению пункты, так и опциональные.
Что бы соответствовать стандарту необходимо естественно реализовать обязательные пункты.
В дальнейшем по мере доработки, по аналогии с РФС, будут более детально расписаны форматы файловых данных, крипто кошелей и тд.
Так же в дальнейшем нужно прописать поведение при разного рода ошибках, обработке опциональных пунктов и тд.
Немного в будущее:
- "О, этот стилер соответствует стандарту Ульф"
- "Круто! Он идеально впишеться в мой сервис..."
- "Как хорошо что есть такой стандарт.."
- "Благодаря Ульфу я могу писать свой софт и не сомневаться что он идеально впишеться в существующую инфраструктуру моих клиентов"
Ну вы поняли.
Приглашаю всех неравнодушных поразмыслить о унификации файловых данных и обязательно в письменном виде.

 

[marmalade]

Честно, как-то неудобно читать полу-художественный стиль. Если есть желание заняться стандартизацией, может оформишь в виде RFC, как испокон веков и были созданы все веб-стандарты?

 

[shady]

Не пытайтесь загнать бинарные данные в БД, она для этого плохо предназначена (хоть и предусмотрен формат). Загоняйте метаданные вроде пути к файлу или пути к файлу в зип архиве. Когда у вас будет БД более 1млн записей бинарных файлов, вы увидите как движок тормозит на выборках и сожрался диск из-за того что данные не сжатые и занимают довольно много места (архив лога занимает 10мб, разархивированные данные условно 50мб);

Загоняют данные в базу для индексации и поиска. Вы будете делать поисковые запросы к бинарным кускам файлов в бд? Сомневаюсь.

P.S.: Просто сделайте 10 парсеров для 10 разных логов и приведите их данные к своему удобному формату (json/bson/xml/???) и далее делайте что хотите с ними. Проблема больше в том, что стилеры тянут не всю нужную для автоматизации информацию и лучше определить сначала нужные вам пользовательские данные, прежде чем клепать _стандарт_.

 

[peacemaker]

Да мне кажется, народ забил уже)

 

[KijomBa]

Не пытайтесь загнать бинарные данные в БД, она для этого плохо предназначена (хоть и предусмотрен формат). Загоняйте метаданные вроде пути к файлу или пути к файлу в зип архиве. Когда у вас будет БД более 1млн записей бинарных файлов, вы увидите как движок тормозит на выборках и сожрался диск из-за того что данные не сжатые и занимают довольно много места (архив лога занимает 10мб, разархивированные данные условно 50мб);

Загоняют данные в базу для индексации и поиска. Вы будете делать поисковые запросы к бинарным кускам файлов в бд? Сомневаюсь.

P.S.: Просто сделайте 10 парсеров для 10 разных логов и приведите их данные к своему удобному формату (json/bson/xml/???) и далее делайте что хотите с ними. Проблема больше в том, что стилеры тянут не всю нужную для автоматизации информацию и лучше определить сначала нужные вам пользовательские данные, прежде чем клепать _стандарт_.

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

Да мне кажется, народ забил уже)

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

 

[l33t]

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

Проблема Раз:
Самым главным это убедить программистов инфостилеров, что твой стандарт это не лишний функционал, а возможность продавать свой софт лучше.

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

Проблема номер Два:
Разработчику стиллера проще архивировать всё в zip и отправить в панель, чем сериализовать всё в Json под твой стандарт в стиллере.

Решение проблемы Два:
Если им проще не писать - то они и не будут этого делать в стиллере. А значит тебе нужно будет разработать плагин и апи для экспорта, который разработчик панели сможет подключить к своему продукту. Сколько стиллеров - столько и языков для панели. Это в основном - php, python, golang, не отменяет того, что возможно будет что то экзотическое. Покрыть хотя бы три языка для плагина экспорта тебе нужно будет изначально.

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

Решения проблемы Три:
Конечно при всех расскладах, выдвинутых программистом будет звучать отмазка "Это твой ****** йоба-стандарт виноват!", а пользователь побежит выдумывать новый арбитраж. Так что изначально крутой PR именно формата необходим раньше написания самой спецификации формата.

 

[l33t]

Ну если никому не интересно - запилю свой парсер с блекджеком и шлюхами. Хе-хе-хе

 

[KijomBa]

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

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

Ну если никому не интересно - запилю свой парсер с блекджеком и шлюхами. Хе-хе-хе

Я только за) Тут можем обсудить что нужно если возникнут проблемы.