CentOS webserver biztonsagossa tetelere keresek profit ;-)

Security-all

Sziasztok,

Keresek linux/apache/ssl kombinacioban jartas hup-os szakembert, akivel konzultalnek emailban/chaten a lehetosegekrol/buktatokrol/trukkokrol, esetleg tavolrol felkeszitene centos masinainkat (3db) eles uzemre. ket jatekos php-t futtat, a harmadik chat klienst gugli kodben/mas szolgaltatonal vps-en.

kerdeseke elore megvalaszolva:
- miert nem megyek fel a googlera ... vagy csinalom meg magam:
Idom nem engedi, eles uzemu szerverrel nem szeretnek besulni, evek es a rutin kell uzemeltetesi teruletrol
- mennyit fizetek:
rajtad mulik, mennyira vagy tapasztalt a teren es kommunikacio kepes, paypal a baratunk
- egyszeri alkalom?
nem, folyamatosan lesznek kerdesek/feladatok, nem tul sok, de ingyen semmmit sem kivanok

ha van kedved segiteni legyszi keress privatban, irj par sort a szakmai hatteredrol es hogy hol elsz helyileg (mi: fejer megye)

koszi

  • 3082 megtekintés

( uid_4656 v | 2015. 04. 23., cs – 16:03 )

Szereintem itt a biztonsásosság 90%-a nem a webszerver konfigján, hanem az alkalmazáson fog múlni...

Ahja... a CentOS (és a többi disztribúció is) alapvetően biztonságos, ha az ember 'à la nature' feltelepíti a szükséges csomagokat és nem kezdi el konfigurálni hozzáértés nélkül... szóval itt csak annyit ajánlanék, hogy nulláról telepítsétek fel újra a szervereket és csak azt állítsátok át, ami feltétlen szükséges az üzemszerű működéshez és/vagy tudjátok is, hogy mit okoz. A továbbiakban pedig ehhez tartsátok magatokat és a lehető leggyakrabban frissítsétek.

Ha a fenti megvan, akkor a saját kódbázissal ezt a biztonságot teljesen el lehet rontani és általában a saját kódbázis az, ami miatt biztonságilag gyenge egy szerver, de ez nem CentOS szakértő témaköre, hanem egy sokkal komplexebb audit, amihez ismerni kell a szoftvert is.

Nekem most van 3 x 6 + 2 szerverem vegyesen CentOS 6 és 7 alatt, kinn vannak élesben már egy éve nagyjából, a logokból az látszik, hogy az SSH-t próbálgatják, tehát legyen egy kellően erős jelszó backup célokra egy felhasználónak engedélyezve (ha elveszne a kulcs) mindenféleképpen csak kulcs alapján legyen elérhető a többi felhasználó, plusz lehet IP tartományra szűkíteni az SSH portot, ha tudod, hogy honnan fogsz belépni.

A többi próbálkozás a különféle webes szoftverek ismert hibáit próbálja kihasználni, ezért legyen mindig minden frissítve, akkor nem lesz gond. A többi a saját kódbázison múlik.

--
https://test.gacivs.info/

Ha átteszed másik portra és ettől drasztikusan csökken a próbálgatások száma, akkor felesleges a forrás IP szűrése... ha így is megtalálják (és megtalálják), akkor meg felesleges áttenni.

Most szerverenként napi kb. 15-20e próbálgatás érkezik, én ráhagyom az SSH-ra, hogy rázza le ezeket, mert az a 15-20MB plusz forgalom és 3-4 másodpercenként egy-egy próbálgatás nem okoz akkora problémát, mint az, hogy plusz egy-kettő-három réteget adjak hozzá az authorizációs/authentikációs réteghez ellenőrizetlen forrásból és/vagy módosítsak a default beállításokon. Ezzel csak üzemeltetési kockázatot és felesleges karbantartási időt viszek be a rendszerbe cserébe egy kis mentális biztonságérzetért.

"nem neveznék "mentális biztonságérzet növelésnek" :)"

Ha mögötte az SSH csak kulcsot fogad el, akkor nem mindegy? Mi a célja ennek a szűrésnek? Az SSH forgalom csökkentése? Félelem attól, hogy kitalálják/lenyúlják a kulcsot a passphrase jelszóval? Komolyan érdekel, hogy milyen kockázatelemzés van a GeoIP alapú szűrés mögött...

