Új, BSD-alapú IPS tűzfalak (x)

Címkék

A történet 1998-ban kezdődött, amikor Fabien Thomas a franciaországi Villeneuve d’Ascq városában a BSD kernel totális átalakításával saját operációs rendszer (NS-BSD) és behatolásvédelem fejlesztésébe kezdett. Az azóta már 9. generációnál járó IPS tűzfal segítségével Fabien cége, a NETASQ egész Európát meghódította és 2009-re már Európai legnagyobb vállalati tűzfalgyártójává fejlődött, 2011-ben pedig hazai képviseletet és oktatóközpontot nyitott.

Az „IPS tűzfal” nem marketingszöveg: a BSD kernelbe statikusan fordított, valósidejű Layer 7 behatolásvédelem, az ASQ szűrőmotor alkotja Fabien és a NETASQ mérnökcsapat fő fejlesztését. Az IPS-től elválaszthatatlan vállalati tűzfalrendszert a kezdetek óta úgy tervezik, hogy maximális biztonsági beállítások mellett vonalsebességű védelmet nyújtson, vagyis a hálózat sebességét a védelem ne csökkentse. Erről tanúskodnak a NETASQ legkisebb, passzív hűtésű eszközei is, amelyek 200 Mbps szűrési teljesítményre képesek – nem szimulált, hanem valós felhasználás mellett.

Az IPS tűzfal pedig azért állja meg a helyét nagyvállalati környezetben, mert hasonlóan más gyártók „újgenerációs” tűzfalaihoz, az egyes hálózati szabályokat nem IP címek és portok alapján, hanem alkalmazásokhoz és felhasználókhoz kapcsolódóan lehet kialakítani.

Miért a NETASQ? Mert az ASQ-motorhoz optimalizált hardveres gyorsítással egy vállalati szerver áráért, hardverárban biztosít teljes védelmi platformot, amely a BSD-kernelben valós időben írja át a javascripteket, hogy eltávolítsa a Facebookról a chatet - vagy amit csak szabályozni szeretnénk.

Rendben, de miért lenne jobb egy hardveres tűzfal?

A folytatásban szeretnénk bemutatni, hogy milyen előnyökkel rendelkeznek a magas szinten integrált NETASQ hardveres IPS tűzfalak a Linux- vagy BSD-alapú nyílt rendszerek, illetve más tűzfalmegoldásokkal szemben.

NETASQ U450

Biztonságos operációs rendszer

A NETASQ termékek esetén nem kell számolni az operációs rendszer biztonsági hibáiból adódó problémákkal. A tűzfalak operációs rendszere, bár BSD alapokon nyugszik, nem általános disztribúció. Nincsenek fölösleges csomagok és alkalmazások. Nem szükséges különböző biztonsági patcheket alkalmazni, hiszen a firmware kizárólag tűzfalfunkciók ellátására készült. Mi sem bizonyítja jobban a NETASQ operációs rendszerének biztonságát mint az, hogy a 13 év alatt 75.000 eladott tűzfalból még egyetlen egyet sem törtek fel.

Tűzfalhoz optimalizált célhardver

A célhardver teljesítménybeli előnye egyértelmű az univerzális számítógépekkel szemben: jóval alacsonyabb áron, jóval alacsonyabb fogyasztás mellett tudnak azonos teljesítményt nyújtani. Ezért egy hasonló teljesítményű és azonos mélységű biztonsági szűrést végző tűzfalat PC alkatrészekből már összeállítani is nehéz azon az áron, amibe egy NETASQ tűzfal kerül.

Sőt, a NETASQ tűzfalak alaplapja és a gyorsítóchipek a firmware igényeihez optimalizáltak, ezért nem állhat fenn a hardver-inkompatibilitás veszélye. Nagymértékben befolyásolja a szűrési teljesítményt az is, hogy a kernelben futó IPS miatt nincs teljesítménycsökkenés a gyakori környezetváltások miatt.

Könnyen áttekinthető beállítások

A NETASQ IPS tűzfalak egyértelmű előnye az egységes, logikusan felépített, minden biztonsági szempontra egyformán kiterjedő kezelőfelület, ami a teljes biztonsági házirendet segít egy képernyőn áttekinteni.

Tűzfalszabály

Gondoljunk csak bele, mennyivel egyszerűbb grafikus felületen elvégezni ezeket a beállításokat, mint ezernyi konfigurációs fájlban kutakodni. A grafikus felület ráadásul automatikusan figyelmeztet a nem megfelelő szabály konfigurációkra; konfigurációs fájlok esetén ennek hiánya inkonzisztens szabályokat és rejtett hibákat, valamint kritikus működési problémákat egyaránt okozhat.

Ha valaki ennek ellenére mégis a konzolos elérést részesíti előnyben, akkor a NETASQ eszközöket SSH-n keresztül korlátlanul, a beállításokat közvetlenül szerkesztve is felügyelheti a tűzfalat.

Beépített kockázatkezelés

A NETASQ beépített valós idejű kockázatmenedzselő megoldása, a SEISMO segítségével gyorsan azonosíthatók a hálózat legkockázatosabb végpontjai.

A SEISMO folyamatosan figyeli a teljes átmenő forgalmat, és minden egyes protokollból következtet a futó programokra: az operációs rendszerekre, a böngésző verziókra, a biztonsági szoftverekre, a PDF olvasókra és bármilyen olyan programra, amit hálózati forgalmából fel lehet ismerni.

Így a SEISMO felületén a rendszergazda valós időben láthatja, mely klienseken van távolról kihasználható sebezhetőség, melyek futtatnak elavult szoftvert, amely hiányzó biztonsági frissítésekkel valódi kockázatot jelentenek.

Soha többet nincs gond a frissítésekkel

NETASQ integrált hálózatbiztonsági eszközök frissítése esetén nem adódhatnak inkompatibilitási problémák a különböző közösségektől származó frissítésekből. A főbb verziók közötti firmware frissítés, vagy épp az előző verzióra történő visszaállítás (a hasznos dupla partícionálásnak köszönhetően) gördülékeny, szemben egy disztribúciófrissítéssel.

Vállalati címtárak használata

A NETASQ tűzfalak egyszerűen integrálhatóak a már meglévő vállalati címtárral (pl.: Active Directory, eDirectory, OpenLDAP). A címtárat felhasználhatjuk az összes szűrési szabályban illetve a VPN felhasználók azonosítása során is. Iptables, ipfw és Snort használata esetén ezt gyakorlatilag lehetetlen megoldani, de még Squid esetén is körülményes az ilyen beállítás. Pedig ma már nincs sok értelme portokra szűrni, hanem felhasználók és csoportok alapján célszerű kialakítani a biztonsági házirendet.

Beépített magas rendelkezésre állás

