Bug or Defect?

Друзі, привіт! Як ваш день?Добрався до розбору свіженького пула - і він прямо класика жанру для всіх, хто хоч раз боровся з мережами в офісі чи вдома.і так шо я маю вам сказать Чому не (A) ping 10.0.0.1Ping - це перевірити один конкретний хост.Один.А не всю мережу.Тут задача: побачити всіх сусідів, а не перевірити, чи живе роутер.Ping не пробіжить нам підмережу, не покаже список активних пристроїв, нічого.Чому не (B) ssh 10.0.0.1SSH - це не інструмент для сканування, а для підключення.Та й щоб підключитись, треба знати логін/пароль - ви ж не будете ламатись у всі квартири підряд. Це точно не перший крок.Чому не (D) url http://10.0.0.1Це взагалі перевірка веб-сервера.А у нас задача мережевої діагностики, а не HTTP.Якщо у хоста немає веб-сервера - запит просто нічого не дасть.І навіть якщо є - це покаже лише один пристрій, а не всіх.Ну чому всеж правильна відповідь (C) nmap -sn 10.0.0.0/24Бо це і є нормальний спосіб перевірити: він реально хто живий у мережі, які IP відповідають, а які пристрої активні прямо зараз.nmap -sn робить ping-scan по всій підмережі й повертає список реальних пристроїв, без зайвих деталей і без сканування портів.Це реально найшвидший і найчистіший метод для такої задачі.Який мін поінт до вас)Це дуже базовий, але важливий навик для КУА чи будь-кого, хто хоче розуміти, що відбувається в мережі.правило таке:коли треба знайти всіх у мережі → завжди починаємо з nmap -sn.Хто вгадав - респект, мислення в правильному напрямку.Хто ні - тепер знаєте, як правильно робити первинну діагностику.Всім гарного вечора і настрою!Сильні💛💛💛

Друзі привіт, як ви? Ну шо як і завжди повертаємося про беспеку? Сьогодні хочу поділитись штукою, яка, як на мене, має бути у кожного хто працює з API - неважливо, ви QA, Dev чи просто хочете краще розуміти, що відбувається “під капотом”.Натрапив на дуже цікавий репозиторій - API Security Empire.І чесно, виглядає це як нормальний “центр управління польотами” по всіх темах безпеки для REST, GraphQL і SOAP.Що я маю вам сказать)Це зібрана в одному місці база знань по тестуванню безпеки API.Там є і майндмепи, і інструменти, і сценарії атак, і чеклісти - все, щоб не просто “тикати ендпоінти”, а реально розуміти, де слабкі місця.Реально прикольная структура• структуровані mindmap-и для розвідки і атак• нормальний список тулзів, якими реально користуються (Burp, FFUF, Arjun, Kiterunner, SecLists і т.д.)• сценарії атак під REST, GraphQL, SOAP• купа навчальних матеріалів - дуже зручно, якщо хочеш підтягнути або систематизувати знанняви же знаєте тестувати API тільки на “expected result”- це база.А от дивитися на API як на поверхню атаки - це вже зовсім інший рівень.Можна набагато краще розуміти архітектуру, поведінку запитів і логіку обробки даних.Ну і чесно, воно прокачує вашу інтуїцію QA дуже сильно.само репо:https://github.com/Cyber-Guy1/API-SecurityEmpireЯкщо хочете реально рости в темі API - це гарне місце почати або продовжити.Можу зробити окремий пост з тим, як КУА може використовувати ці техніки без пентест-скилів, але дуже ефективно.Всім гарного дня і настрою друзіСильні 💛💛💛

Доброго ранку банда! Як ваш ранок?Слухайте, хочу вам розказати як я вчора в 10 веччері попав на фокап , і коли ти думаєшь «Чорт, а я ж думав, що знаю мережі» ))Ранкові QA-історія: як же іх давно не було ТАК???Тестував я інтеграцію між двома сервісами.Умовно Сервер Х шле запити на Сервер Y - і раптом половина викликів тупо падає в таймаут. Без помилок. Без 5xx. Просто тиша.Ну окей, думаю«Зараз три каманди в терміналі - і розберемося».Ага… як же жНу перевірка, як завжди, з очевидногоЦе - ncnc -vz server-y 9090 конект є, все красиво.як же без telnettelnet server-y 9090 - всі помьятають шо він робе так? і теж ок.ну і сurlcurl -v http://server-y:9090/health і тут вже починається «вічне завантаження»… і Потім timeout.Тобто дістатися можна, а відповіді нема.Так-так, це той самий момент, коли мозок каже: «ооо, походу буде весело».Короче поліз я даліТобто сервері Y сервіс живий:Спробуємо sudo ss -tulnp | grep 9090 У логах видно, що запит прийшов і навіть була сформована відповідь, і трафік на вихід теж є - tcpdump підтвердив.І тут уже зрозумів:проблема не на стороні Y, відповідь відправляється.І ось тут почалося цікавеНа сервері X зняв дамп:Через sudo tcpdump -i eth0 host server-y -w debug.pcap Відкриваю у Wireshark.І реально видно:SYN → SYN-ACK → ACK → запит полетів → а назад пакетів НУЛЬ.Не дроп, не RST, не ICMP. Просто… нічого.Як у чорну діру.тобто розгадка яка (після години матюків і інфри)Виявилось, що сервер X після міграції в інший датацентр отримав новий набір правил фаєрвола.І там було правило типу: - дозволити вихід на порт 9090, але заборонити вхідні пакети з цього діапазону IPТобто:- вийти можна- повернутись не можнаІ curl зависав, бо пакет-відповідь просто рубився фаєрволом ще до додатку.Шо я маю вам сказать:Не ведіться на «telnet працює - значить все добре».Telnet і nc показують тільки те, що можна достукатись,А не те, що відповідь повернеться назад.Фаєрволи інколи працюють за принципом:«Випущу. Але назад не пущу.»І це найпідліший тип багів.Всім гарного дня і настрою!Обняв, друзі 🤗🤗🤗