GCP - Logging Enum

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Основна інформація

Цей сервіс дозволяє користувачам зберігати, шукати, аналізувати, контролювати та сповіщати про лог-дані та події з GCP.

Cloud Logging повністю інтегрований з іншими службами GCP, надаючи централізований сховище для логів з усіх ваших ресурсів GCP. Він автоматично збирає логи з різних служб GCP, таких як App Engine, Compute Engine та Cloud Functions. Ви також можете використовувати Cloud Logging для додатків, що працюють на власних серверах або в інших хмарах, використовуючи агент або API Cloud Logging.

Основні функції:

  • Централізація даних логування: Агрегуйте дані логування з різних джерел, пропонуючи голістичний погляд на ваші додатки та інфраструктуру.

  • Управління логами в реальному часі: Потік логів в реальному часі для негайного аналізу та реагування.

  • Потужний аналіз даних: Використовуйте розширені можливості фільтрації та пошуку для швидкого просіювання великих обсягів даних логування.

  • Інтеграція з BigQuery: Експортуйте логи в BigQuery для детального аналізу та запитування.

  • Метрики на основі логів: Створюйте власні метрики на основі ваших даних логування для моніторингу та сповіщення.

Потік логів

По суті, стоки та метрики на основі логів визначають, де слід зберігати лог.

Конфігурації, підтримувані GCP Logging

Cloud Logging має високу налаштовуваність для відповідності різноманітним операційним потребам:

  1. Лог-ведра (Зберігання логів в мережі): Визначте відра в Cloud Logging для управління збереженням логів, надаючи контроль над тим, як довго зберігаються ваші записи логів.

  • За замовчуванням створюються відра _Default та _Required (одне логує те, що інше ні).

  • _Required є:

LOG_ID("cloudaudit.googleapis.com/activity") OR LOG_ID("externalaudit.googleapis.com/activity") OR LOG_ID("cloudaudit.googleapis.com/system_event") OR LOG_ID("externalaudit.googleapis.com/system_event") OR LOG_ID("cloudaudit.googleapis.com/access_transparency") OR LOG_ID("externalaudit.googleapis.com/access_transparency")
  • Період збереження даних налаштовується для кожного відра і повинен бути принаймні 1 день. Однак період збереження _Required становить 400 днів і не може бути змінений.

  • Зверніть увагу, що Лог-ведра не є видимими в Cloud Storage.

  1. Стоки логів (Маршрутизатор логів в мережі): Створіть стоки для експорту записів логів до різних місць призначення, таких як Pub/Sub, BigQuery або Cloud Storage на основі фільтра.

  • За замовчуванням створюються стоки для відер _Default та _Required:

_Required logging.googleapis.com/projects//locations/global/buckets/_Required LOG_ID("cloudaudit.googleapis.com/activity") OR LOG_ID("externalaudit.googleapis.com/activity") OR LOG_ID("cloudaudit.googleapis.com/system_event") OR LOG_ID("externalaudit.googleapis.com/system_event") OR LOG_ID("cloudaudit.googleapis.com/access_transparency") OR LOG_ID("externalaudit.googleapis.com/access_transparency") _Default logging.googleapis.com/projects//locations/global/buckets/_Default NOT LOG_ID("cloudaudit.googleapis.com/activity") AND NOT LOG_ID("externalaudit.googleapis.com/activity") AND NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND NOT LOG_ID("externalaudit.googleapis.com/system_event") AND NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND NOT LOG_ID("externalaudit.googleapis.com/access_transparency")

* **Фільтри виключень:** Можливо налаштувати **виключення для запобігання включенню конкретних записів логів**, що вводить економію витрат та зменшує непотрібний шум.
3. **Метрики на основі логів:** Налаштуйте **власні метрики** на основі вмісту логів, що дозволяє сповіщати та моніторити на основі даних логування.
4. **Перегляди логів:** Перегляди логів надають розширене та **деталізоване керування тим, хто має доступ** до логів у ваших відрах логів. 
* Cloud Logging **автоматично створює перегляд `_AllLogs` для кожного відра**, який показує всі логи. Cloud Logging також створює перегляд для відра `_Default` під назвою `_Default`. Перегляд `_Default` для відра `_Default` показує всі логи, за винятком логів аудиту доступу до даних. Перегляди `_AllLogs` та `_Default` не можна редагувати.

