NeTko

Statistika

Pridružen/a:
24 jul 2012, 15:58
Zadnjič aktiven:
Prispevki:
Teme:
0 | Vse teme
6
3
0
#5

Si že razmišljal o dodatnem MTA in Queue Replication? Kar en server ne zmore, bosta morda dva?


všeč(0) ni všeč(0) spam(0)
#19

Zagovorniki odprtokodnih rešitev bi lahko malo manj zagrizeno branili svoj vrtiček.



Po vašem mnenju komercialni ponudniki rešitev zgolj zmečejo skupaj nekaj odprte kode, to potlačijo v neko škatlo in gor nalepijo svojo nalepko in to potem drago prodajo.



Da nekaj 'bazira' na odprti kodi, lahko pomeni, da so si tam izposodili source za kernel, ga modificirali 'utrdili' in vključili v svojo rešitev. V sklopu rešitve so lahko uporabili tudi drugr fragmente kode drugih razvijalcev, ki ima določena licenčna pravila ali celo patente. Zato se na koncu licenčnih pravil običajno navaja tudi lastnike teh pravic. S tem pa še zdaleč ni rečeno, da ima proizvod kakršnokoli podobnost s samo rešitvijo, pri kateri so si izposodili del kode.



Zagotovo se da na odprti kodi sestaviti 'delujoč sistem'. V to nihče ne dvomi, lahko tudi najdemo na miljone takšnih sistemov. Vendar bi bil zelo zelo pazljiv pri primerjavi odprtokodne rešitve z neko zaokroženo komercialno rešitvijo.

Ko nekdo na veliko razlaga, da je njegova odprtokodna rešitev boljša od nekega Juniperja ali podobnega resnejšega proizvoda, se mi poraja misel, da takega proizvoda še nikoli ni imel priložnosti testirati in govori na osnovi izkušenj z nekimi SOHO proizvodi.



Če so odprtokodne rešitve tako superiorne, bi se potem najprej vprašal, zakaj vsi ISP-ji in velike korporacije uporabljajo komercialne rešitve in ne odprtokodne.



Kdor si vzame le minuto časa za razmislek, bo hitro ugotovil, da je problem v vzdrževanju odprtokodne rešitve. Upravljalec v podjetju lahko postane suženj odprtokodne rešitve, če hoče vsak dan spremljati, ali je kdo objavil kakšno luknjo v kodi, pa potem še išče, kje bo našel popravke, ki jih mora nato še namestiti. Ker odprtokodna rešitev ni sestavljena le iz ene komponente, ampak iz najmanj desetih, se zadeva že podeseteri. Če ima več odprtokodnih požarnih pregrad.... ?



Ker pa vsi dobro vemo, da nihče nima časa stalno se samo z požarno pregrado ukvarjati, se ponavadi zgodi, da se zadevo postavi, nato pa se jo zanemari in ne doživi nobene nadgradnje, dokler nekega dne ne zariba disk in je treba zadevo takointako na novo postaviti.

Tudi sicer so nadgradnje problematične, saj se jih praktično ne da izvajati na delujočem sistemu, brez da bi prekinili internetno povezavo. Torej moramo imeti pri roki še rezervni sistem.



Zadnje čase se na veliko uporablja besedna zveza 'security awareness' - pojem, ki je pri nas še kako na psu. Če nekdo misli, da ima varen sistem samo zato, ker je baziran na Linuxu in da ga zato ne rabi neprestano krpati, potem je ta oseba popolnoma skregana s kakršnokoli zavednostjo.



Komercialne rešitve so drage. Drži. Ene bolj, druge manj. Vendar se v ceni odraža trud, ki ga razvijalci vlagajo, da ti v paketu dostavijo vse popravke sistema, ki jih v nekaj sekundah naložiš in se lahko posvetiš drugim nalogam. Ne rabiš ure in ure tuhtati, kako boš neko novo funkcionalnost implementiral, ne rabiš iskati nasvete po forumih - vse dobiš že narejeno.