Kockázatnak meg behoztál néhány olyan faktort, amelyek okozhatnak meglepetést:
- hibás GeoIP adatbázis miatt kitiltod magad vagy elutazol olyan országba, amelyet tiltottál
- a nem támogatott csomag miatt a frissítés után nem üzemszerűen működik a tiltás
- biztonsági hiba (esetleg backdoor) kerül a rendszerbe, mert külön kell a szoftver és az adatbázis frissítéséről is gondoskodni
- ésatöbbi, ami nem jut eszembe

Én speciál egy olyan helyen használom ahol FTP forgalom megy. Igen, sima FTP, nem sftp, vagy bármi egyéb. (sajnos a kliens oldalon ezt igénylik / kérik)
Vagy akár mondhatnék mapguide (osgeo) szoftvert (ez is 3rdparty szoftver ugye), arra is simán lehet egy GeoIP alapú szűrés, stb.

Ha egy kicsit elszakadunk az SSH-tól, akkor igen is lehet létjogosultsága geoip szűrésnek, pl olyan service-ek esetében amik nem tudnak "csak kulcs alapon" működni.

Abban egyet is értünk, amiket leírtál itt a listádban. Nyilván ha "3rd party" csomagot viszel be a rendszerbe annak a konfigurása, beállítása, helyes használata, valamint magának a szoftvernek a frissítése és üzemeltetése a saját felelősséged lesz.

Azért az csak nem mind1, hogy az egész világ szkennelgetheti az adott dolgokat random botnetekkel, vagy mondjuk ezt leredukálhatom HU -ra.

De elnézést, csak egy javaslat volt. Aki használja használja aki nem nem. A te véleményedet és álláspontodat is tiszteletben tartom természetesen!

Én szeretem használni a GeoIP-t. SSH és FTP legfőkébb de kb minden másra amit nem kell hogy külföldről elérjenek. Másik előny, hogyha kijön az exploit pl ftp-re, akkor azért csak itthoni gépekről tudják max feltolni nem bárhonnan.
Nekem jóval több előnnyel jár mint 1x leforgatni a kernel modult, mert utána a dkms végzi a dolgát. Valamint néha a maxmindtól leszedni a geoip adatbázist.

Fedora 21, Thinkpad x220

Ha megvan a kulcs, akkor kell egy olyan IP vel rendelkező gép amivel mondjuk be is tudnak lépni.

És a reakcióidő nagyon nem mind1, ugyanis ha megvan a kulcs hamarabb belépnek vele mint ahogy te annyit mondanál hogy fapapucs :D Ezért szoktam geoip-t tolni, ha többen használják ssh ról akkor .hu, de mégjobb egy VPN mögül persze. Az ördög nem alszik, és a robotokse. 1x éve még egy szerver kint lehetett 1234 root jelszóval a neten mire rátaláltak, tavaly év vége fel kb 5 perc kellett ehhez, vagy annyi se. Valamin ahol fut a geoip ott a fail2ban kb munka nélkül maradt.

Fedora 21, Thinkpad x220

"Ha megvan a kulcs, akkor kell egy olyan IP vel rendelkező gép amivel mondjuk be is tudnak lépni."

Ha megvan a kulcs, (megvan a passphrase is,) akkor közel 100 százalékos eséllyel megvan az a gép és az az IP is, amiről beenged a szerver, nem? :)

"Valamin ahol fut a geoip ott a fail2ban kb munka nélkül maradt."

Aztán egyszer belefutsz egy ilyesmibe és nézel majd, mint a moziban... :)

https://www.digitalocean.com/community/questions/droplet-in-amsterdam-g…

--
https://test.gacivs.info

A ráfordítás a kulcsszó és hogy adott idő alatt minnél több távoli site-ot valamilyen módon "felnyomjanak". Egyszerűen nem foglalkoznak azzal, hogy minden protokollra minden portot rápróbáljanak. Egyrészt borzasztó időt emésztene fel sok 100k IP címnél, másrészt pedig ahol már másik porton van valami, ott jó eséllyel erősebb védelemmel találkoznak.

