Доброго дня

Враження наступне - з контейнера НЕМА доступу до Інтернета. Може це якась стандартна фігня, а я не знаю про це?

Конфлікт між адресами мереж VPC та Docker. Docker може використовувати всі сірі мережі за замовчуванням. Змінити діапазон мереж Docker можна за допомогою default-address-pools в daemon.json. -- Best regards, Mykola On Sun, Jan 8, 2023 at 10:15 AM Volodymyr Sharun wrote:

Привіт,

Контейнер і його нетворкінг рулиться хостом by design.

Тож контейнер сам відкидаємо. Далі набагато складніше - це можуть бути outbound ruleset'и на хості (нат, файрвол), або на external gateway VPC (більш ймовірно).

Тобто якщо на хості tcpdump -i $ext_if and host $docker побачиш траф, який виходить з докера (apt update), це означає, що щось далі.

On 08/01/23 8:42, Oleh Hrynchuk wrote:

Доброго дня всім,

Шановне панство, маю питання стосовно security policy в private VPC of AWS.

Суть в наступному.

Нам "старші товариші з US" приписали завести одну docker-type аплікуху в спеціально виділеній private VPC на спеціальному ЕС2. "Спеціальність" останнього полягає в попередній "заточці" стандартного Amazon Linux 2 AMI під корпоративні правила безпеки. Зокрема вмиканні там SeLinux, сетапі спеціальних nftables.rules тощо.

І вийшло так, що ніби все з матюками вдалося зробити (SELinux довелося вирубати "за згодою сторін") за винятком одного: email notifications (на порт 587 GMail SMTP) принципово з контейнера не ходять. А ось із docker host (отого ЕС2) - нормально ходять. Також неможливо з докер-контейнера (там Ubuntu) виконати оновлення OS (apt update) - нема доступу назовні.

Враження наступне - з контейнера НЕМА доступу до Інтернета. З docker-хоста - є. Ще така фігня, що в контейнері нема найнеобхідніших інструментів для траблшутинга - навіть ping/traceroute. І не поставиш - apt не має виходу назовні. (Ну, тут можна із"їбнутися і підсунути щось в docker volume напряму... ще ось не пробував так, але спробую).

Підозра падає на NAT Gateway між private VPC та outside world.

Чи хтось з таким стикався і що робити, щоби це а) точно локалізувати; б) полікувати цю фігню. Може це якась стандартна фігня, а я не знаю про це?

Дякую.

-- Regards, /oleh hrynchuk

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

привіт Л2 можна перевірити з хост-системи, просто подивитись таблицю арп та й пінги в сторону контейнера повинні йти. Якщо пінги ходять в контейнер, тоді можна встановити на хост-машині проксі-сервер і вже через нього встановити в контейнер софт для діагностики. нд, 8 січ. 2023 р. о 08:43 Oleh Hrynchuk пише:

Доброго дня всім,

Шановне панство, маю питання стосовно security policy в private VPC of AWS.

Суть в наступному.

Нам "старші товариші з US" приписали завести одну docker-type аплікуху в спеціально виділеній private VPC на спеціальному ЕС2. "Спеціальність" останнього полягає в попередній "заточці" стандартного Amazon Linux 2 AMI під корпоративні правила безпеки. Зокрема вмиканні там SeLinux, сетапі спеціальних nftables.rules тощо.

І вийшло так, що ніби все з матюками вдалося зробити (SELinux довелося вирубати "за згодою сторін") за винятком одного: email notifications (на порт 587 GMail SMTP) принципово з контейнера не ходять. А ось із docker host (отого ЕС2) - нормально ходять. Також неможливо з докер-контейнера (там Ubuntu) виконати оновлення OS (apt update) - нема доступу назовні.

Враження наступне - з контейнера НЕМА доступу до Інтернета. З docker-хоста - є. Ще така фігня, що в контейнері нема найнеобхідніших інструментів для траблшутинга - навіть ping/traceroute. І не поставиш - apt не має виходу назовні. (Ну, тут можна із"їбнутися і підсунути щось в docker volume напряму... ще ось не пробував так, але спробую).

Підозра падає на NAT Gateway між private VPC та outside world.

Чи хтось з таким стикався і що робити, щоби це а) точно локалізувати; б) полікувати цю фігню. Може це якась стандартна фігня, а я не знаю про це?