Két NETASQ IPS tűzfal néhány kattintással összekapcsolható egy logikai tűzfalnak. Így az operációs rendszer bármilyen hardverhiba esetén 1 másodpercen belül(!) átvált a meghibásodottról a jó tűzfalra és minden kapcsolat, session, kontextus vagy épp titkosított telefonhívás ugyanúgy folytatódik. Hasonló saját rendszert kialakítani és minden eshetőségre, terhelési szintre felkészíteni komplex és időigényes, számos rejtett hibát hordozható feladat.

5 további érv a hazai NETASQ mellett:

  • Helyi szakmai képviselettel és oktatóközponttal rendelkezünk Magyarországon. Bármilyen probléma esetén gyors és szakszerű segítséget nyújtunk.
  • Teljesen európai és független a technológia, mi készítjük saját magunk, gazdaságunk, kormányaink és katonaságaink biztonságára.
  • A közölt átviteli teljesítmény a valóságban is helytálló. A mérések esetén például nem használunk Jumbo csomagokat, hanem a csúcstechnológiát képviselő SPIRENT tesztkörnyezettel szimulálunk valódi felhasználást.
  • Minden tűzfalunkon ugyanaz a firmware fut. Teljesítménykülönbség kizárólag az egyes modellek hardveréből adódik, szoftveresen semmit sem korlátozunk. Például a dokumentációban látható maximális VPN kapcsolatok száma nem korlátot jelent, hanem az ajánlott, garantáltan kiszolgálható kapcsolatok számát értjük alatta.
  • Törekszünk a minél közvetlenebb kapcsolatra. Várjuk a kérdéseidet, itt a HUP fórumán, telefonon, emailben vagy épp honlapunk chates ügyfélszolgálatán.

Tudj meg minden továbbit az IPS tűzfalról a http://netasq.hu/Tuzfal oldalon!

(A NETASQ megbízásából készített anyag)

Hozzászólások

Valaki gyakorlati infót is tud adni? (Naná, hogy elolvastam, ha egyszer benne van a bűvszó: LSD - izé BSD.)

Persze, milyen gyakorlati infót szeretnél tudni? Ha van rá időd, terveink szerint legközelebb április 15-én tartunk egy technikai bemutatót Budapesten, ahol élőben is meg tudod nézni a tűzfalakat, mindenféle beállítási lehetőséggel és minden kérdésre választ kaphatsz. Ha többen is szeretnétek megnézni élőben itt a fórumon, akkor szívesen találkozhatunk előtte is egy mindenkinek jó helyszínen!

Bódis Ákos, NETASQ

Mi sem bizonyítja jobban a NETASQ operációs rendszerének biztonságát mint az, hogy a 13 év alatt 75.000 eladott tűzfalból még egyetlen egyet sem törtek fel.

márminthogy legalábbis nem tudnak róla :)

a BSD kernelbe statikusan fordított, valósidejű Layer 7 behatolásvédelem, az ASQ szűrőmotor

remote kernel exploit FTW

Az EAL4+ v3.1-ből adódóan szigorú szabályai vannak a bugkezelésnek, tehát bármilyen bug vagy exploit nem tűnhet el nyom nélkül. Az kétségtelen, hogy távolról kihasználható exploitról soha nem volt tudomásunk, egy ilyen lecsupaszított BSD-n sokaknak meglepetést okozna.

Bódis Ákos, NETASQ

Persze hogy lehet benne hiba, de pont az az IPS lényege, hogy a belső több ezer más alkalmazás hibáját és támadásait kivédhesse. Ha úgy akarod tekinteni, hogy 1 hibaforrást behozol úgy hogy több ezer másikat megszüntetsz, akkor mindenképp jó irányban haladsz. Bízom benne, hogy a több mint évtizedes remote exploit mentességünk pedig sokkal jobb, mint amit bármelyik hálózati OS fel tud mutatni.

Bódis Ákos, NETASQ

Segítünk szívesen, de valóban... a cikkből sok minden kiderül. Ami talán lényeges lehet a kérdezőnek, hogy mindenféle hálózati és biztonsági probléma ellen (exploit, távoli behatolás) és teljes tartalomszűrésre (vírus, spam, url, ...) fejlesztjük, mindent egy dobozban (UTM).

Bódis Ákos, NETASQ

Hát nem mondom, hogy egyértelmű volt amit kérdeztem.

Lehet, hogy elkerülte a cikkben a figyelmemet, de számomra nem derült ki pontosan milyen típusú a tűzfal:

Csomagszűrő
Állapottartó csomagszűrő
Proxy tűzfal (teljes értékű protokoll elemző képességgel)
vagy egyéb

Ha megírjátok megköszönöm :)

Kérlek, bombázzatok bennünket kérdésekkel, véleményekkel és ötletekkel, azért született a cikkünk hogy alaposan körbejárjuk a témakört. Folyamatosan itt leszünk és mindenkinek - mindenre válaszolunk! :)

Bódis Ákos, Rajtmár Ákos és Gömbös Attila, NETASQ

- milyen módon oldható meg a felhasználók és alkalmazások szabályozása (kell valamilyen szoftvert/drivert telepíteni a kliensekre?)

- melyik független IT biztonságtechnikai céggel auditáltatták az eszközöket (különösképp a módosított BSD kernelt és a hozzákapcsolódó userlandet).

- milyen cpu dolgozik a dobozok belsejében (mips, ppc, x86?), milyen "gyorsítóchipek"?

- mennyire felelnek meg az itthoni elvárásoknak (pszáf, ász)?

Válaszolva sorban:

- milyen módon oldható meg a felhasználók és alkalmazások szabályozása (kell valamilyen szoftvert/drivert telepíteni a kliensekre?)
- Nincs kliens-oldali program, az autentikáció történhet számos módon. SSO és Captive portal a két legnépszerűbb, SSO esetében semmi dolga a felhasználónak, Captive portalnál pedig mint egy hotspot belépési pontja, először kikényszeríti a bejelentkezést

- melyik független IT biztonságtechnikai céggel auditáltatták az eszközöket (különösképp a módosított BSD kernelt és a hozzákapcsolódó userlandet).
- Common Criteria és NATO tagállamok saját szerverzetei, akik nem csak a forráskódot, de a cég/fejlesztés teljes működését is elemzik

- milyen cpu dolgozik a dobozok belsejében (mips, ppc, x86?), milyen "gyorsítóchipek"?
- x86 processzorok és különböző ASIC-ek, utánajárunk pontosan

- mennyire felelnek meg az itthoni elvárásoknak (pszáf, ász)?
- Hazai NBH bevizsgálás folyamatban. PSZÁF hogy jön ide? :)

Bódis Ákos, NETASQ

