Miszter X és a fejléc tűzfal

Egyszer már piszkálgattam a receive konnektorokat, csakhogy ezek olyanok, hogy nem lehet sokáig piszkálatlanul hagyni őket.

De most egy kicsit más perspektívából szeretnék foglalkozni velük, sőt, nem is csak velük. Bemelegítésképpen nézzük meg ezt az ábrát.

From Segédlet

Szép ábra, sokat szoktam nézegetni. (Az eredeti, poszter méretben itt található.) De nem csak szép, hasznos is. (Tipikus háttérkép a desktopra.)
Nos, ha eleget nézegetjük, feltűnhet, hogy van egy elem, mely többször is szerepel rajta. Narancssárga téglalap és az van beleírva, hogy header firewall. Ahhoz képest, hogy mennyiszer szerepel, nem mondhatni, hogy túlzottan benne lenne a köztudatban.

Na, ezen szeretnék most javítani.

Első lépésben vizsgáljuk meg, mi is az a header, amit tűzfalazni kell. Nagy vonalakban az email (és most csak a belső részéről beszélek, a boríték jelen cikkben nem játszik) két részből áll: fejlécből és tartalomból. A fejlécen belül pedig megkülönböztetünk szabványos mezőket és nem szabványos (vagy ronda szóval élve kvázi-szabványos) mezőket. A szabványosakat RFC írja le, a nem szabványosakról nem ír semmit az RFC (azért nem szabványosak), de elterjedt, hogy az X betűvel kezdődő fejlécmezők gyakorlatilag bármiből állhatnak, bármit jelenthetnek. Azaz ezek a mezők gyártóspecifikusak: egy konkrét gyártó smtp szervere érteni fogja, mit akar üzenni neki egy másik, hasonló szerver, a többi smtp szerver meg nem foglalkozik ezekkel a mezőkkel.
A valóságban itt is lezajlott egy evolúció, néhány X-mező annyira elterjedt, hogy ma már a kitalálójától eltérő gyártók is használják.

Mire jók ezek a mezők? Rengeteg mindenre. A feladó smtp szerver belerak egy csomó információt, melyeket utána a többi smtp szerver is fel tud használni. Ide kerülhet bele, hogy a levél mikor lépett be az Exchange birodalomba, milyen autentikációs módszerrel jutott be, milyen transport rule-ok gyötörték meg a levelet, sima levél vagy journaling… és egy csomó egyéb dolog. Akár magunknak is gyárthatunk X-mezőket. (Igaz, ez a cikk még eventsink-kel dolgozik, de ügynökkel sem lehet sokkal bonyolultabb.) X-mezőbe kerül bele az például, hogy a levelet mennyire érezte szpemnek egy korábbi smtp szerver (Spam Confidence Level, SCL), illetve az is, hogy már átment egy vizsgálaton és ne vizsgálják többet.

Hoppá.

Bejelzett a vészcsengő? Egy szpemmer számára mi sem lenne egyszerűbb, mint rögtön az elején belerakni a levelekbe egy X-mezőt, miszerint ezt a levelet már ne vizsgálják, oszt jónapot.

Na, itt lép be a képbe a header firewall. Ez ugyanis azt csinálja, hogy – beállítástól függően – kipucolja akár az Exchange által használt X-mezőket, akár az egyéb fejlécmezőket a levelekből. Így bejövő levél esetében nem hiszünk el semmit a többi smtp szervernek, kimenő levél esetén nem adunk ki olyan információt, mely segíthet feltérképezni a belső rendszerünket.

Ennyit a bevezetésről, jöhet a vadulás.

Hogyan tudjuk aktivizálni a header firewallt? Hát, úgy, hogy letiltjuk. Gyárilag ugyanis általában működik. De nagyon nem mindegy, hogy kifelé megy a levél, vagy befelé jön, illetve a feladó smtp szerver milyen jogosultságokkal bír a konkrét (receive/send) konnektoron. Érzem, hogy ebből nehéz lesz érthetően kijönnöm, inkább írok egy példát. Egy konkrét receive konnektoron engedélyezem az Ms-Exch-Accept-Headers-Organization jogosultságot mondjuk az ExchangeServers jogosultsági csoportnak. Ebben az esetben, ha egy levél ezen a receive konnektoron keresztül jött be és a sessiont kezdeményező akárki tagja az ExchangeServers jogosultsági csoportnak, akkor a header firewall kussol, legalábbis az organizáció szintű X-mezőkkel kapcsolatban. (Az Exchange X-mezőknek két nagy csoportja van, az organizáció szintűek és az erdő szintűek. Az előző jogosultságnak az erdő szintű X-mezőkre vonatkozó párja az Ms-Exch-Accept-Headers-Forest jogosultság.) Ha a sessiont kezdeményező nem tagja az ExchangeServers permission groupnak, azaz tiltva van számára az a bizonyos accept-headers jogosultság, és a levél ezen a receive konnektoron keresztül jön be, akkor a header firewall már ugrik és gyapálja is ki az organizáció szintű X-mezőket. Értelemszerűen a send konnektorokkal is hasonlóan tudunk elbánni.