Дякую.

-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Привіт, Я б попершу подивився, чи є егресс пакет від докеру на зовнішньому інтерфейсі вже "заначений", і, що суттєво - який src ip. Тобто ти робиш apt update, і ця активність повинна виходити із зовнішнього інтерфейса хоста. Якщо її там немає, то скоріше за все є богус фільтр на хості. Пакет з зовнішнього адаптера повинен вийти. Ну а далі питання - він виходить з ip хоста, чи з ip контейнера. У першому випадку - до VPC gateway йдемо або до полісі у VPC, у другому (ip контейнера) - треба робити NAT. Не бажаєш tcp proxy поставити на хост ? Відправляти через нього. Тоді і NAT не треба буде робити на хості, логгінг активності, усе таке. Секюрна тема :) On 08/01/23 13:18, Oleh Hrynchuk wrote:

Дякую, колеги.

Проблема дійсно десь на подальших хопах від docker host.

tcpdump показує, що запити від контейнера (результат запущеної там команди *apt update*) покидають зовнішній інтерфейс eth0 docker-хоста. І десь губляться далі (відповіді вже не приходять). Буду далі колупатися.

Причому приватна AWS VPC має адреси 10.х.х.х/24, а docker network 172.17.0.0/16 http://172.17.0.0/16. Тому mismatching ІР-адрес там не відбувається. NACL ніби нормально там... ось NAT gateway ще не дивився...

нд, 8 січ. 2023 р. о 12:29 VASYL MELNYK пише:

привіт

Л2 можна перевірити з хост-системи, просто подивитись таблицю арп та й пінги в сторону контейнера повинні йти. Якщо пінги ходять в контейнер, тоді можна встановити на хост-машині проксі-сервер і вже через нього встановити в контейнер софт для діагностики.

нд, 8 січ. 2023 р. о 08:43 Oleh Hrynchuk пише:

Доброго дня всім,

Шановне панство, маю питання стосовно security policy в private VPC of AWS.

Суть в наступному.

Нам "старші товариші з US" приписали завести одну docker-type аплікуху в спеціально виділеній private VPC на спеціальному ЕС2. "Спеціальність" останнього полягає в попередній "заточці" стандартного Amazon Linux 2 AMI під корпоративні правила безпеки. Зокрема вмиканні там SeLinux, сетапі спеціальних nftables.rules тощо.

І вийшло так, що ніби все з матюками вдалося зробити (SELinux довелося вирубати "за згодою сторін") за винятком одного: email notifications (на порт 587 GMail SMTP) принципово з контейнера не ходять. А ось із docker host (отого ЕС2) - нормально ходять. Також неможливо з докер-контейнера (там Ubuntu) виконати оновлення OS (apt update) - нема доступу назовні.

Враження наступне - з контейнера НЕМА доступу до Інтернета. З docker-хоста - є. Ще така фігня, що в контейнері нема найнеобхідніших інструментів для траблшутинга - навіть ping/traceroute. І не поставиш - apt не має виходу назовні. (Ну, тут можна із"їбнутися і підсунути щось в docker volume напряму... ще ось не пробував так, але спробую).

Підозра падає на NAT Gateway між private VPC та outside world.

Чи хтось з таким стикався і що робити, щоби це а) точно локалізувати; б) полікувати цю фігню. Може це якась стандартна фігня, а я не знаю про це?

Дякую.

-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Regards, /oleh hrynchuk

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Привіт, Скоріше за все так і є. Але питання починалося з "секюрного сетапа". Наприклад файрвол з чекінгом TTL, або закритий файрвол на VPC ext gateway. Коли це фінансова установа - це джентльменський набір трапів для IDS. On 12/01/23 15:00, Oleksandr Moskalenko wrote:

Привет

Компоненты AWS тут вообще не при чем, дело в сети на самом хосте. У докера есть несколько режимов, у тебя скорее всего Bridge, для него нужно включать форвардинг на хосте, я бы начал с него.

PS: Идеология контейнеризации не подразумевает обновления ОС и других компонентов в процессе работы и рекомендуется ФС делать readonly

On Sun, Jan 8, 2023 at 1:07 PM Volodymyr Sharun wrote:

Привіт,

