Apache server védelme

Debian GNU/Linux

Sziasztok!

Debian 9-en fog futni egy apache server. Az apache config file-ját a fejlesztők fogják kezelni.
Igaz teszt rendszer lesz, ettől függetlenül amennyire lehet szeretném védeni tűzfal szabállyal.
Kinek milyen javaslata van erre?
Manapság mennyire érdemes jail,chroot-ot alkalmazni? Régen felületesen olvasgattam róla, most viszont belerázódnék egy kicsit. Mennyire nehéz jail-be, chroot-ba tenni? Jól gondolom, hogy ez gyakorlatilag ugyanaz a kettő (jail,chroot)?

Előre is köszönöm a válaszokat!

L.

( kiuka | 2018. 03. 30., p – 19:25 )

rakd konténerbe, manapság az a megfelelő chroot alternativa.

( dentzol | 2018. 03. 30., p – 21:04 )

Egy belső hálózaton levő tesztkörnyezetről van szó ahol a felhasználókat szeretnéd teljesen elszeparálni, vagy pluszban ez az egész ki van publikálva pluszban az internetre és a bejövő forgalmat kellene alkalmazás szinten szűrni?

( gthomas | 2018. 03. 30., p – 21:22 )

SELinux-al le kellene korlátozni, mihez férhet hozzá az apache (ha van a gépen még más is);
tűzfal szabályokkal meg hogy sehova se tudjon kérést indítani, sehogy!
Befele meg persze csak a megengedett (443) HTTPS porton.

( sj | 2018. 03. 30., p – 21:41 )

Az apache config file-ját a fejlesztők fogják kezelni.

engem mar a gondolattol is kiver a viz. Remelem, a ti fejlesztoitek oda-vissza ismerik az apache-ot, ezert akarjak ok konfigolni :-)

Ugyan lehet chroot-olni, docker-be tenni, amit akarsz, de a leggyengebb lancszem mindig a kaka webszerver konfig es a bug-os alkalmazas szokott lenni. Azert review-n atmennek nalatok a modositasok, ahol legalabb egy felnott is +2-t nyom, mielott egy modositas kimegy a dev gepre?

Ha ram hallgatsz, tedd a gepet dmz-be ugy, hogy sehogy se tudjon a belso halo fele kapcsolodni.

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

a sok negativ tapasztalat miatt :)
en meg 20 ev alatt nem talalkoztam olyan webfejlesztovel aki akar kicsit is ertett volna a linuxhoz. persze ettol meg leteznek, tuti, csak elkerultuk egymast :)
mar az is ritka hogy a seucirty mint olyan szempont a fejlesztesnel, eleg hajmerestzo dolgokat szoktak csinalni/kerni...

Akkor meg varhat 2 hetet a modositasi kerelemre, hiszen a sysadminoknak keves idejuk van a kavezgatas mellett meg supportalni is a fejlesztoket.

Aztan mivel a sysadminnak halvany lila segedfogalma sincs arrol, hogy hogy is mukodik a program, ami a rendszeren fut, es meg se akarja altalaban erteni, igy marad az, hogy a fejleszto veszi kezbe a dolgok konfiguralasat, hiszen rajta csattan az ostor, ha valami nincs kesz hataridore.

Full-stack, devops mond valamit?

Trainingelni meg annak a dolga, aki ert hozza. Kollaboracio, vagy mi a fene, meg egyuttmukodes.

Szép buzzwordok. :) Ezzel szemben visszatérő probléma, hogy sokadszorra is hiába kapnak meg infót fejlesztőék "elkerüli a figyelmüket", vagy újra és újra valamilyen hajmeresztő tippel állnak elő, ráadásul egy nemlétező vagy félig már megoldott issue-ra. Szerencsére több fejlesztőt ismerek, akikkel lehet értelmesen együtt dolgozni, tehát remény az van.

Általában minimális vagy semmilyen trainging/doksi nincs fejlesztőéktől, hogy mégis hogyan működne valami.

A határidőkről meg hát izé, nagyon-nagyon szeretik letoltni magukról fejlesztőék a problémákat "szaraszerver", "nemkaptunkinfót" (lásd fentebb) c. eposzokkal.

Trainget több okból sem egymásnak szokás adni, hanem hívni kell egy "szakértőt" (aki ugye a másik városból jött).

Gondolom ez is a fejelsztok hibaja, mert... mert... mert csak!

Aztan majd a masik varosbol jott szakerto tok jol ra tud vilagitani azokra az egyedi dolgokra, amiket in-house hackelgetnek a rendszergizdak, es vegeredmenyben meg veletlenul se zavarodnak ossze a fejlesztok, hogy "dehat ezt nekunk igy mondtak, megse igy van. De akkor hogy is van ez?".