Szóval, jogosultság és jogosultsági csoportok. Emlékszünk?

From Segédlet

Látható, hogy gyárilag létezik néhány előre definiált jogosultsági csoport (permission group). Hogy még durvább legyen a helyzet, létezik néhány előre definiált receive konnektor tipus is.

From Segédlet

Gondolom, senkit nem lep meg, hogy mindegyikhez – tehát jogosultsági csoporthoz is és konnektortipushoz is – eleve be van állítva, hogy működjön a header firewall, vagy sem.

Na, ezt nem kis munka lesz nyomon követni.
Szerencsére annyira nagy sem.

Mind az organizáció, mind az erdő szintű X-mezőket illetően a receive konnektoroknál csak az internal tipusnál és csak az ExchangeServers jogosultsági csoportnál nem működik a header firewall, minden más esetben igen.
Send konnektor esetén némileg bonyolult a helyzet, ott gyárilag nem jogosultsági csoport van hozzárendelve a konnektorhoz, hanem security group. Nagy általánosságban elmondható, hogy ha internal tipusú konnektort gyártottunk, akkor az Exchange szervereket tartalmazó csoportoknál nem működik a header firewall, minden más esetben igen.

Jogos lehet a kérdés, hogy bele tudunk-e ebbe piszkálni? Nos, egy irányba igen. Ha nagyon megerőszakoljuk a rendszert, akkor be tudjuk állítani, hogy az Exchange szerverekre is vonatkozzon a tűzfal.

Azaz összességében elmondható, hogy az Exchange 2010 elég kegyetlenül bánik a saját X-mezőivel: se ki nem engedi, se be nem engedi azokat, de még bent is csak az ExchangeServers jogosultsági csoport élvez mentességet. És ezek közül sem mindegyik. Organizáció, illetve erdő szintű X-mező eleve csak a 2007-es verziótól felfelé létezik, azaz ha korábbi verziójú szerverről jön levél, akkor dolgozik a header firewall (mert vagy nincs benne ilyen X-mező, ha meg van, akkor biztosan sunyi módon került bele), illetve amennyiben korábbi verziójú Exchange szerverre megy a levél, akkor meg azért lép akcióba a header firewall, mert tök felesleges lenne az X-mezőket benne hagyni, a szerver úgysem értené.

Megjegyzem, a levélküldésbe nem csak konnektorokon keresztül kerülhetnek be a levelek. Tessék csak megnézni, a narancssárga téglalapok ott vannak minden kilométerkőnél.

  • Pickup könyvtár: Ide lehet manuálisan leveleket behajigálni. A header firewall működik.
  • Replay könyvtár: Ide kerülnek azok a levelek, melyek egyszer már bent voltak a queue-ban, csak éppen valamiért kikerültek onnan. Ha ez a queue Exchange2010-es volt (az X-Createdby X-mező értéke MSExchange14), akkor a header firewall békén hagyja a levelet, ha nem, akkor rávetődik.
  • Drop könyvtár: A külsős alkalmazások könyvtára, a foreign konnektorok révén ezen keresztül tudnak leveleket küldeni, fogadni. A header firewall aktív.
  • Store driver: A kapcsolat a mailbox adatbázis és az smtp motor között. A kifelé menő levelek esetében a header firewall kivágja az illetékes X-mezőket, a befelé jövő levelek esetében válogat: bizonyos X-mezők repülnek, mások maradhatnak. (Oké, pongyola voltam. Általánosságban elmondható, hogy a szpemekkel kapcsolatos X-mezők maradnak, a többiek nem. Az ugye tiszta, hogy ezeket az infókat csak a mi smtp szerverünk rakhatta bele a levélbe, mert a kintről jövő levelekből az Edge/Hub már korábban kivágta az ilyesmit, már ha léteztek egyáltalán.)
  • Delivery Status Notfication, DSN: A header firewall mindig kigyapálja az X-mezőket a DSN-be ágyazott eredeti levelekből.