Я б попершу подивився, чи є егресс пакет від докеру на зовнішньому інтерфейсі вже "заначений", і, що суттєво - який src ip. Тобто ти робиш apt update, і ця активність повинна виходити із зовнішнього інтерфейса хоста. Якщо її там немає, то скоріше за все є богус фільтр на хості. Пакет з зовнішнього адаптера повинен вийти.

Ну а далі питання - він виходить з ip хоста, чи з ip контейнера. У першому випадку - до VPC gateway йдемо або до полісі у VPC, у другому (ip контейнера) - треба робити NAT.

Не бажаєш tcp proxy поставити на хост ? Відправляти через нього. Тоді і NAT не треба буде робити на хості, логгінг активності, усе таке. Секюрна тема :)

On 08/01/23 13:18, Oleh Hrynchuk wrote:

...

Дякую, колеги.

Проблема дійсно десь на подальших хопах від docker host.

tcpdump показує, що запити від контейнера (результат запущеної там команди *apt update*) покидають зовнішній інтерфейс eth0 docker-хоста. І десь губляться далі (відповіді вже не приходять). Буду далі колупатися.

Причому приватна AWS VPC має адреси 10.х.х.х/24, а docker network 172.17.0.0/16 http://172.17.0.0/16. Тому mismatching ІР-адрес там не відбувається. NACL ніби нормально там... ось NAT gateway ще не дивився...

нд, 8 січ. 2023 р. о 12:29 VASYL MELNYK пише:

привіт

Л2 можна перевірити з хост-системи, просто подивитись таблицю арп та й пінги в сторону контейнера повинні йти. Якщо пінги ходять в контейнер, тоді можна встановити на хост-машині проксі-сервер і вже через нього встановити в контейнер софт для діагностики.

нд, 8 січ. 2023 р. о 08:43 Oleh Hrynchuk пише:

Доброго дня всім,

Шановне панство, маю питання стосовно security policy в private VPC of AWS.

Суть в наступному.

Нам "старші товариші з US" приписали завести одну docker-type аплікуху в спеціально виділеній private VPC на спеціальному ЕС2. "Спеціальність" останнього полягає в попередній "заточці" стандартного Amazon Linux 2 AMI під корпоративні правила безпеки. Зокрема вмиканні там SeLinux, сетапі спеціальних nftables.rules тощо.

І вийшло так, що ніби все з матюками вдалося зробити (SELinux довелося вирубати "за згодою сторін") за винятком одного: email notifications (на порт 587 GMail SMTP) принципово з контейнера не ходять. А ось із docker host (отого ЕС2) - нормально ходять. Також неможливо з докер-контейнера (там Ubuntu) виконати оновлення OS (apt update) - нема доступу назовні.

Враження наступне - з контейнера НЕМА доступу до Інтернета. З docker-хоста - є. Ще така фігня, що в контейнері нема найнеобхідніших інструментів для траблшутинга - навіть ping/traceroute. І не поставиш - apt не має виходу назовні. (Ну, тут можна із"їбнутися і підсунути щось в docker volume напряму... ще ось не пробував так, але спробую).

Підозра падає на NAT Gateway між private VPC та outside world.

Чи хтось з таким стикався і що робити, щоби це а) точно локалізувати; б) полікувати цю фігню. Може це якась стандартна фігня, а я не знаю про це?

Дякую.

-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Regards, /oleh hrynchuk

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Привіт, Форвардінг у широкому сенсі (NAT, firewall, FIBs) Доречі може так бути що кожний namespace (читай - контейнер) має свою FIB, яка коннектед із бриджем, але дефолту немає. Тому дофіга варіантів на хості і перше, що дасть відповідь у методі вирішення проблем "ділення на два" - це чи є егресс пакет на зовнішньому інтерфейсі хоста, який породжується apt update'ом в контейнері. On 12/01/23 15:51, Oleh Hrynchuk wrote:

Привіт всім.

ну, таку штуку я ще здатен передбачити...

image.png

чт, 12 січ. 2023 р. о 15:00 Oleksandr Moskalenko пише:

Привет

Компоненты AWS тут вообще не при чем, дело в сети на самом хосте. У докера есть несколько режимов, у тебя скорее всего Bridge, для него нужно включать форвардинг на хосте, я бы начал с него.

PS: Идеология контейнеризации не подразумевает обновления ОС и других компонентов в процессе работы и рекомендуется ФС делать readonly