Ez oké, de egy ilyen script-támadás, ami adott portot küld meg 100k-s mennyiségben nem nevezhető kifinomult technikának. Aki célirányosan akar bejutni egy rendszerbe, annak a port nem jelent problémát.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Ezek nem akarnak célirányosan bejutni. Ezek szőnyegbombáznak gyakorlatilag és amit sikerül találniuk azzak főznek. Ahova célirányosan akarnak bejutni (tehát nem az előzőek, hanem mások), oda be fognak jutni, e felől senkinek se legyen kétsége. :)

Pont a szőnyegbombázós jelleg miatt lenne kiemelten fontos, hogy mindenki frissítgesse a WP-jét, Joomláját, Drupálját, Apache-át és úgy egyébként legalább bugfix supporttal bíró OS-el hasítsa az Internet habjait.

Szerverenként jelenleg kb. 200-250 IP címről jönnek a próbálkozások naponta, a medián 20-30 próbálkozás / nap körül van, a legkitartóbb IP cím 1500-2000 próbálkozás / nap körül jár, naponta 15e-20e próbálkozás jön összesen, a felső kb. 25 százalékról jön a támadások kb. 90 százaléka.

Amikor áttettem más portra az SSH-t, akkor eltűnt az alja, amelyek megejtenek 3-6-9 próbálkozást, aztán nem nagyon jönnek vissza; de a nagyüzem megmaradt, szóval a tényleg kitartóan próbálkozók portscan-el indítanak.

--
https://test.gacivs.info

Minek? Ezek a támadások olyanok, mint a természetes háttérsugárzás, egy jól beállított és frissen tartott rendszeren nem tudnak fogást találni, a legális adatforgalom töredékét se hozzák, tapogatózzanak csak, nincs értelme erőforrást pazarolni a védekezésre. Minden plusz eszközzel csak üzemeltetési kockázatot és plusz karbantartási időt viszek a rendszerbe, pláne a felsorolt eszközök jó részével saját magamat is meg tudom szívatni, ha egy apró hibát ejtek vagy épp hibát keresek...

Ha vannak konkrét és célzott támadások, akkor persze próbálok védekezni, de ahogy Knuth is megmondta: the premature optimization is the root of all evil

--
https://test.gacivs.info

Összességében egyetértek, de mi van akkor, ha találnak egy komolyabb hibát az ssh-ban, amit aktívan elkezdenek támadni?
Az ehhez hasonló, igaz nagyon ritkán bekövetkező esetben időt nyerhetsz, ha el van pakolva más portra. Nem jelent plusz biztonsági kockázatot, hibát, de speciális esetben jól jöhet, a beállítása pedig egyszerű.
Ez a teljesen bízzunk meg az ssh-ban, mindenkiben, aki hozzáfér a szerverhez... szerintem kockázatos. Legalább egy plusz szűrés, korlátozás,... kell.

"Összességében egyetértek, de mi van akkor, ha találnak egy komolyabb hibát az ssh-ban, amit aktívan elkezdenek támadni?"

Akkor védekezel specifikusan.

"Nem jelent plusz biztonsági kockázatot, hibát"

Dehogynem. Frissítésnél jön egy új konfigurációs pont, mert így javítanak mondjuk egy biztonsági hibát, ezért például kézzel kell összefésülnöd a saját pluszbeállításaidat és ha ezt elfelejted (márpedig el fogod), akkor nyitva hagysz egy biztonsági rést.

"Legalább egy plusz szűrés, korlátozás,... kell."

Milyen gyakran frissítesz a szerveren? Milyen gyakran telepíted újra a szervert?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ha én tudok hamarabb a hibáról, mint hogy kihasználják, és tudok érdembe tenni ellene, akkor igazad van, de ez ugye nincs így mindig. Nem akkor van a baj, amikor nincsen baj.

Nem vagyok híve annak, hogy 1% teljesítmény javulás érdekébe fordítsunk saját kernelt, ... de ez a használjunk alapbeállításokat, mert mi lesz frissítéskor a másik véglet.

A speciális beállításokkal igazad lehet, de egy 22 ssh portot nem fogok elfelejteni átrakni, ellenőrizni, és elég hamar ki is fog derülni, ha mégis.

"Ha én tudok hamarabb a hibáról, mint hogy kihasználják, és tudok érdembe tenni ellene"