Baje, da je čas denar. Mislite, da je vaš delovni čas zastonj? Preračunajte enkrat, koliko ur bi letno porabili, če bi resno hoteli vzdrževati neko kompleksno odprtokodno rešitev, da bi imeli vse luknje v sistemu pokrpane najkasneje en teden po odkritju. Bi bili dve vaši plači dovolj? Za ta denar pa lahko že kupite dokaj spodoben komercialni proizvod, ki bo počel isto, kot vaša kompleksna rešitev, le da bo malo bolj eleganten za upravljati in nudil še dodatne funkcionalnosti, ki jih na odprti kodi nikakor niste mogli implementirati.



Res nočem v nič dajati odprtokodnih rešitev. Nekatere so odlične in iz mnogih so se kasneje razvile komercialne rešitve. Vendar je že v tem stavku bilo povedano bistvo - iz njih so se razvile - dodalo se jim je nekaj. Govorimo o dodatni funkcionalnosti, uporabniških vmesnikih, enotnem upravljanju - in ne na koncu storitvah, ki vso zgodbo zaokrožijo.



ZATO se mi zdi nepošteno sploh primerjati odprtokodne rešitve in komercialne rešitve. Ene so za akademska okolja, učenje tehnologij, domačo rabo in podobno, druge pa so za komercialno rabo, ki podlega svojim zakonitostim. Žal pa te zakonitosti marsikomu niso niti približno jasne.


všeč(3) ni všeč(0) spam(0)
#31

Z vidika ponastavitev strežnika je bilo že kar nekaj povedanega, bolj malo pa z vidika varovanja omrežja.



Po mojem mnenju bi moral kot prvo pobarati ponudnika hostinga in protestirati zaradi (pre)slabe zaščite, ki jo nudi.



Dejansko bi moral ponudnik imeti nameščeno 'prvo obrambno linijo', ki pa je v tem primeru ni bilo, ali pa je odpovedala na celi črti. S tem, ko ga seznaniš z 'neprijetnim dogodkom' mu dejansko omogočiš, da preveri vzpostavljene varnostne mehanizme in jih po potrebi nadgradi oz. prilagodi. Če mu nič ne rečeš, potem tudi ne moreš pričakovati, da bo prišlo do kakšnih izboljšav.



Optimalno bi bilo, da je 'nadgrajevanje' spletišč omogočeno izključno preko varne VPN povezave. To bi pomenilo, da te strežnik vidi kot lokalno IP adreso (ustrezno nastaviš v .htaccess). Če je ta IP naslov izven poola strežnikov, si tako (za prvo silo) zavarovan tudi pred dostopom s kakšnega drugega kompromitiranega strežnika pri temu ponudniku.



Kot drugo je potrebno filtrirati outgoing promet. Raznorazni malware deluje tako, da sam vzpostavi povezavo (v outgoing smeri). Pri tem se lahko s ponudnikom hostinga dogovoriš, da tvojemu strežniku blokira VSE porte, razen tistih, ki jih nujno potrebuješ. Če ima ponudnik nameščen požarni zid 'naslednje generacije', bo ta sposoben tudi filtrirati promet na dovoljenih portih, tako da bo šel ven izključno http promet Apache strežnika.



Seveda moraš obvezno izvesti tudi vse, kar so že drugi prej našteli, da pokrpaš varnostne luknje na strežniku.


všeč(2) ni všeč(3) spam(0)
#21

DDoS napadi se redko dogajajo brez nekega razloga. Najbolj učinkovito torej DDoS napade odpraviš s tem, da odstraniš razlog, zaradi katerega si napaden.



Seveda to ni vedno možno, tako da je potrebno poseči po alternativnih metodah za zmanjševanje učinkov DDoS napadov.



Če poganjaš spletni strežnik, ki zaradi DDoS postane nedosegljiv, si lahko pogledaš http://www.cloudflare.com - osnovno storitev nudijo brezplačno in baje dokaj uspešno vzdržuje dosegljivost strežnikov v primeru DDoS napadov.



Koristno je imeti dovolj inteligenten požarni zid, ki sam prepozna DDoS napad in blokira IP naslove, ki vzpostavljajo preveč povezav. Kot pa je bilo rečeno že prej, to ne rešuje 'zatrpanosti' linije. Dodatna internetna povezava je v tem primeru vsekakor prednost, vsekakor pa mimo pomoči s strani ponudnika interneta ne prideš, če se gre za resen DDoS napad.


všeč(1) ni všeč(0) spam(0)