Доброго ранку друзі - як ви? як ваш ранок?

Це відео якраз про те шо деви іноді роблять бяку в обход куа)
Але миж куа не повині бякі пропускати в прод) Думаю підніму вам настрій

Всім гарного дня, друга кавуся вже допита і погнали працювати)

Сьогодні буде цікава інфа))

Сильні💛💛💛

Друзі, привіт! Як ваш день?
Добрався я до розбору нового пула - і цього разу він прям життєвий для всіх, хто хоч раз ловив «сервер лагає, API відповідає повільно» )

І так

Чому не (A) systemctl status
Багато хто натиснув саме це, і я розумію чому, перша думка: «подивлюсь, чи сервіс впав».
Але… якщо на сервері вже лагає все, ця команда не покаже головне - хто конкретно вантажить систему.
Вона просто скаже «running / failed», але не дасть ні CPU, ні пам’яті, ні load average.

Так це корисно, але точно не перше, що треба запускати.

Чому не (C) ping 8.8.8.8
Ping - це перевірити інтернет, а не сервер.
API гальмує → причина всередині машини, а не у зв’язку з Google DNS. і пінг вже вмер( краше юзати неткат типо шось nc -vz host port

Ping не покаже, що у вас один процес з’їв 100% CPU і тримає систему за горло.

Чому не (D) cd /var/log
О, логи - це святе)
Але лізти туди в першу секунду - це як шукати граблі в темній кімнаті.
Спочатку треба зрозуміти, чи взагалі живий залізяка, а вже потім дивитися логи.

Ну і чому правильна відповідь (B) htop

Тут все просто:
htop - це рентген сервера за 1 секунду.

Він вам покаже
- хто жере CPU;
- хто з’їв пам’ять;
- load average;
- процеси, що зависли;
- свопінг;
- загальну температуру системи.

Ви за 2 секунди розумієте:
«ага, ось цей java/python/node процес живе власним життям і душить усе навколо».

Саме тому htop - перше, що запускає інженер, коли на сервері почалося пекло )

І що я всеж маю вам сказать)
Правильна відповідь тут - не про "знати команду", а про мислення:
спочатку діагностика заліза → потім сервіс → потім логи.

Хто вгадав з першого разу - респект, ви мислите як SRE)
Хто ні - нічого страшного, тепер будете знати з чого починати.

Всім гарного дня і настрою!
Обняв 🤗

Доброго ранку банда! Як ваш ранок?
Слухайте, хочу вам розказати як я вчора в 10 веччері попав на фокап , і коли ти думаєшь «Чорт, а я ж думав, що знаю мережі» ))

Ранкові QA-історія: як же іх давно не було ТАК???

Тестував я інтеграцію між двома сервісами.
Умовно Сервер Х шле запити на Сервер Y - і раптом половина викликів тупо падає в таймаут. Без помилок. Без 5xx. Просто тиша.
Ну окей, думаю
«Зараз три каманди в терміналі - і розберемося».
Ага… як же ж

Ну перевірка, як завжди, з очевидного

Це - nc

nc -vz server-y 9090

конект є, все красиво.

як же без telnet

telnet server-y 9090

- всі помьятають шо він робе так?
і теж ок.

ну і сurl

curl -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 показують тільки те, що можна достукатись,
А не те, що відповідь повернеться назад.

Фаєрволи інколи працюють за принципом:
«Випущу. Але назад не пущу.»
І це найпідліший тип багів.

Всім гарного дня і настрою!
Обняв, друзі 🤗🤗🤗

Друзі привіт, як ви? Ну шо як і завжди повертаємося про беспеку?
Сьогодні хочу поділитись штукою, яка, як на мене, має бути у кожного хто працює з 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 - це гарне місце почати або продовжити.
Можу зробити окремий пост з тим, як КУА може використовувати ці техніки без пентест-скилів, але дуже ефективно.

Всім гарного дня і настрою друзі
Сильні 💛💛💛

Друзі привіт - як ваш день?
Сподіваюсь ви в безпеці, а кава вже вариться, бо без неї TCP точно не зрозуміти)

Ну що??

Протоколи для QA - TCP

Якщо WebSocket - це вже “живий” канал, то TCP це, грубо кажучи, те шосе, по якому він взагалі їздить.

TCP - це базовий транспортний протокол, який забезпечує
надійну доставку даних між двома точками.

Коли вам кажуть “REST працює поверх HTTP, а HTTP поверх TCP” - це саме про нього.

Що я маю вам сказать!

Багато ваших "дивних" багів, типу
«час від часу падає запит», «перші пакети не доходять», «раптовий time-out»
- це не про бекенд.
Це про TCP-механіку.

Як взагалі той TCP працює, якщо коротко)