Nagyon nagy százalékban előbb jön a frissítés, mint ahogy publikálják a sebezhetőséget... sokkal fontosabb akár a napi automatikus frissítés az automatizált regressziós és validációs tesztekkel, mint az, hogy itt a piros-hol a piros játékot játssz a szolgáltatások portjával...

"A speciális beállításokkal igazad lehet, de egy 22 ssh portot nem fogok elfelejteni átrakni, ellenőrizni, és elég hamar ki is fog derülni, ha mégis."

Nem is erről van szó... átírod például az sshd_config fájlban a portot, aztán jön a frissítés, odateszi a sshd_config.rpmnew fájlt és kézzel kell összefésülnöd... jó esetben lemaradsz valami új feature-ről, rossz esetben nyitva marad egy biztonsági rés és/vagy nem fog működni egy régi feature. Ez üzemeltetési kockázat.

Nem vagyok ellene ezeknek a megoldásoknak, de tegyétek mellé a plusz adminisztrációt, a plusz dokumentációs kényszert, a plusz betanítási köröket, a plusz kockázatokat és a többi költségelemet és nézzétek meg, hogy arányban áll-e a támadással és annak sikerességével ez a védekezés.

Nem az SSH-n keresztül fognak megtörni, hanem egy nem kellő gyakorisággal frissített komponensen keresztül jönnek be vagy egy egyedi fejlesztésű kódbázison találnak rést.

És ismét hangsúlyozom: tegye fel a kezét, aki automatikusan frissít és az automatizált regressziós és validációs tesztek eredménye alapján automatikusan engedélyezi az adott frissítést egy kiadási szinttel feljebb; tegye fel a kezét, aki automatikusan újratelepíti a szervereit egy-két havonta; tegye fel a kezét, aki automatikusan újraindítja a szervereit pár naponta. A "nem nyúlok hozzá, mert működik" szemlélet nagyon nagy üzemeltetési kockázatot rejt, mert tényleg nem fog működni, amikor egy-másfél-két évvel később frissíteni kell vagy újra kell indítani...

--
https://test.gacivs.info

Ha a Docker és a logikája megvan, akkor nem értem mit nem értesz az újratelepítésen... a Docker el fogja dobni a régit és készít egy újat a megadott "recept" alapján... újra van telepítve: egy docker = egy szolgáltatás = egy virtuális gép. Docker nem arra való, hogy foltozgasd a szervered.

Röviden leírva kétféle szervertípus van:
- háziállat típusú, ahol a szervernek van neve, rendszergazdája, több éves az élettörténete, ha beteg, akkor gyógyítják, ha jól érzi magát, akkor boldog a rendszergazda, ha egy kicsit is terhelik, akkor meg szomorú és mérges a felhasználókra, mert használják a szerverecskéjét
- haszonállat típusú, ahol a szervernek száma van, automatizált környezet hozza létre, napokig-hetekig él, ha egyet köhent, meg a kukába és annyira terhelik, amennyit éppen elbír a megfelelő válaszidőkkel

A világ a haszonállat szerver felé megy, csak nem mindenki tudja ezt érzelmileg feldolgozni, amikor 5-10-15 éven át gondozott szeretettel pár szervert.

--
https://test.gacivs.info

"nagy szazalekban elobb a hibat talaljak meg, mielott jon a frissites"

Ez hol mond ellent annak, amit írtam?

Megtalálják a hibát, javítják, jön a frissítés, aztán publikálják a sebezhetőséget... ritka dolog a 0day publikáció...

...ha nem publikált de létező sebezhetőséggel támadnak, akkor valószínűleg egyetlen egy próbálkozással fognak bejönni, tehát a portsentry és a fail2ban haszontalan; a GeoIP szűrésen is átmegy a kérés, ha a whitelist-en lévő országból jön a támadás - és miért ne jönne onnan _is_, amikor világszerte mindenhonnan jönnek a próbálkozások?

Tényleg hamis biztonságérzetnek tudom csak felfogni ezeket a rendszereket.

--
https://test.gacivs.info

sehol nem allitottam, hogy egy portscan-detektor telepitese utan iszonyatosan biztonsagban erzem magam.
viszont ha van, akkor korantsem biztos, hogy nem publikalt sebezhetoseggel is egy lepesben jutnak be; elso korben ki kell talalni, hol van pl. az ssh, de ha par probalkozas utan elhajtja a portsentry, akkor ez mar eleve tovabb tart, mint nelkule.

