January 2023 - UANOG

Operational Support Systems for software development?
by Oleh Hrynchuk 25 Jan '23

25 Jan '23

Доброго дня, колеги. Керівництво доросло до розуміння потреб чогось на зразок "OSS for software development". Зокрема ось хотєлкі (нижче). Вони стосуються в першу чергу нашої AWS-інфраструктури. Може хтось щось підкаже в цьому плані? А то по телко я ніби в курсі, а ось по software development та програмних комплексах/системах ні. Може якісь стандарти/рекомендації напрацьовані/існують у світі для управління цим усім господарством? Ну і готові системи управління... Ось самі хотєлкі (просто тези, котрі вдалося застенографувати): --------------- Хотілося б мати завжди актуальну (up to date) інвентаризацію всіх програмних систем у нашому середовищі розробки. Що потрібно від цієї інвентаризації: 1. Перелік всіх елементів інфраструктури, систем та програмного забезпечення, якими ми користуємося і за які несемо відповідальність 2. Які версії операційних систем та програмного забезпечення працюють на кожній такій системі? 3. Хто несе відповідальність за те, що система правильно налаштована та експлуатується в усіх відношеннях? Хто "власник" системи? 4. Як здійснюється моніторинг кожної системи? (Варіанти: ніяк, Intruder, Wuzah, централізоване ведення журналу, локальне ведення журналу тощо) 5. Хто переглядає вихідні моніторингові дані? 6. Як налаштовується кожна система? (Варіанти: вручну, Terraform, інша автоматизація тощо) 7. Де можна знайти документацію для правильного налаштування кожної системи? 8. Який статус безпеки системи? (Варіанти: невідомий, сумісний з CIS, сумісний з SOC2 тощо) 9. Хто відповідає за безпеку в системі? 10. Хто має адміністративний доступ до системи? 11. Які зв'язки з іншими системами має дана система? 12. Чи має система зовнішні підключення до Інтернету? 13. Дата останнього перегляду/використання/логіну в систему? 14. Все інше, що забули явно вказати, але про що повинні знати... Після того, як ми створимо інвентаризацію, нам знадобляться процеси, щоб підтримувати її в актуальному стані, періодично переглядати її і переконатися, що люди не змінюють інфраструктуру і виробництво, не пройшовши відповідний процес (change management). Наприклад, ми не повинні запускати незаплановані, незатверджені, необліковані системи, програмне забезпечення та послуги. Нам потрібно задокументувати геть усі наші продукти, системи, все, що маємо і почати виправляти ті місця, де управління не є повністю зрілим, відповідно до найкращих інженерних практик. Чому? Будь-яка система є потенційним вектором атаки. Будь-яка ненадійна система - це потенційний незадоволений клієнт. Будь-який інцидент безпеки або збій системи шкодить нашій репутації. Будь-яке розслідування, проведене зовнішньою організацією, повинно виявити, що ми належним чином управляємо своїми системами та послугами, використовуючи найкращі інженерні практики та операції відповідно до існуючих стандартів. Щоб досягти цього, ми повинні постійно бути в курсі того, що саме ми маємо. ----------------------- Дякую. -- Regards, /oleh hrynchuk

2 2

AWS private VPC, NAT gateway, ACL... нема доступу в outside world from docker container of docker host.
by Oleh Hrynchuk 12 Jan '23

12 Jan '23

Доброго дня всім, Шановне панство, маю питання стосовно 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

6 12

Wi-Fi ретранслятор з акумулятором
by Volodymyr Melnyk 11 Jan '23

11 Jan '23

Шановне панство, а чи зустрічав хтось десь такі ретранслятори Wi-Fi, щоб у них всередині десь акумуляторчик був, аби він, коли живлення подається, підзаряджався, а коли немає - продовжував собі певний час працювати тихенько всім на радість? Дякую.

7 12

Sam Halabi "OSPF Design Guide"
by Volodymyr Litovka 01 Jan '23

01 Jan '23

Привіт, ще раз в Новим Роком! Нехай це буде рік нашого планування, а не чійогось. Питання - те, що раніше було доступно в два кліки в гуглі, тепер можу знайти тільки на сайтах з реєстрацію. Бісить. У кого в заначці є "OSPF Design Guide" славнозвісного Сема Хелебі (Sam Halabi)? Треба військовим віддати для самонавчання. Може _крім_ вищезазначеної книги у когось щось знайдеться в укр або рус перекладі? Я свої давешні тренінги підсунув, але документації _простими словами_ завжди мало було. Дякую. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

1 1