En ertem, hogy semmi segitokeszseg, proaktivitas nincs benned, a komfort zona nagyon marasztalo tud lenni, csak amikor emberekkel dolgozol, akkor nem art odatenni azt a pici kis tobbletet, amivel nem csak a sajat, hanem a tobbiek munkajat is megkonnyited.

De nyilvan en vagyok a helikopter, es az a legjobb, ha a fejlesztok es a sysadminok konstans fujnak egymasra, es toljak le magukrol a felelosseget. Nagyon erett, felnott viselkeses.

azert tedd melle hogy az ugyfel sokallja a 8000ft/evet a tarhelyert de azert meg en debuggoljam ki az elbaszott websitejat amit felrakat oda, mert addig nemhogy nem fizet de meg karteritesi igenyei is vannak. ilyenkor az ember kevesbe segitokesz.
ha kifizeti valaki en szivesen beszallok a fejlesztesbe vagy debuggolasba, vagy akar oktatast is tarthatok, de nem szoktak.

Ahogy írtam, van több fejlesztő akivel jól lehet együtt dolgozni és vannak akikre fújunk.

Nagycéges környezetben is előjön, hogy a kapott infót nem használják és habzanak, hogy jajjúristen nemműködik. Ahogy ő gondolja úgy valóban nem, de ahogy néhány héttel azelőtt megírtam ÉS teszteltem, úgy igen, ráadásul ők kérték a plusz beállítást. Ugyanitt sokéve nem rakhattuk domainbe a szervert, mert az "nem várt" problémákat hozhat elő és így ragadtunk be a 32bites 2008-ra a 32 bites Javával. Miután eljutottam a 32 bites Java 1152MB-os limitjéig, utána már csak 2-3 hetente dőlt el a cuccuk. Még tippet sem kaptunk, hogy akkor a növekvő adatmennyiségnél állítsunk utána, de szerencsére a 100e+áfa-s devel/supportnapokat boldogan számlázták.

Ugyanakkor jó tapasztalatról is beszámolok, nehogy problémák legyenek. Szintén nagycéges környezet és volt/van kolléga, akivel leülünk megbeszélni, hogy mit szeretne, mi az igénye. Ezt szépen alápakoljuk, a biztonsági/technikai/bármilyen korlátokat megbeszéljük és szépen halad a dolog. Az más kérdés, hogy a kedves megrendelő kitalálja, hogy az addig nonpublik és sietve fejlesztett projekt hirtelen legyen publikus. A fejlesztőnk meg fogta a fejét, mert a határidőt nem tudta volna tartani, hogy ha abszolút "security-in-mind" halad. Tipikusan 2 ember helyett dolgozott, ennyi fért bele.

A PHP-s webhostingos vonal az valóban súlyos, fantörpikus, amiket összehoznak. Ezt tetézi, hogy a Megrendelő azt látja, hogy irgalmatlan pénzt fizet ki a fejlesztőnek az üzemeltetéshez képest, és az akármit csinál, annak márpedig úgy kell mennie.

Hiába akarok proaktív lenni, meg hanyatthomlok menekülök a komfortzónából, egyszerűen nincs kapacitás már folyamatosan bizonyítani a legbanálisabb dolgok működését.

igen azt en is tapasztalom, hogy a secuirty altalaban nem szempont. vagy mert nem is erdekli / nem ert hozza a fejleszto (ez a gyakoribb), vagy nincs ra penz/ido, mert minden tegnapra kell, igy szuletnek az olyan megoldasok, hogy get-ben megy be a bankkartya adatok, meg egy tulterhelestol bekovetkezo hiba eseten kihanyja a php stack tracet a bongeszobe, benne az sql jelszoval stb

igen erre a "szaraszerver" hozzaallasra celoztam en is. mert ha nem mukodik a stackoverflowrol/githubrol osszelapatolt ganyolmanya a production szerveren akkor csakis a szerver lehet a szar, mert az o laptopjan WAMP alatt bezzeg megy, megmutatja o szivesen, a megrendelonek meg is mutatta, igy reszerol problema lezarva, oldjam meg. es en olyan vagyok hogy nekiallok kidebuggolom a php kokanyolasat es megkeresem mit cseszett el, aztan megirom neki, cc-zve a megrendelot is, ha mar o kezdte. ilyenkor meg jol megsertodnek, pedig egy "bocsi ezt elqrtam" is eleg lenne.
visszatero kedvenceim amikor a php kodja meghivja a http://127.0.0.1/ize/mize.php-t ami nala localhoston mukodik is, a szerveren meg vajon miert nem. meg amikor c:\\users\jozsika\melo\logo.png-t akar betolteni de nem tudja, viszont a rewrite-ok miatt (mert anelkul ugye nem lehet elni se) az index.php-re fog atiranyitodni es igy szepen rekurzivan vegtelen ciklusba kerul. es sorolhatnam meg...