Nem, nem hajtja el a portsentry, mert több IP-ről összehangoltan próbálkoznak és amikor kitökölték, hogy melyik port mi és merre van, akkor ez az információ elterjed és már célzottan azt próbálgatják... egyszerűen a másik oldal is tanulékony.

De mindegy, használd. Én mérnök embernek tartom magam, megmértem, mérlegeltem és nem találtam úgy, hogy lenne bármi haszna, de mindenki azzal szopatja magát, amivel jólesik.

Sajnos több mint sok olyan rendszerrel találkoztam, ahol volt mindenféle HBR technológia a hálózat és a gépek minden pontján, két tűzfal közé is tettek egy harmadik tűzfalat, de nem frissítettek soha semmit, mert féltek hozzányúlni, újraindítani meg pláne.

Amikor már minden friss és naprakész, amikor már nem okoz arcidegrángást egy újraindítás és amikor már megvolt a sok saját fejlesztésű szkript, szoftver és kommunikációs rendszer biztonsági átvizsgálása, na, akkor lehet ilyen úri huncutságokkal foglalkozni, addig csak hangyabaszás és statisztikajavítás az SSH port költöztetése.

--
https://test.gacivs.info

"Nagyon nagy százalékban..."
És mi van a kis százalékkal? Nyilván mérlegelni kell, de pl ami ellen tiltakozol a 22 port elpakolása máshova, a megéri kategória szerintem. Ahogy írod, a geoIP nem csodaszer, de sok helyen mégis hasznos.
Javaban is csak azokat a kivételeket kapod el, amik gyakran következnek be, mert a többi kód, csak feleslegesen növeli a program méretét, és még lassítja is a futtatást? A plusz hibalehetőségről nem is beszélve, amit a sok kivétel lekezelés okozhat.

A Microsoft (windows) az utóbbi időben elég jó példája annak, ha nem kritikus hibáról van szó, ne tegyük fel azonnal a frissítést, mert "gyakran" visszavonják, hibát okoz.
A "nem nyúlok hozzá, mert működik" nem elfogadható.
Nem hinném, hogy csak ezek a szélsőséges megoldások lehetnek, és azt sem, hogy minden szerverhez, szolgáltatáshoz ugyanazt a módszert kéne alkalmazni.

Ha nincsen semmi riasztás, hetente frissítünk, és a legtöbbször elég a szolgáltatásokat újraindítani. Elfogadhatónak tartom, ha néha újra kell indítani a szervereket, mert inkább legyen 2 perc tervezett kiesés, mint váratlan dolog. Ahol nincs ezer szerver, nincsenek speciális követelmények, ott ezt tökéletesnek tartom.

Igen, meglehet tervezni egy automatikus frissítést mindenféle ellenőrzéssel, újratelepítéssel,... de ez megint szélsőség, és speciális eseteket leszámítva a soha meg nem térülő kategória.

"a 22 port elpakolása máshova, a megéri kategória szerintem"

Ez ilyen sacc-per-kábé megéri vagy mérted is a támadások számosságának a változását és mondjuk cégvezetőként áldoznál arra mondjuk egy fél rendszergazdányi munkaerőt, hogy ez így legyen és elvennél egy fél fejlesztőnyi pénzt azon fejlesztések elől, amelyek pénzt hoznak?

Mert én mértem és úgy láttam, hogy semmi értelme, lásd: http://hup.hu/node/140150#comment-1861906

"Igen, meglehet tervezni egy automatikus frissítést mindenféle ellenőrzéssel, újratelepítéssel,... de ez megint szélsőség, és speciális eseteket leszámítva a soha meg nem térülő kategória."

Kis cégnél éri meg a legjobban, hogy a kevés számú munkatárs érdemleges és értékteremtő dolgokkal foglalkozzon az automatizálható tevékenységek helyett, pláne ha bővül a cég, akkor olyan feladatokra koncentráljanak, ami bevételt hoz.

Nagy cégnél a méretgazdaságosság és a leépítések miatti negatív megítéléstől való félelem okán később jelentkezik ez a fajta versenyhátrány, szóval tipikusan nagyvállalatoknál szoktak később automatizálni a folyamatokat.