PSZÁF pl. szokott ilyeneket kérdezni, hogy van-e olyan tűzfal policy management, hogy melyik netadmin mikor, milyen célból módosított a szabályokon, melyik vezető engedélyével, milyen lejárati idővel, stb. Megfeleltethetők-e a vezetői jóváhagyások a jelenleg beállított tűzfal szabályokkal. Erre egyes helyeken külön nyilvántartó rendszert vezetnek, olyan szoftverekkel, amelyek ezt megkerülhetetlenül kikényszerítik (és akár maguk a szoftverek konfigurálják a hálózati eszközöket, a tűzfalak konfigurációjához így közvetlenül a netadminok sem nyúlnak). A kérdés töbekközt az, hogy ilyen jellegű policy management van-e integrálva a tűzfalba, vagy kapható-e hozzá olyan szoftver, amely támogatja ezt. Esetleg más gyártók ilyen jellegű termékei együttműködnek-e ezekkel az eszközökkel, amelyekkel ezt nyilván lehet tartani.

Köszönöm a pontosítást, így már értem! Mindenképp utánajárunk, hogy itthon milyen vizsgálatot tudunk esetleg velük lefolytatni. PCI DSS szabványnak megfelelünk (rengeteg banki ügyfelünk van), change management integrálva van a tűzfalba, tehát jól követhető hogy ki-mikor és mit módosított. Minden netadmin saját felhasználójával tudja kezelni a tűzfalat, különböző jogkörökkel természetesen. Tehát külön szoftverre nincs hozzá szükség, ez a menedzsmentszoftverekben benne van.

Bódis Ákos, NETASQ

"Common Criteria és NATO tagállamok saját szerverzetei, akik nem csak a forráskódot, de a cég/fejlesztés teljes működését is elemzik"

Ez igy meg semmit sem mond, lattunk mar szornyu dolgokat CC EAL4 plecsenivel.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

- Maximális átviteli sebesség 64byte méretű packetek esetén?
- Van-e multicast support?
- A fenti kérdésből fakadóan esetleg PIM-SM (vagy DM), DVMRP, etc protokol támogatás?
- Mennyi a hozzáadott latency - nyilván ki lett mérve - abban az esetben ha minden létező védelem be van kapcsolva.
- HA esetében csak active-passive üzem van? Esetleg Active-Active?
- Management felület: Van-e és tud-e egyszerre több tűzfalat managelni, multiple shared policy, shared objects,? A'la Check Point Provider-1 vagy Juniper NSM ?

Sziasztok,

ami kerdesre hirtelen tudok valaszolok, a tobbinek kicsit utana kell nezni :)

- milyen módon oldható meg a felhasználók és alkalmazások szabályozása (kell valamilyen szoftvert/drivert telepíteni a kliensekre?)

Nem kell telepiteni semmit, a felhasznalok authentikalasa captive portalon keresztul tortenik, amennyiben beallitod.

- milyen cpu dolgozik a dobozok belsejében (mips, ppc, x86?), milyen "gyorsítóchipek"?

Alapvetoen amennyire en lattam x86-os architektura, a gyorsitochipeknek pedig ha egzakt valaszt szeretnek adni, meg kell kerdezni a fejlesztoket, de olyan chipekre kell itt gondolni, mint az IPSEC vpn gyorsitasara szolgalo, valamint az egyeb titkosito/hashelo algoritmusokat kiszolgalo chipek.

- Maximális átviteli sebesség 64byte méretű packetek esetén?

Ennek utanakerdezhetek, hogy erre a konkret esetre milyen eredmenyek szulettek, de az egyes atviteli sebessegek a mert legkisebb sebesseget veszik alapul, ami termeszetesen minden funkcio bekapcsolasa mellett ertendo. Igy az eszkozre vonatkozo megadott atviteli sebessegnel nagyobb, vagy egyenlo lesz ez
az ertek.

Rajtmar Akos, Netasq

igyvan, a legtobb gyarto imadja 1500bytes eredmenyeit publikalni, a 64 tokeletes viszonyszam.

latom SPIRENT-el teszteltetek, akkor csak eresszetek ra egy 64byteos tesztcase-t, meg kivancsi lennek egy IMIX eredmenyre is.

Megvalami, komplex protokolloknal mint pl VoIP ha van full DPI, mennyi a maximum konkurrens hivas, illetve a call setup rate?

Na meg láttunk már olyat, hogy max pps közelében bekapcsoltuk a session init/session close logolást és az egész miskulancia (cisco) újraindult. :)
Szóval nekem olyan kérdésem van, hogy le is tudja logolni a megadott forgalmakat? TCP/TLS alapú logolást tud-e. Mennyi log buffer-van?, Mi történik ha elveszti a logszerverrel a kapcsolatot (audit loss mitigation?) stb.

hahaha igen ezek nagyon elvezetesek tudnak lenni, CP-n is volt egyszer 650+ szabalyt tartalmazo policyben kellett a loggolast bekapcsolni, szegeny tuzfal azonnal elvesztette a kapcsolatot a CLM-el, (de elotte a CLM-et teleszemetelte annyira hogy az MLM-en mdsrestart kellett.) Ez meg az R60as idokben volt, R65 + feljebb igen stabil lett mostmar ez a resze is :-)

Elnézést a késői válaszért, tehát: van lehetőséged leállítani a tűzfalat (pontosabban a forgalmat) ha megtellik a log. Külső syslog szerverre és belsőre is dolgozhat, és kritikus környezetben garantált, hogy nem mehet át csomag naplózás nélkül.

Persze bármilyen forgalmat is lehet vele naplóztatni .pcap formátumban, utána pedig lehet elemezni Wireshark és társaival.

Bódis Ákos, NETASQ

Nézd meg kérlek szépen az IPS tűzfal honlapját, a jobb oldalon van egy táblázat a max. egyidejű kapcsolatok számával (50ezertől 2,5 millióig). Illetve az ott is hivatkozott PDF, amit az oldalon picit feljebb találsz részetes táblázatot tartalmaz az egyes modellek teljesítményadatairól, pl. a maximális másodpercenkénti új kapcsolatok számáról.

Bódis Ákos, NETASQ

A legutolsó, ami eszembe jutna, hogy egy grafikus felületen konfigurálható tűzfalat rakja a rendszerbe...

kivancsi lennek arra a sajat admin feluletre hogy mit tud.

CP vagy Juniper eseten pl mindkettohoz van egy grafikus felulet is remekbeszabott(!) CLI melle, es hogy miert, mert 1000+ tuzfalnal atlathatobb a szabalyrendszer es az osszes tobbi egyebb beallitas.

Pl itt sehol se latom leirva hogy csak grafikus felulet lenne, es nelehetne hozzaferni mondjuk a full confighoz akar egy txt vagy xml faljban...

Idézet a posztból:
"Gondoljunk csak bele, mennyivel egyszerűbb grafikus felületen elvégezni ezeket a beállításokat, mint ezernyi konfigurációs fájlban kutakodni."
kérdezem: biztos?

egyébként is van pár beszólás a linux felé, ez sem tetszik. egy berendezés gyártója ne a linux *ellen* határozza meg önmagát, hanem arról írjon, hogy miért jobb.

az admin cuccom egy speciális részterületre van, nem általános, mint egy cp vagy egy juniper.

