Ложные запросы, аудиторы сертификатов?

В последние несколько дней я видел много запросов POST для многих доменов, у которых есть следующие пути:

/ct/v1/sct-gossip
/ct/v1/sct-feedback
/.well-known/ct/v1/sct-feedback
/.well-known/ct/v1/sth-pollination
/.well-known/ct/v1/collected-sct-feedback
/.well-known/ct/v1/sct-gossip
/topleveldir/subdir/research-feedback

Это кто-то пытается сделать что-то сомнительное?

Я нашел следующий документ, который предполагает, что это может быть связано с аудиторами сертификатов, хотя я не уверен, что! Все мои веб-сайты выходят на Cloudflare, который предоставляет сертификаты SSL, поэтому я бы действительно ожидал, что Cloudflare будет обрабатывать любые такие запросы.

https://tools.ietf.org/html/draft-ietf-trans-gossip-00

Любые мысли будут оценены: -)

Ответ 1

После расследований запросы поступают из https://net.in.tum.de/projects/gino/index.html#internet-wide-scans

Они проводят интернет-измерения, чтобы найти конечные точки Gossip для прозрачности сертификатов.

Вы можете попросить их занести в черный список ваш домен /IP, просто отправив электронное письмо на адрес [email protected]

Привет

Ответ 2

Это протокол безопасности knwon для цепочек сертификатов.

Ответ 3

https://ct.grahamedgecombe.com/

имеет: Сплетня с надписью Tree Head

Для обмена сообщениями STH предусмотрены две конечные точки API:

/ct/v1/sth-gossip, which implements draft-linus-trans-gossip-ct-01.
/.well-known/ct/v1/sth-pollination, which implements draft-ietf-trans-gossip-00.

Оба возвращают все STH, наблюдаемые в течение последнего часа, поэтому есть немного вопросов в запросе их более одного раза каждые 30 минут. Если вы используете одну из этих конечных точек, я был бы признателен за возможность сплетни с вашего монитора взамен. В частности, конечная точка /ct/v 1/sth-gossip не поддерживает обмен сплетнями в обоих направлениях. Свяжитесь со мной, если вы хотите организовать это. Подписанный сертификат Сплетни с меткой времени

Экспериментальная конечная точка API предоставляется для отправки сплетен SCT:

/ct/v1/sct-feedback, which implements draft-ietf-trans-gossip-00.

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

Ответ 4

TL;DR; - скорее всего, вредоносный трафик или проверьте, что ips попадают в диапазон, отправленный @QuentinL.D.

URL-адреса .well-known, вероятно, пытаются использовать некоторые возможные из https://www.letsencrypt.org. Или, скорее, неправильно сконфигурированные веб-серверы. Я говорю, что возможно b/c, я не слышал о каких-либо проблемах с letencrypt, если вы не используете letsencrypt, тогда я бы рассмотрел этот вредоносный трафик. Обычный запрос от letsencrypt/certbot [1] будет выглядеть так:

127.0.0.1 - - [03/Oct/2017:22:21:02 +0000] "GET /.well-known/acme-challenge/2VJSAGWTQ3l14rkSa7MTbVYKiwPEXvrx2T1BdQpOVhc HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let Encrypt validation server; +https://www.letsencrypt.org)" "-"

Обратите внимание, что мои состояния 127.0.0.1 b/c направляют эти запросы с помощью haproxy локально на отдельный порт/сервер, а не на веб-серверы в кластере.

1 - https://github.com/certbot/certbot

Я тоже вижу их в своих журналах веб-сервера, которые никогда не будут размещать папку letencrypt .well-known, поэтому я (кратко) объяснил мою настройку выше

Я понимаю, что это не точный ответ на ваш вопрос, но, надеюсь, это помогает.

EDIT: IP-адреса, попавшие в эти URL-адреса, находятся в пределах ярости, отправленных @QuentinL.D, не заметили этого комментария, спасибо за ссылку.