mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-04-28 12:03:08 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-services/aws-ec2-
This commit is contained in:
Translator
@@ -4,192 +4,182 @@
|
||||
|
||||
## AWS Networking in a Nutshell
|
||||
|
||||
**VPC** містить **CIDR мережі** як 10.0.0.0/16 (з його **таблицею маршрутизації** та **мережевим ACL**).
|
||||
A **VPC** містить **network CIDR** наприклад 10.0.0.0/16 (з його **routing table** та **network ACL**).
|
||||
|
||||
Ця мережа VPC поділяється на **підмережі**, тому **підмережа** безпосередньо **пов'язана** з **VPC**, **таблицею маршрутизації** та **мережевим ACL**.
|
||||
Ця мережа VPC ділиться на **subnetworks**, тож **subnetwork** безпосередньо пов'язана з **VPC**, **routing table** та **network ACL**.
|
||||
|
||||
Потім **мережеві інтерфейси**, підключені до сервісів (як EC2 екземпляри), **підключені** до **підмереж** з **групами безпеки**.
|
||||
Потім, **Network Interface** підключені до сервісів (наприклад EC2 instances) **з’єднуються** з **subnetworks** з допомогою **security group(s)**.
|
||||
|
||||
Отже, **група безпеки** обмежить відкриті порти мережевих **інтерфейсів, що її використовують**, **незалежно від підмережі**. А **мережевий ACL** **обмежить** відкриті порти для **всіх мереж**.
|
||||
Отже, **security group** буде обмежувати відкриті порти мережевих **interfaces, що його використовують**, **незалежно від субмережі**. А **network ACL** буде **обмежувати** відкриті порти для **усієї мережі**.
|
||||
|
||||
Більше того, для **доступу до Інтернету** є кілька цікавих конфігурацій, які слід перевірити:
|
||||
Крім того, щоб мати **доступ до Інтернету**, є кілька цікавих налаштувань, які варто перевірити:
|
||||
|
||||
- **Підмережа** може **автоматично призначати публічні IPv4 адреси**
|
||||
- **Екземпляр**, створений у мережі, що **автоматично призначає IPv4 адреси, може отримати одну**
|
||||
- **Шлюз Інтернету** потрібно **підключити** до **VPC**
|
||||
- Ви також можете використовувати **Шлюзи Інтернету тільки для виходу**
|
||||
- Ви також можете мати **NAT шлюз** у **приватній підмережі**, щоб мати можливість **підключатися до зовнішніх сервісів** з цієї приватної підмережі, але **неможливо досягти їх ззовні**.
|
||||
- NAT шлюз може бути **публічним** (доступ до Інтернету) або **приватним** (доступ до інших VPC)
|
||||
- **subnetwork** може **автоматично призначати публічні IPv4 адреси**
|
||||
- **instance**, створений у мережі з **автоматичним призначенням IPv4 адрес**, може отримати адресу
|
||||
- **Internet gateway** має бути **підключений** до **VPC**
|
||||
- Також можна використовувати **Egress-only internet gateways**
|
||||
- Можна мати **NAT gateway** у **private subnet**, щоб було можливим **підключатися до зовнішніх сервісів** з цієї приватної subnet, але **неможливо дістатися до нього ззовні**.
|
||||
- NAT gateway може бути **public** (доступ в інтернет) або **private** (доступ до інших VPC)
|
||||
|
||||
.png>)
|
||||
|
||||
## VPC
|
||||
|
||||
Amazon **Віртуальна Приватна Хмара** (Amazon VPC) дозволяє вам **запускати ресурси AWS у віртуальній мережі**, яку ви визначили. Ця віртуальна мережа матиме кілька підмереж, шлюзи Інтернету для доступу до Інтернету, ACL, групи безпеки, IP...
|
||||
Amazon **Virtual Private Cloud** (Amazon VPC) дозволяє вам **розгортати AWS ресурси у віртуальній мережі**, яку ви визначили. Ця віртуальна мережа матиме кілька subnet, Internet Gateways для доступу до Інтернету, ACLs, Security groups, IPs...
|
||||
|
||||
### Підмережі
|
||||
### Subnets
|
||||
|
||||
Підмережі допомагають забезпечити вищий рівень безпеки. **Логічна група подібних ресурсів** також допомагає вам підтримувати **зручність управління** у вашій інфраструктурі.
|
||||
Subnets допомагають забезпечити вищий рівень безпеки. **Логічне групування подібних ресурсів** також допомагає зберегти **зручність управління** вашою інфраструктурою.
|
||||
|
||||
- Дійсні CIDR від /16 до /28.
|
||||
- Підмережа не може бути в різних зонах доступності одночасно.
|
||||
- **AWS резервує перші три IP адреси хостів** кожної підмережі **для** **внутрішнього використання AWS**: перша адреса хоста використовується для маршрутизатора VPC. Друга адреса зарезервована для AWS DNS, а третя адреса зарезервована для майбутнього використання.
|
||||
- Підмережі, які мають **прямий доступ до Інтернету, називаються публічними підмережами, тоді як приватні підмережі - ні.**
|
||||
- Дійсні CIDR — від /16 netmask до /28 netmask.
|
||||
- Subnet не може належати до різних availability zones одночасно.
|
||||
- **AWS резервує перші три host IP адреси** кожної subnet **для внутрішнього використання AWS**: перша адреса використовується для VPC router. Друга адреса резервується для AWS DNS, а третя адреса резервується для майбутнього використання.
|
||||
- Називаються **public subnets** ті, що мають **прямий доступ до Інтернету**, тоді як private subnets — ні.
|
||||
|
||||
<figure><img src="https://lh5.googleusercontent.com/N_WTrTrDAHwN61FMKJvLSHVua2EM0IazHH1fSTg8JQfTChm-dLN9mn7wkjz2MlpD-uOUqtWdMZpqKOp4VxaHy5-5X66GD1K8y1UGc27r-GbHdFty9ImpXdcjEsC7u4vjxKme_B_HwDOUnG6camxENYECTw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
### Route Tables
|
||||
|
||||
<figure><img src="https://lh3.googleusercontent.com/MmjfVzGmV4jM7tO8lVoTKONoeqbq6E40DGeKUoo4kN-lmMDKnEiGNB-gGVx3EvjK9UV844im225CA8aAjomHf1Modt3MramHrHZdEGbeSZncWhVuT9R8f7tQZ2pXjdSJxeNfErmJ-0mmcUaV6dcU0TAd2A=s2048" alt=""><figcaption></figcaption></figure>
|
||||
Route tables визначають маршрутизацію трафіку для subnet у межах VPC. Вони визначають, який мережевий трафік пересилається в інтернет або через VPN-з'єднання. Зазвичай ви знайдете маршрути до:
|
||||
|
||||
### Таблиці маршрутизації
|
||||
|
||||
Таблиці маршрутизації визначають маршрутизацію трафіку для підмережі в VPC. Вони визначають, який мережевий трафік пересилається в Інтернет або до VPN з'єднання. Ви зазвичай знайдете доступ до:
|
||||
|
||||
- Локального VPC
|
||||
- Local VPC
|
||||
- NAT
|
||||
- Шлюзів Інтернету / Шлюзів Інтернету тільки для виходу (необхідні для надання VPC доступу до Інтернету).
|
||||
- Щоб зробити підмережу публічною, вам потрібно **створити** та **підключити** **шлюз Інтернету** до вашого VPC.
|
||||
- Точки доступу VPC (для доступу до S3 з приватних мереж)
|
||||
- Internet Gateways / Egress-only Internet gateways (потрібні, щоб надати VPC доступ до Інтернету).
|
||||
- Щоб зробити subnet публічною, потрібно **створити** та **прикріпити** **Internet gateway** до вашого VPC.
|
||||
- VPC endpoints (щоб отримувати доступ до S3 з приватних мереж)
|
||||
|
||||
На наступних зображеннях ви можете перевірити різницю між типовою публічною мережею та приватною:
|
||||
### ACLs
|
||||
|
||||
<figure><img src="https://lh3.googleusercontent.com/q4ASpcLAYqijdNMLhMLl8EoowDtTMU5I_7YCVfk7-5hxDyeQOik9ImHnD2SYy32XUA2qXjEbXTAxA1lP--znJASdhYOdBveDcrD42f9XBKZ3EmjJCazN3YPLC6oS0xtRMmfORuwCszmMt-KrAkH07_izwg=s2048" alt=""><figcaption></figcaption></figure>
|
||||
**Network Access Control Lists (ACLs)**: Network ACLs — це правила брандмауера, що контролюють вхідний та вихідний мережевий трафік до subnet. Вони можуть використовуватися для дозволу або заборони трафіку до конкретних IP адрес або діапазонів.
|
||||
|
||||
<figure><img src="https://lh5.googleusercontent.com/30psylXAI0gRN6_LK-reP00aGIlMma64E1qafCVPunn6nS-y5jAO6Y2JiempKcf6-LFi7ScicYcOh7BbHEya2VWtksnFX_8SPXQf97tKkg2tNZzrArWbiDCCn2m2LP1QUq6MZ_KayH3yir7t8zpO7CEQOw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
- Найчастіше дозволи/заборони виконують за допомогою security groups, але ACLs — це єдиний спосіб повністю розірвати вже встановлені reverse shells. Зміна правила у security group не зупиняє вже встановлені з’єднання.
|
||||
- Проте це застосовується до всієї subnet — будьте обережні при забороні, оскільки необхідна функціональність може бути порушена.
|
||||
|
||||
### ACL
|
||||
### Security Groups
|
||||
|
||||
**Списки контролю доступу до мережі (ACL)**: Мережеві ACL - це правила брандмауера, які контролюють вхідний та вихідний мережевий трафік до підмережі. Вони можуть використовуватися для дозволу або заборони трафіку до конкретних IP адрес або діапазонів.
|
||||
|
||||
- Найчастіше доступ дозволяється/забороняється за допомогою груп безпеки, але це єдиний спосіб повністю відключити встановлені зворотні оболонки. Змінене правило в групах безпеки не зупиняє вже встановлені з'єднання.
|
||||
- Однак це стосується всієї підмережі, будьте обережні, забороняючи речі, оскільки необхідна функціональність може бути порушена.
|
||||
|
||||
### Групи безпеки
|
||||
|
||||
Групи безпеки - це віртуальний **брандмауер**, який контролює вхідний та вихідний мережевий **трафік до екземплярів** у VPC. Відношення 1 SG до M екземплярів (зазвичай 1 до 1).\
|
||||
Зазвичай це використовується для відкриття небезпечних портів в екземплярах, таких як порт 22, наприклад:
|
||||
Security groups — це віртуальний **брандмауер**, який контролює вхідний та вихідний мережевий **трафік до instances** у VPC. Відношення 1 SG до M instances (зазвичай 1 до 1).\
|
||||
Зазвичай використовується для відкриття небезпечних портів на інстансах, наприклад порт 22:
|
||||
|
||||
<figure><img src="https://lh5.googleusercontent.com/LliB7eb3cYfkEyOpyw1-eYgWsn2kq1yF6uRn5VYndvOuTvDlURimYx9UvuK8F2impTLmx50mid4MdTXE-Ljt2i_rxaIfnKUdji_hFjCdU9tdoW-axng9-W4tSL71gbbjrPQ7IYY5lAdH_G3UoMRMGGGOxQ=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Еластичні IP адреси
|
||||
### Elastic IP Addresses
|
||||
|
||||
_Еластична IP адреса_ - це **статична IPv4 адреса**, призначена для динамічного хмарного обчислення. Еластична IP адреса виділяється вашому обліковому запису AWS і залишається за вами, поки ви її не звільните. Використовуючи еластичну IP адресу, ви можете маскувати збій екземпляра або програмного забезпечення, швидко перенаправляючи адресу на інший екземпляр у вашому обліковому записі.
|
||||
_Elastic IP address_ — це **статична IPv4 адреса**, призначена для динамічних обчислювальних середовищ у хмарі. Elastic IP адреса виділяється вашому AWS акаунту і належить вам, поки ви її не звільните. Використовуючи Elastic IP, ви можете приховати збій інстансу або софту шляхом швидкого перепризначення адреси іншому інстансу у вашому акаунті.
|
||||
|
||||
### З'єднання між підмережами
|
||||
### Connection between subnets
|
||||
|
||||
За замовчуванням усі підмережі мають **автоматичне призначення публічних IP адрес вимкнене**, але його можна увімкнути.
|
||||
За замовчуванням у всіх subnets **автоматичне призначення публічних IP адрес вимкнено**, але його можна ввімкнути.
|
||||
|
||||
**Локальний маршрут у таблиці маршрутизації дозволяє зв'язок між підмережами VPC.**
|
||||
**Локальний маршрут у route table дозволяє зв’язок між VPC subnets.**
|
||||
|
||||
Якщо ви **з'єднуєте підмережу з іншою підмережею, ви не можете отримати доступ до підмереж, підключених до іншої підмережі, вам потрібно створити з'єднання з ними безпосередньо.** **Це також стосується шлюзів Інтернету.** Ви не можете пройти через з'єднання підмережі, щоб отримати доступ до Інтернету, вам потрібно призначити шлюз Інтернету своїй підмережі.
|
||||
Якщо ви **з'єднуєте subnet з іншою subnet, ви не зможете отримати доступ до subnet, з'єднаних з тією іншою subnet**, потрібно створювати з’єднання безпосередньо з ними. **Це також стосується Internet gateways.** Ви не можете пройти через з’єднання між subnet, щоб потрапити в інтернет — потрібно призначити internet gateway вашій subnet.
|
||||
|
||||
### Пірінг VPC
|
||||
### VPC Peering
|
||||
|
||||
Пірінг VPC дозволяє вам **з'єднувати дві або більше VPC разом**, використовуючи IPV4 або IPV6, так, ніби вони є частиною однієї мережі.
|
||||
VPC peering дозволяє **з'єднати дві або більше VPC між собою**, використовуючи IPv4 або IPv6, так ніби вони були частиною однієї мережі.
|
||||
|
||||
Якщо з'єднання пірінгу встановлено, **ресурси в одній VPC можуть отримувати доступ до ресурсів в іншій**. З'єднання між VPC реалізується через існуючу інфраструктуру мережі AWS, тому воно має високу доступність без вузьких місць у пропускній здатності. Оскільки **з'єднання пірінгу працюють так, ніби вони є частиною однієї мережі**, існують обмеження щодо діапазонів ваших CIDR, які можуть бути використані.\
|
||||
Якщо у вас є **перекриваючі або дубльовані CIDR** діапазони для вашого VPC, то **ви не зможете з'єднати VPC** разом.\
|
||||
Кожен AWS VPC **спілкуватиметься лише зі своїм піром**. Наприклад, якщо у вас є з'єднання пірінгу між VPC 1 і VPC 2, і ще одне з'єднання між VPC 2 і VPC 3, як показано, тоді VPC 1 і 2 можуть спілкуватися один з одним безпосередньо, як і VPC 2 і VPC 3, однак VPC 1 і VPC 3 не можуть. **Ви не можете маршрутизувати через один VPC, щоб дістатися до іншого.**
|
||||
Після встановлення peer-з’єднання **ресурси в одній VPC можуть отримувати доступ до ресурсів в іншій**. З’єднання між VPC реалізується через існуючу інфраструктуру мережі AWS, тому воно високо доступне і без вузьких місць по пропускній здатності. Оскільки **peered connections працюють так, ніби вони частина однієї мережі**, існують обмеження щодо CIDR-блоків, які можна використовувати.\
|
||||
Якщо у вас **перекриваються або дублюються CIDR** діапазони для ваших VPC, тоді **ви не зможете з'єднати ці VPC через peering**.\
|
||||
Кожна AWS VPC буде **комунікувати лише зі своїм peer**. Наприклад, якщо у вас є peering між VPC 1 та VPC 2, і ще один між VPC 2 та VPC 3, то VPC 1 та VPC 2 можуть безпосередньо спілкуватися, як і VPC 2 та VPC 3, проте VPC 1 та VPC 3 не зможуть. **Ви не можете маршрутизувати через одну VPC, щоб дістатися до іншої.**
|
||||
|
||||
### **Журнали потоку VPC**
|
||||
### **VPC Flow Logs**
|
||||
|
||||
У вашому VPC ви можете мати потенційно сотні або навіть тисячі ресурсів, які спілкуються між різними підмережами, як публічними, так і приватними, а також між різними VPC через з'єднання пірінгу VPC. **Журнали потоку VPC дозволяють вам захоплювати інформацію про IP трафік, що проходить між мережевими інтерфейсами ваших ресурсів у вашому VPC.**
|
||||
У межах вашої VPC потенційно може бути сотні або навіть тисячі ресурсів, що обмінюються трафіком між різними subnets — як публічними, так і приватними — а також між різними VPC через VPC peering connections. **VPC Flow Logs дозволяють захоплювати інформацію про IP трафік, що проходить між мережевими інтерфейсами ваших ресурсів у VPC**.
|
||||
|
||||
На відміну від журналів доступу S3 та журналів доступу CloudFront, **дані журналів, згенеровані журналами потоку VPC, не зберігаються в S3. Натомість дані журналів, що захоплюються, надсилаються до журналів CloudWatch.**
|
||||
На відміну від S3 access logs і CloudFront access logs, **логові дані, згенеровані VPC Flow Logs, не зберігаються в S3. Замість цього дані надсилаються до CloudWatch logs**.
|
||||
|
||||
Обмеження:
|
||||
|
||||
- Якщо ви використовуєте з'єднання пірінгу VPC, ви зможете бачити лише журнали потоку пірінгових VPC, які знаходяться в одному обліковому записі.
|
||||
- Якщо ви все ще використовуєте ресурси в середовищі EC2-Classic, на жаль, ви не зможете отримати інформацію з їх інтерфейсів.
|
||||
- Як тільки журнал потоку VPC створено, його не можна змінити. Щоб змінити конфігурацію журналу потоку VPC, вам потрібно видалити його, а потім створити новий.
|
||||
- Наступний трафік не контролюється та не захоплюється журналами. DHCP трафік у VPC, трафік від екземплярів, призначений для сервера DNS Amazon.
|
||||
- Будь-який трафік, призначений для IP адреси маршрутизатора за замовчуванням VPC, та трафік до і з наступних адрес, 169.254.169.254, який використовується для збору метаданих екземпляра, та 169.254.169.123, який використовується для служби синхронізації часу Amazon.
|
||||
- Трафік, пов'язаний з ліцензією активації Windows Amazon з Windows екземпляра.
|
||||
- Трафік між інтерфейсом навантажувального балансувальника мережі та інтерфейсом мережевої точки доступу.
|
||||
- Якщо ви використовуєте VPC peered connection, то ви зможете бачити flow logs peered VPC лише в межах одного акаунту.
|
||||
- Якщо ви все ще використовуєте ресурси у середовищі EC2-Classic, то, на жаль, ви не зможете отримати інформацію з їх інтерфейсів.
|
||||
- Після створення VPC Flow Log його не можна змінити. Щоб змінити конфігурацію, потрібно видалити його і створити заново.
|
||||
- Наступний трафік не контролюється і не захоплюється логами: DHCP трафік у межах VPC, трафік від інстансів, призначений для Amazon DNS Server.
|
||||
- Будь-який трафік, призначений IP-адресі для VPC default router, та трафік до і з наступних адрес: 169.254.169.254 (використовується для збору instance metadata) і 169.254.169.123 (використовується для Amazon Time Sync Service).
|
||||
- Трафік, пов'язаний з активацією ліцензії Amazon Windows з Windows instance.
|
||||
- Трафік між network load balancer interface та endpoint network interface.
|
||||
|
||||
Для кожного мережевого інтерфейсу, який публікує дані в групу журналів CloudWatch, буде використовуватися різний потік журналу. І в кожному з цих потоків будуть дані подій журналу потоку, які показують вміст записів журналу. Кожен з цих **журналів захоплює дані протягом приблизно 10-15 хвилин**.
|
||||
Для кожного network interface, що публікує дані в CloudWatch log group, буде використовуватись окремий log stream. І в кожному з цих потоків будуть flow log event дані, які показують вміст записів логів. Кожен з цих **логів захоплює дані у вікні приблизно 10–15 хвилин**.
|
||||
|
||||
## VPN
|
||||
|
||||
### Основні компоненти AWS VPN
|
||||
### Basic AWS VPN Components
|
||||
|
||||
1. **Шлюз клієнта**:
|
||||
- Шлюз клієнта - це ресурс, який ви створюєте в AWS, щоб представляти вашу сторону з'єднання VPN.
|
||||
- Це, по суті, фізичний пристрій або програмне забезпечення на вашій стороні з'єднання Site-to-Site VPN.
|
||||
- Ви надаєте інформацію про маршрутизацію та публічну IP адресу вашого мережевого пристрою (такого як маршрутизатор або брандмауер) AWS для створення шлюзу клієнта.
|
||||
- Він слугує точкою посилання для налаштування з'єднання VPN і не несе додаткових витрат.
|
||||
2. **Віртуальний приватний шлюз**:
|
||||
- Віртуальний приватний шлюз (VPG) - це концентратор VPN на стороні Amazon з'єднання Site-to-Site VPN.
|
||||
- Він підключений до вашого VPC і слугує ціллю для вашого з'єднання VPN.
|
||||
- VPG - це кінцева точка AWS для з'єднання VPN.
|
||||
- Він обробляє безпечну комунікацію між вашим VPC та вашою локальною мережею.
|
||||
3. **З'єднання Site-to-Site VPN**:
|
||||
- З'єднання Site-to-Site VPN з'єднує вашу локальну мережу з VPC через безпечний IPsec VPN тунель.
|
||||
- Цей тип з'єднання вимагає шлюз клієнта та віртуальний приватний шлюз.
|
||||
- Використовується для безпечної, стабільної та постійної комунікації між вашим центром обробки даних або мережею та вашим середовищем AWS.
|
||||
- Зазвичай використовується для регулярних, довгострокових з'єднань і оплачується на основі обсягу даних, переданих через з'єднання.
|
||||
4. **Кінцева точка клієнтського VPN**:
|
||||
- Кінцева точка клієнтського VPN - це ресурс, який ви створюєте в AWS для активації та управління сесіями клієнтського VPN.
|
||||
- Використовується для дозволу окремим пристроям (таким як ноутбуки, смартфони тощо) безпечно підключатися до ресурсів AWS або вашої локальної мережі.
|
||||
- Вона відрізняється від Site-to-Site VPN тим, що призначена для окремих клієнтів, а не для з'єднання цілих мереж.
|
||||
- З клієнтським VPN кожен клієнтський пристрій використовує програмне забезпечення клієнта VPN для встановлення безпечного з'єднання.
|
||||
1. **Customer Gateway**:
|
||||
- Customer Gateway — ресурс, який ви створюєте в AWS, щоб представляти ваш бік VPN-з'єднання.
|
||||
- Це, по суті, фізичний пристрій або програмний додаток на вашому боці Site-to-Site VPN з'єднання.
|
||||
- Ви надаєте інформацію про маршрутизацію і публічну IP-адресу вашого мережевого пристрою (наприклад роутера або фаєрвола) в AWS для створення Customer Gateway.
|
||||
- Служить як точка посилання для налаштування VPN-з'єднання і не несе додаткових витрат.
|
||||
2. **Virtual Private Gateway**:
|
||||
- Virtual Private Gateway (VPG) — це VPN-концентратор на стороні Amazon для Site-to-Site VPN з'єднання.
|
||||
- Він прикріплюється до вашого VPC і служить як ціль для вашого VPN-з'єднання.
|
||||
- VPG — це AWS-ендпоінт для VPN-з'єднання.
|
||||
- Він обробляє захищене спілкування між вашим VPC і вашою on-premises мережею.
|
||||
3. **Site-to-Site VPN Connection**:
|
||||
- Site-to-Site VPN connection з'єднує вашу on-premises мережу з VPC через захищений IPsec VPN тунель.
|
||||
- Для цього типу з'єднання потрібні Customer Gateway і Virtual Private Gateway.
|
||||
- Використовується для безпечного, стабільного та послідовного спілкування між вашим дата-центром або мережею і вашим AWS середовищем.
|
||||
- Зазвичай використовується для регулярних, довготривалих з'єднань і тарифікується на основі обсягу даних, що передаються через з'єднання.
|
||||
4. **Client VPN Endpoint**:
|
||||
- Client VPN endpoint — ресурс, який ви створюєте в AWS для дозволу і управління клієнтськими VPN сесіями.
|
||||
- Використовується для дозволу окремим пристроям (наприклад ноутбукам, смартфонам тощо) безпечно підключатися до AWS ресурсів або вашої on-premises мережі.
|
||||
- Відрізняється від Site-to-Site VPN тим, що призначений для індивідуальних клієнтів, а не для з'єднання цілих мереж.
|
||||
- Кожен клієнтський пристрій використовує VPN client software для встановлення безпечного з'єднання.
|
||||
|
||||
### Site-to-Site VPN
|
||||
|
||||
**Підключіть вашу локальну мережу до вашого VPC.**
|
||||
**З'єднує вашу on premisses мережу з вашим VPC.**
|
||||
|
||||
- **З'єднання VPN**: Безпечне з'єднання між вашим обладнанням на місці та вашими VPC.
|
||||
- **Тунель VPN**: Зашифрований зв'язок, через який дані можуть проходити з мережі клієнта до AWS або з AWS.
|
||||
- **VPN connection**: Захищене з'єднання між вашим on-premises обладнанням і вашими VPC.
|
||||
- **VPN tunnel**: Зашифрований канал, через який дані можуть передаватися від клієнтської мережі до AWS або навпаки.
|
||||
|
||||
Кожне з'єднання VPN включає два тунелі VPN, які ви можете одночасно використовувати для високої доступності.
|
||||
Кожне VPN-з'єднання включає два VPN tunnels, які можна використовувати одночасно для забезпечення високої доступності.
|
||||
|
||||
- **Шлюз клієнта**: Ресурс AWS, який надає інформацію AWS про ваш пристрій шлюзу клієнта.
|
||||
- **Пристрій шлюзу клієнта**: Фізичний пристрій або програмне забезпечення на вашій стороні з'єднання Site-to-Site VPN.
|
||||
- **Віртуальний приватний шлюз**: Концентратор VPN на стороні Amazon з'єднання Site-to-Site VPN. Ви використовуєте віртуальний приватний шлюз або транзитний шлюз як шлюз для сторони Amazon з'єднання Site-to-Site VPN.
|
||||
- **Транзитний шлюз**: Транзитний хаб, який можна використовувати для з'єднання ваших VPC та локальних мереж. Ви використовуєте транзитний шлюз або віртуальний приватний шлюз як шлюз для сторони Amazon з'єднання Site-to-Site VPN.
|
||||
- **Customer gateway**: Ресурс AWS, який надає AWS інформацію про ваш customer gateway device.
|
||||
- **Customer gateway device**: Фізичний пристрій або програмний додаток на вашому боці Site-to-Site VPN з'єднання.
|
||||
- **Virtual private gateway**: VPN-концентратор на стороні Amazon для Site-to-Site VPN з'єднання. Ви використовуєте virtual private gateway або transit gateway як шлюз на стороні Amazon для Site-to-Site VPN з'єднання.
|
||||
- **Transit gateway**: Транзитний хаб, який може використовуватися для взаємозв'язку ваших VPC і on-premises мереж. Ви використовуєте transit gateway або virtual private gateway як шлюз на стороні Amazon для Site-to-Site VPN з'єднання.
|
||||
|
||||
#### Обмеження
|
||||
#### Limitations
|
||||
|
||||
- Трафік IPv6 не підтримується для з'єднань VPN на віртуальному приватному шлюзі.
|
||||
- З'єднання AWS VPN не підтримує виявлення MTU шляху.
|
||||
- IPv6 трафік не підтримується для VPN з'єднань на virtual private gateway.
|
||||
- AWS VPN connection не підтримує Path MTU Discovery.
|
||||
|
||||
Крім того, врахуйте наступне, коли ви використовуєте Site-to-Site VPN.
|
||||
Крім того, врахуйте наступне при використанні Site-to-Site VPN.
|
||||
|
||||
- При підключенні ваших VPC до спільної локальної мережі ми рекомендуємо використовувати неперекриваючі CIDR блоки для ваших мереж.
|
||||
- При підключенні ваших VPC до спільної on-premises мережі рекомендується використовувати неперекривні CIDR блоки для ваших мереж.
|
||||
|
||||
### Клієнтський VPN <a href="#what-is-components" id="what-is-components"></a>
|
||||
### Client VPN <a href="#what-is-components" id="what-is-components"></a>
|
||||
|
||||
**Підключіться з вашого пристрою до вашого VPC**
|
||||
**Підключення з вашого пристрою до вашого VPC**
|
||||
|
||||
#### Концепції
|
||||
#### Concepts
|
||||
|
||||
- **Кінцева точка клієнтського VPN:** Ресурс, який ви створюєте та налаштовуєте для активації та управління сесіями клієнтського VPN. Це ресурс, де завершуються всі сесії клієнтського VPN.
|
||||
- **Цільова мережа:** Цільова мережа - це мережа, яку ви асоціюєте з кінцевою точкою клієнтського VPN. **Підмережа з VPC є цільовою мережею**. Асоціювання підмережі з кінцевою точкою клієнтського VPN дозволяє вам встановлювати сесії VPN. Ви можете асоціювати кілька підмереж з кінцевою точкою клієнтського VPN для високої доступності. Усі підмережі повинні бути з одного VPC. Кожна підмережа повинна належати до різної зони доступності.
|
||||
- **Маршрут**: Кожна кінцева точка клієнтського VPN має таблицю маршрутів, яка описує доступні маршрути мережі призначення. Кожен маршрут у таблиці маршрутів вказує шлях для трафіку до конкретних ресурсів або мереж.
|
||||
- **Правила авторизації:** Правило авторизації **обмежує користувачів, які можуть отримати доступ до мережі**. Для вказаної мережі ви налаштовуєте групу Active Directory або постачальника ідентичності (IdP), якій дозволено доступ. Тільки користувачі, що належать до цієї групи, можуть отримати доступ до вказаної мережі. **За замовчуванням немає правил авторизації**, і ви повинні налаштувати правила авторизації, щоб дозволити користувачам отримувати доступ до ресурсів і мереж.
|
||||
- **Клієнт:** Кінцевий користувач, який підключається до кінцевої точки клієнтського VPN для встановлення сесії VPN. Кінцеві користувачі повинні завантажити клієнт OpenVPN і використовувати файл конфігурації клієнтського VPN, який ви створили, для встановлення сесії VPN.
|
||||
- **Діапазон CIDR клієнта:** Діапазон IP адрес, з якого призначаються IP адреси клієнтів. Кожне з'єднання з кінцевою точкою клієнтського VPN отримує унікальну IP адресу з діапазону CIDR клієнта. Ви вибираєте діапазон CIDR клієнта, наприклад, `10.2.0.0/16`.
|
||||
- **Порти клієнтського VPN:** AWS Client VPN підтримує порти 443 і 1194 для TCP та UDP. За замовчуванням використовується порт 443.
|
||||
- **Мережеві інтерфейси клієнтського VPN:** Коли ви асоціюєте підмережу з вашою кінцевою точкою клієнтського VPN, ми створюємо мережеві інтерфейси клієнтського VPN у цій підмережі. **Трафік, що надсилається до VPC з кінцевої точки клієнтського VPN, надсилається через мережевий інтерфейс клієнтського VPN**. Потім застосовується трансляція адреси джерела мережі (SNAT), де IP адреса джерела з діапазону CIDR клієнта транслюється на IP адресу мережевого інтерфейсу клієнтського VPN.
|
||||
- **Журнал з'єднань:** Ви можете увімкнути журнал з'єднань для вашої кінцевої точки клієнтського VPN, щоб реєструвати події з'єднання. Ви можете використовувати цю інформацію для проведення судово-медичних експертиз, аналізу того, як використовується ваша кінцева точка клієнтського VPN, або для налагодження проблем з'єднання.
|
||||
- **Портал самообслуговування:** Ви можете увімкнути портал самообслуговування для вашої кінцевої точки клієнтського VPN. Клієнти можуть увійти в веб-портал, використовуючи свої облікові дані, і завантажити останню версію файлу конфігурації кінцевої точки клієнтського VPN або останню версію клієнта, наданого AWS.
|
||||
- **Client VPN endpoint:** Ресурс, який ви створюєте і конфігуруєте для дозволу та управління клієнтськими VPN сесіями. Це ресурс, на якому завершуються всі клієнтські VPN сесії.
|
||||
- **Target network:** Target network — це мережа, яку ви асоціюєте з Client VPN endpoint. **Subnet із VPC є target network**. Асигнування subnet до Client VPN endpoint дозволяє встановлювати VPN сесії. Ви можете асоціювати кілька subnet з Client VPN endpoint для високої доступності. Всі subnets повинні бути з одного VPC. Кожна subnet повинна належати різній Availability Zone.
|
||||
- **Route**: Кожен Client VPN endpoint має route table, що описує доступні маршрути призначення мереж. Кожен маршрут у таблиці маршрутизації визначає шлях для трафіку до конкретних ресурсів або мереж.
|
||||
- **Authorization rules:** Правило авторизації **обмежує користувачів, які можуть отримати доступ до мережі**. Для певної мережі ви налаштовуєте Active Directory або identity provider (IdP) групу, якій дозволено доступ. Лише користувачі, що належать до цієї групи, можуть отримати доступ до вказаної мережі. **За замовчуванням немає authorization rules** і вам потрібно їх налаштувати, щоб дозволити користувачам доступ до ресурсів і мереж.
|
||||
- **Client:** Кінцевий користувач, який підключається до Client VPN endpoint для встановлення VPN сесії. Кінцеві користувачі повинні завантажити OpenVPN client і використовувати Client VPN configuration file, який ви створили, щоб встановити VPN сесію.
|
||||
- **Client CIDR range:** Діапазон IP адрес, з якого призначаються IP адреси клієнтів. Кожне з'єднання з Client VPN endpoint отримує унікальну IP адресу з client CIDR range. Ви обираєте client CIDR range, наприклад, `10.2.0.0/16`.
|
||||
- **Client VPN ports:** AWS Client VPN підтримує порти 443 і 1194 для TCP і UDP. За замовчуванням порт 443.
|
||||
- **Client VPN network interfaces:** Коли ви асоціюєте subnet з вашим Client VPN endpoint, ми створюємо Client VPN network interfaces у цій subnet. **Трафік, що відправляється до VPC з Client VPN endpoint, надсилається через Client VPN network interface**. Потім застосовується Source network address translation (SNAT), де вихідна IP адреса з client CIDR range транслюється у IP адресу Client VPN network interface.
|
||||
- **Connection logging:** Ви можете увімкнути logging з'єднань для вашого Client VPN endpoint, щоб логувати події підключення. Ви можете використовувати цю інформацію для проведення судово-експертних розслідувань, аналізу того, як використовується ваш Client VPN endpoint, або відлагодження проблем зі з'єднанням.
|
||||
- **Self-service portal:** Ви можете увімкнути self-service portal для вашого Client VPN endpoint. Клієнти можуть увійти в веб-портал за допомогою своїх облікових даних і завантажити останню версію Client VPN endpoint configuration file або останню версію клієнта, наданого AWS.
|
||||
|
||||
#### Обмеження
|
||||
#### Limitations
|
||||
|
||||
- **Діапазони CIDR клієнта не можуть перекриватися з локальним CIDR** VPC, в якому знаходиться асоційована підмережа, або будь-якими маршрутами, які вручну додані до таблиці маршрутів кінцевої точки клієнтського VPN.
|
||||
- Діапазони CIDR клієнта повинні мати розмір блоку не менше **/22** і не повинні **перевищувати /12.**
|
||||
- **Частина адрес** у діапазоні CIDR клієнта використовується для **підтримки моделі доступності** кінцевої точки клієнтського VPN і не може бути призначена клієнтам. Тому ми рекомендуємо вам **призначити блок CIDR, який містить удвічі більше IP адрес, ніж потрібно** для забезпечення максимальної кількості одночасних з'єднань, які ви плануєте підтримувати на кінцевій точці клієнтського VPN.
|
||||
- **Діапазон CIDR клієнта не може бути змінений** після створення кінцевої точки клієнтського VPN.
|
||||
- **Підмережі**, асоційовані з кінцевою точкою клієнтського VPN, **повинні бути в одному VPC**.
|
||||
- Ви **не можете асоціювати кілька підмереж з однієї зони доступності з кінцевою точкою клієнтського VPN**.
|
||||
- Кінцева точка клієнтського VPN **не підтримує асоціації підмереж у VPC з виділеним орендою**.
|
||||
- Клієнтський VPN підтримує **тільки** трафік IPv4.
|
||||
- Клієнтський VPN **не** відповідає стандартам обробки інформації федерального рівня (**FIPS**).
|
||||
- Якщо багатофакторна аутентифікація (MFA) вимкнена для вашої Active Directory, пароль користувача не може бути у наступному форматі.
|
||||
- **Client CIDR ranges cannot overlap with the local CIDR** VPC, в якому знаходиться асоційована subnet, або будь-які маршрути, додані вручну до route table Client VPN endpoint.
|
||||
- Client CIDR ranges повинні мати розмір блоку принаймні **/22** і **не більше ніж /12.**
|
||||
- **Частина адрес** у client CIDR range використовується для **підтримки моделі доступності** Client VPN endpoint і не може бути призначена клієнтам. Тому рекомендується **призначити CIDR блок, що містить вдвічі більше IP адрес, ніж потрібно**, щоб підтримати максимальну кількість одночасних з'єднань, які ви плануєте.
|
||||
- **client CIDR range не можна змінити** після створення Client VPN endpoint.
|
||||
- **subnets**, асоційовані з Client VPN endpoint, **повинні бути в одному VPC**.
|
||||
- Ви **не можете асоціювати кілька subnets з однієї Availability Zone з Client VPN endpoint**.
|
||||
- Client VPN endpoint **не підтримує асоціації subnet у VPC з dedicated tenancy**.
|
||||
- Client VPN підтримує лише **IPv4** трафік.
|
||||
- Client VPN **не є сумісним** з Federal Information Processing Standards (**FIPS**).
|
||||
- Якщо багатофакторна аутентифікація (MFA) вимкнена для вашого Active Directory, пароль користувача не може мати такий формат.
|
||||
|
||||
```
|
||||
SCRV1:<base64_encoded_string>:<base64_encoded_string>
|
||||
```
|
||||
|
||||
- Портал самообслуговування **не доступний для клієнтів, які аутентифікуються за допомогою взаємної аутентифікації**.
|
||||
- Self-service portal **не доступний** для клієнтів, які автентифікуються за допомогою mutual authentication.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - S3, Athena & Glacier Перелічення
|
||||
# AWS - S3, Athena & Glacier Enum
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,34 +6,34 @@
|
||||
|
||||
Amazon S3 — це сервіс, який дозволяє вам **зберігати великі обсяги даних**.
|
||||
|
||||
Amazon S3 надає кілька опцій для досягнення **захисту** даних у стані спокою. Опції включають **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** та **MFA based delete**. Користувач може **увімкнути** будь-яку з цих опцій для забезпечення захисту даних. **Data replication** — це внутрішня можливість від AWS, за якої **S3 автоматично реплікує кожний об’єкт по всіх Availability Zones**, і організації не потрібно додатково її вмикати.
|
||||
Amazon S3 надає кілька опцій для забезпечення **protection** даних у стані спокою (at REST). До опцій належать **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** та **MFA** **based delete**. **Користувач може ввімкнути** будь-яку з цих опцій для захисту даних. **Data replication** — це вбудована функція AWS, коли **S3 автоматично реплікує кожен об’єкт по всіх Availability Zones**, і організації не потрібно додатково її вмикати.
|
||||
|
||||
With resource-based permissions, you can define permissions for sub-directories of your bucket separately.
|
||||
За допомогою дозволів на основі ресурсів (resource-based permissions) ви можете окремо визначати дозволи для піддиректорій вашого bucket.
|
||||
|
||||
### Bucket Versioning and MFA based delete
|
||||
|
||||
When bucket versioning is enabled, any action that tries to alter a file inside a file will generate a new version of the file, keeping also the previous content of the same. Therefore, it won't overwrite its content.
|
||||
Коли bucket versioning увімкнено, будь-яка дія, яка намагається змінити файл всередині файлу, створить нову версію файлу, також зберігаючи попередній вміст. Тому його вміст не буде перезаписано.
|
||||
|
||||
Moreover, MFA based delete will prevent versions of file in the S3 bucket from being deleted and also Bucket Versioning from being disabled, so an attacker won't be able to alter these files.
|
||||
Крім того, MFA based delete запобіжить видаленню версій файлів у S3 bucket та вимкненню Bucket Versioning, тому зловмисник не зможе змінити ці файли.
|
||||
|
||||
### S3 Access logs
|
||||
|
||||
It's possible to **enable S3 access login** (which by default is disabled) to some bucket and save the logs in a different bucket to know who is accessing the bucket (both buckets must be in the same region).
|
||||
Можна **увімкнути S3 access login** (за замовчуванням вимкнено) для певного bucket і зберігати логи в іншому bucket, щоб знати, хто отримує доступ до bucket (обидва bucket повинні бути в одному регіоні).
|
||||
|
||||
### S3 Presigned URLs
|
||||
|
||||
It's possible to generate a presigned URL that can usually be used to **access the specified file** in the bucket. A **presigned URL looks like this**:
|
||||
Можна згенерувати presigned URL, який зазвичай використовується для **доступу до вказаного файлу** в bucket. A **presigned URL looks like this**:
|
||||
```
|
||||
https://<bucket-name>.s3.us-east-1.amazonaws.com/asd.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUUE8GZC4S5L3TY3P%2F20230227%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230227T142551Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjELf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIBhQpdETJO3HKKDk2hjNIrPWwBE8gZaQccZFV3kCpPCWAiEAid3ueDtFFU%2FOQfUpvxYTGO%2BHoS4SWDMUrQAE0pIaB40qggMIYBAAGgwzMTgxNDIxMzg1NTMiDJLI5t7gr2EGxG1Y5CrfAioW0foHIQ074y4gvk0c%2B%2Fmqc7cNWb1njQslQkeePHkseJ3owzc%2FCwkgE0EuZTd4mw0aJciA2XIbJRCLPWTb%2FCBKPnIMJ5aBzIiA2ltsiUNQTTUxYmEgXZoJ6rFYgcodnmWW0Et4Xw59UlHnCDB2bLImxPprriyCzDDCD6nLyp3J8pFF1S8h3ZTJE7XguA8joMs4%2B2B1%2FeOZfuxXKyXPYSKQOOSbQiHUQc%2BFnOfwxleRL16prWk1t7TamvHR%2Bt3UgMn5QWzB3p8FgWwpJ6GjHLkYMJZ379tkimL1tJ7o%2BIod%2FMYrS7LDCifP9d%2FuYOhKWGhaakPuJKJh9fl%2B0vGl7kmApXigROxEWon6ms75laXebltsWwKcKuYca%2BUWu4jVJx%2BWUfI4ofoaGiCSaKALTqwu4QNBRT%2BMoK6h%2BQa7gN7JFGg322lkxRY53x27WMbUE4unn5EmI54T4dWt1%2Bg8ljDS%2BvKfBjqmAWRwuqyfwXa5YC3xxttOr3YVvR6%2BaXpzWtvNJQNnb6v0uI3%2BTtTexZkJpLQYqFcgZLQSxsXWSnf988qvASCIUhAzp2UnS1uqy7QjtD5T73zksYN2aesll7rvB80qIuujG6NOdHnRJ2M5%2FKXXNo1Yd15MtzPuSjRoSB9RSMon5jFu31OrQnA9eCUoawxbB0nHqwK8a43CKBZHhA8RoUAJW%2B48EuFsp3U%3D&X-Amz-Signature=3436e4139e84dbcf5e2e6086c0ebc92f4e1e9332b6fda24697bc339acbf2cdfa
|
||||
```
|
||||
Presigned URL можна **created from the cli using credentials of a principal with access to the object** (якщо акаунт, який ви використовуєте, не має доступу, буде створено коротший presigned URL, але він буде марним)
|
||||
presigned URL можна **створити через cli, використовуючи credentials певного principal, що має доступ до object** (якщо account, який ви використовуєте, не має доступу, буде створено коротший presigned URL, але він буде марним)
|
||||
```bash
|
||||
aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'
|
||||
```
|
||||
> [!NOTE]
|
||||
> Єдиний необхідний дозвіл для генерації presigned URL — це дозвіл, що надається; отже для попередньої команди єдиний дозвіл, потрібний principal, — `s3:GetObject`
|
||||
> Єдиним необхідним дозволом для генерації presigned URL є дозвіл, що надається, тому для попередньої команди єдиний дозвіл, необхідний principal — `s3:GetObject`
|
||||
|
||||
Також можливо створювати presigned URLs з **іншими дозволами**:
|
||||
Також можна створювати presigned URLs з **іншими дозволами**:
|
||||
```python
|
||||
import boto3
|
||||
url = boto3.client('s3').generate_presigned_url(
|
||||
@@ -42,24 +42,24 @@ Params={'Bucket': 'BUCKET_NAME', 'Key': 'OBJECT_KEY'},
|
||||
ExpiresIn=3600
|
||||
)
|
||||
```
|
||||
### S3 Механізми шифрування
|
||||
### S3 Encryption Mechanisms
|
||||
|
||||
**DEK означає Data Encryption Key** і це ключ, який завжди генерується та використовується для шифрування даних.
|
||||
**DEK означає ключ шифрування даних (Data Encryption Key)** — це ключ, який завжди генерується і використовується для шифрування даних.
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Server-side encryption with S3 managed keys, SSE-S3</strong></summary>
|
||||
|
||||
Цей варіант вимагає мінімальної конфігурації — управління ключами шифрування повністю здійснюється AWS. Все, що потрібно зробити, — це завантажити дані, і S3 обробить усі інші аспекти. Кожному bucket у акаунті S3 призначається bucket key.
|
||||
Цей варіант вимагає мінімальної конфігурації, і все управління використовуваними ключами шифрування здійснюється AWS. Все, що потрібно — завантажити ваші дані, і S3 обробить усі інші аспекти. Кожному bucket в S3-акаунті призначено bucket key.
|
||||
|
||||
- Шифрування:
|
||||
- Encryption:
|
||||
- Object Data + created plaintext DEK --> Encrypted data (stored inside S3)
|
||||
- Created plaintext DEK + S3 Master Key --> Encrypted DEK (stored inside S3) and plain text is deleted from memory
|
||||
- Розшифрування:
|
||||
- Decryption:
|
||||
- Encrypted DEK + S3 Master Key --> Plaintext DEK
|
||||
- Plaintext DEK + Encrypted data --> Object Data
|
||||
|
||||
Зверніть увагу, що в цьому випадку **ключ керується AWS** (ротація лише кожні 3 роки). Якщо ви використовуєте власний ключ, ви зможете виконувати його ротацію, відключати та застосовувати контроль доступу.
|
||||
Зверніть увагу, що в цьому випадку **ключ керується AWS** (ротація лише раз на 3 роки). Якщо ви використовуєте власний ключ, ви зможете виконувати ротацію, вимикати та застосовувати контролі доступу.
|
||||
|
||||
</details>
|
||||
|
||||
@@ -67,13 +67,13 @@ ExpiresIn=3600
|
||||
|
||||
<summary><strong>Server-side encryption with KMS managed keys, SSE-KMS</strong></summary>
|
||||
|
||||
Цей метод дозволяє S3 використовувати Key Management Service для генерації ваших data encryption keys. KMS дає набагато більшу гнучкість у тому, як керувати ключами. Наприклад, ви можете відключати, обертати та застосовувати контроль доступу до CMK, а також контролювати їх використання за допомогою AWS Cloud Trail.
|
||||
Цей метод дозволяє S3 використовувати Key Management Service для генерації ваших data encryption keys. KMS дає значно більшу гнучкість у керуванні ключами. Наприклад, ви можете відключати, обертати (rotate) та застосовувати контролі доступу до CMK, а також відстежувати їх використання за допомогою AWS Cloud Trail.
|
||||
|
||||
- Шифрування:
|
||||
- Encryption:
|
||||
- S3 request data keys from KMS CMK
|
||||
- KMS uses a CMK to generate the pair DEK plaintext and DEK encrypted and send them to S£
|
||||
- S3 uses the paintext key to encrypt the data, store the encrypted data and the encrypted key and deletes from memory the plain text key
|
||||
- Розшифрування:
|
||||
- Decryption:
|
||||
- S3 ask to KMS to decrypt the encrypted data key of the object
|
||||
- KMS decrypt the data key with the CMK and send it back to S3
|
||||
- S3 decrypts the object data
|
||||
@@ -84,14 +84,14 @@ ExpiresIn=3600
|
||||
|
||||
<summary><strong>Server-side encryption with customer provided keys, SSE-C</strong></summary>
|
||||
|
||||
Ця опція дає можливість надати власний master key, який ви вже можете використовувати поза AWS. Ваш customer-provided key надсилається разом з даними до S3, де S3 виконує шифрування за вас.
|
||||
Цей варіант дає змогу надати власний master key, який ви, можливо, вже використовуєте поза AWS. Ваш customer-provided key буде відправлений разом із даними до S3, де S3 виконуватиме шифрування за вас.
|
||||
|
||||
- Шифрування:
|
||||
- Encryption:
|
||||
- The user sends the object data + Customer key to S3
|
||||
- The customer key is used to encrypt the data and the encrypted data is stored
|
||||
- a salted HMAC value of the customer key is stored also for future key validation
|
||||
- the customer key is deleted from memory
|
||||
- Розшифрування:
|
||||
- Decryption:
|
||||
- The user send the customer key
|
||||
- The key is validated against the HMAC value stored
|
||||
- The customer provided key is then used to decrypt the data
|
||||
@@ -102,14 +102,14 @@ ExpiresIn=3600
|
||||
|
||||
<summary><strong>Client-side encryption with KMS, CSE-KMS</strong></summary>
|
||||
|
||||
Подібно до SSE-KMS, цей варіант також використовує KMS для генерації data encryption keys. Але цього разу виклик до KMS робить клієнт, а не S3. Шифрування відбувається на боці клієнта, після чого зашифровані дані відправляються до S3 для зберігання.
|
||||
Аналогічно до SSE-KMS, цей метод також використовує Key Management Service для генерації data encryption keys. Однак цього разу KMS викликається клієнтом, а не S3. Шифрування відбувається на боці клієнта, після чого зашифровані дані відправляються до S3 для зберігання.
|
||||
|
||||
- Шифрування:
|
||||
- Encryption:
|
||||
- Client request for a data key to KMS
|
||||
- KMS returns the plaintext DEK and the encrypted DEK with the CMK
|
||||
- Both keys are sent back
|
||||
- The client then encrypts the data with the plaintext DEK and send to S3 the encrypted data + the encrypted DEK (which is saved as metadata of the encrypted data inside S3)
|
||||
- Розшифрування:
|
||||
- Decryption:
|
||||
- The encrypted data with the encrypted DEK is sent to the client
|
||||
- The client asks KMS to decrypt the encrypted key using the CMK and KMS sends back the plaintext DEK
|
||||
- The client can now decrypt the encrypted data
|
||||
@@ -120,13 +120,13 @@ ExpiresIn=3600
|
||||
|
||||
<summary><strong>Client-side encryption with customer provided keys, CSE-C</strong></summary>
|
||||
|
||||
За допомогою цього механізму ви можете використовувати власні ключі та AWS-SDK клієнт, щоб зашифрувати дані перед відправкою до S3 для зберігання.
|
||||
За допомогою цього механізму ви можете використовувати власні ключі і AWS-SDK клієнт для шифрування даних перед відправкою їх до S3 для зберігання.
|
||||
|
||||
- Шифрування:
|
||||
- Encryption:
|
||||
- The client generates a DEK and encrypts the plaintext data
|
||||
- Then, using it's own custom CMK it encrypts the DEK
|
||||
- submit the encrypted data + encrypted DEK to S3 where it's stored
|
||||
- Розшифрування:
|
||||
- Decryption:
|
||||
- S3 sends the encrypted data and DEK
|
||||
- As the client already has the CMK used to encrypt the DEK, it decrypts the DEK and then uses the plaintext DEK to decrypt the data
|
||||
|
||||
@@ -134,7 +134,7 @@ ExpiresIn=3600
|
||||
|
||||
### **Enumeration**
|
||||
|
||||
Один із традиційних основних шляхів компрометації організацій AWS починається з компрометації публічно доступних buckets. **Ви можете знайти** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
|
||||
Один із традиційних основних шляхів компрометації AWS orgs починається з компрометації публічно доступних buckets. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
|
||||
```bash
|
||||
# Get buckets ACLs
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -150,7 +150,7 @@ aws s3api list-buckets
|
||||
|
||||
# list content of bucket (no creds)
|
||||
aws s3 ls s3://bucket-name --no-sign-request
|
||||
aws s3 ls s3://bucket-name --recursive
|
||||
aws s3 ls s3://bucket-name --recursive --no-sign-request
|
||||
|
||||
# list content of bucket (with creds)
|
||||
aws s3 ls s3://bucket-name
|
||||
@@ -229,7 +229,7 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
|
||||
```
|
||||
### dual-stack <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
|
||||
|
||||
Ви можете отримати доступ до S3 bucket через dual-stack endpoint, використовуючи virtual hosted-style або path-style endpoint name. Це корисно для доступу до S3 через IPv6.
|
||||
Ви можете отримати доступ до S3 бакета через dual-stack endpoint, використовуючи virtual hosted-style або path-style ім'я endpoint. Це корисно для доступу до S3 через IPv6.
|
||||
|
||||
Dual-stack endpoints використовують наступний синтаксис:
|
||||
|
||||
@@ -238,7 +238,7 @@ Dual-stack endpoints використовують наступний синта
|
||||
|
||||
### Privesc
|
||||
|
||||
На наступній сторінці ви можете переглянути, як **abuse S3 permissions to escalate privileges**:
|
||||
На наступній сторінці ви можете дізнатися, як **abuse S3 permissions to escalate privileges**:
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-s3-privesc/README.md
|
||||
@@ -266,21 +266,21 @@ Dual-stack endpoints використовують наступний синта
|
||||
|
||||
### S3 HTTP Cache Poisoning Issue <a href="#heading-s3-http-desync-cache-poisoning-issue" id="heading-s3-http-desync-cache-poisoning-issue"></a>
|
||||
|
||||
[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) було можливо кешувати відповідь довільного bucket так, ніби вона належала іншому. Це могло бути використано, наприклад, для зміни відповіді javascript файлів і компрометації довільних сторінок, які використовують S3 для зберігання статичного коду.
|
||||
[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) було можливо кешувати відповідь довільного бакета так, ніби вона належала іншому. Це могло б бути використано для зміни, наприклад, відповідей javascript-файлів і компрометації довільних сторінок, які використовують S3 для зберігання статичного коду.
|
||||
|
||||
## Amazon Athena
|
||||
|
||||
Amazon Athena — це інтерактивний сервіс запитів, який полегшує аналіз даних безпосередньо в Amazon Simple Storage Service (Amazon **S3**) **using** standard **SQL**.
|
||||
Amazon Athena — це інтерактивний сервіс запитів, який полегшує **аналіз даних** безпосередньо в Amazon Simple Storage Service (Amazon **S3**) **за допомогою** стандартного **SQL**.
|
||||
|
||||
Потрібно **підготувати relational DB table** з форматом вмісту, який буде з’являтися в monitored S3 buckets. Після цього Amazon Athena зможе заповнити DB з логів, щоб ви могли виконувати запити.
|
||||
Потрібно **підготувати реляційну DB-таблицю** з форматом вмісту, який буде з'являтися в моніторованих S3 бакетах. Після цього Amazon Athena зможе заповнювати таблицю з логів, щоб ви могли її опитувати.
|
||||
|
||||
Amazon Athena підтримує **можливість запитувати S3 дані, які вже зашифровані**, і, якщо налаштовано відповідним чином, **Athena також може шифрувати результати запиту, які потім можуть зберігатися в S3**.
|
||||
Amazon Athena підтримує **можливість виконувати запити до S3-даних, які вже зашифровані**, і, якщо налаштовано відповідним чином, **Athena також може шифрувати результати запиту, які потім можна зберігати в S3**.
|
||||
|
||||
Це шифрування результатів є незалежним від базових запитуваних S3 даних, тобто навіть якщо S3 дані не зашифровані, результати запиту можуть бути зашифровані. Варто пам’ятати, що Amazon Athena підтримує дані, зашифровані лише наступними методами шифрування S3: SSE-S3, SSE-KMS та CSE-KMS.
|
||||
**Це шифрування результатів не залежить від підлягаючих запиту S3-даних**, тобто навіть якщо S3-дані не зашифровані, результати запиту можуть бути зашифровані. Варто зауважити, що Amazon Athena підтримує дані, зашифровані лише наступними методами шифрування S3: **SSE-S3, SSE-KMS, and CSE-KMS**.
|
||||
|
||||
SSE-C та CSE-C не підтримуються. Крім того, важливо розуміти, що Amazon Athena виконуватиме запити лише до зашифрованих об’єктів, що знаходяться в тому ж регіоні, що й сам запит. Якщо вам потрібно виконувати запити до S3 даних, зашифрованих за допомогою KMS, користувачеві Athena потрібні відповідні дозволи для виконання такого запиту.
|
||||
SSE-C і CSE-C не підтримуються. Крім того, важливо розуміти, що Amazon Athena виконуватиме запити лише до **зашифрованих об'єктів, які знаходяться в тому ж регіоні, що й сам запит**. Якщо потрібно виконати запит до S3-даних, зашифрованих за допомогою KMS, користувачу Athena потрібні спеціальні дозволи для виконання такого запиту.
|
||||
|
||||
### Enumeration
|
||||
### Перерахування
|
||||
```bash
|
||||
# Get catalogs
|
||||
aws athena list-data-catalogs
|
||||
|
||||
Reference in New Issue
Block a user