szerintem lezárhatjuk, hogy az én cuccom milyen, elmondtam, hogy milyen stiláris és egyéb problémáim vannak a hirdetéssel, a többit meg hagyjuk.

> az admin cuccom egy speciális részterületre van

tehát vi, ezért mondjuk kár volt a patetikus felvezetés

> ne a linux *ellen* határozza meg önmagát, hanem arról írjon, hogy miért jobb.

a cikk a kép után folytatódik, egotrip helyett próbáld tovább olvasni - common mistake

egyébként is van pár beszólás a linux felé, ez sem tetszik. egy berendezés gyártója ne a linux *ellen* határozza meg önmagát

én pl. a "linux" szót nálad látom először, így nem tudom mennyire az *ellen* van.

az, hogy bsd-alapú nyilván valamennyire marketingfogás akarna lenni azoknak, akik linuxot már láttak, a bsd-ről meg azt hiszik, hogy valami misztikus dolog...

Lehet, hogy letezik szerencsesebb megfogalmazasa is, de ennek a resznek a lenyege fokent az lett volna, hogy teljesitmenyben lenyegesen mast nyujt ez a megoldas a celhardver miatt, mintha fogsz egy "hetkoznapi" architekturaval rendelkezo szervert es esetleg abbol alakitasz ki egy mondjuk linuxos alapokkal biro rendszert. Ennel tobbet ne gondoljatok bele :) Nincs szo semmilyen mertekben sem mas platformok leszolasarol.

Rajtmar Akos, NETASQ

Az más tészta, én a hirdetésről beszéltem, hogy abban valószínűleg miért lett ez kiemelve.

A Juniper router/tűzfal termékei és a Cisco IronPort is FreeBSD alapúak, mégse ezzel a szöveggel szokták hirdetni, mert legtöbb embernek semmit se mond ez. Nyilván itt érdemes erre alapozni a marketinget, mert a sok linuxos hupper csak annyit tud róla, hogy a hup.hu is FreeBSD-n fut, úgyhogy biztos jó lehet... :p

(Disclaimer: Ezen poszt írója nem kívánta a FreeBSD rendszereket se jónak, se rossznak beállítani, egyszerűen csak óva inti az olvasókat attól, hogy pusztán egy ilyen információ alapján próbáljanak meg messzemenő következtetéseket levonni egy termékről. :)

Egy bonyolult szűrő a kernelben kétélű fegyver. A minél nagyobb teljesítmény miatt elsőre nyilván logikus döntésnek tűnik (nem öli meg a rendszert nagy terhelés esetén a context switching például), de nem körültekintően implementált megoldás esetén irtó nagy biztonsági kockázat lehet. Márpedig egy bonyolult szűrőrendszert elég nehéz hibamentesen lekódolni.

Ha hozzáveszem, hogy a W^X memóriavédelem még a - tévesen - róla elhíresült rendszeren sincs megvalósítva kernel térben (tehát még OpenBSD kernelspaceben sincs W^X, nemhogy FreeBSD-ben, ahol még userspaceben se), akkor pláne problémásnak találom az ilyen jellegű megoldásokat, mert még csak prevenciós technikák se próbálnak védeni a kihasználásuk ellen.

De hátha NETASQ megcsinált egy komplett PaX portot FreeBSD-re, ami megnehezítené a kernelben lévő memória korrupciós hibák kihasználását, ezért lenne jó látni valami részletes anyagot valamelyik ITsec cégtől, akik darabokra szedték a tűzfalukon futó rendszert és leírták a tapasztalataikat... ;)

Minden beállítás elérhető egyszerű, könnyen érthető ASCII fájlokban is. Néha (főleg távolról) könnyebb lehet például egy hibás NAT szabályt parancssorban kijavítani.
Amúgy nincsen pontosan korlátozott CLI felület, hanem teljes SSH elérés, persze sok egyszerűsítő paranccsal. De nem ez a cél, a GUI-n a beállítások 99%-a elérhető.

Bódis Ákos, NETASQ

Néhány dolog amit találtam, hátha mást is érdekel:

- Egy EuroBSDCon előadás szlájdjai 2007-ből NETASQ BSD kapcsán. Van benne néhány érdekes dolog, sajnos az ASQ szűrőmotorról nem sok szó esik.
- A leírásban szerepel egy hivatkozás a Pollng patchükre, amelyben van egy 100 oldalas doksi rakás méréssel.
- Egy rövid interjú franciául (google translate) a fentebb előadó NETASQ fejlesztővel.

Nagyszerű dolgokat találtál, sok minden kiderül belőlük! Bevallom én annyiról tudok, hogy szoros az együttműködés a FreeBSD közösség tagjaival és gyakran javítunk hibákat, például a prezentációban is említetteket. Ezen felül több részletet ritkán kötnek az orrunkra, de igyekszünk mindenre választ adni!

Bódis Ákos, NETASQ

Es valoban, meg freebsd devel listan is szoktam latni a cegeteket.

7-STABLE:


op@pandora-d sys> git log | grep -i netasq
    Sponsored by: NETASQ
    Sponsored by: NETASQ
    Obtained from:      NETASQ
    Obtained from:      NETASQ
    Obtained from:      NETASQ
    Reported by:    VANHULLEBUS Yvan <vanhu@netasq.com>
    Obtained from:      NETASQ
    Obtained from:      NETASQ
      Reported by:  david gueluy <david.gueluy at netasq.com>
    Submitted by:       fabien.thomas@netasq.com
    Reported by:        Fabien THOMAS <fabient@netasq.com>

9-CURRENT:


op@pandora-d 9-CURRENT.git> git log | grep -i netasq
    Obtained from:      NETASQ
    Obtained from:      NETASQ
    Obtained from:      NETASQ
    Obtained from: NETASQ
    Sponsored by: NETASQ
    Obtained from:      NETASQ
    Obtained from: Xavier Heiny <xavier.heiny@netasq.com>
    Submitted by:       aurelien.ansel@netasq.com
    Obtained from:      NETASQ
    Submitted by:       aurelien.ansel@netasq.com
    Obtained from:      NETASQ
    (julien.vanherzeele@netasq.com, for years of bug reporting), the PFSense
    Obtained from:      NETASQ
    Obtained from:      NETASQ
    Obtained from:      NETASQ
    Obtained from:      NETASQ
    Obtained from:      NETASQ
    Obtained from:      NETASQ
    Reported by:        david gueluy <david.gueluy at netasq.com>
    Submitted by: fabien.thomas@netasq.com
                Fabien Thomas <fabien dot thomas at netasq dot com>,
    Tested by:  Fabien Thomas <fabien.thomas at netasq dot com>
    Requested by:       Fabien Thomas <fabien.thomas at netasq dot com>
    Reported by:        VANHULLEBUS Yvan <vanhu@netasq.com>
    Submitted by:       Alexandre Belloni  alexandre.belloni of netasq.com
    Reported by:        Fabien THOMAS <fabient@netasq.com>

___
info