Handshake - і 3 кроки для встановлення з'єднання
SYN → SYN-ACK → ACK
Якщо десь тут все зависає - клієнт навіть не почав говорити з сервером.

Далі Segmentation & Reassembly
Дані ріжуться на сегменти й збираються на другому боці.
Якщо є втрати - буде повторна передача (retransmission) і це він гарантує

Потім Flow control
Сервер каже “повільніше, я не встигаю”.
Клієнт регулює швидкість.

ну і як же без Congestion control
У мережі тісно - TCP автоматично зменшує швидкість.
Саме через це іноді падає перший запит після простою.

ну і я вже расказував више вам про Keep-alive
Якщо довго нема даних - TCP може тримати з’єднання “напівживим”.
Не плутати з WebSocket ping/pong - це рівнем нижче.

Найчастіше проблеми це, Запити “висять” → це може бути проблема з handshake
- Часткові респонси або розрив з’єднання → drop сегментів
- Перший запит після idle - завжди довший → congestion window
- ну і Рандомні timeouts → firewall блочить SYN-ACK або фінальні ACK
- і Непослідовність подій у real-time сервісах → затримки в сегментах

тестувати TCP принцепі просто?

В ЮА ви цього не побачите, може побачити але складно(
Але КУА повинен вміти перевірити трафік:

1) Чи порт взагалі слухає:

nc -vz host 8080

2) Подивитись, чи SYN/ACK доходить:

tcpdump -i eth0 port 8080 -w trace.pcap

3) Аналіз у Wireshark:
чи є повторні передачі (Retransmissions)
чи SYN не завис
чи RTT не надто великий

4) Перевірити маршрут:

traceroute host

Що я хочу донести до вас)
TCP - це фундамент.
Без розуміння його роботи дуже легко переплутати: де проблема у бекенді, де проблема у фронті, а де це просто мережа сказала:
“сьогодні я працюю так, як хочу”

І так, WebSocket, REST, gRPC - всі вони живуть поверх TCP.
І часто найглибші баги сидять саме тут.

Вроді все розповів :)
Наступним розберемо UDP - от там буде “без підтверджень, без гарантій, але дуже швидко”.

Всім гарного вечора і настрою.
Обняв! 🤗🤗🤗

Доброго раночку колеги, як ваш ранок?
Ну що, повертаємось до теми безпеки - куди ж без неї зараз.

Натрапив на цікаву штуку, яка точно зайде вам) я сам ше не до кінця внирнув але початом мені дуже нравиться)
Тобто зараз все йде в беспеки - незнаючи безпеку як воно працює ми починаємо відставати як технарі від свого напрямку і це не ОК - то якщо не знаєте з чого почату тут саме про це)

Що я хочу вам сказать
хороша точка входу, щоб підтягнути фундамент і дивитись на системи не тільки як на функціонал, а як на поверхню атаки.
Для КУА це прям must-have: краще розумієш архітектуру, логіку даних і чому певні баги - це не просто “minor”, а потенційна дірка.

Саме репо тут)
https://github.com/Hacking-Notes/Hacker-Roadmap

Як хочете, можу зробити окремий пост: з чого саме почати КУА і як це використовувати без глибокого пентест-бекграунду.

Всім гарного дня і настрою, я допиваю каву і занурююсь
Обняв🤗🤗🤗
Сильні💛💛💛

Ше раз привіт банда) ну як ви проснулись?

Як кажуть сказав TCP то кажи і UDP)

Протоколи для QA - UDP

І так)
Як TCP - це “акуратний хлопець”, який перепитує кожне слово, то UDP - це той, хто просто кричить фразу через дорогу і не чекає, почули ви її чи ні.

UDP - максимально простий, швидкий, але без будь-яких гарантій доставки.
І саме тому багато систем, які працюють у реальному часі, будуються саме на ньому.

Що я маю вам сказати
UDP не встановлює з’єднання.
Немає ніякого SYN → SYN-ACK → ACK.
Ти просто береш пакет і відправляєш його на потрібний порт.

Доставиться?
Може так, може ні.
Але зате швидко.

Працює UDP, просто
Немає підтверджень
Сервер не каже “я отримав твій пакет”.
Якщо загубився - значить загубився.

Немає повторних передач
UDP не робить retransmission.
Якщо треба повтор - це має вирішувати застосунок, а не протокол.

Немає контролю потоку
Сервер не попросить “повільніше”.
Що відправиш - те й прилетить (або не прилетить).

Пакети можуть приходити не по порядку
Order - це проблема застосунку, не протоколу.

От якраз UDP дуже багато де юзають - хотя він не надійний, але є коли надійність непотрібна)
це якраз там, де швидкість важливіша за точність:

Аудіо/відео трафік
Велика затримка гірша, ніж пропущений пакет.
VoIP
Трохи пропав голос - окей. Затримка на секунду - катастрофа.
Онлайн-ігри
Гравця “подергало” - краще, ніж отримати дані на пів секунди пізніше.
DNS
Запит маленький, простий і якщо пропав - просто шлеться знову.

Скажете як перевіряти і на що треба звертати увагу?
І саме тут починається цікаве.
UDP створює дуже “дивні” баги, бо немає жодної гарантії, що ти бачиш повну картину.

Типові проблеми це
Перервані голосові/відео кадри
Пакет дропнувся і все - назад не прийде.

Різна якість на різних мережах
На Wi-Fi ок, на мобільному - повний розрив.

Пакети приходять не по порядку
У real-time це виглядає як ривки, фрізи, перекручування звуку.

Рандомні втрати під навантаженням
UDP не регулює швидкість → мережа сама починає відкидати надлишок.

Тестувати просто але тут без мережевих тулів ніяк.
Подивитись, чи взагалі летять UDP-пакети:

sudo tcpdump -i eth0 udp -w udp_trace.pcap

Подивитись у Wireshark:
чи є packet loss
чи є jitter (різкі стрибки затримок)
чи пакети приходять out-of-order

Створити навантаження:

iperf3 -u -b 5M -c host

Так можна побачити, як система поводиться при втраті пакетів.

Перевірити MTU
Дуже часто UDP “ламається” просто через fragmentation.

Мій поінт яки до вам)
UDP - це мінімум гарантій, максимум швидкості.
І якщо TCP - це стабільність, то UDP - про те, як система поводиться у реальному світі, де мережа недосконала.

Саме тому тестувати UDP-сервіси - це завжди робота не тільки з API або UI, а й з мережею, середовищем і умовами передачі трафіку.

Хочете чи ні - але без розуміння UDP важко тестувати VoIP, відеодзвінки, стрімінг, ігри, DNS і купу сучасних real-time сервісів.

Всім гарного дня і настрою.

Note: Відео для вас для повного розуміння як працює наглядно)))

Доброго ранку друзі, як ви?

а у мене вчора і сьогодні просто запара нереальна(

Ранкові історії QA) це мені тільки везе? чи у вас теж таке буває??

PM каже:
- Там дрібний фікс, взагалі не переживайте, сьогодні треба закрити срочно)

і теж Dev додає:
- Я просто додав пару ковичок у SQL, Copilot підсказав… все має працювати.

А я такий наівний запускаю smoke - і бачи, що “пара ковичок” знесла не тільки функцію, а й сусідні ендпоінти.
Пів системи лежить. Частина запитів падає по syntax error, частина - по timeout, бо бекенд навіть не може зібрати квері.

І ти в цей момент реально розумієш:
в КУА не існує “дрібного фікса”, особливо коли дев шарив SQL на рівні “ну воно ж працювало вчора”.

Бувало у вас таке?
Коли дев каже “тривіальний фікс”, а ти через 5 хвилин стоїш з блокером і розгрібаєш історію одного відсутнього апострофа.

Всім гарного дня і настрою) сподіваюсь сьогодні буде без пригод далі)

Обняв 🤗🤗🤗

Друзі, привіт! Як ваш день?
Добрався до розбору свіженького пула - і він прямо класика жанру для всіх, хто хоч раз боровся з мережами в офісі чи вдома.

і так шо я маю вам сказать

Чому не (A) ping 10.0.0.1
Ping - це перевірити один конкретний хост.
Один.
А не всю мережу.
Тут задача: побачити всіх сусідів, а не перевірити, чи живе роутер.
Ping не пробіжить нам підмережу, не покаже список активних пристроїв, нічого.

Чому не (B) ssh 10.0.0.1
SSH - це не інструмент для сканування, а для підключення.
Та й щоб підключитись, треба знати логін/пароль - ви ж не будете ламатись у всі квартири підряд. Це точно не перший крок.

Чому не (D) url http://10.0.0.1
Це взагалі перевірка веб-сервера.
А у нас задача мережевої діагностики, а не HTTP.

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

Ну чому всеж правильна відповідь (C) nmap -sn 10.0.0.0/24

Бо це і є нормальний спосіб перевірити: він реально хто живий у мережі, які IP відповідають, а які пристрої активні прямо зараз.

nmap -sn робить ping-scan по всій підмережі й повертає список реальних пристроїв, без зайвих деталей і без сканування портів.

Це реально найшвидший і найчистіший метод для такої задачі.

Який мін поінт до вас)
Це дуже базовий, але важливий навик для КУА чи будь-кого, хто хоче розуміти, що відбувається в мережі.