Szóval a lehető legtöbb dolgot automatizálni kell, különben piacot veszítesz, maximum a kapcsolati tőke és a lendület még visz előre egy kicsit...

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Nagyságrendileg hasonlók a tapasztalatok, amit te is mértél.
De ahogy már írtam, nem azért van elpakolva, mert beesik napi pár ezer próbálkozás elhanyagolható terhelést okozva. Egyszerűen lehetnek olyan egyedi esetek, amikor egy ilyennel időt nyerhetsz, vagy teljesen elkerülhetsz egy (sikeres)támadást.
Igazad van, ha nem előzünk meg vele problémát, akkor feleslegesen foglalkozunk vele. Csak ezt nem tudhatjuk előre.

Már párszor megkaptam, hogy ha rajtam múlna, mindenhonnan kirúgnám az emberek felét, és automatizálnám amit csinálnak.
Jelen esetben egyáltalán nem érzem felesleges munkaórának azokat a beállításokat, frissítéseket, amiket csinálunk. Az eredmény teljesen rendben van, az automatizálás kiépítése félő, hogy többe kerülne. De szívesen olvasok a témában, ha küldesz linket, vagy leírod a saját tapasztalatokat.

"De szívesen olvasok a témában, ha küldesz linket, vagy leírod a saját tapasztalatokat."

Nagyon sok best practice van, virtualizálni kell minél kisebb egységeket, egészen a Docker filozófia szerinti egy virtualizált gép - egy szolgáltatás felé, hozzé kell tenni egy Puppet filozófia szerinti konfiguráció menedzsmentet és a DevOps szemléletet, egymás mellé ültetni a fejlesztést és az üzemeltetést, lássa a fejlesztő, hogy mivel szív az üzemeltetés, ha lazán vesz dolgokat és lássa az üzemeltetés, hogy milyen szívást tud okozni a fejlesztésnek.

Aztán ilyen architektúrában adja magát az automatizálás, el se lehet téveszteni. :)

--
https://test.gacivs.info

Egy plusz biztonsági réteget ne használjon az ember, mert egy csomó gond származhat belőle, de virtualizáljon mindent, ami sokkal komolyabban érinti az egész rendszert.

Nem vagyok meggyőződve, hogy általánosan nézve, főleg kevés szerver esetén, egy ilyen rendszer teljes automatizálása (ne egyszerre álljon le az összes szerver hajnalban) egyértelműen olcsóbb, megbízhatóbb. Gond esetén gyorsabban helyreállítható. Azt nem mondom, hogy nem ez a jövő, de nem látom, hogy ez lenne a jelen. Mindenesetre utána fogok olvasni.

Ha meg valaki nagyon problémásnak, költségesnek tartja az üzemeltetést, ahova csak lehet béreljen platformot a felhőben. Ez is része lehet a tervezésnek, és akár teljesen ki is lehet hagyni a rendszergazdát/üzemeltetőt.

Régen is szóltak érvek mellette, és ahol kicsit is nagyobb rendszerről van szó, ott ma is külön fizikai/virtuális gép szolgál ki különböző feladatokat.
Kicsit utánaolvastam. Nagyon nyomják a Dockert, további lehetőségeket biztosít, de nem érzem, hogy ez most egyértelműen stabilabb, biztonságosabb, egyszerűbb környezetet biztosítana, az évek óta jól bevált megoldásokkal szemben. Kell még ennek egy kis idő.

"Egy plusz biztonsági réteget ne használjon az ember, mert egy csomó gond származhat belőle, de virtualizáljon mindent, ami sokkal komolyabban érinti az egész rendszert."

A virtualizációra kulcsrakész rendszerek vannak (private cloud-ra is!)... egyszerű RESTful API-n át lehet karbantartani a virtuális gépeket, bármilyen szkriptnyelvből lehetőség van egy teljes körű adminisztrációra... :)

"egy ilyen rendszer teljes automatizálása (ne egyszerre álljon le az összes szerver hajnalban) egyértelműen olcsóbb, megbízhatóbb"

Szerintem nézd meg, hogy egy hozzáértő rendszergazda, egy Docker és egy Puppet mire képes... mondjuk ezt érdemes megnézni:
https://puppetlabs.com/presentations/using-docker-puppet-james-turnbull…

