DG
Если юзер совсем лох, я бы добавил флаг поля, если предыдущая колонка текстом ipv4 – первая регулярка, else другая
Size: a a a
2020 January 29
AL
я сначала подумал что ты тоже тролишь но выходит норм. Собственно да, вопрос был как тогда делить поля, чтобы они не напутали когда будут писать парсер ipv4+порт от ipv6
Ну может тогда написать парсер для двух сторон - вашей и черного ящика. Тогда хоть ошибок приема не будет. А можно вообще отдавать как есть - там все равно никто не сможет разобрать фиды
NA
Кидайте в protobuf и вас возненавидят!
JD
мне json ближе. Там можно логично нагромоздить избыточность данных на своем уровне. + например отдать тулзу которая будет json перекидывать в красивый csv если требуется предобработка людьми (например не могут написать парсер и будут все руками делать)
NA
Я уже этим путем прошел
NA
Конвертер надо будет поддерживать
JD
Конвертер надо будет поддерживать
ественно
V
мне json ближе. Там можно логично нагромоздить избыточность данных на своем уровне. + например отдать тулзу которая будет json перекидывать в красивый csv если требуется предобработка людьми (например не могут написать парсер и будут все руками делать)
а ещё не стоит забывать про экранирование json
JD
Я уже этим путем прошел
я потому и написал что явно люди уже прошли через это
NA
у меня сейчас в конвертере с JSON реализация в CSV для ArcSight, MP SIEM и под всякие Redis. Проще конвертер не отдавать, а держать на своей стороне и выдавать итоговый CSV в нужном формате.
AL
на край в ids
На край? Много ли ids умеют работать с чужими фидами? Тогда уж в Snort-формате их надо отдавать, но для этого опять же надо знать, что на приеме стоит
JD
Alexey Lukatsky
На край? Много ли ids умеют работать с чужими фидами? Тогда уж в Snort-формате их надо отдавать, но для этого опять же надо знать, что на приеме стоит
да и отсюда вырастает проблема что нужно некую экосистему делать с ориентировкой на пользователей. И задача явн оперестает быть совсем тривиальной
AL
да и отсюда вырастает проблема что нужно некую экосистему делать с ориентировкой на пользователей. И задача явн оперестает быть совсем тривиальной
Ну я бы нарисовал красивую картину с процедурой а-ля хендшейк, в рамках которой определяется, в каком формате надо отдать фиды. Но это все равно малоореально без понимания, что стоит на приеме. SIEMы тоже разные бывают. Кто-то понимает STIX только определенной версии. Кто-то зато Sigma воспринимает на ура...
AL
Либо установить жесткое правило - отдаем только в STIX или CSV, а получатель пусть сам мучается, как это засунуть в свой приемник
JD
Alexey Lukatsky
Ну я бы нарисовал красивую картину с процедурой а-ля хендшейк, в рамках которой определяется, в каком формате надо отдать фиды. Но это все равно малоореально без понимания, что стоит на приеме. SIEMы тоже разные бывают. Кто-то понимает STIX только определенной версии. Кто-то зато Sigma воспринимает на ура...
да, и вот вопрос что отдать когда там зоопарк + что-то в процессе изменений
JD
мне json ближе. Там можно логично нагромоздить избыточность данных на своем уровне. + например отдать тулзу которая будет json перекидывать в красивый csv если требуется предобработка людьми (например не могут написать парсер и будут все руками делать)
начал рыть stix. Там транспорт json. Это просто формат полей для него
AL
Ну не будет ответа на этот вопрос, если на стороне приемник непонятно как работает и на него нельзя повлиять
$
Alexey Lukatsky
Ну может тогда написать парсер для двух сторон - вашей и черного ящика. Тогда хоть ошибок приема не будет. А можно вообще отдавать как есть - там все равно никто не сможет разобрать фиды
Классное предложение в условиях «чёрный ящик на той стороне»
$
Кидайте в protobuf и вас возненавидят!
Я бы попросил!
$
мне json ближе. Там можно логично нагромоздить избыточность данных на своем уровне. + например отдать тулзу которая будет json перекидывать в красивый csv если требуется предобработка людьми (например не могут написать парсер и будут все руками делать)
Зачем тулза? Выгружай отдельные списки. Ни регулярок не нужно, ни логики