Пассивное определение ОС, веб-сервера и браузера удалённых хостов только по анализу трафика — без отправки единого пакета. Работает незаметно для IDS/IPS. Используется для разведки, мониторинга сети и сбора метаданных без активных запросов.
# Kali Linux / Debian: sudo apt install p0f # Прослушивание на интерфейсе: sudo p0f -i eth0 -p -o /tmp/p0f.log # Анализ pcap-файла: sudo p0f -r capture.pcap
============================= p0f v3: пассивный fingerprinter =============================
http://lcamtuf.coredump.cx/p0f3.shtml
Copyright (C) 2012 Michal Zalewski lcamtuf@coredump.cx
P0f — это инструмент, который использует набор сложных, полностью пассивных механизмов fingerprinting трафика для идентификации участников любого попутного TCP/IP-общения (часто даже по одному обычному SYN-пакету) без какого-либо вмешательства.
Некоторые из его возможностей включают:
Highly scalable and extremely fast identification of the operating system and software on both endpoints of a vanilla TCP connection - especially in settings where NMap probes are blocked, too slow, unreliable, or would simply set off alarms,
Измерение времени работы системы и сетевого подключения, расстояния (включая топологию за NAT или фильтрами пакетов) и т.д.
Автоматическое обнаружение совместного использования соединений / NAT, балансировки нагрузки и настроек проксирования на уровне приложений.
Обнаружение недобросовестных клиентов/серверов, подделывающих декларативные утверждения, такие как X-Mailer или User-Agent.
Инструмент может работать в интерактивном режиме или как демон, и предоставляет простой API в реальном времени для сторонних компонентов, желающих получить дополнительную информацию о собеседниках.
Типичные области применения p0f включают разведку при тестировании на проникновение;Routine monitoring of network traffic; обнаружение несанкционированных сетевых соединений в корпоративных средах; Providing signals for abuse-prevention tools; and miscellanous forensics.
Пример типичного вывода p0f может выглядеть так:
.-[ 1.2.3.4/1524 -> 4.3.2.1/80 (syn) ]-
| | client = 1.2.3.4 | os = Windows XP | dist = 8 | params = none | raw_sig = 4:120+8:0:1452:65535,0:mss,nop,nop,sok:df,id+:0 | `----
.-[ 1.2.3.4/1524 -> 4.3.2.1/80 (syn+ack) ]-
| | server = 4.3.2.1 | os = Linux 3.x | dist = 0 | params = none | raw_sig = 4:64+0:0:1460:mss*10,0:mss,nop,nop,sok:df:0 | `----
.-[ 1.2.3.4/1524 -> 4.3.2.1/80 (mtu) ]-
| | client = 1.2.3.4 | link = DSL | raw_mtu = 1492 | `----
.-[ 1.2.3.4/1524 -> 4.3.2.1/80 (uptime) ]-
| | client = 1.2.3.4 | uptime = 0 days 11 hrs 16 min (modulo 198 days) | raw_freq = 250.00 Hz | `----
Живую демонстрацию можно посмотреть здесь:
http://lcamtuf.coredump.cx/p0f3/
Большинство метрик, используемых p0f, были придуманы специально для этого инструмента и включают данные, извлеченные из заголовков IPv4 и IPv6, заголовков TCP, динамики TCP handshake, а также содержимого полезных нагрузок уровня приложений.
Для TCP/IP инструмент делает отпечатки SYN-пакета, инициированного клиентом, и первого ответа SYN+ACK от сервера, уделяя внимание таким факторам, как порядок опций TCP, соотношение между максимальным размером сегмента и размером окна, динамика временных меток TCP и состояние около дюжины возможных особенностей реализации (например, ненулевые значения в полях "должно быть нулем").
Метрики, используемые для трафика уровня приложений, варьируются от модуля к модулю; где возможно, инструмент опирается на такие сигналы, как порядок или синтаксис HTTP-заголовков или команд SMTP, а не на какие-либо декларативные утверждения, такие как User-Agent. Модули fingerprinting уровня приложений в настоящее время поддерживают HTTP. До выхода инструмента из "бета"-версии, я хочу добавить SMTP и FTP. Другие протоколы, такие как FTP, POP3, IMAP, SSH и SSL, могут последовать.
Список всех измеряемых параметров рассматривается в разделе 5 далее. Часть анализа также происходит на более высоком уровне: несоответствия в данных, собранных из различных источников, или в данных из одного и того же источника, полученных с течением времени, могут указывать на трансляцию адресов, проксирование или просто откровенный обман. Например, система, в которой временные метки TCP скачают вперед и назад, или где TTL и MTU слегка меняются, вероятно, является устройством NAT.
Чтобы скомпилировать p0f, попробуйте запустить ./build.sh; если это не удастся, вы, вероятно, получите некоторые советы о возможной причине. Если советы бесполезны, пришлите мне злобное письмо.
Также возможно собрать отладочный бинарный файл (./build.sh debug), в этом случае подробный разбор пакетов и информация о сопоставлении отпечатков будут записаны в stderr. Это полезно при устранении проблем, но на этом всё.
Инструмент должен компилироваться без ошибок в любой достаточно новой версии Linux, FreeBSD, OpenBSD, MacOS X и т.д. Вы также можете собрать его на Windows, используя cygwin и winpcap. Я не тестировал его на всех возможных вариантах un*x, но если возникнут проблемы, они должны быть довольно поверхностными.
После того как у вас скомпилирован бинарный файл, вы должны знать следующие опции командной строки:
-f fname - reads fingerprint database (p0f.fp) from the specified location. See section 5 for more information about the contents of this file.
Расположение по умолчанию — `./p0f.fp`. Если вы хотите установить p0f, вы можете изменить `FP_FILE` в `config.h` на `/etc/p0f.fp`.
-i iface - asks p0f to listen on a specific network interface. On un*x, you should reference the interface by name (e.g., eth0). On Windows, you can use adapter index instead (0, 1, 2...).
Несколько параметров `-i` не поддерживаются; для этого вам нужно запускать отдельные экземпляры p0f. В Linux вы можете указать `any` для доступа к псевдоустройству, объединяющему трафик на всех других интерфейсах; единственное ограничение заключается в том, что в этом режиме libpcap не будет распознавать кадры с VLAN-метками, что может быть проблемой в некоторых более экзотических конфигурациях.
Если вы не укажете интерфейс, libpcap, вероятно, выберет первый доступный интерфейс в вашей системе.
-L - lists all available network interfaces, then quits. Particularly useful on Windows, where the system-generated interface names are impossible to memorize.
-r fname - instead of listening for live traffic, reads pcap captures from the specified file. The data can be collected with tcpdump or any other compatible tool. Make sure that snapshot length (-s option in tcpdump) is large enough not to truncate packets; the default may be too small.
Как и с `-i`, за раз можно указать только одну опцию `-r`.
-o fname - appends grep-friendly log data to the specified file. The log contains all observations made by p0f about every matching connection, and may grow large; plan accordingly.
Только один экземпляр p0f должен писать в конкретный файл в любой момент времени; там, где это поддерживается, используется рекомендательная блокировка, чтобы избежать проблем.
-s fname - listens for API queries on the specified filesystem socket. This allows other programs to ask p0f about its current thoughts about a particular host. More information about the API protocol can be found in section 4 below.
В любой момент времени только один экземпляр p0f может слушать на конкретном сокете. Этот режим также несовместим с `-r`.
-d - runs p0f in daemon mode: the program will fork into background and continue writing to the specified log file or API socket. It will continue running until killed, until the listening interface is shut down, or until some other fatal error is encountered.
Этот режим требует указания либо `-o`, либо `-s`.
Чтобы продолжать захватывать отладочный вывод p0f и сообщения об ошибках (но не отпечатки), перенаправьте stderr в другое не-TTY-назначение, например:
`./p0f -o /var/log/p0f.log -d 2>>/var/log/p0f.error`
Обратите внимание, что если указан `-d`, а stderr указывает на TTY, сообщения об ошибках будут потеряны.
-u user - causes p0f to drop privileges, switching to the specified user and chroot()ing itself to said user's home directory.
Этот режим *настоятельно* рекомендуется (но не требуется) в системах un*x, особенно в режиме демона. Подробнее см. в разделе 7.
Более сложные настройки (вам, вероятно, не нужно их трогать):
-p - puts the interface specified with -i in promiscuous mode. If supported by the firmware, the card will also process frames not addressed to it. -S число - устанавливает максимальное количество одновременных API-соединений. По умолчанию — 20; верхний предел — 100.
-m c,h - устанавливает максимальное количество соединений (c) и хостов (h), отслеживаемых одновременно (по умолчанию: c = 1 000, h = 10 000). Как только лимит достигнут, удаляются 10% самых старых записей, чтобы освободить место для новых данных.
Эта настройка фактически управляет потреблением памяти p0f. Стоимость отслеживания одного хоста составляет менее 400 байт; активные соединения в худшем случае потребляют около 18 кБ. Высокие лимиты также оказывают некоторое влияние на ЦП, поскольку усложняют поиск данных в кэше.
ПРИМЕЧАНИЕ: P0f отслеживает соединения только до завершения рукопожатия и, если возможно протокольное отпечатывание, до обмена несколькими первыми килобайтами данных. Это означает, что большинство соединений удаляются из кэша менее чем за 5 секунд; следовательно, переменная 'c' может быть намного ниже реального количества параллельных соединений, происходящих в сети.
-t c,h - устанавливает тайм-аут для сбора отпечатков для любого соединения (c); и для удаления неактивных хостов из кэша в оперативной памяти (h). Первый параметр задается в секундах и по умолчанию составляет 30 с; второй — в минутах и по умолчанию составляет 120 мин.
Первое значение должно быть достаточно высоким для надежного захвата SYN, SYN+ACK и первых нескольких кБ трафика. Сайты с низкой производительностью могут немного увеличить его.
Второе значение определяет, как долго можно делать API-запросы о ранее seen хосте; и какой максимальный интервал между отпечатками, при котором еще происходит обнаружение NAT и т.д. Увеличивать его обычно не рекомендуется; уменьшение до 5-10 минут может быть целесообразным для серверов с высоким трафиком, где можно видеть, как несколько независимых посетителей последовательно получают один и тот же динамический IP от своего провайдера.
Вот, в общем-то, и всё. Возможно, вам придется запускать инструмент от имени root. Некоторые из наиболее частых вариантов использования:
Формат журнала для утилит grep (-o) использует символ pipe ('|') в качестве разделителя, с парами имя=значение, описывающими отпечаток способом, очень похожим на форматированный вывод, генерируемый в stdout:
[2012/01/04 10:26:14] mod=mtu|cli=1.2.3.4/1234|srv=4.3.2.1/80|subj=cli|link=DSL|raw_mtu=1492
Параметр 'mod' идентифицирует подсистему, сгенерировавшую запись; параметры 'cli' и 'srv' всегда описывают направление, в котором устанавливается TCP-сессия; а 'subj' описывает, какая из этих двух сторон фактически отпечатывается.
Параметрам командной строки может следовать один параметр, содержащий правило фильтрации трафика в стиле pcap. Это позволяет отбрасывать некоторые менее интересные пакеты по соображениям производительности или конфиденциальности. Простые примеры включают:
'dst net 10.0.0.0/8 and port 80'
'not src host 10.1.2.3'
'port 22 or port 443'
Вы можете прочитать больше о поддерживаемом синтаксисе, выполнив 'man pcap-filter'; если это не сработает, попробуйте этот URL:
http://www.manpagez.com/man/7/pcap-filter/
Фильтры работают как для захвата в реальном времени (-i), так и для ранее собранных данных, созданных любым другим инструментом (-r).
API позволяет другим приложениям, работающим в той же системе, получать текущее мнение p0f о конкретном хосте. Это полезно для его интеграции со спам-фильтрами, веб-приложениями и т.д.
Клиенты могут подключаться к unix-сокету, указанному через -s, используя протокол SOCK_STREAM, и могут отправлять любое количество запросов фиксированной длины. Запросы будут обрабатываться в порядке их поступления.
Обратите внимание, что нет кэширования ответов и программных ограничений на стороне p0f, поэтому ответственность за написание достаточно корректных клиентов лежит на вас.
Запросы имеют ровно 21 байт. Формат следующий:
Магическое слово (0x50304601), в нативном порядке байт платформы.
Байт типа адреса: 4 для IPv4, 6 для IPv6.
16 байт данных адреса, в сетевом порядке байт. Адреса IPv4 должны быть выровнены по левому краю.
На такой запрос p0f отвечает:
Еще одно магическое слово (0x50304602), нативный порядок байт.
Слово состояния: 0x00 для 'некорректный запрос', 0x10 для 'ОК', и 0x20 для 'нет совпадения'.
Информация о хосте, действительная только если состояние 'ОК' (ширина байта в квадратных скобках):
[4] first_seen - unix-время (секунды) первого наблюдения хоста.
[4] last_seen - unix-время (секунды) последнего трафика.
[4] total_conn - общее количество seen соединений.
[4] uptime_min - вычисленное время работы системы, в минутах. Ноль, если неизвестно.
[4] up_mod_days - интервал обнуления времени работы, в днях.
[4] last_nat - время последнего обнаружения разделяемого IP (NAT, балансировка нагрузки, проксирование). Ноль, если никогда не обнаруживалось.
[4] last_chg - время последнего отдельного несовпадения ОС (например, из-за мультизагрузки или повторного использования IP).
[2] distance - расстояние до системы (получено из TTL; -1, если нет данных).
[1] bad_sw - p0f считает, что строки User-Agent или Server не являются точными. Значение 1 означает различие ОС (возможно, из-за проксирования), а 2 означает явное несовпадение.
ПРИМЕЧАНИЕ: Если User-Agent отсутствует, это значение остается 0.
[1] os_match_q - качество совпадения ОС: 0 для обычного совпадения; 1 для неточного (например, из-за различий TTL или DF); 2 дляgeneric-отпечатка; и 3 для обоих.
[32] os_name - имя последней положительно совпавшей ОС, завершающееся NUL. Если ОС неизвестна, os_name[0] — NUL.
ПРИМЕЧАНИЕ: Если хост впервые seen с известной системой, а затем переключается на неизвестную, это поле не сбрасывается.
[32] os_flavor - версия ОС. Может быть пустой, если нет данных.
[32] http_name - последнее положительно идентифицированное HTTP-приложение (например, 'Firefox').
[32] http_flavor - версия HTTP-приложения, если есть.
[32] link_type - тип сетевого соединения, если распознан.
[32] language - язык системы, если распознан.
Простая эталонная реализация API-клиента приведена в p0f-client.c. Реализации на C / C++ также могут повторно использовать api.h из исходного кода p0f.
Разработчикам, использующим API, следует знать о нескольких важных ограничениях:
Максимальное количество одновременных API-соединений ограничено 20. Лимит может быть регулирован параметром -S, но неконтролируемый параллелизм может привести к плохо управляемой задержке; рассмотрите возможность использования одного конвейера запросов, возможно, с приоритизацией и кэшированием.
Максимальное количество хостов и соединений, отслеживаемых в любой момент времени, подчиняется настраиваемым лимитам. Вам следует изучить статистику вашего трафика и посмотреть, подходят ли значения по умолчанию.
Вы также должны иметь в виду, что при проведении DDoS-атаки или атаки SYN spoofing Dos p0f может удалять записи быстрее, чем вы успеваете по ним запрашивать. Альтернатива — исчерпание памяти, так что не переживайте.
Записи кэша без активности более 120 минут будут удалены, даже если кэш почти пуст. Тайм-аут регулируется параметром -t, но вы не должны использовать API для получения устаревших данных; если вам регулярно нужно возвращаться на часы или дни, лучше парсить журналы, чем тратить оперативную память.
Когда p0f получает отпечаток из observed трафика, он обращается к данным, прочитанным из p0f.fp, для идентификации операционной системы и получения некоторых вспомогательных данных, необходимых для других задач анализа. База данных отпечатков — это простой текстовый файл, где строки, начинающиеся с ; игнорируются.
== Спецификация модуля ==
Файл разделен на секции в зависимости от типа трафика, к которому относятся отпечатки. Идентификаторы секций заключены в квадратные скобки, например:
[module:direction]
module - имя модуля отпечатывания (например, 'tcp' или 'http').
direction - направление отпечатываемого трафика: 'request' (от клиента к серверу) или 'response' (от сервера к клиенту).
Для модуля TCP 'client' соответствует начальному SYN; а 'server' соответствует SYN+ACK.
Часть 'direction' опускается для отпечатков MTU, так как они одинаково хорошо работают в обоих направлениях.
== Группы отпечатков ==
Сами отпечатки должны предваряться строкой 'label', описывающей отпечатываемое программное обеспечение:
label = type:class:name:flavor тип - некоторые подписи в p0f.fp предлагают широкое, последнее средство сопоставления для менее изученных пограничных случаев. Цель состоит в том, чтобы дать ответ, несколько лучше, чем "неизвестно", но менее точный, чем может ожидать пользователь.
Нормальные, достаточно конкретные подписи, которые не могут быть
радикально улучшены, должны иметь тип 's'; тогда как.generic,
последние средства должны быть помечены как 'g'.
Обратите внимание, что.generic подписи рассматриваются только в том
случае, если в базе данных не найдено никаких конкретных совпадений.
класс - инструменту необходимо различать подписи, идентифицирующие ОС (из которых только одна должна быть сопоставлена для любого конкретного хоста) и подписи, которые просто идентифицируют пользовательские приложения (многие из которых могут наблюдаться одновременно).
Для помощи в этом, подписи, специфичные для ОС, должны указывать
здесь семейство архитектуры ОС (например, 'win', 'unix', 'cisco');
тогда как подписи, связанные с приложениями (NMap, MSIE, Apache),
должны использовать специальное значение '!' .
Большинство TCP-подписей являются специфичными для ОС, и должны
иметь определенное семейство ОС. Другие подписи, такие как HTTP,
должны использовать '!' , если только компонент отпечатка не
глубоко переплетен с платформой (например, Windows Update).
ПРИМЕЧАНИЕ: Чтобы избежать вариаций (например, 'win' и 'windows'
или 'unix' и 'linux'), все классы должны быть предварительно
зарегистрированы с помощью директивы 'classes', которую можно
увидеть в начале p0f.fp.
имя - человекочитаемое краткое название того, что на самом деле помогает идентифицировать отпечаток - например, 'Linux', 'Sendmail' или 'NMap'. Инструмент не обращает внимания на точное значение, но требует последовательности - поэтому не переключайтесь между 'Internet Explorer' и 'MSIE', или 'MacOS' и 'Mac OS'. вариант - все, что вы хотите сказать для further квалификации наблюдения. Может быть версией идентифицированного программного обеспечения или описанием того, что, похоже, делает приложение (например, 'SYN scan' для NMap).
ПРИМЕЧАНИЕ: Не будьте слишком конкретны: если у вас есть подпись
для Apache 2.2.16, но нет причин подозревать, что другие
последние версии ведут себя радикально иначе, просто скажите '2.x'.
P0f использует метки для группировки похожих подписей, которые, как можно правдоподобно предположить, генерируются одной и той же системой или приложением, и не должны рассматриваться как сильный сигнал для обнаружения NAT.
Чтобы further помочь инструменту в определении того, какие комбинации ОС и приложений являются разумными, а какие свидетельствуют о нарушениях, любая строка 'label' для приложений (класс '!') должна сопровождаться списком разделенных запятыми имен ОС или классов архитектуры ОС с префиксом @, на которых, как известно, используется это программное обеспечение. Например:
label = s:!:Uncle John's Networked ls Utility:2.3.0.1 sys = Linux,FreeBSD,OpenBSD
...или:
label = s:!:Mom's Homestyle Browser:1.x sys = @unix,@win
За меткой может следовать любое количество специфических для модуля подписей; все они будут связаны с самой последней меткой и будут сообщаться одинаково.
Все секции, кроме 'name', опускаются для подписей [mtu], которые не передают никакой информации, специфичной для ОС, и просто описывают типы каналов.
== Сигнатуры MTU ==
Многие операционные системы получают максимальный размер сегмента, указанный в параметрах TCP, из MTU своего сетевого интерфейса; это значение, в свою очередь, обычно зависит от дизайна протокола канального уровня. Разные MTU ассоциируются с PPPoE, другие с IPSec и другие с VPN Juniper.
Формат сигнатур в секции [mtu] чрезвычайно прост и состоит только из описания и списка значений:
label = Ethernet sig = 1500
Они будут сопоставлены для любых TCP-пакетов с диким MSS (см. ниже), не сгенерированных пользовательскими TCP-инструментами.
== TCP-сигнатуры ==
Для TCP-трафика макет подписи выглядит следующим образом:
sig = ver:ittl:olen:mss:wsize,scale:olayout:quirks:pclass
ver - подпись для IPv4 ('4'), IPv6 ('6') или обоих ('*').
НОВЫЕ ПОДПИСИ: P0f документирует протокол, наблюдаемый в сети,
но вы должны заменить его на '*', если вы не наблюдали
каких-либо реальных различий между трафиком IPv4 и IPv6, или
если программное обеспечение поддерживает только одну из этих
версий.
ittl - начальный TTL, используемый ОС. Почти все операционные системы используют 64, 128 или 255; старые версии Windows иногда использовали 32, а несколько малоизвестных систем иногда прибегают к странным значениям, таким как 60.
НОВЫЕ ПОДПИСИ: P0f обычно предложит что-то, используя формат
'observed_ttl+distance' (например, 54+10). Рассмотрите
возможность использования traceroute для проверки точности
расстояния, затем сложите значения. Если начальный TTL нельзя
угадать, p0f выведет 'nnn+?', и вам нужно будет использовать
traceroute для оценки '?'.
Небольшое количество пользовательских инструментов будет
генерировать случайные TTL. В этих случаях определите
максимальный начальный TTL, а затем добавьте суффикс - к
значению, чтобы избежать путаницы.
olen - длина опций IPv4 или заголовков расширения IPv6. Обычно ноль для нормального трафика IPv4; всегда ноль для IPv6 из-за ограничений libpcap.
НОВЫЕ ПОДПИСИ: Копируйте вывод p0f дословно.
mss - максимальный размер сегмента, если он указан в параметрах TCP. Специальное значение '*' может использоваться для обозначения того, что MSS варьируется в зависимости от параметров сетевого соединения отправителя и не должно быть частью подписи. В этом случае MSS будет использоваться для угадывания типа сетевого подключения в соответствии с правилами [mtu].
НОВЫЕ ПОДПИСИ: Используйте '*' для любых распространенных ОС,
где MSS составляет около 1300 - 1500, если только вы не
знаете наверняка, что он фиксирован. Если значение выходит за
эти пределы, вы, вероятно, можете скопировать его дословно.
wsize - размер окна. Может быть выражен как фиксированное значение, но многие операционные системы устанавливают его как кратное MSS или MTU, или как кратное некоторому случайному целому числу. P0f автоматически определяет эти случаи и позволяет использовать нотацию, такую как 'mss4', 'mtu4' или '%8192'. Возможно также использование подстановочного символа ('*').
НОВЫЕ ПОДПИСИ: Копируйте вывод p0f дословно. Если наблюдаются
частые вариации, ищите очевидные паттерны. Если паттернов нет,
'*' является возможной альтернативой.
scale - масштабирующий коэффициент окна, если он указан в параметрах TCP. Фиксированное значение или '*' .
НОВЫЕ ПОДПИСИ: Копируйте дословно, если только значение не
меняется случайным образом. Многие системы переключаются между
2 или 3 масштабирующими коэффициентами, в которых случае лучше
иметь несколько строк 'sig', а не подстановочный символ.
olayout - разделенный запятыми макет и порядок параметров TCP, если таковые имеются. Это один из самых ценных сигналов для идентификации TCP. Поддерживаемые значения:
eol+n - явный конец параметров, за которым следуют n байтов
выравнивания
nop - параметр без операции
mss - максимальный размер сегмента
ws - масштабирование окна
sok - выборочное подтверждение разрешено
sack - выборочное подтверждение (не должно наблюдаться)
ts - временная метка
?n - неизвестный ID параметра n
НОВЫЕ ПОДПИСИ: Копируйте эту строку дословно.
quirks - разделенные запятыми свойства и особенности, наблюдаемые в заголовках IP или TCP:
df - установлен флаг "не фрагментировать" (вероятно, PMTUD);
игнорируется для IPv6
id+ - DF установлен, но IPID не нулевой; игнорируется для
IPv6
id- - DF не установлен, но IPID нулевой; игнорируется для
IPv6
ecn - поддержка явного уведомления о перегрузке
0+ - поле "должно быть нулевым" не нулевое; игнорируется
для IPv6
flow - ненулевой IPv6 идентификатор потока; игнорируется для
IPv4
seq- - номер последовательности равен нулю
ack+ - номер подтверждения не нулевой, но флаг ACK не
установлен
ack- - номер подтверждения нулевой, но флаг ACK установлен
uptr+ - указатель URG не нулевой, но флаг URG не установлен
urgf+ - используется флаг URG
pushf+ - используется флаг PUSH
ts1- - собственная временная метка указана как нулевая
ts2+ - ненулевая временная метка собеседника на начальном SYN
opt+ - завершающие ненулевые данные в сегменте параметров
exws - чрезмерный масштабирующий коэффициент окна (> 14)
bad - искаженные параметры TCP
Если подпись охватывает и IPv4, и IPv6 и содержит особенности, действительные только для одного из этих протоколов, такие особенности игнорируются для пакетов, использующих другой протокол. Например, любая комбинация 'df', 'id+' и 'id-' всегда соответствует любому пакету IPv6.
НОВЫЕ ПОДПИСИ: Копируйте буквально.
pclass - классификация размера полезной нагрузки: '0' для нулевого, '+' для ненулевого, '*' для любого. Пакеты, которые мы сейчас отпечатываем, обычно не имеют полезной нагрузки, но существуют некоторые пограничные случаи.
НОВЫЕ ПОДПИСИ: Копируйте буквально.
ПРИМЕЧАНИЕ: Модуль TCP допускает некоторую неточность, когда точное соответствие не найдено: особенности 'df' и 'id+' могут исчезать; могут появляться 'id-' или 'ecn'; а значения TTL могут меняться.
Для сбора новых подписей SYN ('запрос') просто подключитесь к отпечатываемой системе, и p0f предоставит вам необходимые данные. Для сбора подписей SYN+ACK ('ответ') вам следует использовать встроенную утилиту p0f-sendsyn, пока p0f работает в фоновом режиме; создавать их вручную не рекомендуется.
== HTTP-подписи == В начале раздела [http:request] должна появиться специальная директива, структурированная следующим образом:
ua_os = Linux,Windows,iOS=[iPad],iOS=[iPhone],Mac OS X,...
Этот список должен указывать имена операционных систем, которые следует искать в строке User-Agent, если строка в остальном считается честной. Этот вход не используется для отпечатывания, но помогает обнаружению NAT полезными способами.
Имена должны соответствовать именам, используемым в спецификаторах 'sig' в файле p0f.fp. Если конкретное имя, используемое в p0f, отличается от того, что обычно появляется в User-Agent, можно использовать синтаксис name=[строка] для определения любого количества псевдонимов.
Помимо этого, HTTP-подписи для запросов GET и HEAD имеют следующую структуру:
sig = ver:horder:habsent:expsw
ver - 0 для HTTP/1.0, 1 для HTTP/1.1 или '*' для любого.
НОВЫЕ ПОДПИСИ: Копируйте значение буквально, если у вас нет веской причины делать иначе.
horder - разделенный запямины упорядоченный список заголовков, которые должны появляться в соответствующем трафике. Подстроки для соответствия внутри каждого из этих заголовков можно указать, используя нотацию name=[значение].
Подпись будет соответствовать, даже если между ними появляются другие заголовки, при условии, что сам список соответствует в указанной последовательности.
Заголовки, которые обычно появляются в трафике, но могут исчезнуть (например, Accept-Language, если у пользователя нет определенных языков, или Referer, если нет ссылающегося сайта), должны иметь префикс '?', например "?Referer". P0f допустит их исчезновение, но не позволит им появляться в любом другом месте.
НОВЫЕ ПОДПИСИ: Просмотрите список и удалите любые заголовки, которые кажутся несущественными для отпечатываемого программного обеспечения, и пометьте временные знаком '?'. Удалите значения заголовков, которые не добавляют ничего к подписи или являются специфичными для запроса или пользователя. В частности, обратите внимание на Accept, Accept-Language и Accept-Charset, так как они highly специфичны для типа запроса и пользовательских настроек.
P0f автоматически удаляет некоторые заголовки, ставит префикс '?' перед другими и подавляет значение таких полей, как 'Referer' или 'Cookie', - но это не замена ручной проверки.
ПРИМЕЧАНИЕ: Серверные подписи могут отличаться в зависимости от запроса (HTTP/1.1 против 1.0, keep-alive против одноразового и т.д.) и от возвращаемого ресурса (например, CGI против статического контента). Поэкспериментируйте, просматривайте несколько URL, а также попробуйте curl и wget.
habsent - разделенный запямины список заголовков, которые не должны появляться в соответствующем трафике. Это особенно полезно для отмечания отсутствия стандартных заголовков (например, 'Host') или для различения иначе очень похожих подписей.
НОВЫЕ ПОДПИСИ: P0f автоматически подчеркнет отсутствие любых обычно присутствующих заголовков; другие записи могут быть добавлены при необходимости.
expsw - ожидаемая подстрока в 'User-Agent' или 'Server'. Это не используется для соответствия трафику, а лишь служит для обнаружения недобросовестного программного обеспечения. Если вы хотите явно сопоставить User-Agent, вам нужно сделать это в разделе 'horder', например:
User-Agent=[Firefox]
Любой из этих разделов, кроме 'ver', может быть пустым.
Существует множество особенностей на уровне протоколов, которые p0f мог бы обнаруживать - например, использование нестандартных переносов строк или отсутствие или добавление пробелов между именами полей заголовков и их значениями. Также есть некоторая информация, которую можно извлечь из ответов на OPTIONS или POST. Тем не менее, это не кажется стоящим усилий: протокол настолько многословен и реализован настолько произвольно, что мы получаем более чем достаточно информации с помощью простого отпечатка GET / HEAD.
== SMTP-подписи ==
*** ЕЩЕ НЕ РЕАЛИЗОВАНО ***
== FTP-подписи ==
*** ЕЩЕ НЕ РЕАЛИЗОВАНО ***
Помимо довольно простых измерений внутренних свойств одного TCP-сеанса, p0f также пытается сравнивать подписи между сеансами для обнаружения общего использования соединений на стороне клиента (NAT, HTTP-прокси) или балансировки нагрузки на стороне сервера.
Это делается в два этапа: первое значительное отклонение обычно вызывает запись "host change" (которая также может указывать на мультизагрузку, повторное использование адреса или другие разовые события); а устойчивая закономерность изменений позже вызывает уведомление "ip sharing".
Все эти сообщения сопровождаются набором кодов причин:
os_sig - обнаруженная сейчас ОС не совпадает с ранее обнаруженной ОС.
sig_diff - нет определенных данных обнаружения ОС, но характеристики на уровне протоколов резко изменились (например, другой макет опций TCP).
app_vs_os - обнаруженное приложение, работающее на хосте, предположительно не должно работать на операционной системе хоста.
x_known - подпись перешла от известной к неизвестной или наоборот.
Следующие дополнительные коды специфичны для TCP:
tstamp - временные метки TCP откатились или прыгнули вперед.
ttl - значения TTL изменились.
port - номер исходного порта уменьшился.
mtu - MTU системы изменился.
fuzzy - точность соответствия TCP-подписи изменилась.
Следующий код также выдается модулем HTTP:
via - данные явно включают Via / X-Forwarded-For.
us_vs_os - отпечаток ОС не совпадает со данными User-Agent, и значение User-Agent в остальном выглядит честным.
app_srv_lb - подписи серверного приложения меняются, что указывает на балансировку нагрузки.
date - дата, объявленная сервером, меняется непоследовательно.
Разные причины имеют разный вес, сбалансированный для поддержания высокой чувствительности p0f даже в очень гомогенных средах за NAT. Если вы столкнетесь с ложноположительными результатами или другими проблемами обнаружения в вашей среде, пожалуйста, дайте мне знать!
Вы должны рассматривать вывод этого инструмента как рекомендательный; отпечатывание можно обмануть при небольших усилиях, и его также можно обойти полностью (например, с помощью чрезмерной фрагментации IP или неправильных контрольных сумм TCP). Планируйте соответственно.
P0f должен быть разумно безопасен для работы в качестве демона. Тем не менее, пользователи unix должны использовать опцию -u для сброса привилегий и chroot() при непрерывном запуске инструмента. Это минимизирует последствия любых сбоев - а сбои в C просто имеют обыкновение случаться.
Чтобы этот шаг имел смысл, пользователь, от имени которого вы запускаете p0f, должен быть полностью непривилегированным и иметь пустую, доступную только для чтения домашнюю директорию. Например, вы можете сделать:
Пожалуйста, не размещайте сам бинарный файл p0f или какие-либо другие ценные активы в домашней директории этого пользователя; и определенно не используйте общие расположения, такие как / или /bin/, вместо подходящей домашней директории.
P0f, работающий в фоновом режиме, должен быть довольно устойчив к DoS, особенно по сравнению с любыми реальными TCP-службами, за которыми он будет наблюдать. Тем не менее, существует так много факторов, специфичных для конкретной среды, что вы всегда должны заранее проводить стресс-тестирование вашей конфигурации и наблюдать, как она себя ведет.
Помимо этого, поговорим о безопасности файловой системы. При использовании инструмента в режиме API (-s) прослушиваемый сокет всегда пересоздается с правами 666, чтобы приложения, работающие от имени других uid, могли запрашивать его по мере необходимости.
Если вы хотите сохранить конфиденциальность перехваченного трафика в многопользовательской системе,
убедитесь, что сокет создан в каталоге с более строгими
правами доступа; или измените API_MODE в config.h.
Режим файлов по умолчанию для бинарных журнальных данных (-o) — 600, поскольку другим пользователям,
вероятно, не нужен доступ к историческим данным; если вам нужно расшарить журналы,
вы можете заранее создать файл или изменить LOG_MODE в config.h.
Не собирайте p0f и не храните его исходный код, бинарные файлы, файлы конфигурации, журналы
или сокеты запросов в доступных для записи всеми пользователями местах, таких как /tmp (или любых
созданных в нем подкаталогах).
И, наконец, пожалуйста, не пытайтесь сделать p0f setuid или иным образом
наделить его привилегиями, более высокими, чем у вызывающего пользователя. Ни сам инструмент,
ни сторонние компоненты, от которых он зависит, не предназначены для того, чтобы противостоять
нечестным вызывающим с низкими привилегиями. Если вы используете /etc/sudoers для перечисления p0f
как единственной программы, которую пользователь X может запускать от имени root, этот пользователь, вероятно,
сможет скомпрометировать вашу систему. То же самое касается и многих других применений sudo.
Вот некоторые известные проблемы, с которыми вы можете столкнуться:
== Общие ==
1) Режимы экспериментальной отпечатков (RST, ACK и др.), доступные в p0f v2, больше не поддерживаются в v3. Это связано с тем, что они оказались слишком малоинформативными. В результате вы больше не можете определять отпечатки на ответах "connection refused".
2) Запросы API или выполнение в режиме демона не поддерживаются при чтении автономных pcap-файлов. Хотя для этого могут быть некоторые пограничные случаи использования, автономные pcap-файлы используют гораздо более простой цикл обработки событий, и поэтому поддержка этих функций потребовала бы дополнительных усилий.
3) P0f должен наблюдать как минимум около 25 миллисекунд квалифицирующего трафика для оценки времени работы системы. Это означает, что если вы тестируете его через loopback или локальную сеть, вам, возможно, придется позволить ему увидеть более одного соединения.
Системы с чрезвычайно медленными часами временных меток могут требовать более длительных периодов сбора (до нескольких секунд); очень быстрые часы (более 1,5 кГц) полностью отклоняются, поскольку это запрещено RFC. Почти все ОС работают в диапазоне от 100 Гц до 1 кГц, что должно работать нормально.
4) Некоторые системы варьируют ответы SYN+ACK в зависимости от содержимого начального SYN,
иногда удаляя TCP-опции, не поддерживаемые другой стороной.
К сожалению, нет простого способа это учесть, поэтому может потребоваться несколько отпечатков SYN+ACK
для одной системы. Прилагаемая утилита p0f-sendsyn помогает с их сбором.
Еще одним следствием этого является то, что вы иногда будете видеть время работы сервера только если в вашей собственной системе включены временные метки RFC1323. Linux делает это с версии 2.2; в Windows вам понадобится версия 7 или новее. Время работа клиентов не затрагивается.
== Портирование на Windows ==
1) API-сокеты не работают в Windows. Это связано с ограничением winpcap;
подробности см. в live_event_loop(...) в p0f.c.
2) Песочница chroot() (-u) в Windows не обеспечивает реальной безопасности.
Это связано с ограничениями cygwin.
3) Утилита p0f-sendsyn не работает из-за ограниченных возможностей
необработанных сокетов Windows (это должно быть относительно легко исправить, если найдутся
заинтересованные пользователи).
P0f стал возможен благодаря вкладу нескольких хороших людей, включая:
Phil Ames Jannich Brendle Matthew Dempsky Jason DePriest Dalibor Dukic Mark Martinec Damien Miller Josh Newton Nibbler Bernhard Rabe Chris John Riley Sebastian Roschke Peter Valchev Jeff Weisberg Anthony Howe Tomoyuki Murakami Michael Petch
Если вы хотите помочь, самый простой способ сделать это — просто собирать новые отпечатки, особенно с менее популярных или старых платформ (серверы, сетевое оборудование, портативные / встроенные / специализированные ОС и т.д.).
Проблемы? Предложения? Жалобы? Комплименты? Вы можете связаться с автором по адресу lcamtuf@coredump.cx. Автор очень одинок и ценит ваши письма.