Bug or Defect?

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

Як кажуть сказав 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: Відео для вас для повного розуміння як працює наглядно)))

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

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

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

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

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

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

Друзі привіт - як ваш день?
Сподіваюсь ви в безпеці, а кава вже вариться, бо без неї 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 - от там буде “без підтверджень, без гарантій, але дуже швидко”.

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

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

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

Друзі, привіт! Раз ми з вами вже залізли в історію про таймаути, tcpdump і “сервер мене не любить”, то хочу дати вам ще одну корисну штуку.

Бо, чесно, половина всіх розслідувань у Linux починаються не з магії, а з базових команд.
І часто я бачу одне й те саме: люди заходять на сервер… і зависають.
Типу: а далі що?

От саме для цього я й кидаю вам цю маленьку шпаргалку.
Вона як стартовий набір для виживання на будь-якому проєкті:
Це той мінімум, без якого будь-яке КУА-розслідування перетворюється на ворожіння по логах.

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

Всім гарного вечора! і початок вихідних
Сильні 💛💛💛

Доброго ранку банда! Як ваш ранок?
Слухайте, хочу вам розказати як я вчора в 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 відповідає повільно» )

І так

Чому не (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)
Хто ні - нічого страшного, тепер будете знати з чого починати.

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

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

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

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

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

Сильні💛💛💛

Друзі привіт - як ваш ранок?

Я все поки в запарі на роботі і налаштуванні свого енв)

Є для вас круте пояснення роботи одного з протоколів, мені подобається формат а вам? Чайники не про васС))

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

Доброго ранку, друзі!
Як ви? Як пройшли вихідні?

А у мене вихідні почався з міні-катастрофи(
Мій старий сервер, на якому ми роками ганяли SQL / NoSQL / Linux-лаби / демки - просто злетів.
Не впав, не завис - контора просто перестала його сапортити.

Всі середовища, налаштування, тестові бази, постановки, пайплайни… в трубу.
Болить тільки за учнів, які зараз зі мною в навчанні - і чекають поки я це все відновлю (

Але нічого - піднімемо нове.
І навіть краще. Уже думаю чи не пора зробити собі свій олдскульний домашній дата-центр на 3–4 ТБ, щоб більше ніхто не ламав мою КУА-лабораторію 😄

А тепер шо я хочу вам сказать)
Останнім часом у мене рекомендації просто кишать відео про мікрочіпи, кремнієві фабрики і виробництво. Мабуть я занадто захопився цією темою)

Але ви уявіть, який там рівень тестування.
Ці системи тестують не тільки виробництво, а й:

- пропускну здатність,
- деградацію матеріалів,
- напругу,
- температурні коливання,
- дефекти на рівні нанометрів.
І це ж теж КУА, просто на іншому рівні.
От реально круто же дорости до такого рівня інженерії.

Натрапив на статтю про те, як тестують напівпровідники. Дуже стисло, але технічно і по суті:
https://mptestequipment.com/blog/how-semiconductor-testing-works/

Подумав - може і вам буде цікаво. Бо QA - це не тільки UI/REST/кнопочки. Це цілий світ технологій.

Всім гарного дня і настрою. Обняв!
Сильні 💙

P.S. якщо маєте поради по стабільному сервісу для піднятя Linux-середовища на пару терабайт - буду дуже вдячний. Я вже дивлюсь у бік Hetzner але може є щось прям проверене у робочих умовах?

Доброго дня друзі - як ви? як ваш день?
Ну шо ше пару годин і можно відпочівати)

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

Чесно? gRPC - це той випадок, коли REST вже не тягне по швидкості і навантаженню.
Це не просто ще один API-формат - це зовсім інший підхід.

Що я маю вам сказать сьогодні
gRPC протокол від Google поверх HTTP/2, який працює на Protobuf (бінарний формат), а не JSON.
Тому він швидший, легший і точніший.

Чому бекенди люблять gRPC?
Бо між мікросервісами треба ганяти величезну кількість даних без зайвого оверхеду.
Тому там де REST “задумується”, gRPC просто пролітає.

Виглядає API принцепі більше складніше ніж ви привикли бачити РЕСТ?

Тут не endpoint-и, а методи сервісу:

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

Все строго типізовано.
Або підходить - або не проходить. Ніяких “а тут стрінга чи інт?”

Важливий момент для КУА для розуміня
- У gRPC є 4 режими викликів:
- звичайний request/response
- сервер стрімить багато відповідей
- клієнт стрімить запити
- двосторонній стрім (майже як WebSocket)

Для чого його реально юзають:
мікросервіси / high-load / фінтех/ігри/стрімінг / real-time системи, де час відповіді важливий

Тестувати теж в принцепі не складно
BloomRPC /grpcurl / Kreya / Postman (так, тепер теж вміє)

Приклад:

grpcurl -plaintext localhost:50051 list

Що ви маєте перевіряти?
- правильність схем (Proto)
- помилки/коди статусів (вони тут свої)
- performance (gRPC створений для цього)
- роботу стрімів (часто саме там і падає) то що

Ну вроді все - є що добавити то кажіть)

Всім гарно закінчення дня)
Обняв🤗

Друзі доброго вечора!!!

Як ваш день?

Слухайте є ідея такого формата порівнювання і різниці між ти і тим умовно - як вам така ідея? буде цікаво? якщо так то з вам багато багато серденняк )))

Всім ше раз гарного вечора і головне спокійного 🤗🤗🤗