AWS: VPC Flow Logs  -  знайомство та аналітика з CloudWatch Logs Insights
Tags: security, ukraine, aws, monitoring
Published: 2022-10-06 06:10:17

---
title: AWS: VPC Flow Logs  -  знайомство та аналітика з CloudWatch Logs Insights
published: true
date: 2022-06-10 06:34:11 UTC
tags: security,ukraine,aws,monitoring
canonical_url: https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/
---

### AWS: VPC Flow Logs  -  знайомство та аналітика з CloudWatch Logs Insights

![](https://cdn-images-1.medium.com/max/1024/1*Qy7g2pY9eLZtXFYPQ_2SmQ.png)

AWS VPC Flow Logs -  сервіс Amazon, який дозволяє логувати інформацію про трафік між мережевими інтерфейсами у AWS VPC. Далі, ці логи можуть бути передані у AWS CloudWatch Logs для подальшого аналізу, при цьому логування трафіку ніяк не впливає на швидкість роботи мережі.

Коротко розглянемо основні поняття, доступні опції та налаштуємо Flow Logs для VPC з передачею даних для аналізу у CloduWatch Logs.

### Зміст

- [Опис VPC Flow Logs](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#%D0%9E%D0%BF%D0%B8%D1%81_VPC_Flow_Logs)
- [Use Cases — приклади використання](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#Use_Cases_-_%D0%BF%D1%80%D0%B8%D0%BA%D0%BB%D0%B0%D0%B4%D0%B8_%D0%B2%D0%B8%D0%BA%D0%BE%D1%80%D0%B8%D1%81%D1%82%D0%B0%D0%BD%D0%BD%D1%8F)
- [Flow Log record — поля](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#Flow_Log_record_-_%D0%BF%D0%BE%D0%BB%D1%8F)
- [Обмеження VPC Flow Logs](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#%D0%9E%D0%B1%D0%BC%D0%B5%D0%B6%D0%B5%D0%BD%D0%BD%D1%8F_VPC_Flow_Logs)
- [Створення VPC Flow Log](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#%D0%A1%D1%82%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F_VPC_Flow_Log)
- [CloudWatch Logs Log Group](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#CloudWatch_Logs_Log_Group)
- [Створення IAM Policy та IAM Role](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#%D0%A1%D1%82%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F_IAM_Policy_%D1%82%D0%B0_IAM_Role)
- [VPC — включення Flow Logs](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#VPC_-_%D0%B2%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%BD%D1%8F_Flow_Logs)
- [CloudWatch Logs Insights](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#CloudWatch_Logs_Insights)
- [VPC Flow Log — Custom format](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#VPC_Flow_Log_-_Custom_format)
- [Flow Log Custom format та CloudWatch Logs Insights](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#Flow_Log_Custom_format_%D1%82%D0%B0_CloudWatch_Logs_Insights)
- [Приклади Logs Insights](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#%D0%9F%D1%80%D0%B8%D0%BA%D0%BB%D0%B0%D0%B4%D0%B8_Logs_Insights)
- [Посилання по темі](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#%D0%9F%D0%BE%D1%81%D0%B8%D0%BB%D0%B0%D0%BD%D0%BD%D1%8F_%D0%BF%D0%BE_%D1%82%D0%B5%D0%BC%D1%96)
- [VPC Flow Logs](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#VPC_Flow_Logs)
- [CloudWatch Logs](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/#CloudWatch_Logs)

### Опис VPC Flow Logs

Логи можуть бути включені для цілої VPC, підмережі, або конкретного інтерфейсу. При включенні для всієї VPC — логування буде включено для всіх мережевих інтерфейсів цієї мережі.

Сервіси, для яких можна використовувати Flow Logs:

- Elastic Load Balancing
- Amazon RDS
- Amazon ElastiCache
- Amazon Redshift
- Amazon WorkSpaces
- NAT gateways
- Transit gateways

Дані будуть записані у вигляді [_flow log records_](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html#flow-log-records), які представляють собою текстовий запис з заданними полями.

#### Use Cases — приклади використання

Що можна відстежити за допомогою Flow logs?

- спрацьовування правил SecuirtyGroup/Network Access List — заблоковані запити будуть відмічені як REJECTED
- те, заради чого логі впроваджуємо ми — отримати картину трафіку між VPC та сервісами, щоб зрозуміти хто найбільше трафіку споживає, де і скільки cross-AZ трафіку тощо
- моніторинг віддалених логінів у систему — стежити за портами 22 (SSH), 3389 (RDP)
- відстеження сканування портів

#### Flow Log record — поля

Кожен запис у логах містить дані про IP-трафіку, отриманому за _aggregation interval_ і є рядком з полями, розділені пробілами, де кожне поле містить інформацію про передачу даних, наприклад — Source IP, Destination IP і протокол.

За замовчуванням використовується такий формат:

```
${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}
```

Див. таблицю _Available fields_ в [документації](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html#flow-log-records) — все у колонці Version 2 включено у default format. Інші версії доступні у Custom Format.

При створенні Flow Logs, ми можемо використовувати дефолтний формат або створити свій — розглянемо його трохи нижче:

![](https://cdn-images-1.medium.com/max/606/0*K0fQBDWyMxXbtZxB.png)

#### Обмеження VPC Flow Logs

- не можна використовувати з інстансами EC2-Classic
- не можна створити логі для VPC-пірингів, якщо вони ведуть до VPC в іншому акаунті
- після створення лога — не можна змінити його конфігурацію чи формат записів
- якщо в інтерфейсу кілька IPv4-адрес, і траїфк відправляється до одного з secondary-адрес, то в полі `dstaddr` буде відображено primary-адресу; щоб отримати оригінальну адресу — використовуйте поле `pkt-dstaddr`
- якщо трафік відправлений з або на мережевий інтерфейс, поля `srcaddr` та `dstaddr` будуть містити його primary private IPv4 адресу; щоб отримати оригінальну адресу — використовуйте поля `pkt-dstaddr` та `pkt-dstaddr`

Також, враховуйте, що:

- не логуються записи до DNS Amazon, але пишуться, якщо використовується свій DNS
- не логується трафік на та з адреси 169.254.169.254 для отримання [метаданих EC2-інстансу](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)
- не логується трафік між мережевим інтерфейсом EC2 та інтерфейсом AWS Network Load Balancer

Див. всі обмеження на [Flow log limitations](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html#flow-logs-limitations).

### Створення VPC Flow Log

Для створення нам потрібно вказати:

- ресурс, логи якого будемо писати — VPC, підмережа або конкретний мережевий інтерфейс
- тип трафіку, який логуємо (_accepted traffic, rejected traffic_ або _all traffic_)
- і куди писатимемо дані — в кошик, або CloudWatch Logs

Поки подивимося, що вийде з CloudWatch Logs, а наступного разу — спробуємо візуалізувати у [Kibana](https://rtfm.co.ua/elastic-stack-obzor-i-ustanovka-elk-na-ubuntu/) або [Grafana](https://rtfm.co.ua/category/monitoring-ru/grafana-ru/).

#### CloudWatch Logs Log Group

Створюємо Log Group:

![](https://cdn-images-1.medium.com/max/1024/0*uH1M2aMTmdu5jKvv.png)

![](https://cdn-images-1.medium.com/max/831/0*t1iIY3epQhz6dFaO.png)

#### Створення IAM Policy та IAM Role

Для того, щоб сервіс Flow Logs міг писати в наш CloudWatch — налаштовуємо йому права доступу.

Переходимо в AWS IAM, створюємо IAM Policy та IAM Role.

Починаємо з Policy:

![](https://cdn-images-1.medium.com/max/1024/0*i-gFPuox7owNpKNL.png)

Додаємо саму політику:

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}
```

Зберігаємо:

![](https://cdn-images-1.medium.com/max/1024/0*ka82UAL0PGEyJpiU.png)

Створюємо роль.

Переходимо в IAM Roles, створюємо нову, вибираємо тип EC2:

![](https://cdn-images-1.medium.com/max/1024/0*tjWUbm_u9vdKQtVU.png)

Знаходимо створену вище політику, підключаємо:

![](https://cdn-images-1.medium.com/max/1024/0*tC9Vz18WGn-t_thJ.png)

Задаємо ім’я, зберігаємо:

![](https://cdn-images-1.medium.com/max/1024/0*-c2avCbGohqsUXyG.png)

Переходимо до _Role Trust relationshitp_ (див. [AWS: IAM AssumeRole — описание, примеры](https://rtfm.co.ua/aws-iam-assumerole-opisanie-primery/)), редагуємо — змінюємо значення поля `Service` на _vpc-flow-logs.amazonaws.com_:

![](https://cdn-images-1.medium.com/max/1024/0*sZhNb4Bv1eqz-MV-.jpg)

Вказуємо:

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "vpc-flow-logs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

Зберігаємо:

![](https://cdn-images-1.medium.com/max/1024/0*d75K9djLJNtVhCBm.png)

#### VPC — включення Flow Logs

І нарешті переходимо до включення логів — знаходимо потрібну VPC, клікаємо _Flow Logs > Create_:

![](https://cdn-images-1.medium.com/max/1024/0*8BQ-PFDVYDdhic22.png)

Задаємо ім’я, _Filter_, _Interval_:

![](https://cdn-images-1.medium.com/max/822/0*1rX-SrH432VbqRCj.png)

У _Destination_ вибираємо CloudWatch Logs, вказуємо створені раніше Log Group та IAM Role:

![](https://cdn-images-1.medium.com/max/823/0*ySSAsIrjgtCQBehJ.png)

Format — залишаємо _Default_.

Перевіряємо Status:

![](https://cdn-images-1.medium.com/max/770/0*KUQLYDkta_ISunWU.png)

І за декілька хвилин — дані пішли:

![](https://cdn-images-1.medium.com/max/1024/0*OobZSpjR15qi3f5Y.png)

У лог-групі з’явився перший стрим з ім’ям Elastic Network Interface, з якого знімаються дані:

![](https://cdn-images-1.medium.com/max/1024/0*Jwal_0TCGCfw_hRB.jpg)

### CloudWatch Logs Insights

Швидко подивимося, що нам доступно в Logs Insights.

Клікаєм _Queries_ для отримання підказки щодо синтаксису запитів:

![](https://cdn-images-1.medium.com/max/1024/0*dE2jnj1zTxkF9Rvs.png)

Наприклад, отримаємо топ-15 хостів за кількістю пакетів:

![](https://cdn-images-1.medium.com/max/1024/0*aXXcjLK-Tgx4V3b4.png)

Або за обсягом надісланих даних:

```
stats sum(bytes) as BytesSent by srcAddr, dstAddr
| sort BytesSent desc
```

![](https://cdn-images-1.medium.com/max/1024/0*qadBQa3ciH4gZgvW.png)

Окей, а що з іншими форматами?

Наприклад, хочеться побачити напрямок запиту (egress/ingress) та значення поля `pkt-dstaddr`.

### VPC Flow Log — Custom format

[Див. приклади на сторінціFlow log record examples](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html).

Використовуємо такий формат:

```
region vpc-id az-id subnet-id instance-id interface-id flow-direction srcaddr dstaddr srcport dstport pkt-srcaddr pkt-dstaddr pkt-src-aws-service pkt-dst-aws-service traffic-path packets bytes action
```

У CloudWatch Logs створюємо новий Log group, назвемо його _bttrm-eks-dev-1–21-vpc-fl-custom_, не забуваємо про retention, щоб дані не лежали вічно (ну і взагалі не забуваємо, що CloudWatch не самий дешевий сервіс):

![](https://cdn-images-1.medium.com/max/1024/0*zSjvWudBX9SKZQks.png)

Повертаємось до VPC, знаходимо потрібну мережу, створюємо новий Flow Log, назвемо його _bttrm-eks-dev-1–21-vpc-fl-custom_:

![](https://cdn-images-1.medium.com/max/694/0*5mbMnoVukofqH9Gb.png)

Вибираємо Custom Format та поля, які хочемо записувати. При цьому враховуйте, що порядок полів у логах буде такий, який ви використовуєте під час вибору полів.

Тобто, якщо першим клікнути на “_region_” — то й у логах він буде йти першим:

![](https://cdn-images-1.medium.com/max/733/0*g0fb9ce23ol_SBzC.png)

Виходить так:

```
${region} ${vpc-id} ${az-id} ${subnet-id} ${instance-id} ${interface-id} ${flow-direction} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${pkt-srcaddr} ${pkt-dstaddr} ${pkt-src-aws-service} ${pkt-dst-aws-service} ${traffic-path} ${packets} ${bytes} ${action}
```

![](https://cdn-images-1.medium.com/max/733/0*6t7qPKuZF_mfxdoV.png)

#### Flow Log Custom format та CloudWatch Logs Insights

Але якщо ми тепер ми зайдемо в Logs Insights, і спробуємо будь-який із попередніх запитів — отримаємо зовсім не ті поля, які хотіли:

![](https://cdn-images-1.medium.com/max/1024/0*1jdmrjkjskCPjL3r.png)

Тобто, дані бачимо, але як розбити поля по колонках?

Ми навряд чи будемо щільно користуватися CloudWatch Logs, швидше за все в продакшені дані підуть у S3 і потім в ELK (logz.io), тому докладно тут зупинятись не буду, проте принцип роботи подивимося.

CloudWatch Logs за замовчуванням створює кілька мета-полів, які ми можемо використовувати у запитах:

- `@message`: "сирі" дані - все повідомлення в text
- `@timestamp`: час події
- `@logStream`: ім'я стриму

Для Custom format, щоб сформувати поля, використовуємо команду [`parse`](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html), якою передаємо поле `@message` з усім змістом, а потім парсимо його по полях, які розділені пробілами:

```
parse @message "* * * * * * * * * * * * * * * * * * *" 
| as region, vpc_id, az_id, subnet_id, instance_id, interface_id, 
| flow_direction, srcaddr, dstaddr, srcport, dstport, 
| pkt_srcaddr, pkt_dstaddr, pkt_src_aws_service, pkt_dst_aws_service, 
| traffic_path, packets, bytes, action 
| sort start desc
```

Тут кількість “`*`" в `@message` має бути рівним кількості імен полів, які ми задаємо - ${vpc-id} і т.д.

Крім того, імена полів не повинні містити тире. Тобто, оригінальне ім’я поля `${vpc-id}` для виведення імені колонки вказуємо як `vpc_id` (або `vpcID` - кому який формат більше подобається).

Перевіряємо:

![](https://cdn-images-1.medium.com/max/1024/0*CrZydTbJnU2Motm7.png)

Інша справа!

Окрім parse, ми можемо використовувати такі команди, як `filter`, `display`, `stats`. Див. усі в [CloudWatch Logs Insights query syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html).

#### Приклади Logs Insights

Ну і спробуємо щось зобразити, наприклад — отримати всі заблоковані запити SecuirtyGroup/Network Access List — вони будуть відзначені як _REJECTED_.

До нашого запиту:

```
parse @message "* * * * * * * * * * * * * * * * * * * * * *" 
| as start, end, region, vpc_id, az_id, subnet_id, instance_id, interface_id, 
| flow_direction, srcaddr, dstaddr, srcport, dstport, protocol, 
| pkt_srcaddr, pkt_dstaddr, pkt_src_aws_service, pkt_dst_aws_service, 
| traffic_path, packets, bytes, action
```

Додамо:

- `filter action="REJECT"`
- `stats count(action) as redjects by srcaddr`
- `sort redjects desc`

Тут:

- фільтруємо по дії над пакетом — вибираємо все _REJECTED_
- рахуємо кількість записів по полю action, вибираючи за IP-адресою джерела, виводимо в колонці _redjects_
- і сортуємо по колонці _redjects_

Тобто повністю запит зараз буде:

```
parse @message "* * * * * * * * * * * * * * * * * * *" 
| as region, vpc_id, az_id, subnet_id, instance_id, interface_id, 
| flow_direction, srcaddr, dstaddr, srcport, dstport, 
| pkt_srcaddr, pkt_dstaddr, pkt_src_aws_service, pkt_dst_aws_service, 
| traffic_path, packets, bytes, action 
| filter action="REJECT" 
| stats count(action) as redjects by srcaddr 
| sort redjects desc
```

Отримуємо:

![](https://cdn-images-1.medium.com/max/469/0*QSFWdpwG_3ktDcfl.png)

Ми також можемо використовувати негативні фільтри та комбінувати умови фільтра з операторами `and/or`.

Наприклад, прибрати з виводу всі IP, що починаються з _162.142.125_ — додаємо `filter (srcaddr not like "162.142.125.")`:

```
...
| filter action="REJECT"
| filter (srcaddr not like "162.142.125.")
| stats count(action) as redjects by srcaddr
| sort redjects desc
```

Див. [Sample queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html).

І додамо фільтр на вибірку тільки вхідних запитів — `flow_direction == _ingress_`:

```
...
| filter action="REJECT"
| filter (srcaddr not like "162.142.125.") and (flow_direction like "ingress")
| stats count(action) as redjects by flow_direction, srcaddr, dstaddr, pkt_srcaddr, pkt_dstaddr
| sort redjects desc
```

![](https://cdn-images-1.medium.com/max/926/0*fyUYMB0_h4kdPnj8.png)

Отримуємо топ відкинутих запитів — спрацювало правило SecurityGroup або VPC Network Access List.

І дивимося — що за IP у `dstaddr` – кому йшов пакет, який був заблокований?

Переходимо в _EC2 > Network Interfaces_, шукаємо Private IP:

![](https://cdn-images-1.medium.com/max/796/0*064PifzAZzB5Lt2m.png)

Знаходимо “_Elastic IP address owner_”:

![](https://cdn-images-1.medium.com/max/204/0*wP_LfVxVMBjX-qtV.png)

LoadBalancer.

Якщо адреса не знаходиться в AWS — можливо, це якийсь [ендпоінт у Kubernetes](https://rtfm.co.ua/kubernetes-chto-takoe-endpoints/) — шукаємо наприклад так:

```
$ kubectl get endpoints — all-namespaces | grep 10.1.55.140
dev-ios-check-translation-ns ios-check-translation-backend-svc 10.1.55.140:3000 58d
dev-ios-check-translation-ns ios-check-translation-frontend-svc 10.1.55.140:80 58d
```

Загалом на це все.

У наступній частині — налаштуємо збір логів в AWS S3, потім будемо їх звідти збирати в ELK, і там спробуємо зробити візуалізацію та алерти.

### Посилання по темі

#### VPC Flow Logs

- [Collect Amazon VPC flow logs with Elastic Agent](https://docs.elastic.co/en/integrations/aws/vpcflow)
- [Flow log record examples](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html)

#### CloudWatch Logs

- [AWS Security Logging Fundamentals — VPC Flow Logs](https://panther.com/cyber-explained/aws-security-logging-vpc-flow-logs/)
- [Analyze Query And Visualize AWS Cloudwatch Logs Using Logs Insight](https://dheeraj3choudhary.com/analyze-query-and-visualize-aws-cloudwatch-logs-using-logs-insight)
- [How to Visualize and Refine Your Network’s Security by Adding Security Group IDs to Your VPC Flow Logs](https://aws.amazon.com/blogs/security/how-to-visualize-and-refine-your-networks-security-by-adding-security-group-ids-to-your-vpc-flow-logs/)
- [Visualizing log data in graphs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Insights-Visualizing-Log-Data.html)
- [Analyze CloudWatch Logs like a pro](https://marbot.io/blog/analyze-cloudwatch-logs-like-a-pro.html)
- [Filter, Parse & Group Log Data in AWS CloudWatch Logs Insights](https://harishkm.in/2020/06/25/filter-parse-group-log-data-in-aws-cloudwatch-logs-insights/)
- [How can I analyze custom VPC Flow Logs using CloudWatch Logs Insights?](https://aws.amazon.com/ru/premiumsupport/knowledge-center/cloudwatch-vpc-flow-logs/)
- [How can I use CloudWatch Logs Insights queries with my VPC flow log?](https://aws.amazon.com/ru/premiumsupport/knowledge-center/vpc-flow-logs-and-cloudwatch-logs-insights/)
- [CloudWatch Logs Insights query syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)
- [Triaging Networking Issues Using AWS CloudWatch Logs Insights](https://www.cloudreach.com/en/technical-blog/networking-issues-cloudwatch-logs-insights/)

_Originally published at_ [_RTFM: Linux, DevOps, and system administration_](https://rtfm.co.ua/uk/aws-vpc-flow-logs-znajomstvo-ta-priklad-analitiki-z-cloudwatch-logs-insights/)_._