Під час моніторингу 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.


Відповіді:


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-адресу.


Перевагою цього tcpflowє те, що воно вже доступне в сховищах за замовчуванням у Ubuntu 10.04 (justsniffer, httpry не є). Інформація про пакет говорить про те, що фрагменти IP не записані належним чином - не знаю, якщо це має значення для цього випадку використання - можливо, Justsniffer може впоратися з ними краще.
maxschlepzig

Оскільки ви просто захоплюєте URL-адресу, схоже, це не матиме значення. Tcpflow відобразить пакети в тому порядку, в якому вони були отримані в інтерфейсі. Таким чином, якщо ви намагалися зафіксувати вміст файлу, ви можете отримати пакети, які виходять з ладу і дадуть пошкоджений файл. Але ваш випадок використання, зазначений у питанні, я думаю, це допоможе вам. Ви також можете розширити свій греп (або вилучити -o), щоб побачити більше даних пакету для сортування чи чогось пізніше.
bahamat

@bahamat Чи може "tcpflow" працювати з https URL?
Patel Maulik

Все частіше відповідь - ні. У минулому SSL був досить слабким, що якби у вас був доступ до ключа, використовуваного для потоку, ви могли розшифрувати будь-який трафік, що використовується цим ключем. Сьогодні більшість сайтів використовуватимуть таємну передачу вперед та узгоджують ефемерні ключі. Найкращий на сьогодні варіант - так званий прозорий проксі-сервер "натикається на дріт".
bahamat

1
під час перегляду, користуючись wifi: нічого не було: sudo tcpflow -p -c -i wlo2 порт 80 | Grep -oe '(GET | POST | ГОЛОВА) * HTTP / 1 [01] | Ведучий: ... *'
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

(вихід трохи скорочений)


Як я можу показати заголовок або тіло запиту чи відповіді?
Мохаммед Нурелдін

нічого не отримав Суд 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 для отримання додаткової інформації.


1

Я думаю, що Wireshark здатний робити те, що ти хочеш

З іншого боку, він дуже потужний, його можна встановити через apt-get, і він постачається з графічним інтерфейсом.

Однак система фільтрування є складною - але вбудовані хороші підручники, і це дасть вам огляд руху або запуску / зупинки трафіку.

Введення слова "http" у фільтр, ймовірно, дасть вам те, що ви шукаєте (тобто основний трафік, що генерується користувачами).


Хотіли б знати, чому це було знято. Wireshark може читати інтерфейс на льоту і фільтрувати лише http-трафік.
Кевін М

@Kevin M, Ну, я не спростував твоєї відповіді. Але, щоб бути справедливим, ваша відповідь трохи неповна і поза темою. 1) У ньому пропущені деталі щодо того, як саме слід використовувати провідну стрічку, тобто про те, що слід використовувати фільтр, точний вираз фільтра тощо. у підході до графічного інтерфейсу, в режимі перегляду за замовчуванням відображаються GET-запити, де доменне ім’я не відображається поруч - причому це не так зручно для ескізного випадку використання.
maxschlepzig

Я маю на увазі: s / ваша відповідь / відповідь Фобії /
maxschlepzig

1

Ще одним хорошим варіантом можуть бути сіточки

На Fedora доступна серед основних пакетів, а на centos ви можете отримати її через epel repo.


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 (працює чудово під легкістю).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.