правило таке:
коли треба знайти всіх у мережі → завжди починаємо з nmap -sn.

Хто вгадав - респект, мислення в правильному напрямку.
Хто ні - тепер знаєте, як правильно робити первинну діагностику.

Всім гарного вечора і настрою!
Сильні💛💛💛

Друзі доброго ранку!☀️

Як ви? сподіваюсь ви всі в безпеці і ваші близкі, Одеса ми тримаймося, все 3 добу нема світла не на годинку) але зарядні станції роблять свою справу

Як в цілому ваші вихідні?

Хочу вам щось сказати - можливо я вже казав але це постійно гостра тема - особливо моїх учнів

Ранкові історії QA
Хочу сьогодні сказати одну просту, але дуже важливу річ для тих, хто тільки заходить у КУА або вже в процесі, але боїться співбесід.

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

«Я ще не готовий(а).
«А раптом спитають щось, чого я не знаю».
«Теорія слабка, практики мало».

Вчора якраз була така розмова з учнем. - так как нема світла ми чучуть побалакали по телефону) Каже:
- Я боюся йти на співбесіди.

Я питаю:
- Ну чого саме?
- Ну якщо попливу? Якщо не знатиму відповідь?

І от тут головне, що я йому сказав, і що хочу донести вам.

Саме заради цього і треба ходити на співбесіди.

Ніхто не приходить на першу співбесіду впевненим.
Ніхто не народжується з готовим досвідом.
Практика починається не з оферу, а з першої розмови з рекрутером.

Кожна співбесіда - це не іспит, це тренування.
Десь не відповів - ок, тепер знаєш, що підтягнути.
Десь поплив - значить, знайшов свою слабку точку.
Десь нормально пояснив - плюс до впевненості.

Як я раджу готуватись, якщо практики ще мало:
Ходіть на співбесіди навіть якщо в описі «1–2 роки досвіду».
Це часто просто фільтр. Якщо ти можеш логічно пояснити, як тестуєш, як думаєш і як шукаєш баги - цього вже достатньо, щоб тебе почули я вам правду скажу у мене є реальні приклади учнів які отримували офер без досвіду - де було вимога 1 рік

І так Після кожної співбесіди робіть собі рев’ю.
Запишіть питання, де було складно.
Розберіть їх вдома.
Поверніться до них через кілька днів.

Збирайте свою базу знань.
Не курси, не сертифікати - а свою.
Питання зі співбесід, кейси, SQL-запити, типові баги, ситуації з реальних проектів.
Це реально працює.

І найголовніше.
Відмова - це не поразка.
Це просто ще один крок до тієї співбесіди, де ви раптом зрозумієте:
«Стоп… а я ж це знаю. І це теж».

Страх співбесід - це страх невідомого.
А кожна наступна робить вас спокійнішими, впевненішими і сильнішими як QA.

Тому простий ранковий план:
Випили каву.
Відправили резюме.
Пішли на співбесіду.

Навіть якщо здається, що ще не готові.
Саме так і стають готовими - питайте я постійно відкрити до питань - так можу відповідати з затримкаю) але буду.

Всім гарного дня і настрою друзі
Сильні 💛💛💛
Обняв 🤗🤗🤗

Привіт друзі, як ви?

Сьогодні хочу поділитись штукою, яка реально має бути під рукою у всіх, хто хоч трохи лізе в security, API або просто глибше тестує веб.

IntruderPayloads - це репозиторій з готовими payload’ами для Burp Suite Intruder. Думаю, Burp ви і так юзаєте, а от нормальні пейлоуди часто кожен збирає по шматках сам. Тут це вже зробили за вас.

По суті, це велика база payload’ів під різні типи перевірок і вразливостей. Не “стріляти навмання”, а системно ганяти тести.

З корисного це реально
– payload’и для рекогносцировки і збору інформації
– пошук точок входу в апку (де реально можна щось інжектити)
– визначення технологій, фреймворків, серверів
– пошук прихованих URL, API, адмінок
– робота з кодами помилок і нестандартними відповідями
– перевірки SSL/TLS конфігів
– і ще купа всього під різні кейси

це допомагає дивитись на апку не тільки як “expected / actual”, а як на поверхню атаки. Навіть без пентест-ролі ви починаєте краще розуміти, де можуть бути реальні ризики і чому деви або сек’юріті кажуть “це небезпечно”.

Репо тут:
https://github.com/1N3/IntruderPayloads

Рекомендую просто зберегти собі. Навіть якщо зараз не юзаєте - момент, коли воно знадобиться, точно буде.

Сильні 💛💛💛

Це я сьогодні)

Це вам підняти настрій на вечер - я думаю кожен попадав в таку сітуейшен))