Search the Community

La un tutorial ASM facut de @c0unt3rlog1c despre un udp flooder au fost ceva intrebari puse de @Zatarra; Pentru a nu altera threadul omului, am deschis discutia asta. Sunt sigur ca sunt multi care au astfel de intrebari. Va astept aici cu orice intrebare legata de atacurile (D)DoS, efectele acestora cat si metodele de inlaturare ale efectelor. Din exemplul meu din acel thread: 21:07:38.225850 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.225855 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.225857 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.225867 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.225869 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.225994 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.225996 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.225998 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.225999 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 Se pot observa urmatoarele caracteristici ale acestui atac (profilul): - Srcaddr este static (172.16.0.4) - Srcport este static (37438) - Dstport este static (80) ; Avand port 80, tinta atacului este serviciul web. - Lungimea pachetului nu este variabila (length 1) - Atacul este de tip UDP / Non spoofed. Nota: Atacurile udp vizeaza congestia conexiunii. Este un atack ce 'consuma' latimea de banda. Deci, chiar daca filtrati atacul (caz in care pachetele nu mai sunt procesate), latimea de banda o sa fie utilizata. O sa luam intrebarile puse in threadul celalalt (le folosim ca scenarii): - Solutia in ambele scenarii, avand in vedere exemplul de atac de mai sus este filtrarea pachetelor UDP ce au ca tinta portul 80. Acesta fiind folosit de HTTP, comunicarea client->server se face doar pe TCP.