Nehany dolog, ami megragadta a figyelmem, tovabb nem olvastam:)
Kontrasztnak a linux/bsd-t hozzatok fel, igy abbol a szempontbol reagalok en is.

"A NETASQ termékek esetén nem kell számolni az operációs rendszer biztonsági hibáiból adódó problémákkal. A tűzfalak operációs rendszere, bár BSD alapokon nyugszik, nem általános disztribúció. Nincsenek fölösleges csomagok és alkalmazások. Nem szükséges különböző biztonsági patcheket alkalmazni, hiszen a firmware kizárólag tűzfalfunkciók ellátására készült."
-> Nem ertem, hol az ok-okozat osszefuggese?

"Mi sem bizonyítja jobban a NETASQ operációs rendszerének biztonságát mint az, hogy a 13 év alatt 75.000 eladott tűzfalból még egyetlen egyet sem törtek fel."
-> Mennyit tortek meg, abbol, amit vedett, nem? A tuzfal feltorese majdhogynem erdektelen, ha a vedendo ojjektum mar paffon van.

"Ezért egy hasonló teljesítményű és azonos mélységű biztonsági szűrést végző tűzfalat PC alkatrészekből már összeállítani is nehéz azon az áron, amibe egy NETASQ tűzfal kerül."
-> Mint a hozzaszolasokban irjatok, x86, tehat kvazi PC alkateszekbol epul fel ez az eszkoz is: alaplap, ram, x86 proci stb. Miert lenne akkor olcsobb? Sajnos arat hozzavetolegesen sem irtok, igy ez egy nesze semmi fogd meg jol (bocs, ha elkerulte volna a figyelmem, javitsatok ki).

"Nagymértékben befolyásolja a szűrési teljesítményt az is, hogy a kernelben futó IPS miatt nincs teljesítménycsökkenés a gyakori környezetváltások miatt."
-> Mi? Elkezdtem gondolkozni, h meterologusokat is alkalmaztok, kulso felhasznalasra keszitetek eszkozoket, vagy mit akartok ebbol kihozni. Aztan rajottem, a context switching-re gondoltok?
Ez miert erdekes a vegfelhasznalonak a sebesseg szempontjabol? Azt akarjatok allitani, hogy gyorsabb a szures, mint egy hasonlo aru/hw/TCO-ju gep, vagy mit szerettetek volna ezzel kozolni?
Komoly IT szakember ezen elmosolyodik, a manager/penzember pedig hujen nez, hogy miezitt. Nem latom a celjat, pedig tenyleg erdekel.

"Gondoljunk csak bele, mennyivel egyszerűbb grafikus felületen elvégezni ezeket a beállításokat, mint ezernyi konfigurációs fájlban kutakodni"
-> Belegondoltam, semennyire:)

Nem vitas, hogy vannak elonyei egy ilyen eszkoznek, de miert nem azokat emeltetek ki egy szakmai portalon olyan cikkel amik valosan es nemcsak egy altalanos ervenyu generalt szoveg?

Elsore nekem az az erzesem tamadt, hogy a hazai(*) kepviselet nincs kepben azzal kapcsolatban, mit is arulnak/supportalnak. Ami egybol vetozhat meg akkor is, ha a gyarto es maga az eszkoz akar megfelelne.

Ha csinalnatok egy bemutato cikket, szerintem sokan sokkal jobban orulnenek neki, ergo jobban megnerne a penzet.

udv,

t

ui.: A cikk elejen alkalmazott nyelvtani kornyezetben a "hazai" szo a termek hazajat jelenti, pedig ti feltetelezem Mo.-ra gondoltatok.

Arra az összefüggésre akartunk csak rávilágítani, hogy a tűzfalainkon nem egy általános operációs rendszer fut, amire egy független szűrő- és IPS-motort készítettünk. Az operációs rendszer egyrészt a hardverhez optimalizált, nincsenek kompatibilitási problémák. Továbbá nem a felhasználó feladata a több forrásból származó biztonsági frissítések beszerzése sem, és a különböző forrás miatti inkompatiblitási problémák se lépnek fel.

A tűzfal feltörése véleményünk szerint nem teljesen érdektelen. Ha a támadó irányítást szerez a tűzfalon, onnéttól kezdve a belső rendszereken olyan sebezhetőségek is elérhetőek lennének, amit a tűzfal egyéb esetben kivédett volna.

Természetesen összerakható hasonló hardver, azonban az ASQ motor nélkül a teljesítménye jóval alacsonyabb lesz. A tűzfalak tartalmaznak az titkosítást és hashelést támogató chipeket is, használatuk ugyanúgy összemérhetetlen teljesítménynövekedést jelent, mint a GPU-k használata videolejátszás vagy renderelés során.

A konfigurációs interfészről lehet vitatkozni, nálunk mind grafikus felületen, mind konzolból adminisztrálható az eszköz. Mindkettőnek megvannak az előnyei, általános feladatok végrehajtására szerintünk azonban a grafikus felület jóval több szolgáltatást nyújt (pl. konzisztencia ellenőrzés).

Gömbös Attila, NETASQ

"Arra az összefüggésre akartunk csak rávilágítani, hogy a tűzfalainkon nem egy általános operációs rendszer fut, amire egy független szűrő- és IPS-motort készítettünk. Az operációs rendszer egyrészt a hardverhez optimalizált, nincsenek kompatibilitási problémák. Továbbá nem a felhasználó feladata a több forrásból származó biztonsági frissítések beszerzése sem, és a különböző forrás miatti inkompatiblitási problémák se lépnek fel."
-> Igen, ezert jo lett volna, ha csak ennyit irtok. A kompatibilitasi problemak hianyat tobbszor kiemelitek es ez tok jo.

"A tűzfal feltörése véleményünk szerint nem teljesen érdektelen. Ha a támadó irányítást szerez a tűzfalon, onnéttól kezdve a belső rendszereken olyan sebezhetőségek is elérhetőek lennének, amit a tűzfal egyéb esetben kivédett volna."
-> Mint irtam, szerintem sem teljesen. Viszont ami igazan fontos es erdekes, az a vedett rendszerek statisztikaja. Mashogy fogalmazva a fonokember tesz ra, hogy a tuzfalat feltortek vagy nem, ha mogotte a ceg valodi erteket tarolo szervert feltortek, es mondjuk az adatokat elloptak rola.

"Természetesen összerakható hasonló hardver, azonban az ASQ motor nélkül a teljesítménye jóval alacsonyabb lesz."
-> Epp ezert en az ASQ motort emelnem ki a hirdetesben, ill. arra mutato leirasokat raknek bele erdemi informacioval.

"A tűzfalak tartalmaznak az titkosítást és hashelést támogató chipeket is"
-> Ilyen eszkozoket vasarolhatok kulon is, amit hozzailleszthetek a tetszoleges HW-mhez, nem? Itt persze teljesen jogosan kepbe jon ujra a kompatibilitas es az optimalizaltsag.