Можливо дозволити принципалу **використовувати лише певний перегляд логів** за допомогою політики IAM, подібно до:

<div data-gb-custom-block data-tag="code" data-overflow='wrap'>

```json
{
"bindings": [
{
"members": [
"user:username@gmail.com"
],
"role": "roles/logging.viewAccessor",
"condition": {
"title": "Bucket reader condition example",
"description": "Grants logging.viewAccessor role to user username@gmail.com for the VIEW_ID log view.",
"expression":
"resource.name == \"projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_NAME/views/VIEW_ID\""
}
}
],
"etag": "BwWd_6eERR4=",
"version": 3
}

Стандартні журнали

За замовчуванням операції Admin Write (також називають журналами аудиту дій адміністратора) логуються (записують метадані або інформацію про конфігурацію) і не можуть бути вимкнені.

Після цього користувач може увімкнути журнали аудиту доступу до даних, які включають Admin Read, Data Write та Data Write.

Більше інформації про кожен тип журналу можна знайти в документації: https://cloud.google.com/iam/docs/audit-logging

Проте слід зауважити, що це означає, що за замовчуванням дії GetIamPolicy та інші дії читання не логуються. Таким чином, за замовчуванням зловмисник, який намагається перерахувати середовище, не буде виявлений, якщо системний адміністратор не налаштував генерацію більше журналів.

Щоб увімкнути більше журналів у консолі, системний адміністратор повинен перейти за посиланням https://console.cloud.google.com/iam-admin/audit та увімкнути їх. Є 2 різні варіанти:

  • Стандартна конфігурація: Можливо створити стандартну конфігурацію та логувати всі журнали Admin Read та/або Data Read та/або Data Write та навіть додати виняткові принципали:

  • Вибір сервісів: Або просто виберіть сервіси, для яких ви хочете генерувати журнали, тип журналів та виняткового принципала для цього конкретного сервісу.

Також слід зауважити, що за замовчуванням генеруються лише ці журнали, оскільки генерація більше журналів збільшить витрати.

Перерахунок

Командний рядок gcloud є невід'ємною частиною екосистеми GCP, що дозволяє керувати вашими ресурсами та сервісами. Ось як ви можете використовувати gcloud для керування конфігураціями журналів та доступом до журналів.

# List buckets
gcloud logging buckets list
gcloud logging buckets describe <bucket-name> --location <location>

# List log entries: only logs that contain log entries are listed.
gcloud logging logs list

# Get log metrics
gcloud logging metrics list
gcloud logging metrics describe <metric-name>

# Get log sinks
gcloud logging sinks list
gcloud logging sinks describe <sink-name>

# Get log views
gcloud logging views list --bucket <bucket> --location global
gcloud logging views describe --bucket <bucket> --location global <view-id> # view-id is usually the same as the bucket name

# Get log links
gcloud logging links list --bucket _Default --location global
gcloud logging links describe <link-id> --bucket _Default --location global

Приклад перевірки журналів cloudresourcemanager (використовується для BF дозволів): https://console.cloud.google.com/logs/query;query=protoPayload.serviceName%3D%22cloudresourcemanager.googleapis.com%22;summaryFields=:false:32:beginning;cursorTimestamp=2024-01-20T00:07:14.482809Z;startTime=2024-01-01T11:12:26.062Z;endTime=2024-02-02T17:12:26.062Z?authuser=2&project=digital-bonfire-410512

Немає журналів testIamPermissions:

Післяексплуатаційний етап

pageGCP - Logging Post Exploitation

Наполегливість

pageGCP - Logging Persistence

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Last updated