Toata lumea stie ca security through obscurity e o prostie, ca n-ar trebui sa te bazezi niciodata pe asta etc. Si totusi acest tip de protectie poate fi extrem de robust. Dau primul exemplu de scenariu care imi trece prin cap:
Schimb portul la ssh, pun unul aleator, pe care il stiu doar eu
Pun un honeypot pe portul 22, care sa inchida instant toate porturile la prima tentativa de conectare neautorizata pe ssh, in felul asta impiedic si un eventual portscan
Pun parola de login “123”
Astept… si astept… si astept… nu se intampla nimic.
Atentie, scenariul de mai sus acopera strict serviciul ssh, ignoram alte posibile portite (login local etc).
In opinia mea, securitatea prin obscuritate poate multiplica fantastic gradul de protectie pe care il asiguri strict prin metode “ortodoxe” (parola potrivit conceputa, fail2ban, acces doar de la anumite ip-uri etc).
Făra îndoială! Condiția este, așa cum ai zis la început, să nu fie baza securității tale ci ar trebui să fie un layer suplimentar, peste ce ai deja existent.
@dakull , asta e un experiment dus la absurd, in conditii normale de interes din partea “hacherilor” de duminica, aia care ne umplu logurile cu tentative naive de bruteforce.
Evident, este plauzibil sa se treaca de “protectia de mai sus”, cam asa ar fi scenariul:
Sunt suficient de destept incat sa-mi dau seama ca masina-target are un astfel de layer de protectie
Fac rost de 65535 ip-uri si testez toate porturile simultan
Unul din cele 65535 de ip-uri va primi greeting-ul de la ssh
Incep operatiunea normala de bruteforce
Dar asta inseamna ca acord o atentie deosebita acelei masini, vreau neaparat sa patrund in ea, astfel incat sa merite oboseala.
La versiunea initiala mai adaug un layer de obscuritate: inchid TOATE cele 65535 porturi si las activ un serviciu de port-knocking pe UDP (deci n-ai niciun feedback de la el), pe un port stiut doar de mine, care daca primeste un cod stiut doar de mine va deschide portul ssh. Orice tentativa de knocking pe port gresit si orice cod gresit va bloca urmatoarele tentative de port knocking.
Dar e bine de folosit urmatoarea rule-of-thumb cand ai vre-un plan ingineresc - si anume sa te intrebi: “Is {Google|Facebook|Amazon|Twitter|…} doing it?” [1]. In cazul de fata nu. Si ei chiar au niste informatii importante pe care trebuie sa le pazeasca. In schimb folosesc protocoale standard, sunt la curent cu best practices din industrie etc.
In cel mai bun caz cu chestii déatea imbunatatesti putin securitatea - ce conteaza ca nu gaseste portul cand are de trecut de SSH mai intai? In cel mai rau caz, strici protectia.
Exemplul tau pare OK. Dar sunt o groaza de probleme cu el. Trebuie sa faci un program honey pot. Trebuie sa faci un program care blocheaza porturile. Ce se intampla daca cineva face un portscan, si nimereste chiar la portul tau de ssh, isi da seama ca e ssh si incearca parolele in ordine? Toata infrastructura ta trebuie sa fie constienta de portul acela. Nu e deajuns sa stii tu de el, toti coechipierii si toate programele de infrastructura trebuie sa stie de el. Ce se intampla daca ai 100 de masini? Daca cineva vrea sa se joace cu tine, tot trimite mesaje la porturi random ca sa scoata masina din uz.
Expertii o dau in bara cu treburile astea, ce sanse avem noi, muritorii de rand sa obtinem un sistem de securitate mai bun?
[1] Relevant si pentru discutia de password rules de acum cateva zile, de exemplu. Cand ai zeci de oameni pe problema asta, gasesti solutiile OK.
Cred ca o explicatie ar fi ca evenimentele “nefericite” sunt relativ rare, “pretty good security” e suficient, iar pentru un startup costul unui sysadmin adevarat ar fi inutil de mare. Ca sa te “sparga” unul trebuie sa fii deosebit de idiot, iar atacatorul sa fie deosebit de interesat de tine in mod special.
Ce vedem noi zilnic prin loguri sunt tentative jalnice ale unor inapţi, care cauta sa penetreze serverele altora cel putin la fel de inapţi
Si ca sa nu cumva sa se inteleaga ca am parola 123 pe servere, detaliez un pic: ca prima linie de aparare folosesc sistemul asta cu port schimbat si honeypot, la nivelul urmator e acces root doar pe baza de cheie ssh, parolele nu sunt permise. Userii ordinari sunt instruiti sa foloseasca portul de ssh modificat si au acces doar cu scp/sftp, cu shell-ul scponly, chrootat.
E suficient să rulezi un scan cu nmap în Armitage și-ți identifică -în cca. 99% din cazuri, că mai dă și buleală- toate porturile deschise și serviciile rulate, indiferent că rulează pe porturi default sau setate de admin-ul server-ului.
Security through obscurity nu e o prostie (cel puțin până la un anumit nivel al organizației), dacă 1) e bine gândită și 2) se suprapune (așa cum bine a punctat @iamntz) altor straturi de securitate.
Când vine vorba de securitate-n IT: get a bloody good CERT/Pen-Testing team.
Până la un nivel al organizației, da, e suficient(ish). Gen mie mi se brehăne dacă-mi dă vreunu’ cu succes cu brute-force pe blogu’ pe WP, că nu scot bani din el și nici n-am materiale confidențiale pe el. În caz că-l folosește pe post de zombie-server cred că-mi dau seama și-l repar, asta nu-i mare bai. Da’ de la un anumit nivel în sus nu prea mai ține cu pretty good security (leak de materiale confidențiale, pierderi financiare et cetera). My 2 orts.
Singurul motiv pentru care eu schimb portul de SSH e determinat de faptul ca pe 22 e uneori un bruteforce masiv de pe botneturi si treaba asta satureaza resursele. In rest schimbarea portului e irelevanta practic fiindca oricine ti-l poate afla in cateva secunde cu nmap.
Apoi sa faci honeypot pe productie mi se pare o prostie imensa. Faci honeypot pe un DMZ inainte de productie, sau in afara serverului de productie. Honeypotul nu te ajuta cu nimic la securitate ci din contra. Daca vrei sa vezi trenduri si tipuri de atacuri atunci faci honeypot separat si vezi acolo ce si cum.
Dincolo de asta, daca esti asa de paranoic in ceea ce priveste securitatea, pe langa firewallul hardware de ce n-ai pune si un pfSense intermediar ca sa dai din el apoi net catre serverele de productie folosind NAT?
Apoi, fail2ban e previzibil. Si CSF e previzibil si orice script care se bazeaza pe regula “if not true then false”. Eu vad pe servere cu CSF bruteforce eficient doar prin prisma faptului ca baietii s-au prins care sunt regulile dupa care functioneaza CSF-ul si au reconfigurat throttle in asa fel incat sa nu faca trigger.
Nu cred ca ai fost atent la ce s-a discutat mai sus. Nmap nu poate afla nici intr-o secunda, nici in doua secunde, nici in doua zile care e portul schimbat. Daca analizezi liniile de iptables pe care le-am postat mai sus o sa-ti dai seama de ce.
Get a Chinese botnet for 2 bucks find port in minutes?
btw. nu cumva securitatea de tipul acesta de fapt te face more attacker friendly? in sensul ca daca folosesti astfel de tricks practic tipi: “I HAVE IMPORTANT STUFF HERE, STAY AWAY” and some average hacker might actually hack you just for the heck of it.
Sigur, daca inainte sa te apuci de scan verifici daca portul 80 e deschis, da, Dar are si asta o rezolvare: pe un ip ne prefacem ca avem doar serviciul http si nimic altceva (nici firewall, REJECT o sa dea impresia ca orice alt port da "connection refused’, deci serviciu inexistent), pe un al doilea ip avem doar serviciul ssh, cu “honeypot”.
$IP_HTTP=81.49.1.234
$IP_SSH=82.34.94.123
-A INPUT -m recent --rcheck --seconds 86400 --name bad_guys --rsource -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp -d $IP_SSH --dport 57392 -j ACCEPT -m comment --comment "accept ssh"
-A INPUT -p tcp -m state --state NEW -m tcp -d $IP_HTTP --dport 80 -j ACCEPT -m comment --comment "accept http"
-A INPUT -p tcp -d $IP_SSH -m multiport --dports 1:65535 -m recent --set --name bad_guys --rsource -j DROP
-A INPUT -p tcp -d $IP_HTTP -j REJECT