"A konfigurációs interfészről lehet vitatkozni, nálunk mind grafikus felületen, mind konzolból adminisztrálható az eszköz. Mindkettőnek megvannak az előnyei, általános feladatok végrehajtására szerintünk azonban a grafikus felület jóval több szolgáltatást nyújt (pl. konzisztencia ellenőrzés)."
-> En ennel a hozzaszolasomban arra gondoltam, hogy ti megmondjatok, hogy az GUI jobb, kvazi eldontitek a user helyett, ami negativ erzeseket kelt, legalabbis bennem.
Kozben raadasul kiderul, hogy lehet hasznalni CLI-t is:)

Mindamellett tetszenek a termekek. Kulon tetszik, hogy konstruktivan es nyiltan alltok ehhez a a potencialisan user, de egyben zert kukacoskodo kozonseghez is.

udv,

t

engem az M-sorozat erdekel:

- valami konkret pdf. Az attekinto.pdf azert eleg szukszavu, es a gyarto (nem a hazai disztributor, hanem aki konkretan kesziti es programozza a dobozokat) 2 oldalas pdf-einel is valami technikaibbra gondoltam. Van ilyen?
- egy arlista* az M200-tol az M3000-ig
- egy netre feldugott eszkozhoz kapott :-) ssh es webes hozzaferes. Szivesen vegigkattintanam, hogy mit tud...

*: nem csak az alapar, hanem a licencek (cloudmark, kaspersky, ...) ill. az esetleges extrak arai is - ha vannak

Btw. nagyon impressziv a feltuntetett 99.7%-os spam felismeresi arany. Mondjuk az azert nagyon komoly, hogy also hangon 2,5 eves (2008-as) eredmenyrol van szo. Gondolom, ez kell ahhoz, hogy a 80%-os spam aranyt meg ma is el lehessen adni... :-)

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

Az M sorozatrol, vagyis MFILTRO-rol bovebben a honlapunkon talalhatsz infot, de valoban a legjobb az, ha vegig tudod kattintgatni. Aprilis 15-en nincs kedved eljonni az eloadasunkra, ahol utana mindent vegig tudunk kattintani? Arakat is tudok mondani, de az nem a forumba valo :)

A rendszer technikailag a Cloudmark Bizanga IMP MTA-t jelenti Vade Retro es Kaspersky szuromotorral, es nagyon jol alakithato sajat rendszerekhez. Peldaul egy rendszerben kesleltetjuk a levelet, ha az adott postafiokot tarolo backend szerver RAID-je eppen rebuild alatt all, szinte barmilyen adatbazissal es lekerdezesel ossze lehet loni a rendszert.

Bodis Akos, NETASQ

Ha kiderul a helyszin, es a mettol-meddig, akkor meg tudom mondani, hogy el tudok-e menni :-)

Az arakat el tudod kuldeni a kapcsolat fulemen, vagy ha mellekelni is akarsz valamit, akkor kozvetlenul a forum@hfp.hu cimre, kossz.

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

A képzések típusáról módjáról, árairól szeretnék kérdezni még:

-Létezik-e az eszközhöz auditált nemzetközi szintű képesítés?
-Áll rendelkezésetekre nyomtatott tananyag, demo labor?
-A képesítésekről price-list?

Létezik nemzetközi auditált képzés. Az elméleti és gyakorlati részeket is tartalmazó vizsgákat Franciaországban értékelik ki a NetASQ Instituteban.
Háromszintű képzési rendszerünk van:
- Admin: IPS tűzfal és spamszűrő rendszergazdai képzés
- Expert: Komplex rendszerek biztonsági feladatainak megoldása
- Expert+: Partnereket és terméktámogatókat felkészítő képzés
Mindegyik képzéshez nyomtatott könyvet biztosítunk. A képzés során rendelkezésre áll egy labor környezet, amin gyakorlatokat kell elvégezni.

Jelenleg Magyarországon az Admin szint szerezhető meg a havi rendszerességgel tartandó tanfolyamunkon, hamarosan az Expert és Expert+ tanfolyamok is elérhetőek lesznek. Elsődleges célunk most egy viszonteladói és rendszerintegrátori partnerhálózatot Admin képesítéssel felvértezni. A http://netasq.hu/Oktatas oldalon olvashatók röviden ennek a Silver Partner Startup Packnak a részletei.

Amennyiben a konkrét árak érdekelnek, akkor kérlek privátban, vagy a netasq.hu oldalán keress meg.

Rövid leírást az egyes képzésekről itt is találhatsz: http://www.netasq.com/en/firewall-services/training.php

Gömbös Attila, NETASQ

Mivel többen kérdeztétek, íme itt az információ az április 15-én tartandó bemutatónkról.

Helyszín:
AlphaSonic oktatóterem
1044 Budapest, Ipari park u. 8.

Időpont:
2011. április 15. (péntek)
10:00 - 15:00 (vagy ameddig kérdésetek van...)

A délelőtti NETASQ termékekről szóló ismertető után meghívunk egy kellemes ebédre, a délutáni órákban pedig technikai bemutatókat tekinthettek meg, ahol a gyakorlatban is megismerhetitek a NETASQ IPS tűzfalak és az MFILTRO működését.

Várunk szeretettel minden érdeklődőt!:)

Gömbös Attila, NETASQ

spamszuro kerdesek:

- a "dynamic URL blacklisting' az egy (vagy tobb) publikus rbl hasznalatat jelenti, pl. uribl, surbl, ill. a szokasos DNS query-kkel?

- a heurisztikus engine tobb ezer szaballyal az azt jelenti, hogy spamassassin is fut a gepen?

- milyen beallitasok mellett mertek ki pl. az M3000-es orankenti ~1M level teljesitmenyet? Be volt-e kapcsolva az RBL/URL BL-ek hasznalata, ill. mas olyan feature-ok, amelyekhez a szukseges infot az Internetrol szerzi be (pl. egy DNS query)?

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

A spamszurovel kapcsolatban: az eszkoz igazabol mindent "tud". Vagyis egy egyszeru programnyelved van, amiben le tudod programozni, hogy milyen ellenorzeseket, hogyan vegezzen, if-then-else elagazoskat csinalhatsz, szabakyokra ugorhatsz... Mintha egy assembly lenne az SMTP-hez, ahol a szorzas muvelet helyett SURBL lookup szerepel, es memoriamasolas helyett egy SQL queryt tudsz inditani. Nehez elmondani, latni kell!

A teljesitmenyszamok valoban is kijonnek. Legnagyobb hazai telepitsunknel napi 20 millio spamet szurunk, itt sokszor megkozeliti, neha atlepi az orankenti kihasznaltasag a papir szerintit, pedig tobb mint 50 szabalybol all a szurorendszer es 5-6 dns lookup is van benne, tarpitting-szeru traffic shaping mellett.

Bodis Akos, NETASQ