On Sun, Jan 8, 2023 at 1:07 PM Volodymyr Sharun wrote:

Привіт,

Я б попершу подивився, чи є егресс пакет від докеру на зовнішньому інтерфейсі вже "заначений", і, що суттєво - який src ip. Тобто ти робиш apt update, і ця активність повинна виходити із зовнішнього інтерфейса хоста. Якщо її там немає, то скоріше за все є богус фільтр на хості. Пакет з зовнішнього адаптера повинен вийти.

Ну а далі питання - він виходить з ip хоста, чи з ip контейнера. У першому випадку - до VPC gateway йдемо або до полісі у VPC, у другому (ip контейнера) - треба робити NAT.

Не бажаєш tcp proxy поставити на хост ? Відправляти через нього. Тоді і NAT не треба буде робити на хості, логгінг активності, усе таке. Секюрна тема :)

On 08/01/23 13:18, Oleh Hrynchuk wrote:

...

Дякую, колеги.

Проблема дійсно десь на подальших хопах від docker host.

tcpdump показує, що запити від контейнера (результат запущеної там команди *apt update*) покидають зовнішній інтерфейс eth0 docker-хоста. І десь губляться далі (відповіді вже не приходять). Буду далі колупатися.

Причому приватна AWS VPC має адреси 10.х.х.х/24, а docker network 172.17.0.0/16 http://172.17.0.0/16. Тому mismatching ІР-адрес там не відбувається. NACL ніби нормально там... ось NAT gateway ще не дивився...

нд, 8 січ. 2023 р. о 12:29 VASYL MELNYK пише:

привіт

Л2 можна перевірити з хост-системи, просто подивитись таблицю арп та й пінги в сторону контейнера повинні йти. Якщо пінги ходять в контейнер, тоді можна встановити на хост-машині проксі-сервер і вже через нього встановити в контейнер софт для діагностики.

нд, 8 січ. 2023 р. о 08:43 Oleh Hrynchuk пише:

Доброго дня всім,

Шановне панство, маю питання стосовно security policy в private VPC of AWS.

Суть в наступному.

Нам "старші товариші з US" приписали завести одну docker-type аплікуху в спеціально виділеній private VPC на спеціальному ЕС2. "Спеціальність" останнього полягає в попередній "заточці" стандартного Amazon Linux 2 AMI під корпоративні правила безпеки. Зокрема вмиканні там SeLinux, сетапі спеціальних nftables.rules тощо.

І вийшло так, що ніби все з матюками вдалося зробити (SELinux довелося вирубати "за згодою сторін") за винятком одного: email notifications (на порт 587 GMail SMTP) принципово з контейнера не ходять. А ось із docker host (отого ЕС2) - нормально ходять. Також неможливо з докер-контейнера (там Ubuntu) виконати оновлення OS (apt update) - нема доступу назовні.

Враження наступне - з контейнера НЕМА доступу до Інтернета. З docker-хоста - є. Ще така фігня, що в контейнері нема найнеобхідніших інструментів для траблшутинга - навіть ping/traceroute. І не поставиш - apt не має виходу назовні. (Ну, тут можна із"їбнутися і підсунути щось в docker volume напряму... ще ось не пробував так, але спробую).

Підозра падає на NAT Gateway між private VPC та outside world.

Чи хтось з таким стикався і що робити, щоби це а) точно локалізувати; б) полікувати цю фігню. Може це якась стандартна фігня, а я не знаю про це?

Дякую.

-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Regards, /oleh hrynchuk

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Regards, /oleh hrynchuk

+ к этому нужен NAT на исходящем интерфейсе On Thu, Jan 12, 2023 at 5:32 PM Oleksandr Moskalenko < alexander.moskalenko@gmail.com> wrote:

Вот мой sysctl от Fedora 33

# sysctl -a | grep forwa | grep '= 1' *net.ipv4.conf.all.forwarding = 1* net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.docker0.forwarding = 1 net.ipv4.conf.enp2s0f0.forwarding = 1 net.ipv4.conf.enp2s0f1.forwarding = 1 net.ipv4.conf.lo.forwarding = 1 net.ipv4.conf.virbr0.forwarding = 1 *net.ipv4.ip_forward = 1* net.ipv4.ip_forward_update_priority = 1

Amazon Linux 2 основан на CentOS 7, но по идее в этом плане отличий быть не должно