"de nem látom, hogy ez lenne a jelen"

Ez már a jelen... sőt, mondhatni, a múlt. :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

A múltat arra érted, hogy egy éve a fejlesztők már tesztkörnyezetben használták?
A jelent arra érted, hogy már van pár bevállalós üzemeltető, aki pár hónapja használja?

Múlt héten jött ki az 1.6. Az újdonságok között szerintem még alap dolgok szerepelnek. Inkább azt mondanám, most kezd használható lenni, most kezdik érdemben támogatni.
Most elég sok cikket elolvastam. Kíváncsian várom, milyen ütemben kezdik használni, milyen hatása lesz a biztonságra...

"A múltat arra érted, hogy egy éve a fejlesztők már tesztkörnyezetben használták?"

Hhhhh... belinkelek egy kb. egy éves videót, ahol a Kickstarter oldal egyik embere mutatja be, hogy miképp használják élesben a Docker-t és a Puppet-et együtt, hogy kevesebb munkájuk és stabilabb környezetük legyen, erre Te ezzel a szöveggel jössz... legalább kicsit tájékozódj... :/

"A jelent arra érted, hogy már van pár bevállalós üzemeltető, aki pár hónapja használja?"

Nem, nem használja senki, a Kickstarter se, csak szeretnek hülyeségeket beszélni szakmai konferenciákon... most ezt komolyan kérdezed?

"Múlt héten jött ki az 1.6."

Szerinted melyik verziótól lehetne jól használni? :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"a 22 port elpakolása máshova, a megéri kategória szerintem"

Ez ilyen sacc-per-kábé megéri vagy mérted is a támadások számosságának a változását és mondjuk cégvezetőként áldoznál arra mondjuk egy fél rendszergazdányi munkaerőt, hogy ez így legyen és elvennél egy fél fejlesztőnyi pénzt azon fejlesztések elől, amelyek pénzt hoznak?

Elnézést, de itt azt érted, hogy ha az SSH-t átrakod egy másik portra a configban, (mint ahogy pár hozzászólással feljebb írtad is hogy ez miért baj) az erőforrást von majd el és pénzt ?

Nem teljesen értem, akkor miért is fizeti a cég a rendszergazdát adott esetben ? Azért hogy tudása szerint karban tartsa a rendszert.
Az hogy ezt ő hogy oldja meg, hatékonyan vagy sem, az nyilván az adott emberen múlik.

De hogy visszautaljak az egyik hozzászólásodra, nálam nem egy szerveren van az ssh nem default porton, és igen, ha van frissítés én bizony össze-diffelem a régi configot azzal a bizonyos .rpmnew-val. Kb 1 percet vesz igénybe, ha van valami érdemi eltérés, akkor talán 3-at, hogy utánajárjak mi is az az eltérés.. + fel vagyok iratkozva a megfelelő levlistekre, így ha valami frissítés kijön, akkor már ott kapok egy summary-t arról, hogy mi is történt és mi is változott adott esetben.

Ez kicsit sarkítás, hogy pénzt von el ...

Azt látom, hogy te az automatizálás híve vagy, de valljuk be, nem mindenhol és minden esetben lehet mindent automatizálni .. Vagy ha igen (mer csakazért is automatika legyen!) , akkor az adott esetben X vagy Y szolgáltatás kiesésével fog járni. (itt széles körbe, egyedi programokra, stb-re kell gondolni)

"az erőforrást von majd el és pénzt"

Igen, dokumentálni kell, hogy melyik szerveren hol van épp az SSH - vagy mindegyiken ugyanoda kerül és ott is marad az idők végezetéig?
Igen, adminisztrálni kell, hogy ki, mikor és melyik portra tette, ha egy másik szerver kapcsolódna, akkor ott át kell írni, ha változik.
Igen, időbe kerül az új embert betanítani, hogy mit hol talál, mit miért kell másképp csinálni, mint máshol - az "itt így szoktuk faktor" néha és néhol akár fél évbe kerül.
Igen, időben és erőforrásba kerül minden egyes szerverre kapcsolódásnál megnézni, hogy hova kell kapcsolódni, ha ott nem válaszol, akkor a szerver döglött-e meg vagy az SSHD állt meg, vagy hálózati hiba van, vagy éppen azt a portot elkezdte szűrni valamelyik tűzfal, mert a hálózati üzemeltetés is úgy érzi, hogy ez hasznos védekezés.
Igen, pénzt von el, mert különbözik az alapértelmezettől, munkába telik a fenti sok tevékenység.