Hmmm, hat ezt tenyleg latni kell, mert 5-6 DNS query azert sulyos masodpercekbe kerul, ha a netrol kell lehozni az adatot, es pl. nem kizarolag egy lokalis DNS cache-sel kommunikal, amiben ott vannak a rendszeresen frissitett IP es URL feketelista adatok.

Btw. ki ez a magyarorszagi napi 20M levellel kuzdo szervezet? Legalabbis a referenciak kozott nem latok hazai ceget...

Btw. latom, az arak meg mindig titkosak, mert nem akartok arlistat kuldeni ... :-) NDA-rol is lehet szo, ha ezen mulik ... ;-)

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

Minden erdeklodonek kuldunk szivesen arakat, privatban keresni fogunk! Nem hadititok, de ez megis egy nyilvanos forum. Az alaparak lathatok a honlapunkon, amikbol latszik hogy nem a foldtol elrugaszkodott arazasrol van szo.

Az emlitett szervezet hamarosan publikus lesz, be fogjuk jelenteni! :)

Bodis Akos, NETASQ

Hmmm, hat ezt tenyleg latni kell, mert 5-6 DNS query azert sulyos masodpercekbe kerul, ha a netrol kell lehozni az adatot, es pl. nem kizarolag egy lokalis DNS cache-sel kommunikal, amiben ott vannak a rendszeresen frissitett IP es URL feketelista adatok.

És akkor mi van ha várni kell? sleepbe megy a thread, ami azzal a levéllel foglalkozik, amíg meg nem jön a válasz. Egyébként meg ekkora levélfogralomnál már bőven megéri dns cache-t használni.
Én problémásabbnak látom pl a bayes szűrőt, amihez viszonylag sok erőforrás kell, ekkora levélforgalomhoz meg valszeg egy szerverfarm, de utána kellene számolni.

És akkor mi van ha várni kell? sleepbe megy a thread, ami azzal a levéllel foglalkozik, amíg meg nem jön a válasz.

Az, hogy ez csokkenti a throughput-ot.

Egyébként meg ekkora levélfogralomnál már bőven megéri dns cache-t használni.

Persze, kell is, de ez csak akkor segit (igazan), ha egy adott rekordot ismet le akarsz kerdezni. De ahol igazan szamit (spam), ott imho (de javits ki, ha rosszul latom) keves ismetlodo DNS query lesz.

Én problémásabbnak látom pl a bayes szűrőt, amihez viszonylag sok erőforrás kell, ekkora levélforgalomhoz meg valszeg egy szerverfarm, de utána kellene számolni.

OK, szamoljunk. A freemail (2007-es adat szerint) egy kb. hasonlo levelmennyiseget 18 HP rack szerverrel szurt spamre/virusra (nyilvan ebben a redundancia is benne van). A sajat tesztjeim alapjan egy bayesmondjuk most azt elso korben: statisztikai szuro egy noname desktop pc-n napi 4-5M levelet el tud vinni. Adj hozza ehhez is nemi redundanciat, csereld le korrekt, szervernek valo vasakra, es kaptal egy nagy teljesitmenyu cuccot. Majd linkelek konkret szamokat is, ha erdekel...

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

Ha a leveleket lassabban dolgozza fel (mert varni kell a DNS query-k eredmenyere), akkor lassabban haladnak at rajta a levelek, nem? Ha van egy n savos autopalyad, akkor az ateresztokepesseget az hatarozza meg, hogy (az egyes savokon) milyen gyorsan haladnak at az autok. Ha valamiert lassan mennek, akkor x ido alatt csak kevesebb tud atmenni egy adott hosszusagu szakaszon. Vagy nagyon beneztem valamit?

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

husika, tedd mar meg, hogy lekopsz rolam. Mert miert is tennelek be a hup.user.js szurobe, ha okosabb vagy te annal, hogy rajtam koszoruld a dolgaidat? Vagy en is menjek user/1-hez nyivakolni, hogy dobja ki ezt a fika-user-id-det is? Aztan meg nem gyozod majd kisirni magad anyukad szoknyajanal. A vegen meg egy nyakast is kioszt, ha belefujod az orrod... Akadj hat le szepen rolam, kis balazs...

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

biztosan erosodtek, felteve, ha lecsereltek azota :-)

A redundanciat amugy nem az mfiltro doboz kapcsan hoztam elo, hanem ugy kerult a csizma az asztalra, hogy fentebb volt egy felreertes a bayes-i szurok teljesitmenye kapcsan, es arra reflektaltam, hogy teljesen korrekt atereszto kepesseget ki lehet beloluk csiholni.

Btw. egy napi 18M levelet feldolgozo halozatban nyilvanvaloan nem egyetlen hardveres doboz mukodne/ik - imho persze...

Az az osszehasonlitas egyebkent egy masik gyarto masik termeke (amelyik a cloudmark engine-jet hasznalja) es a clapf kozott tortent (OK, VMware alatt), es azt kaptam, hogy az a masik termek, ha jol bekonfigolod, csak picivel marad le a clapf teljesitmenye mogott.

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

Valójában ezeknek a levélmennyiségekenek a töredékét kell csak szűrni. Épp az a lényege az MFILTRO és hasonló rugalmasan programozható SMTP tűzfalaknak, hogy már a policy használatával megtizedelje a spamet, és a tartalomszűrő motoroknak csak kevés feladat maradjon.

Az MFILTRO ezt elég jól teszi, mert külön queueban futnak a tartalomszűrők, tehát el tud fogadni kiugró csúcsokat is, aztán az üresjáratban majd utoléri magát a szűréssel. Jó queue kezelés, jó threadkezelés (vagy thread mentes kontextusok közötti átkapcsolással) óriási kapcsolatmennyiséget le lehet korrektül kezelni.

Bódis Ákos, NETASQ

Az MFILTRO ezt elég jól teszi, mert külön queueban futnak a tartalomszűrők, tehát el tud fogadni kiugró csúcsokat is, aztán az üresjáratban majd utoléri magát a szűréssel.

Ezt az össze after-queue szűrő meg tudja csinálni. A probléma ezzel, hogy már a DATA command végén el kellene dönteni a levélről, hogy befogadjuk-e (before-queue), elkerülve a backscattereket, az adaptív graylistről nem is beszélve.

az after-queue-nak nem kell feltetlen backscatter-rel egyuttjarnia, mert pl. a virusos levelet a legjobb lenyeletni a tartalomszurovel, a spamet meg nem szabad visszabounce-olni. Ill. atfer-queue szuro mellett is sok dolgot meg DATA elott vissza lehet dobni (pl. RBL, greylisting, bena helo, ki mit szeret...)

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

Persze backscatterre egyszerű a megoldás, spamre semmiképp nincs NDR.

Amúgy mindkét megközelítéssel jelentős gyakorlati tapasztalatot sikerült már összegyűjtenünk. A minden szűrést a DATA parancs után végző megoldásnál jelentős thread korlátba ütközünk egy idő után, itt a hagyományos "1 levél szűréséhez X MB memória kell" elv alapján elfogy a memória a párhuzamosan feldolgozott levelek számával.

