Мониторинг HTTP-запросов на лету через сетевой интерфейс?

79

В целях отладки я хочу отслеживать http-запросы на сетевом интерфейсе.

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

Вывод трафика через tcpdumpфайл и последующее использование wiresharkимеет тот недостаток, что он не на лету.

Я представляю себе использование инструмента следующим образом:

$ monitorhttp -ieth0 --only-get --just-urls
2011-01-23 20:00:01 GET http://foo.example.org/blah.js
2011-01-23 20:03:01 GET http://foo.example.org/bar.html
...

Я использую Linux.

networking monitoring http-logging

— maxschlepzig
источник

На superuser.com/questions/67428/possible-to-catch-urls-in-linux

— AlexD

100

Попробуй tcpflow:

tcpflow -p -c -i eth0 port 80 | grep -oE '(GET|POST|HEAD) .* HTTP/1.[01]|Host: .*'

Вывод такой:

GET /search?q=stack+exchange&btnI=I%27m+Feeling+Lucky HTTP/1.1
Host: www.google.com

Очевидно, что вы можете добавить дополнительные HTTP-методы в оператор grep и использовать их sedдля объединения двух строк в полный URL-адрес.

— bahamat
источник

Преимущество tcpflowзаключается в том, что он уже доступен в репозиториях по умолчанию в Ubuntu 10.04 (justsniffer, httpry нет). Информация о пакете гласит, что IP-фрагменты не записаны должным образом - не знаю, имеет ли это значение для этого варианта использования - возможно, justsniffer может обработать их лучше.

— maxschlepzig

Поскольку вы просто захватываете URL, похоже, это не имеет значения. Tcpflow будет отображать пакеты в порядке их получения на интерфейсе. Таким образом, если вы пытаетесь перехватить содержимое файла, вы можете получить пакеты, которые приходят не по порядку и создают поврежденный файл. Но ваш вариант использования, указанный в вопросе, я думаю, это будет работать для вас. Вы также можете расширить свой grep (или удалить -o), чтобы увидеть больше данных пакета для сортировки или еще чего-нибудь позже.

— Багамат

@bahamat Может ли "tcpflow" работать с https URL?

— Маулик Патель

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

— Багамат

1

ничего не получил, просматривая, используя wifi: sudo tcpflow -p -c -i wlo2 порт 80 | grep -oE '(GET | POST | HEAD). * HTTP / 1. [01] | Host:. *'

— ses

23

Вы можете использовать httpry или Justniffer, чтобы сделать это.

httpry доступно, например, через репозиторий пакетов Fedora.

Пример вызова:

# httpry -i em1

(где em1обозначает имя сетевого интерфейса)

Пример вывода:

2013-09-30 21:35:20    192.168.0.1     198.252.206.16    >    POST    unix.stackexchange.com    /posts/6281/editor-heartbeat/edit    HTTP/1.1
2013-09-30 21:35:20    198.252.206.16  192.168.0.1       < HTTP/1.1   200    OK
2013-09-30 21:35:49    192.168.0.1     198.252.206.16    >    POST    unix.stackexchange.com    /posts/validate-body                 HTTP/1.1
2013-09-30 21:35:49    198.252.206.16  192.168.0.1       < HTTP/1.1   200    OK
2013-09-30 21:33:33    192.168.0.1      92.197.129.26    >    GET     cdn4.spiegel.de    /images/image-551203-breitwandaufmacher-fgoe.jpg    HTTP/1.1

(вывод немного укорочен)

— X4lldux
источник

Как я могу показать заголовок или тело запроса или ответа?

— Мухаммед Нурельдин

ничего не получил sudo httpry -i wlo2 (где wlo2 по имени устройства wifi)

— ses

7

Я искал что-то подобное, с дополнительным требованием, чтобы оно работало и для https .

Такие инструменты на базе pcap, как tcpflow httpry urlsnarfи другие tcpdump kung fu, хорошо работают для http, но для защищенных запросов вам не повезло.

Я придумал urldump , небольшую оболочку вокруг mitmproxy .
iptablesиспользуется для перенаправления трафика на прокси, поэтому он работает прозрачно.

$ sudo urldump   
http://docs.mitmproxy.org/en/stable/certinstall.html
http://docs.mitmproxy.org/en/stable/_static/js/modernizr.min.js
https://media.readthedocs.org/css/sphinx_rtd_theme.css
https://media.readthedocs.org/css/readthedocs-doc-embed.css
https://media.readthedocs.org/javascript/readthedocs-doc-embed.js
...

Смотрите README для получения дополнительной информации.

— lemonsqueeze
источник

1

Я думаю, что Wireshark способен делать то, что вы хотите

С другой стороны, он очень мощный, вы можете установить его через apt-get, и он поставляется с графическим интерфейсом.

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

Ввод слова 'http' в фильтр, вероятно, даст вам то, что вы ищете (то есть основной трафик, генерируемый пользователями).

— Махмуд Хоссам
источник

Хотелось бы знать, почему это было понижено. Wireshark может читать интерфейс на лету и фильтровать только http-трафик.

— Кевин М,

@ Кевин М, ну я не понизил твой ответ. Но, если честно, ваш ответ немного неполон и не по теме. 1) Он пропускает детали того, как именно должен использоваться wireshark, то есть, что должен использоваться фильтр, точное выражение фильтра и т. Д. 2) он не позволяет использовать командную строку, как показано в вопросе - даже если я в порядке с При подходе с графическим интерфейсом представление по умолчанию отображает запросы GET, когда имя домена не отображается рядом, что не очень удобно для набросков сценария использования.

— maxschlepzig

Я имею в виду: s / ваш ответ / ответ Фобии /

— maxschlepzig

1

Другим хорошим вариантом могут быть сурки

На fedora доступен среди основных пакетов, а на centos вы можете получить его через репозиторий epel.

— adriano72
источник

1

Существует также программа командной строки, urlsnarfкоторая является частью пакета dsniff (который также поставляется, например, с Fedora 19).

Пример:

# urlsnarf -i em1
urlsnarf: listening on em1 [tcp port 80 or port 8080 or port 3128]
jhost - - [29/May/2014:10:25:09 +0200] "GET http://unix.stackexchange.com/questions HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/ HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/layout/css/style-V5-2-2.css HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/layout/jscfg/http/global-V5-2-2.js HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/layout/js/http/javascript-V5-2-2.js HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/layout/js/http/interface-V5-2-2.js HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/layout/js/http/netmind-V5-2-2.js HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/favicon.ico HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "POST http://ocsp.thawte.com/ HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "POST http://ocsp.thawte.com/ HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0
[..]

(при просмотре сначала в SE, а затем в spiegel.de)

Ограничения: dsnarf не поддерживает IPv6 . Я могу воспроизвести этот отчет об ошибке с 0.17 на Fedora 19. Также, похоже, не работает в Ubuntu trusty atm (отлично работает под lucid).

— maxschlepzig
источник