mire gondolsz? pl. telekom feat bkk? :)
vagy a tenyleg nagyokra, pl facebook, apple stb?
azoknal is elofordultak olyan orbitalis es amator hibak, hogy ez alapjan ott se (sokkal) jobb a helyzet, csak ott sok phpistiek van, es egymasra mutogatnak nem (csak) a sysopra :) de mivel ilyen helyen nem dolgoztam, csak kis-kozepes magyar cegeknek igy ez csak talalgatas :)

Láttam már külföldi "enterspájz PHP" (tudom, sokaknál oximoron, de mind1, ezt adta a gép) appot, ahol hibás SQL jelszónál sig11-gyel röppent az örök bitmezőkre a cucc. Csak 2-3 órát görcsöltem, hogy ugyan mi a túrótól száll el, mindenféle érdemi hibaüzenet nélkül...

az o laptopjan WAMP alatt bezzeg megy, megmutatja o szivesen, a megrendelonek meg is mutatta, igy reszerol problema lezarva, oldjam meg.

ez a klasszikus 'a dev atdobja a falon a cuccat az ops-nak, es sok szerencset kivan neki (muhaha)'. Az almoskonyvek szerint ebbe bele van kodolva a sok f-betus szo (meg a dev, ill. az ugyfel anyjanak) emlegetese. A webhosting ugyfellel azt kell megertetni, hogy a hosting cegnel adott egy bizonyos kornyezet, es az ugyfel fejlesztojenek azon kell demoznia, hogy mukodik a cucc, nem pedig terdet csapkodva oromkodni, hogy a 127.0.0.1-en hogy szakit a cucc. Jaaaj, mennyit fixaltam en is ilyen szarokat :-) Az eves 5-10k penzert ez nem feher embernek valo ez a fillerszabo kozonseg. Nem irigyellek ezert a jo magyar webhostingert :-)

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

nem oromombe csinalom, alapbol nem is vallalok webszervereket pont ezek miatt, csak ez ismeros cegee es csak bennem bizik stb meg amugy mas teruleten eleg sok melot hozott, ezert sajnos ezt nem lehetett lepasszolni, de mar sokszor megbantam hogy belementem :(
(ja persze az egesz ugy indult hogy az o cegenek az oldala lesz rajta csak. aztan meg az egyik partneree. aztan a masike. aztan meg 8 ugyfelee. aztan mar kb mindenkie, mert ha mar ott a szerver, akkor termeljen penzt... ;))

meg azt akartam irni, csak mar nem tudtam szerkeszteni, hogy ugyan a chroot, docker hasznos dolgok, azonban novelik a rendszer komplexitasat (foleg a chroot), ami nem jo. Es mivel atlagbela fejlesztokrol beszelunk, en inkabb nem elnek ezekkel, mert tuti elszabjak, csinalnak valami shortcut-ot, amivel a chroot-olt / docker-ezett eredo rendszer biztonsaga gyengebb lesz, mint anelkul...

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

Már DMZ-be tettem. Ilyen szinten már lekorlátoztam. Az a baj, hogy MariaDB-hez is kell majd csatlakozniuk. Azt mondták teszt lesz, tehát nem gond ha valami miatt újra kell húzni. Csak én nem akarom, hogy esetleg valami zombi gépként használja valami ügyeskedő hülye gyerek... :)

( Oregon | 2018. 03. 31., szo – 13:21 )

mod-proxy? Persze mogotte tetszoleges es dedikalt gepen a fejlesztoi os.

( STP | 2018. 03. 31., szo – 20:23 )

Nos.
OS normális beállítása, pl legyen elég inode, file handler, stb. SELinux vagy egyéb perverzió, aki erre bukik.
Frontális támadás ellen természetesen tűzfal (kapcsolatok IP vagy idő vagy bármi egyéb korlátozásával, esetleg geoIP)
Fail2Ban, hogy ne szopassák szanaszét azt a szervert.
Apache elé egy nginx proxyzni a statikus cuccokat, bár ez hitvitához is vezethet. Ezt akár ignorálhatod is.
Ha van létjogosultsága a geoIP-nek, de nem tűzfal szinten akarod implementálni, akkor megfelelő apache mod beállítása.
Alkalmazás Temp terület (pl ahová uploadolni lehet) noexec-kel mountol területen legyen.
HTTP2 kapcsolatok kezelésének beállítása. (Csak mert a védelem nem csak direkt támadás ellen kell, hanem túlterhelés ellen sem árt.)
PHP-FPM
És a legfontosabb; jól megírt kód