A több queuera bontott szűrésnél sokkal nagyobb tud lenni az áteresztőképesség és sokkal nehezebben DoSolható is a rendszer, nagyságrendekkel több terhelést elbír. Hardveres megoldásoknál éppen ezért csak ezt használjuk, mert itt MB-ra pontosan kiosztható a memória, míg szoftveres esetekben a pre-queue feldolgozás egyszerűbb. De tényleg csak egyszerűbb, mert a másik esetben sincs feltétlenül gyakorlati, a felhasználó-élményben jelentkező probléma, csak a működésből adódó eltérések.

Bódis Ákos, NETASQ

Értelmes szűrési architektúrát kell tervezni: pl n szálból álló worker thread dolgozza fel a leveleket, ha megtelik, akkor sorbaállítjuk a maradékot az MTA-ban (még mindig nem okézzuk le a levelet, csak nyitvatartjuk a TCP kapcsolatot), így csak annyi memóriát foglalnak, amennyi a levél mérete. Az SMTP protokoll elég nagy timeoutot definiál, hogy egy-egy ilyen peaket kezelni tudjon a szűrő.

A szoftveres/hardveres különbséget nem igazán értem. A ti eszközötekben nem x86-os CPU dolgozik, rajta random szoftverrel?

Szoftveres/hardveres különbség: a hardvert tudjuk előre, hogy mi van benne és mennyi memóriánk van, ehhez tudunk optmializálni. Ha egy szoftveres megoldást vásárolnak tőlünk akkor nyilván nem tudjuk pontosan megszabni a paramétereket, ezért az ügyfélre bízható a méretezés. Ha nem szeretne vele foglalkozni, akkor meg ott a hardveres megoldás :)

Bódis Ákos, NETASQ

És a fp vírúsos levelekkel mi történik? Ők így jártak?

Klasszikus felhasználói fiókoknál megfelelő lehet egy after-queue szűrő, ahol be tudod vágni a SPAM mappába a levelet, de pl. egy levelezőlistánál csak lenyelni tudod (a moderálásra küldés nem játszik, mert spamforrássá válunk) ebben az esetben a leveleket. Itt elkerülhetetlen a before-queue szűrő használata.

És a fp vírúsos levelekkel mi történik? Ők így jártak?

elso korben igen, ill. a virusos leveleket karantenba lehet, amit csak a rendszergazdak latnak, es esetleg ok el tudjak onnan ereszteni a levelet. Btw. a te praxisodban mennyire jellemzoek az antivirus fp-hibak?

egy levelezőlistánál csak lenyelni tudod (a moderálásra küldés nem játszik, mert spamforrássá válunk)

Miert? Ha a moderator megnezi, es spam, akkor siman torli vagy eleve az o spam mappajaba kerul...

Itt elkerülhetetlen a before-queue szűrő használata.

Na es spam fp hibanal igy jartak? :-)

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

elso korben igen, ill. a virusos leveleket karantenba lehet, amit csak a rendszergazdak latnak, es esetleg ok el tudjak onnan ereszteni a levelet. Btw. a te praxisodban mennyire jellemzoek az antivirus fp-hibak?

Ez jó módszer, tetszik. Nem találkoztam vele soha, nem jelezte senki, hogy lett volna ebből gond.

Miert? Ha a moderator megnezi, es spam, akkor siman torli vagy eleve az o spam mappajaba kerul...

A moderátor email címét nem mi hosztoljuk. Tapasztalat, hogy rohadtul irritálja őket, főleg ha napi 100 felett van a spamek száma.:)

miért Na es spam fp hibanal igy jartak? :-)

Kapnak a hibakód után egy szép linket, hogy hol tudják jelezni a problémát, és mi megnézzük, hogy miért fogta meg a szűrő és folyamatosan javítjuk. Heti egy bejelentés jön napi 40k levlistákra jövő levél mellett.

Többféle iskolát lehet követni egy spamszűrés megalkotásánál, én mindig azt az elvet vallom, hogy levelet soha nem nyelünk le, mert az a szolgáltatást megbízhatatlanná teszi a felhasználók szemszögéből.

En a spameket mindig lenyeletem, az mar policy fuggo, hogy elpakolom-e usereknek spam folderba, vagy sem (az elobbi preferalt). Ugyanis a botnetekre sima smtp szerver is fel lehet rakva, ami standard SMTP hiba eseten megprobalhat ujra kezbesiteni, a lenyeles viszont az eselyt sem adja meg.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ugyanis a botnetekre sima smtp szerver is fel lehet rakva, ami standard SMTP hiba eseten megprobalhat ujra kezbesiteni, a lenyeles viszont az eselyt sem adja meg.

Ezt nem ertem: a levelet igy is, ugy is atvetted, nem? Vagy az smtp session-ben 250-et mondasz, de kozben valojaban eldobod? Mert az azert kisse bator lenne...

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz

En is tobbszintu szuresben gondolkodok. Elso korben van egy csomo policy, amit a szabvanykoveto SMTP szerverek siman tudnak venni, mindenki mas elbukik rajta. Ilyen az ertelmes HELO, a par masodperces banner elotti varakozas, a postgrey. Ha ezeket az akadalyokat sikeresen vette a level, es ertelmes cimre probal meg kezbesulni (van ilyen az adatbazisban), akkor a level atvetelre kerul. Innentol mar a mogottes rendszer felhasznalasi modja hatarozza meg, mi tortenjen a levellel. Altalaban nem szoktam /dev/null -ba kezbesiteni, kiveve ha kimondottan blackhole-t epitek, a legtobb esetben idoszakonkent automatikusan urulo spam boxba kerul a level, vagy spam mappaba kerul letetelre. De ha kimondottan az az igeny, hogy eltuntessunk minden spamet, akkor akar oda is lehet rakni a levelet.

Blackhole eseten viszont minden levelet befogadok, es lekezbesitek egy mbox -ba, ami a /dev/null utvonalon talalhato. Ez kimondottan a fake mx-ek celjara kialakitott dolog.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Kapnak a hibakód után egy szép linket, hogy hol tudják jelezni a problémát, és mi megnézzük, hogy miért fogta meg a szűrő és folyamatosan javítjuk. Heti egy bejelentés jön napi 40k levlistákra jövő levél mellett.

Na es azt hogy veszed eszre, hogy egy automata level (pl. valamilyen visszaigazolas) nem jott meg? Mert az nyilvan aligha fog barmit is kezdeni egy 55x koddal...

levelet soha nem nyelünk le, mert az a szolgáltatást megbízhatatlanná teszi a felhasználók szemszögéből.

egyetertek, azonban a virusos levelek kivetelevel en sem teszek ilyet. Az meg nalatok sem okozna problemat...

A sorkötelezettség visszaállítása, avagy az (n+1). nímandot koptatja a fidesz