В этом документе рассказывается, как контроллер правил для устройств (DPC) регистрирует сетевую активность. Ниже рассказывается, как добавить ведение сетевого журнала в контроллер политики.
Обзор
Ведение журнала сетевой активности помогает компаниям обнаруживать и отслеживать распространение вредоносного ПО на устройствах. Контроллер может вызывать Logging API для ведения сетевого журнала, чтобы сообщать о TCP-подключениях и DNS-запросах, поступающих от системных сетевых вызовов.
Обычно DPC передает журналы на сервер, чтобы их мог посмотреть системный администратор. Вы можете продолжить обработку журналов на сервере или локально на устройстве. Например, вы можете настроить черные списки DNS, чтобы обнаруживать подозрительные действия и оповещать о них системных администраторов.
Доступность
Ведение сетевого журнала поддерживается в Android 8 и более поздних версиях для владельца устройства. Если правило включено, собираются данные о сетевой активности устройства. Кроме того, она поддерживается в Android 12 и более поздних версиях для владельца управляемого профиля и делегированного приложения с DELEGATION_NETWORK_LOGGING. Если владелец профиля включил ведение сетевого журнала, в него записываются только данные о сетевой активности рабочего профиля. Сведения о личном профиле не собираются.
Подробнее о связанных пользователях…
Журналы событий
Когда ведение сетевого журнала активно, Android записывает каждое событие из приложений, использующих системные сетевые библиотеки. В сетевых журналах регистрируются события двух типов:
- DNS-запросы
- Сетевые подключения
DNS-запросы
В сетевом журнале регистрируются события, связанные с DNS-запросами, которые являются частью системных сетевых запросов. В журналах фиксируется каждый DNS-запрос, который преобразует имя хоста в IP-адрес. Другие вспомогательные DNS-запросы, например обнаружение сервера доменных имен, не записываются.
API для ведения журнала сетевой активности представляют каждый DNS-запрос как экземпляр DnsEvent. В таблице 1 описаны поля и типичные значения, которые записываются в DnsEvent.
Таблица 1. Поля событий DNS
| Данные | Пример | Описание |
|---|---|---|
| Имя хоста | host.example.com | Имя хоста, отправленное в DNS-запросе. |
| IP-адреса | 203.0.113.9, 198.51.100.25 | Список адресов IPv4 или IPv6, которые DNS-запрос разрешил для имени хоста. Чтобы размер журнала не был слишком большим, в результатах могут быть указаны не все IP-адреса. Количество адресов приведено в следующей строке. |
| Количество адресов | 4 | Количество IP-адресов, возвращенных в результате разрешения DNS-запроса. Это позволит вам узнать, являются ли зарегистрированные IP-адреса подмножеством результатов. Значение 0 (ноль) означает, что имя хоста не было преобразовано в IP-адрес. |
| Название пакета | com.android.chrome | Название пакета приложения, которое выполнило DNS-запрос. |
| Временная метка | 1506297600000 | Временная метка, указывающая, когда был выполнен DNS-запрос. Значение представляет собой интервал в миллисекундах между DNS-запросом и полуночью 1 января 1970 г. по всемирному координированному времени. |
| ID | 25 | Числовой идентификатор, который монотонно увеличивается. Доступно в Android 9.0 (уровень API 28) или более поздней версии. |
Хотя DNS-запросы могут помочь администраторам отслеживать сетевые подключения, ведение сетевого журнала не является решением общего назначения для записи DNS. Вот некоторые задачи DNS, которые может выполнять приложение и которые не регистрируются:
- Прямое взаимодействие с сервером доменных имен DNS.
- Вызов библиотеки Java DNS для выполнения DNS-запросов.
- Подключение к фиксированному IP-адресу без DNS-запроса.
Сетевые подключения
В сетевом журнале регистрируется событие для каждой попытки подключения, которая является частью системного сетевого запроса. В журналах регистрируются успешные и неудачные TCP-подключения. Передачи по протоколу UDP не записываются.
API для ведения журналов сетевой активности представляют каждое подключение как экземпляр ConnectEvent. В таблице 2 описаны поля и типичные значения, записанные в ConnectEvent.
Таблица 2. Подключить поля событий
| Данные | Пример | Описание |
|---|---|---|
| IP-адреса | 2001:db8::2f:abc:0 | IP-адрес, к которому подключилось устройство. Это может быть адрес IPv4 или IPv6. |
| Порт | 80 | Номер TCP-порта, к которому подключилось устройство. |
| Название пакета | com.android.chrome | Название пакета подключенного приложения. |
| Временная метка | 1506297600000 | Временная метка, указывающая, когда было установлено сетевое подключение. Значение – это интервал в миллисекундах между подключением и полуночью 1 января 1970 года по всемирному координированному времени. |
| ID | 26 | Числовой идентификатор, который монотонно увеличивается. Доступно в Android 9.0 (уровень API 28) или более поздней версии. |
В сетевом журнале регистрируется событие, когда приложение вызывает стандартные сетевые библиотеки, например встроенные API Android или популярные сторонние библиотеки, чтобы подключиться к хосту. Приложения, которые отправляют системные вызовы напрямую, не регистрируются. Помните, что UDP-трафик не регистрируется, поэтому в журналах могут отсутствовать некоторые приложения для потоковой передачи мультимедиа, обмена сообщениями и игр.
Информирование пользователей
Система предупреждает пользователей устройств о том, что ведется журнал сетевой активности. Пользователи увидят в интерфейсе следующие предупреждения:
- Раздел в диалоговом окне Диспетчер устройств, в котором объясняется, что контроллер политики устройств отслеживает сетевой трафик. Пользователи видят диалоговое окно, когда нажимают на ярлык с информацией об управляемом устройстве в быстрых настройках.
- Системное уведомление, которое можно закрыть. Оно показывается пользователю, который только начинает работать с сетевым журналом. Если нажать на уведомление, откроется диалоговое окно Мониторинг устройства с дополнительными пояснениями в разделе мониторинга сети. Уведомление исчезнет, когда контроллер политики отключит ведение сетевого журнала.
Как добавить ведение сетевого журнала в контроллер политики
Чтобы помочь системным администраторам анализировать сетевые журналы, контроллер политики устройств должен выполнять следующие задачи:
- Включите или отключите ведение сетевого журнала.
- Получать записанные журналы, когда будет готов новый пакет.
- Отправлять полезные данные из журналов на сервер.
Требования
Ведение сетевого журнала доступно в Android 8.0 (уровень API 26) или более поздней версии для владельца устройства и в Android 12 (уровень API 31) или более поздней версии для владельца управляемого профиля. Перед регистрацией сетевой активности контроллер политики устройств должен проверить, является ли он владельцем устройства или владельцем управляемого профиля. Если владелец профиля разрешил это, в сетевые журналы владельца устройства с рабочим профилем не включается сетевая активность в личном профиле.
Включить ведение сетевого журнала
Чтобы начать запись сетевой активности, вызовите метод setNetworkLoggingEnabled() класса DevicePolicyManager и передайте true в качестве аргумента enabled. Чтобы проверить, регистрируется ли сетевая активность, контроллер политики устройств может вызвать метод isNetworkLoggingEnabled().
После того как контроллер политики устройств включит ведение сетевого журнала, может пройти некоторое время, прежде чем будет готов первый пакет журналов. Рекомендуем добавить в пользовательский интерфейс информацию о сроках доставки для системных администраторов.
Чтобы остановить запись сетевой активности, вызовите setNetworkLoggingEnabled() и передайте false. Когда системный администратор отключает ведение сетевого журнала, система удаляет все собранные и неотправленные журналы.
Извлечь журналы
Контроллер политики устройств может получать журналы пакетами. API сетевых журналов не предоставляют произвольный доступ к отдельным записям. Когда доступен новый пакет журналов, подкласс DeviceAdminReceiver вашего контроллера получает обратный вызов onNetworkLogsAvailable(). Обратный вызов включает токен пакета, который контроллер может использовать для получения журналов. Контроллер политики устройств вызывает метод DevicePolicyManager retrieveNetworkLogs(), чтобы получить список сетевых событий.
В примере ниже показано, как получить журналы в подклассе DeviceAdminReceiver:
Kotlin
fun onNetworkLogsAvailable( context: Context, intent: Intent, batchToken: Long, networkLogsCount: Int) { val dpm = getManager(context) var logs: List<NetworkEvent>? = null // Fetch the batch of logs with the batch token from the callback's arguments. try { logs = dpm.retrieveNetworkLogs(getWho(context), batchToken) } catch (e: SecurityException) { // Perhaps an unaffiliated user - handle the exception ... } // Process any logs ... }
Java
public void onNetworkLogsAvailable( Context context, Intent intent, long batchToken, int networkLogsCount) { DevicePolicyManager dpm = getManager(context); List<NetworkEvent> logs = null; // Fetch the next batch of logs using the callback's batch token argument. try { logs = dpm.retrieveNetworkLogs(getWho(context), batchToken); } catch (SecurityException e) { // Perhaps an unaffiliated user - handle the exception ... } // Process any logs ... }
Контроллер должен сразу же извлечь журналы, поскольку система удаляет их, чтобы освободить место для новых пакетов. Рекомендуем хранить локальную копию журналов до тех пор, пока вы не убедитесь, что контроллер политики устройств обработал их без проблем.
Обработка журналов
Пакет журналов обычно содержит сочетание экземпляров DnsEvent и ConnectEvent. Подробнее о полях данных DNS-запросов и сетевых подключений… События упорядочены по времени, и в каждом пакете содержится не более 1200 событий.
После вызова для получения журналов убедитесь, что возвращаемое значение не равно null. Значение может быть равно null, если:
- Пакет, представленный токеном, больше не доступен. Ваш поставщик услуг по защите данных не сможет получить этот пакет и должен будет дождаться следующего.
- Системный администратор отключил ведение сетевого журнала.
В примере ниже показано, как DPC может извлекать разрешенные имена хостов DNS. Вам нужны более сложные инструменты обработки данных и создания отчетов.
Kotlin
// Here, logs might be null. We can't fix because either the token doesn't match // the current batch or network logging was deactivated. // Confirm with isNetworkLoggingEnabled(). logs?.forEach { // For this example, report the DNS hosts and discard all other data. // Because we use the event ID, this example requires API level 28. if (it is DnsEvent) { reportDnsHostToServer(it.hostname, it.getTimestamp(), it.getId()) } }
Java
if (logs == null) { // Abandon processing because either the token doesn't match the current batch // or network logging was deactivated - confirm with isNetworkLoggingEnabled(). return; } for (NetworkEvent event : logs) { // For this example, report the DNS hosts and discard all other data. // This example requires API level 28 because we use the event ID. if (event instanceof DnsEvent) { reportDnsHostToServer( ((DnsEvent) event).getHostname(), event.getTimestamp(), event.getId()); } }
В предыдущем примере также показано, как получить числовой идентификатор для событий, включенных в Android 9.0 (уровень API 28) или более поздней версии. Поскольку идентификатор монотонно увеличивается для каждого события, вы можете помочь системным администраторам обнаружить пробелы в журналах. Система сбрасывает идентификатор при каждом включении ведения журнала контроллером политики устройств или при перезапуске устройства.
Контроллер политики устройств может отправлять всю коллекцию на сервер, или вы можете отфильтровать события на устройстве. Например, вы можете предложить администраторам отчеты по белому списку.
Разработка и тестирование
При разработке и тестировании может потребоваться получать обратные вызовы onNetworkLogsAvailable() без просмотра сотен веб-страниц. В Android 9.0 (уровень API 28) или более поздней версии можно сделать несколько тестовых сетевых запросов и принудительно отправить обратный вызов о доступности журналов. Выполните в терминале следующую команду Android Debug Bridge (adb):
adb shell dpm force-network-logs
Система ограничивает частоту использования инструмента и сообщает о любом намеренном замедлении в выводе терминала. Если журналов нет, контроллер политики не получит обратный вызов.