"Kb 1 percet vesz igénybe, ha van valami érdemi eltérés, akkor talán 3-at, hogy utánajárjak mi is az az eltérés.."

Aham... ami ugye 1 perc per szerver... ésatöbbi.

"Ez kicsit sarkítás, hogy pénzt von el ..."

Írd fel egyszer, hogy mennyi időt visznek el ezek az extra tevékenységek, aztán szorozd fel a órabéreddel és oszd el a szerverek számával. Egyszerű matematika. :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Írd fel egyszer, hogy mennyi időt visznek el ezek az extra tevékenységek, aztán szorozd fel a órabéreddel és oszd el a szerverek számával. Egyszerű matematika. :)

Nem teszek ilyet, mert - többek között - azért kapom a fizetésemet, hogy üzemeltessem azokat a szervereket, amiket rám bíztak.

(btw ez nem szalagmunka, hogy legyártottam X darab plüssállatot és hoztam a rátát... Ezt valahogy egyes emberek nem tudják megérteni hogy üzemeltetés != X darab plüss állat legyártása a soron)

Így a thread folyamán eszembe jutott egy "neves" cég, kezdődik U-val végződik *itis -el (egy betű kimaradt). Bár lehet már felszámolás alatt van. Ők adtak ott olyan tanácsot anno, hogy a szerver terhelés nagy, akkor rakjunk be egy restartot minden nap hajnal 3kor.

Valahogy az ilyen "automatikus újratelepítéses" témáról mindig ez ugrik be :/

"Nem teszek ilyet, mert - többek között - azért kapom a fizetésemet, hogy üzemeltessem azokat a szervereket, amiket rám bíztak."

Hmm... szóval neked és a munkáltatódnak is mindegy, hogy egy szerverre eső havi munkaidőd mondjuk 2 vagy 20 óra?

Másképp kérdezem: ha döntened kellene, hogy

- a meglévő mondjuk 100 darabból álló szerverállományon elvégzel egy újabb beállítást szerverenként 3 perc munkaidővel (bár ebben szerintem nincsenek benne validációs tesztek), de egy fillérrel se kapsz ezért több pénzt és abban se vagy biztos, hogy ettől biztonságosabb lesz, csak olvastál a dologról és megtetszett az ötlet

vagy

- egy újabb szervert állítasz üzembe 300 perc munkaidővel, amiért egyszeri és rendszeres bevételed is lesz,

akkor melyiket választod?

"Valahogy az ilyen "automatikus újratelepítéses" témáról mindig ez ugrik be :/"

A rendszeres újratelepítés és újraindítás mögött az a "filozófia" van, hogy ha valamit beállítasz, akkor újraindítással kiderül, hogy permanensen sikerült beállítani, újratelepítéssel pedig az derül ki, hogy sikerült-e ledokumentálni és/vagy a telepítő szkriptbe rögzíteni... és ha ezeket gyakran műveled, akkor nem fél-egy év múlva kell visszaemlékezni, hogy mi változott, hanem elég egy-két hét nem dokumentált tevékenységeit kitalálni.

Ennek a hozadéka, hogy ha gyakran csinálod, akkor automatizálni is fogod, ha pedig automatizáltad, akkor nem okoz időveszteséget és nem hordoz magában üzemeltetési kockázatot és mindenki rá fog szokni, hogy puszta kézzel nem nyúlkál a rendszerekben, mert az automata szkriptek eltávolítják a keze nyomát, ehelyett mindig minden módosítást azzal kezd, hogy módosítja a szkripteket.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( janoszen v | 2015. 04. 23., cs – 18:42 )

En szivesen segitek ingyen, egy feltetellel: videofelvetel keszul es felkerul a Webtudorra. :)

--
Pásztor János
Üzemeltető Macik

( n.balazs v | 2015. 04. 24., p – 12:27 )

Ha fontos a biztonság, akkor egy IDS/IPS beüzemelésén is elgondolkodnék a helyedben.