Webkiszolgáló védelme

Web, mail, IRC, IM, hálózatok

Sziasztok!

Szeretnék ötleteket, javaslatokat kérni.

Lesz nemsokára egy LAMP környezet ami internet felől természetesen elérhető lesz. Egy darab, saját fejlesztésű alkalmazás fog rajta futni. Egyenlőre tekintsünk el az alkalmazás lehetséges hibáitól mint problémától. Először a hálózati rész optimális megoldását szeretném összerakni.
Első lépésben jó lenne ingyenes alkalmazásokkal megoldani mindent ( illetve elérhető árú szolgáltatással ), amennyiben erre mondjuk egy év múlva is szükség van akkor ( sikerült elérni az üzleti célt ) szóba jöhet kereskedelmi termék is.

Normál felhasználásnál nem kell számottevő terhelésre számítani, napi 300-500 egyedi látogató és max. 5000 oldalletöltésnél nem lesz több meglátásom szerint.

Egy lehetőség, hogy publikus IP címmel kiteszem a VPS-t ( saját vason fut ), iptables input, output láncon beállítom a tiltásokat.

Második ötlet, hogy egy másik VPS mögé teszem, csinálok egy NAT-ot és figyelem a forward láncot, beállítom a tiltásokat, esetleg valami IDS/IPS alkalmazást is megpróbálok beállítani.

Harmadik ötlet, hogy Sucuri, CloudFlare vagy egyéb szolgáltatást igénybe véve próbálom megszűrni a támadások egy részét.

Viszont kérdés, hogy pl. van-e értelme az Apache kiszolgálót egy Nginx mögé bújtatni? Segít-e az Apache elleni célzott támadásokat kivédeni? CloudFlare és társai mennyire hatékonyak? Ha webcímet támadnak és a botok kérdeznek DNS-t akkor ők kapják a kérést, de ha IP címre mennek akkor mindegy. Azt tapasztaltam, hogy botok hónapokkal azután is támadtak domain neveket miután az elkerült az adott szerverről más IP címre.

Gondolom van itt pár kolléga aki dolgozik ilyen rendszerekkel, láttam már pár dolgot én is, de ezt szeretném a kezdetektől "szépen" össze rakni és minden építő ötletet szívesen fogadok.

  • 3830 megtekintés

( andrej_ v | 2015. 10. 17., szo – 00:11 )

Ha ilyen kis forgalomnál felmerül a védelem, akkor a CloudFlare free plan-t nézd meg. A CloudFlare esetén nem fogják tudni az IP címedet. Ilyen kis forgalomnál nemnagyon tudsz optimalizálni a hálózaton.