On Thu, Jan 12, 2023 at 2:52 PM Oleh Hrynchuk wrote:

...

Привіт всім.

ну, таку штуку я ще здатен передбачити...

[image: image.png]

чт, 12 січ. 2023 р. о 15:00 Oleksandr Moskalenko < alexander.moskalenko@gmail.com> пише:

...

Привет

Компоненты AWS тут вообще не при чем, дело в сети на самом хосте. У докера есть несколько режимов, у тебя скорее всего Bridge, для него нужно включать форвардинг на хосте, я бы начал с него.

PS: Идеология контейнеризации не подразумевает обновления ОС и других компонентов в процессе работы и рекомендуется ФС делать readonly

On Sun, Jan 8, 2023 at 1:07 PM Volodymyr Sharun wrote:

...

Привіт,

Я б попершу подивився, чи є егресс пакет від докеру на зовнішньому інтерфейсі вже "заначений", і, що суттєво - який src ip. Тобто ти робиш apt update, і ця активність повинна виходити із зовнішнього інтерфейса хоста. Якщо її там немає, то скоріше за все є богус фільтр на хості. Пакет з зовнішнього адаптера повинен вийти.

Ну а далі питання - він виходить з ip хоста, чи з ip контейнера. У першому випадку - до VPC gateway йдемо або до полісі у VPC, у другому (ip контейнера) - треба робити NAT.

Не бажаєш tcp proxy поставити на хост ? Відправляти через нього. Тоді і NAT не треба буде робити на хості, логгінг активності, усе таке. Секюрна тема :) On 08/01/23 13:18, Oleh Hrynchuk wrote:

Дякую, колеги.

Проблема дійсно десь на подальших хопах від docker host.

tcpdump показує, що запити від контейнера (результат запущеної там команди *apt update*) покидають зовнішній інтерфейс eth0 docker-хоста. І десь губляться далі (відповіді вже не приходять). Буду далі колупатися.

Причому приватна AWS VPC має адреси 10.х.х.х/24, а docker network 172.17.0.0/16. Тому mismatching ІР-адрес там не відбувається. NACL ніби нормально там... ось NAT gateway ще не дивився...

нд, 8 січ. 2023 р. о 12:29 VASYL MELNYK пише:

...

привіт

Л2 можна перевірити з хост-системи, просто подивитись таблицю арп та й пінги в сторону контейнера повинні йти. Якщо пінги ходять в контейнер, тоді можна встановити на хост-машині проксі-сервер і вже через нього встановити в контейнер софт для діагностики.

нд, 8 січ. 2023 р. о 08:43 Oleh Hrynchuk пише:

...

Доброго дня всім,

Шановне панство, маю питання стосовно security policy в private VPC of AWS.

Суть в наступному.

Нам "старші товариші з US" приписали завести одну docker-type аплікуху в спеціально виділеній private VPC на спеціальному ЕС2. "Спеціальність" останнього полягає в попередній "заточці" стандартного Amazon Linux 2 AMI під корпоративні правила безпеки. Зокрема вмиканні там SeLinux, сетапі спеціальних nftables.rules тощо.

І вийшло так, що ніби все з матюками вдалося зробити (SELinux довелося вирубати "за згодою сторін") за винятком одного: email notifications (на порт 587 GMail SMTP) принципово з контейнера не ходять. А ось із docker host (отого ЕС2) - нормально ходять. Також неможливо з докер-контейнера (там Ubuntu) виконати оновлення OS (apt update) - нема доступу назовні.

Враження наступне - з контейнера НЕМА доступу до Інтернета. З docker-хоста - є. Ще така фігня, що в контейнері нема найнеобхідніших інструментів для траблшутинга - навіть ping/traceroute. І не поставиш - apt не має виходу назовні. (Ну, тут можна із"їбнутися і підсунути щось в docker volume напряму... ще ось не пробував так, але спробую).

Підозра падає на NAT Gateway між private VPC та outside world.

Чи хтось з таким стикався і що робити, щоби це а) точно локалізувати; б) полікувати цю фігню. Може це якась стандартна фігня, а я не знаю про це?

Дякую.

-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Regards, /oleh hrynchuk

_______________________________________________ uanog mailing listuanog@uanog.kiev.uahttps://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Regards, /oleh hrynchuk