Comments 5
Спасибо за интересный пост!
Хочется задать пару-тройку вопросиков:
1) Как сейчас оценивается точность в вашем варианте кластеризации?
2) Будет ли использоваться получаемая разметка для дальнейших изысканий, или дрифт данных в этой задаче очень высок?
3)
Не хочу показаться капитаном, но ведь сейчас хватает инструментов для distributed computing (Spark, Dask), или объем данных настолько немыслим? Как же вы сейчас с обработкой справляетесь? :)
Хочется задать пару-тройку вопросиков:
1) Как сейчас оценивается точность в вашем варианте кластеризации?
2) Будет ли использоваться получаемая разметка для дальнейших изысканий, или дрифт данных в этой задаче очень высок?
3)
Стандартные методы кластеризации не работают из-за большого количества признаков. Проклятье размерности не позволяет даже загрузить данные в память,… какие-то алгоритмы кластеризации.
Не хочу показаться капитаном, но ведь сейчас хватает инструментов для distributed computing (Spark, Dask), или объем данных настолько немыслим? Как же вы сейчас с обработкой справляетесь? :)
1) Каждая построенная группа проверяется вручную, поэтому точность кластеризации оценивается так: количество утвержденных групп, разделённое на общее количество построенный групп. Что касается качества классификации, то оно, очевидно 100%, т.к. все работающие группы утверждены вручную.
2) Конечно. После построения группы, она начинает использоваться «в боевом режиме». Все новые URL, попавшие под утвержденную группу отправляются на дальнейшую обработку в CERT.
3) Верно, Spark, Dask тут совсем не применимы. Объем данных — по 10 000-20 000 новых урлов. При этом для каждого урла свои ресурсы. Если создавать матрицу наличия или отсутствия ресурсов, то она даже в оперативную память не поместиться. Прикидывали (на бумаге, естественно), примерно около 1 ТБ будет ;)
2) Конечно. После построения группы, она начинает использоваться «в боевом режиме». Все новые URL, попавшие под утвержденную группу отправляются на дальнейшую обработку в CERT.
3) Верно, Spark, Dask тут совсем не применимы. Объем данных — по 10 000-20 000 новых урлов. При этом для каждого урла свои ресурсы. Если создавать матрицу наличия или отсутствия ресурсов, то она даже в оперативную память не поместиться. Прикидывали (на бумаге, естественно), примерно около 1 ТБ будет ;)
Занятно. Но ведь обфусцировать css/js/image/font не сложнее, чем html. Ведь скорее всего вы храните хэши о ресурсов, а значит достаточно поменять 1 байт. Есть, конечно, методы сравнения похожести для бинарных/произвольных данных, но это уже другие нагрузки и снижение точности…
Верно, если поменять 1 байт — то алгоритм, описанный в данном посте, не будет работать.
Для решения этой проблемы нужно использовать перцептивные функции хеширования.
Но это тема отдельной статьи.
Для решения этой проблемы нужно использовать перцептивные функции хеширования.
Но это тема отдельной статьи.
Да, перцептивные, я знал их как fuzzy hashes. Но по ним уже есть статьи даже на хабре.
Но если не разбирать их алгоритмы, то на статью там мало, имхо. Хотя, применительно к ваше теме я бы с интересом почитал :)
А что-то еще у вас используется, там, байес тот же? Группируете ли по таким критериям, как ip/subnet/ns/as?
Но если не разбирать их алгоритмы, то на статью там мало, имхо. Хотя, применительно к ваше теме я бы с интересом почитал :)
А что-то еще у вас используется, там, байес тот же? Группируете ли по таким критериям, как ip/subnet/ns/as?
Sign up to leave a comment.
Деньги на ветер: почему ваш антифишинг не детектирует фишинговые сайты и как Data Science заставит его работать?