Sokat tenni nem tudsz amúgy, mert ha már elérik a webszervert, pl. "remek" kérésekkel bombázzák, akkor azt megkapod. Bármit is teszel bármi elé. A hatást csökkenteni úgy lehet, hogy példul rewrite szabályokat veszel fel olyan módon, hogy az alkalmazás által nem használt funkciókat tiltod. Példul WP-s oldal esetén a wp-content/*.php -re rögtön lehet forbiddent adni vagy még régebbi dolog, hogy a képek hotlinkelését (referrer nélküli megnyitás) tiltosd.

Ha LAMP és csak szimpla alkalmazás akkor ízlés szerint nginx vagy lighttpd és a PHP-t FPM módban (php-fpm csomag) futtasd. A PHP-hoz pedig szintén az ízlés szerinti opcode cache legyen ott.

"mert ha már elérik a webszervert"

Ezaz, így +1 a Cloudflare-re.

Illetve https://www.duosecurity.com/pricing ezt használom pl. wordpresshez is. Bár nem tudom hogy a jelen esetben hány azonosítandó user lesz, illetve hogy leendő userek beidomíthatóak-e egy ilyesmi használatára (nekem egy userem van, én :D).

( agostonl | 2015. 10. 17., szo – 07:42 )

Melegen ajánlom a fail2ban programot!
Írtam pár hónapja róla egy kedvcsináló cikket, én ezzel védem a szerveremet, eddig volt 4-5 DDOS támadás, meg jópár php apache támadás, de mindet kivédte.

"Értem én, hogy villanyos autó, de mi hajtja?"

( sz332 v | 2015. 10. 17., szo – 07:59 )

Ahogy lentebb is írták, fail2ban, illetve geoip szűréssel én az összes "problémás" német kapásból reptettem (indiai, kína, taiwan, orosz, stb.).

( pike.killer v | 2015. 10. 17., szo – 08:10 )

Ha csak specialis celkozonsegnek szolgalatsz alkalmazast, akkor mindenkinek keszits cert-t. Webszervert csak azok tudjak elerni akik fel tudjak mutatni az altalad kiallitott ervenyes cert-et.

( Szenti v | 2015. 10. 17., szo – 10:53 )

Én még egy Apparmort is felkonfigolnék a webszerverhez és a php-fpm-hez. Ezzel explicit meg lehet határozni, hogy ezek a processzek milyen fájlokhoz és mappákhoz férhetnek hozzá. Továbbá iptables konfig a webszerverre is, ahol az output láncba explicit felvenném azokat az IP címeket és portokat, ahova a gép kommunikálhat (OS update-ek, DNS, stb.), ipset-tel megtámogatva.

( _Franko_ v | 2015. 10. 17., szo – 12:02 )

SSH hozzáférést csak kulcs alapján engedj és tartsd frissen, sokkal többet számít, mint bármilyen más védelem, ami látványos a logot nézve, de a célzott támadások ellen semmit nem véd (geoip, fail2ban és társai).

( procika v | 2015. 10. 17., szo – 14:56 )

Köszönöm az eddigi válaszokat.

Az input, output lánc alapértelmezetten DROP, input láncon csak a 80 és 443 szükséges, hogy nyitva legyen szűrés nélkül. FTP nem lesz, SSH pedig csak pár fix IP cím felől lesz elérhető. Feloldó DNS kiszolgálók és smtp szerverek ( alkalmazás küld levelet ) szintén saját kezelésben vannak, az output lánc szabályai is pontosan megadhatók.

fail2ban-t minden esetben használom, itt értelmét veszti mivel se FTP sem pedig SSH nem lesz, levelezés nem ezen lesz. Viszont máshol WordPress-hez is használom, annak mintájára az alkalmazást fel lehet készíteni, hogy hibás auth esetén írjon a syslogba és ehhez készítek fail2ban szabályt.

CloudFlare, Incapsula a CDN miatt is előnyös lehet. Igaz kicsit más, de a Bitninja mindenképp szóba jön.

Cert nem működik itt mert igaz szűk közönség, de téma miatt és nem tudom előre kik azok, épp ezért országra sem szűrhetek mert Kína pl. fontos szereplő lesz nekünk, holott IT szempontból a leggázosabb talán.

Az oldalon az SSL egyértelmű, ha rajtam múlik semmit nem teszek ki nélküle. Nagyker áron valami bruttó 5.2$-ért kapom.

AppArmort átnézem, biztosan van hozzá anyagom.

SSH kulcs hozzáférés lehet nem fog működni, nem bonyolítom a fejlesztő életét. Az FTP-t így is elszedem tőle. SSH pedig 3 db IP címről lesz elérhető.

Van esetleg értelme a HTTP forgalmat egy külön szerveren ( VPS-en ) átengedni és ott belenézni a csomagokba? Mivel SSL lesz így alapból zűrös a dolog.

Az irányod jó, de a legtöbb gond az alkalmazások hibáiból szokott adódni. Suricata talán még jöhet a listára, plusz php vagy egyéb kódok futásának szeparálása a webszervertől amennyire lehet. A fejlesztők elérését meg helyezd vpn-en belülre.
Ha nagyon pontosan meg tudod határozni a leendő http forgalmat akkor egy l7 pl zorp. Az ssl kapcsolat áthelyezése másik kiszolgálóra vagy a tűzfalra nem jelent problémát, az a valid akinél a kulcs van.

fail2ban-t én DNS-hez is használok, amikor fektették valamelyik nagy DNS szolgáltatót, akkor az enyémmel is próbálkoztak... (ha érdekel, részletesebben leírom a problémát)
Valamint jó, ha ki lehet vele iktatni a web-szerverre érkező próbálgatásokat is.

"Van esetleg értelme a HTTP forgalmat egy külön szerveren ( VPS-en ) átengedni és ott belenézni a csomagokba? Mivel SSL lesz így alapból zűrös a dolog."
Ennek szerintem semmi értelme.

Kína téma, meg hát... Én már szinte az összes kínai, orosz, egyéb keleti ország tartományát kiraktam SYN flood kísérletezgetés miatt. Mostanában inkább ilyen GoDaddy, Amazon IP-kről jön nagyszámú SYN... Ugyan nem fekszik meg tőle a gép, mert iptables-ben korlátozva van, de attól még tiltom, hogy ne is próbáljon válaszolni rá a gép.

Én ssh-t inkább nyitva tartom, de max 2 lehetősége van. Annyiból meg még csak a usernevemre sem jön rá, amivel bessh-zok, nem hogy a jelszóra. root felhasználó meg nem ssh-zhat.

--
openSUSE 13.1 x86_64

( Lacyc3 v | 2015. 10. 18., v – 00:23 )

Amit még nem írtak, de hirtelen eszembe jutott: eszedbe se jusson a PHP-t CGI binárisként futtatni.

sima cgi-kent minden sciptre forkolni kell egyet, igy lassu...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Az access log szerint a legelső, amivel egy bot bepróbálkozik, az a klasszikus cgi -ként futó bármi machinálása.

Url decode után jön a meglepetés, de nem árulom el:
107.20.240.225 - - [02/May/2015:23:17:14 +0200] "POST /cgi-bin/php5?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%22%79%65%73%22+%2D%64+%63%67%69%2E%66%69%78%5F%70%61%74%68%69%6E%66%6F%3D%31+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E

A ShellShock kitörése után sorra jöttek a cgi-bin -t célzó próbálkozások. Sok kedvencem van, de talán az viszi a pálmát, mely közvetlenül a /dev/tcp -be akar dolgozni.

nem arrol van szo, hogy van egy hello world script a cgi-bin alatt, hanem hogy a perl (esetunkben a php) binaris van a cgi-bin alatt. Na ilyen van szerintem csak a meseben...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( zilahu v | 2015. 10. 18., v – 07:58 )

Apache Modsecurity is hasznos lehet még a csomagba, illetve én a findbot.pl scriptet használom, innen tölthető http://www.abuseat.org/findbot.pl ez talál malwaret ott is, ahol a maldet csak néz ártatlan kutyaszemekkel, hogy szerinte minden szuper.

Hogy is fogalmazzak... attól még hogy talál, nem biztos hogy van. Próbaképp elindítottam a gépemen, de annyi fals riasztást dobott hogy pár másodperc után lelőttem.

Visszanézve, az általam írt, kétsoros .txt jegyzet is gyanús neki, mert "c99" van benne:

/usr/bin/gcc -std=c99 -g ....blablabla

( sj | 2015. 10. 18., v – 11:37 )

Normál felhasználásnál nem kell számottevő terhelésre számítani, napi 300-500 egyedi látogató és max. 5000 oldalletöltésnél nem lesz több meglátásom szerint.

tedd egy webhostinggal foglalkozo ceg gepere fel az oldalad, es kb. keszen vagy.

Mivel az alkalmazastol most el akarsz tekinteni (pedig jellemzoen ez a leggazabb resze a dolognak :-)), ezert altalanos hoszt szekurizalo tanacsokat lehet adni: napra kesz OS, befele csak 80,443 engedett + ssh kizarolag kulccsal a te fix ip-cimedrol, kifele inditva semmi a dns kereseken tul.

Egy masik gep moge tenni teljesen folosleges, csak a komplexitast noveled, ellenben extra vedelmet aligha jelent. Az IDS/IPS ill. modsecurity a most nem reszletezett alkalmazast tudja vedeni a fals keresek ellen.

En nem vagyok fail2ban a webre parti, egy massziv ddos ellen (pl. 2-300 Gbps traffik az ip-cimedre) semmit nem er. Ha ilyen felelmeid vannak, akkor jo lehet a cloudflare ingyenes plan-je, ahogy fentebb irtak, de szerintem siman el lehet indulni enelkul is. Legalabbis csillio elerheto oldal, site letezik ilyen panceling nelkul is.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Szia!

"tedd egy webhostinggal foglalkozo ceg gepere fel az oldalad, es kb. keszen vagy."

Ez lesz a legutolsó lehetőség... Ha jól rémlik te sok esetben szóltál hozzá már ilyen témához. Szerinted a szolgáltatók mekkora százaléka tart fent elfogadhatónak mondható rendszert? Illetve ott van még a MariaDB, Phalcon, MongoDB és ami még közben kellhet. Nem fogok napokig könyörögni bármi beállításért.

Nem tekintek el az alkalmazás problémájától mert valós, de első lépésben a hálózatot és a futtató környezetet szeretném rendbe tenni. Tudtommal az IPS/IDS alkalmazások elég erőforrás igényesek, vagy legalább is nagyobb a terhelésük mint egy iptables szabálykészletnek, azért gondolnám külön gépre.

DDOS ellen kb. semmi nem véd, ha jön az UDP elárasztás. Az én rendszerem előtt van egy szolgáltatói tűzfal ott is be lehet avatkozni, vagy Telekom. Valószínű nem a mostani költségvetésünkhöz méretezett áron, de a Telekomnak van erre szolgáltatása.

CloudFlare fizetős is belefér, az ingyenesre több helyről azt hallottam, hogy megbízhatatlan, azt viszont nem engedhetjük meg, hogy egy harmadik szolgáltató miatt rendszeres kiesések legyenek.

Szerinted a szolgáltatók mekkora százaléka tart fent elfogadhatónak mondható rendszert?

nincs ilyen adatom.

Illetve ott van még a MariaDB, Phalcon, MongoDB és ami még közben kellhet. Nem fogok napokig könyörögni bármi beállításért.

ez eddig ismeretlen adat volt a feladathoz :-) Ha nem ad ilyet a szolgaltato, akkor masikat kell keresni, vagy ha egyik sem biztosit ilyen kornyezetet, akkor marad a sajat gep / vps

Tudtommal az IPS/IDS alkalmazások elég erőforrás igényesek

azok. Elmeletileg egy hibatlanul megirt alkalmazas ill. webszerver eseten el lehetsz ips nelkul, hiszen azok minden malformed inputra helyes hibauzenetet adnak vissza.

azt viszont nem engedhetjük meg, hogy egy harmadik szolgáltató miatt rendszeres kiesések legyenek.

mivel az alkalmazasrol semmit nem tudunk, ezert latatlanban azt mondanam, hogy csinalj egy tartalek site-ot egy masik halozaton (kulfold?), amit gond eseten el tudsz inditani.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Csak szolok, hogy nem a fizetos/nemfizetos reszen mulik, hogy a CF neha szar. Business plannal is lesznek kiesesek, nalunk pl rendszeresen vannak ssl handshake-tol kezdve mindenfele errorok, hiaba vered a supporton az asztalt, mindenki szettarja a kezet, hogy "cloud". (raadasul az ilyen errorok nagy resze hozzad nem is jut el, neked lovesed sincs arrol, hogy valahol valami nem franko)
Probalkozhat az ember whitelist-tel, akarmi, a "mukodo" megoldas az adott ugyfel levalasztasa lett a cloudrol...

raadasul az ilyen errorok nagy resze hozzad nem is jut el, neked lovesed sincs arrol, hogy valahol valami nem franko

azert csak monitorozod a sajat uzleti site-od elerhetoseget?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Az ismert CF pop-okra vannak local vps-ek monitorozasra, de ez nyilvan nem garantal semmit, ugyebar...
Szerk: Ertem ezalatt, hogy a routing valtozhat (mindket oldalon), mashol latja a pop-ot a vps, stb.
Ha lenne kapacitas, raallitanek egy embert, aki naponta vegignyalazza a vpseket, hogy vajh meg a jo-t latja-e, hogy all a CF-RayID, lehet ragozni, de jelenleg erre nincs szabad kez elerheto.
Szerk2: elmentunk monitoring iranyba, holott nem ez a lenyeg; hiaba mondod a supportnak, hogy ekkor meg ekkor elerhetetlen volt innen es innen a site, vagy hiaba latod te magad is a monitoringon, te ezzel CF mogul nem fogsz tudni mit kezdeni, erre akartam kilikadni.

arra gondoltam, hogy a monitorozas alapjan eloallo infok segitsegevel el lehet donteni, hogy jar-e vissza suska az sla sertes miatt, vagy hogy fostalicska a cloudflare szolgaltatasa, es ott kell oket hagyni a csaba...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( procika v | 2015. 10. 18., v – 12:14 )

Itt egy mai fogás pl.:

index.php?setlang=999999.9+%2f**%2fuNiOn%2f**%2faLl+%2f**

Ilyeneket jó lenne megfogni mielőtt átengedem az Apache felé.

Mióta el sem jut az appig a rendellenes kérés, hanem a kliens rögtön forbiddent kap. Példul ha csak /egyikdolog /masikdolog szeru url-eket használ az app, akkor felvehető szabály, hogy egyéb esetben jöjjön a 403. Elég sok lehetőség van, az elmúlt 12 évben éltem is velük, ahol kellett és nem azért mert a változót nem kezelték (vagy akár én, ha írtam a PHP kódot), hanem mert így eleve csak az jut el az appig, aminek el kell.

Ez természeseten csak elfedi a hibát, ettől még az appban minden változót rendesen kell kezelni.

"Mióta el sem jut az appig a rendellenes kérés, hanem a kliens rögtön forbiddent kap."

Ha az alkalmazás sebezhető és nem frissített, akkor persze körül lehet ácsolni a hibát; ha nem sebezhető, akkor miért is fáj, ha az alkalmazás nem szolgálja ki a hibás kérést?

"Ez természeseten csak elfedi a hibát, ettől még az appban minden változót rendesen kell kezelni."

Tehát például az "index.php?setlang=999999.9+%2f**%2fuNiOn%2f**%2faLl+%2f**" helyett vagy validálod az alkalmazás helyett, hogy a setlang milyen értékeket vehet fel; vagy a "/setlang/999999.9+%2f**%2fuNiOn%2f**%2faLl+%2f**" ugyanúgy bejut az alkalmazásig és tulajdonképpen semmit nem tettél a biztonság érdekében...

...bónuszban a GET kéréseken kívüli minden egyéb átgyalogol a rendszeren, miközben nyugodtan hátradőlve szemlélődsz, mert a POST tartalmát nem látod egyik logban se, és a rewrite se...

Röviden: ötletszerűen és vaktában értelmetlen védekezni, meg kell nézni, mit futtatsz, annak milyen ismert sebezhetőségei vannak (egy utolsó molyfing weboldalt nem fognak vadonat új ismeretlen sebezhetőséggel támadni!) és vagy frissíteni vagy alkalmazni a sebezhetőségnél leírt workaround-ot. Minden más csak hamis biztonságérzet.

--
https://portal.gacivs.info

Az nem otletszeru, hogy fixen azokat a kereseket engedem at az app fele amik kinezetre validak az app szempontjabol. Masreszt ilyen botos sql injection kereso cuccoknak mar sikerult dosolnia az apache-ot, illetve az alkalmazast vegsosoron. Harmadreszt kelloen nagy alkalmazasban tuti lesz hiba amit ez kived, meg akkor is, ha rendszeresen frissitett.

Masreszt ilyen botos sql injection kereso cuccoknak mar sikerult dosolnia az apache-ot

hogy?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Minimális tűzfal és rewrite megoldotta

ok, de ez elso sorban a weboldal hibaja volt, ill. ha apache helyett (gondolom libphp.so-val) mondjuk nginx-et hasznalsz fast cgi-vel, akkor talan tovabb huzta volna. Erdemes ip-cimenkent egy jol eltalalt ertekre korlatozni az aktiv tcp kapcsolatok szamat akar a tuzfalon, akar (es/vagy) talan mod_evasive az apache modul neve, ami hasonlot tud (ne kerdezd, hogy aktivan fejlesztik-e meg)...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Sharedhosting volt... :) A php-fpm-el lehet hogy 2 perccel később koppantja a maximális processzámot. :)

Az a baj, hogy hiába a weboldal hibája (akár shared, akár egy vps futó egy darab oldal) jön a rosszaszerver lemez 3 perccel azután, hogy megállt. A nagios persze szól ezekről, de hát izé.

"Ha regexpel rendesen megadod, akkor is megfogod a nagyreszet."

Akkor megfogtál egyet a sok százezer közül... ráadásul olyat, ami nem is képes bejutni, mert nincs olyan szoftvered, ami sebezhető ezzel a hibával.

"Azzal tisztaban vagyok, hogy ezek nem 100%-os megoldasok, de a kerdezo a vedekezest kerdezte."

Azt értem, de a javaslatok nagy része vagy security by obscurity volt vagy csak szimplán növeli a hamis biztonságérzetet, de semmit nem ad hozzá a tényleges biztonsághoz...

"A post kereseket lehet adott url-ekre korlatozni."

Ezt is értem, de naplózzátok és elemzitek is az összes HTTP kérést minden küldött adattal együtt? Szerintem nem, sőt.

A jelek szerint csak a GET-re vagytok ráizgulva, mert az benne van alapból az Apache logban és olyan kevés értékes kérés jön, hogy szemrevételezéssel kiszűrhető az, amikor egy sebezhetőséget próbálnak automatizáltan detektálni.

--
https://portal.gacivs.info

Szia,
Lehet, hogy magamat köveztetem meg, de szerintem az ilyeneket pont az applikációnak kellene lekezelnie. Ő kap hamis inputot (backend oldalra), nem pedig az apache enged be téves lekérést.
Minden értelmesen megírt internet felől elérhető alkalmazásnak fel kell készülnie arra, hogy malformed esetleg támadó jellegű adatot kap (tehát mind az adatforrást, mind annak érték validálnia kell ) és arra tudjon megfelelő hibajelzést adni - vagy reagálni, anélkül hogy bármi komplikációt okozna.
Ha ez nem sikerül, akkor az egész alkalmazás szerintem egy jó nagy security hole, igazából már csak erőforrás pazarlás egyéb védelmeket köré építeni... ( A támadók nem fognak IP réteggel mókázni, ha már egy szimpla GET kéréssel támadható. Nem kérheted meg őket, hogy legyenek kedvesek az acélajtón áttörni, mivel nincs körülötte fal)
De ha kimondottan ismered, milyen mintákra sebezhető az alkalmazásod, és nem tudsz ellene védekezni, szerintem egy reverse proxy elférhet előtte szűrési céllal. Vagy, egy jól konfigurált mod-rewrite...
De ezt ilyen célra csak akkor ajánlanám, ha nem tudsz az alkalmazáson javítani bármilyen okból kifolyólag.
Persze, ez csak a saját véleményem :)
Amit még felvetnék, hogy igazából mitől szeretnéd védeni? Először ez szükséges szerintem meghatározni. Elsősorban, hogy miért érheti támadás a gépedet? Ha ezt meg tudod határozni, akkor már félúton jársz a megfelelő védekezés kapcsán.
( Ha csak attól tartasz, hogy "valaki feltöri", akkor feltehetőleg az átlagos google://[tetszoleges_program_neve]+hardening sokat segít - feltéve, hogy nem minden programod egyedi fejlesztés.)
Üdv,
LuiseX

Szia,
Természetesen ezzel tisztában vagyok, de ha van lehetőséged már az alkalmazással védekezni, rengeteg overheadet tudsz megspórolni ( és, szerintem biztosabb, ha védelem csak annyira vastag, mint szükséges. ).
Mivel szerintem nem csak egy dobozos alkalmazás üzemeltetéséről van szó, hanem érdemben a kódot is tudja módosítani a validációk végett, hatékonyabb lehet nem egy WAF megoldásra támaszkodni, hanem magát az alkalmazást megerősíteni.
Mivel pedig csak egy alkalmazásról van szó, ezért egy WAF megoldás szerintem overkill lenne, és hamis biztonságérzetet kelthet.
A felesleges bevezetett rétegek csak újabb és újabb hibalehetőségeket hordozhatnak - szerintem. Mindig érdemes lehet mérlegelni, hogy szükségesek-e és nem-e túl sokba kerülnek a későbbi karbantartás oldalán. Jelen esetben például, egyetlen alkalmazás elé, ami nem black-box jellegű, szerintem inkább átok, mint haszon.
Persze, ez csak az én meglátásom, a tévedés jogát fenntartom :)
Üdv,
LuiseX

egyetertek, hogy a 'hibatlan' webes cucc a beugro, hogy az ember egyaltalan ki merje tenni a cuccot a webre

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( tbs v | 2015. 10. 20., k – 10:06 )

HaProxy? (A kedvencem. Mostanában (3+éve) az esetleges júzer ssh-k is rajta keresztül mennek. De csak feliratkozás gyanánt. :) )

Backend csere könnyebbség (ahol pl. az sshd lakik), +filter lehetőség (kibagyors regexp!), meg amúgy is kéznél van. Nagyon jó pátyolgatható, a felhasználói (vég és még végebb) access control gyakorlatilag egy helyen van... Ultimate tool - pláne mióta ssl-t is támogat natívan. Szervezem is kifele a stunnel-eket a vasakról. :)