Zaščita web servisa

Na strežniku imam nek web servis, na katerega se povezuje nek drug računalnik (IP tega računalnika se spreminja).

Kakšne so kej opcije, da zaščitim ta web servis, da ne bi kar nekdo dostopal do njega? V osnovi imam neko geslo, ki ga moraš podat kot parameter, ampak to ne vem če kej koristi sploh iz smisla varnosti?

Če hočeš da se samo tisti računalnik povezuje gor potem je najbolj popolna možnost da dobiš statičen IP in potem s firewallom blokiraš vse ostalo.

Če firewall podpira avtentikacijo uporabnikov, lahko s tem še dodatno omejiš zadevo (spustiš samo avtenticiranega uporabnika).

Druga možnost je VPN povezava, s pomočjo katere ravno tako avtenticiraš uporabnika na drugi strani.

mirancar je 31. jul 2014 ob 22:18 izjavil:

tx-z je 30. jul 2014 ob 09:34 izjavil:

V osnovi imam neko geslo, ki ga moraš podat kot parameter, ampak to ne vem če kej koristi sploh iz smisla varnosti?

zakaj to nebi bilo dovolj Ok?

Ker se da lepo bruteforce napad izvest?
Ker ima web servis lahko varnostne luknje, s katerimi se ne želi ubadati, saj ima takointako samo enega (znanega) uporabnika?
itd...

Prav nič ni narobe, če razmišlja o zaščiti. Definitivno bolje, kot si reči 'na svetu je nekaj miljard IP naslovov, pa ja ne bodo glih mojega hekali'.

Poenostavljeno povedano je MITM 'napad', ko nekdo prestreže tvojo zahtevo, ki jo pošiljaš spletnemu (ali drugemu) strežniku, 'pogleda' kaj si poslal in potem namesto tebe pošlje zahtevo strežniku (lahko tudi spremenjeno zahtevo).
Ko strežnik odgovori, ta odgovor najprej prejme 'napadalec', ki lahko odgovor 'pogleda' in ti ga posreduje naprej (tudi tu lahko naredi kakšno spremembo v odgovoru).
Čar tega je, da ponavadi ne veš, da je nekdo 'bral' kar si komuniciral s spletnim strežnikom.

Sam princip kot tak, uporabljajo proxy strežniki že od pradavnine, tako da ni kar vse MITM napad, kar gre preko nekega posrednika (po tvoji volji ali brez nje). Brez tega nebi delovali caching serverji, ad-blockerji, kot tudi ne številni varnostni proxiji, ki se uporabljajo za zaščito omrežij.

O 'napadu' lahko govorimo predvsem takrat, ko se v promet vključi nekdo 'nepooblaščen' z zlemi namerami (vohljanje za podatki, gesli, namerno spreminjanje podatkov, itd.).

Avtentifikacija oz. prijava v tvoj web servis preko kakšnega AD bi morala biti v tvojem primeru na prvem mestu.

Jaz sploh nebi toliko kompliciral zaradi enega samega uporabnika (razen če imaš v načrtih dati servis na razpolago širšemu občinstvu).
Pri enem samem uporabniku postaviš OpenVPN ali kakšno IPSec varianto in se ne ubadaš z ostalimi zadevami.

Če pa imaš v planu stvari kasneje nuditi širšemu krogu uporabnikov in bi jih rad omejeval, da res lahko do servisa pridejo zgolj tisti, ki jim to dovoliš, potem se bo pa treba spogledati s SSL komunikacijo in client-side certifikati.

Reverse web proxy pa se mi zdi overkill za neko 'domačo rešitev'. Če imaš zadevo v požarni pregradi, potem jo seveda lahko uporabiš, ampak Tomato&Co mislim, da tega še dolgo ne bodo nudili.

Že mogoče, da je zadeva (nginx) preprosta, ampak načeloma ni mišljena, da bi laufala na isti mašini kot web server (če nič drugega, imaš potem probleme s porti, ki jih moraš preusmerjati). Da bi pa zaradi ENEGA uporabnika postavljal dodatno mašino, pa definitivno nima smisla.

Mufasa je 1. avg 2014 ob 11:08 izjavil:

Ssh tunell z client certom in call na localhost:19999/xy...to je ajnfoh.. vpn ki pa je cisti overkill ako je toj sole purpose dostop do enega endpointa je bloated opcija.

Če že ima vzpostavljen npr. OpenVPN (ali podobno)za lastni oddaljeni dostop, potem to ni noben tak poseben overkill.

Sploh pa se mi zdi, da OP ni povedal, na kateri platformi ima postavljen web server. Če je MS, je potem treba biti še pazljiv pri izbiri ssh software-a. Sem namreč že videl ljudi, ki so si od nevemkje navlekli nek ssh server, ki je zadnji update doživel pred desetimi leti....

OP je rekel, da se IP spreminja! Tako mu to ne nuca kaj dosti (na IP range je pa že tako omejil).

V takem primeru narediš HTTPS s client-side certifikatom - torej tvoj client naj pošlje (lahko tudi self-signed) certifikat serverju pri povezavi, server pa poskrbi da se samo tisti client lahko poveže. Podprto na praktično vseh implementacijah ter dokaj varno.