Securitate prin obscuritate

De ce ma simplu nu punem un LB +/- CloudFlare (deci doar 80 si 443) sau ceva similar in-house iar tot ce tine de infrastructura (deploys etc.) VPN combinat cu ceva similar a la Kubernetes sau in-house Docker etc.?

sau revenind la exemplul tau care tot primeste additions - cum ar arata de sus o varianta secure pt. un start-up?

1 Like

Ma rog, aici deja am intrat in despicat firul in 1024, initial era vorba despre cum ne putem imbunatati securitate folosind obscuritatea. Din 5 reguli de firewall ai scapat de 99% din script-kiddies. Alte metode ar fi de exemplu utilizarea unui server http/framework care sa nu fie mainstream. Un bug in apache sau nginx sau wordpress sau magento nu are cum sa afecteze un web server sau un framework dezvoltat in-house, va trebui ca atacatorul sa dezvolte unelte de hacking special pentru tine. Daca nu esti NASA sau vreo banca, cine naiba sta sa-si piarda timpul cu tine :slight_smile:

Pei stai un pic - ai propus o solutie iar n-users au venit with actual constructive critique.

Din punctul meu de vedere - daca nu esti sysadmin ce ai pus mai sus nu merge deloc i.e. you will shoot yourself in the foot e.g. un coleg uita sa puna -p 57392 si blocheaza accesul pt. the whole team.

Ok atunci, challenge accepted :slight_smile: Sa zicem ca ne-am impuscat in picior. Daca inainte sa ne impuscam am avut fericita inspiratie sa punem un port-knocking access suntem in regula:

-A INPUT -m recent --rcheck --seconds 86400 --name good_guys --rsource -j ACCEPT
-A INPUT -p udp --dport 43490 -m recent --set --name good_guys --rsource --match string --algo kmp --string "deschide poarta" -j ACCEPT
[... restul de reguli ...]

Regula de mai sus iti va whitelista ip-ul pentru 24 de ore, daca trimiti un pachet udp la portul 43490, cu textul “deschide poarta”.

echo -n "deschide poarta" >/dev/udp/$IP_SSH/43490
1 Like

Ok, insa is still an annoyance (for a team) also care este contextul aici? presupun ca un singur VM public facing nu?

In sensul ca incerc sa-mi dau seama cum ai folosi all these tips in the real world.

Iar asta ar fi varianta cu access exclusiv prin port knocking:

-A INPUT -m recent --rcheck --seconds 60 --name good_guys --rsource -j ACCEPT
-A INPUT -p udp --dport 60 -m recent --set --name good_guys --rsource --match string --algo kmp --string "deschide poarta" -j ACCEPT

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT -m comment --comment "accept http"
-A INPUT -j REJECT

Faci o mica aplicatie care sa trimita pachete udp cu string-ul care descuie poarta pentru un minut. Ai inchis aplicatia, s-a taiatul accesul la ssh.

1 Like

Sa zicem ca nu-ti mai bati capul cu script-kiddies. Astia sunt relativ inofensivi, dar pot fi sâcâitori si din cauza “zgomotului” pe care il provoaca in loguri s-ar putea sa-ti scape chestii cu adevarat importante.

But does this scale beyond one VM?

In ce sens?

Am scris un pic mai sus, o app web standard, infrastructura este un LB in fata si VMs +/- containers in spate - care de obicei stau intr-un internal network. Iar LB vin as a IaaS nu treb. configurate manual.

Cred ca e cam exagerat sa spunem ca o aplicatie web standard are nevoie de load-balancing :slight_smile:

Nu stiu, banuiesc ca intr-un fel sau altul developerii au nevoie de acces remote la infrastructura pe care stă aplicatia. Ca e ssh, ca e cvs/svn/git, ca e vpn, ca e alta metoda de acces, consider ca e o idee foarte buna sa nu laşi expuse aceste servicii esentiale direct, la dispozitia tuturor. Stiu, avem parole, chei ssh etc. Doar ca astea sunt inutile in cazul unui exploit care permite bypass-ul autentificarii.

Nu e exagerat deloc.

  1. Nu există o aplicație web standard;
  • Dacă ai … nu știu, 50.000 unici simultan, ce faci? Pui un banner mare pe prima pagină în care spui „ne pare rău, noi avem o aplicatie web standard, nu putem scala pe mai multe servere”?

Eu am imprumutat terminologia folosita de colegul dakull :slight_smile:

O aplicatie o dimensionezi in functie de profilul ei. Ar fi o risipa incredibila sa faci o aplicatie capabila sa serveasca 50k clienti simultan, cand tu o sa ai 10 vizitatori pe ora.

Avand in vedere ca ai nevoie de un sysadmin pt. a implementa ce este mai sus - as merge pe cat mai mult IaaS-way - mai ales cat de cheap sunt lately (un managed LB este 20$ iar pt. simple stuff a Heroku dyno este 7$)

Iar in loc sa scriu aplicatii pt. cazul in care imi prind degetele in my own web - mai simplu scriu the damn app that will actually generate profit (or not).

Don’t get me wrong - that kind of knowledge is fun but if you can’t fully master it, one should just leave it at fun …

EDIT: cred ca mi-am rasp. si la intrebarea de ce sysadmins are kinda rare lately cel putin in the start-up world and in the early stages.

1 Like