Jó. A trükkös szpemekkel elbántunk. (Az SCL is X-mező, Exchange 2010-ben egész pontosan így hivják: X-MS-Exchange-Organization-SCL.) Az X-mezők kaptak egy tockost meg egy kokit, nem mennek kifelé, nem jönnek befelé. De jó-e az nekem, ha pl. egy alkalmazásszerverem az Exchange szerveren keresztül küld ki levelet, és ez az útvonal benne marad a levélben? Nevekkel együtt? Ki tudnám ezt gyapálni?
Ki.
A logika teljesen hasonló az organizáció illetve erdő szintű X-mezőkhöz. Ha egy konnektoron engedélyezve van egy identitás számára a Ms-Exch-Accept-Headers-Routing jogosultság, akkor a routing információk benne maradnak a levél fejlécében. Ha nem, akkor a header firewall kitörli azokat.
Nézzük az alapértelmezéseket. Receive konnektoron a a következő jogosultsági csoportok számára helyből engedélyezve van a jog (azaz tiltva a header firewall): Anonymous, ExchangeUsers, ExchangeServers, ExchangeLegacyServers, Partner. Valamennyi név a naptárban. (Vessünk egy pillantást a fenti ábrára: csak ezek vannak.) Hogy lehet akkor aktivizálni a header firewallt, hogy mégiscsak rúgja ki a routing információkat? Úgy, hogy Custom konnektort készítünk és nem adunk meg semmilyen jogosultsági csoportot. Vagy meglévő konnektorból töröljük ki az összeset. Vagy az Add-ADPermission paranccsal vesszük el egy-egy csoporttól a konkrét konnektoron a jogot.
A Send konnektorokok esetében nagyjából hasonló a helyzet, alapértelmezésben a routing információk maradnak, de ha akarjuk, akkor a jogosultság tiltásával a header firewall kiszedi azokat. Érdemes megemlíteni itt is az alternatív útvonalakat: a Replay, Drop könyvtárak, illetve az ügynökökön keresztül érkező levelek esetében a header firewall nem bántja a routing információkat. A Pickup könyvtár esetében mindig törlődnek a routing információk. Szintúgy a DSN-be ágyazott levelek esetében. A Store driver a kifelé menő levelek esetében töröl, a befelé jövők esetében nem. (Ez egy kicsit félrevezető lehet. A Store driver a mailbox és a hub transport szerepkör között dolgozik. Azaz ha jön egy levél a mailbox adatbázisból, melyet a kliens mondjuk MAPI-n keresztül rakott össze, annak a routing információit – ha vannak egyáltalán – nem engedjük ki. De a következő lépésben a hub transport szerver belerakja a saját routing információját és az már marad.)

A sok elmélet után jöjjön most egy konkrét példa. Van egy Oracle szerverünk, meg egy csomó alkalmazásunk. A szerveren fut egy smtp szerver is, az alkalmazások azon keresztül leveleznek, illetve a cégből kifelé egy Exchange szerveren keresztül. Hogyan tudjuk megoldani, hogy az internetre ne kerüljenek ki az Oracle szerverre vonatkozó routing információk? Úgy, hogy a szerver kap egy egyedi receive konnektort (csak az ő IP címe szerepel benne), a jogosultsági csoportok közül meg egyet sem adunk meg. Ekkor a konnektoron nem lesz Ms-Exch-Accept-Headers-Routing jogosultság, amit a header firewall úgy értelmez, hogy tiltva van – azaz törli az addigi routing információkat.
Aha. Viszont rögtön belefutunk abba, hogy ez egy open relay tipusú konnektor (igaz, csak egy IP címre), amelyhez Externally Secured autentikáció kell. Ez viszont kiköveteli az ExchangeServers jogosultsági csoportot. Megoldás: az Add-ADPermission paranccsal csak ezen a konnektoron deny-re állítjuk az ExchangeServers permission group jogosultságát az Ms-Exch-Accept-Headers-Routing elemi jognál.

Ezzel tulajdonképpen be is fejeződhetne a cikk. Beszéltünk 3 jogosultságról (Ms-Exch-Accept-Headers-Organization, Ms-Exch-Accept-Headers-Forest, Ms-Exch-Accept-Headers-Routing), arról, hogy mi történik, ha ezeket a jogosultságokat elvesszük, illetve arról, hogy mik a gyári beállítások. Úgy gondolom, hogy hasznos lehet a másik oldalról is ránézni az összerendelésekre: milyen jogosultságokkal rendelkeznek beépítetten az egyes jogosultsági csoportok?

Anonymous (Anonymous user account)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
– Ms-Exch-Accept-Headers-Routing

ExchangeUsers (Authenticated user accounts)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-Accept-Headers-Routing

ExchangeServers (Hub Transport servers, Edge Transport servers, Exchange Servers (Hub Transport server only), Externally Secured servers)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Accept-Authoritative-Domain-Sender
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-SMTP-Accept-Authentication-Flag
– Ms-Exch-Bypass-Message-Size-Limit
– Ms-Exch-Accept-Headers-Routing
– Ms-Exch-Accept-Exch50
– Ms-Exch-Accept-Headers-Organization (Kivéve az Externally Secured servers.)
– Ms-Exch-Accept-Headers-Forest (Kivéve az Externally Secured servers.)

ExchangeLegacyServers (Exchange Legacy Interop security group)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Accept-Authoritative-Domain-Sender
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-SMTP-Accept-Authentication-Flag
– Ms-Exch-Bypass-Message-Size-Limit
– Ms-Exch-Accept-Headers-Routing
– Ms-Exch-Accept-Exch50

Partner (Partner Server account)
– Ms-Exch-SMTP-Submit
– Ms-Exch-Accept-Headers-Routing

És legvégül két link a témában jobban elmélyülni szándékozóknak:

2 thoughts on “Miszter X és a fejléc tűzfal

  1. De ezek ugye csak az Xch specifikus X headerekre vonatkoznak? Vagyis, ha nekem van pl. egy OTRS-em a rendszerben, ami X headerekkel koveti nyomon a levelet, akkor az X-OTRS cimu mezok nem fognak megszunni?

Leave a Reply

Your email address will not be published. Required fields are marked *