Hogyan ellenőrizhető, hogy a szerver Spam-e
a vállalatoknak, egyetemeknek és szolgáltatóknak (például: ISP-k, marketing e-mail szolgáltatók, alkalmazásszolgáltatók, SaaS, tárhelyszolgáltatók) aggódniuk kell, ha rendszerük spam-et küld. Van egy még rosszabb probléma; a Szolgáltató e-mail platformját kiberbűnözők szivároghatták be, lehetővé téve számukra, hogy kihasználják a platformot spam küldésére, adathalászatra vagy a felhasználói kommunikáció megsértésére. Az ilyen jogsértések megkönnyítik a számítógépes bűnözők számára, hogy oldalirányban mozogjanak a hálózaton és a hálózat más részein és az üzleti műveletekben.
ez a cikk bemutatja a legjobb biztonsági gyakorlatokat annak ellenőrzésére, hogy a szerver spamet küld-e. Szóval itt vagyunk.
először ellenőrizze a levelezőkiszolgáló naplóit, majd nézze meg a blokklistákat másodszor
figyelje a kimenő levelezési naplóit
a levéladminisztrátor számára spamet küldő kiszolgálók két legjelentősebb kiberbiztonsági mutatója a megnövekedett visszapattanás vagy az NDR (nem Kézbesítési jelentések) vagy a kiszolgálók kimenő e-mail sorainak meghosszabbítása. Mindkettő akkor fordul elő, ha az IP-címek vagy a tartományok blokkolva vannak egy sérült kiszolgálóhoz, a felhasználó gépéhez vagy egy webes fiókhoz. Ezért rendszeresen figyelnie kell az e-mail szerver Linux var naplóját vagy az Exchange szerver Rendszerkezelőjét, ha meg akarja mondani, hogy az exchange szerver spam-et küld-e, amelyet a blokkolólisták azonosítottak.
a dolgok, amelyeket keresned kell, a következők:
- az NDR-k növekvő arányát mutató naplókat általában az okozza, hogy egy vagy több blokklista blokkolja az IP-címet vagy a domaint.
- a kézbesítési halasztások miatt növekvő kimenő e-mail sorok hasonlóak a fenti feltételhez. Ezenkívül figyelmeztetést kaphat a levelezőszerverről. A Microsoft Exchange például “SMTP-kiszolgáló Távoli várólista hosszára vonatkozó figyelmeztetést küld.”
mindkettő egy jelentősebb probléma mutatója, valamint annak ellenőrzése, hogy a levelezőszerver spamet küld-e. A legjobb gyakorlat az, hogy azonnal szünetelteti a kimenő levelek áramlását, hogy megtalálja és megoldja a problémát, így más levelezőszerverek nem utasítják el az e-mailt, és hagyják, hogy a kézbesítési és beérkező levelek aránya normalizálódjon.
ellenőrizze a spam blokklistákat
ezután ellenőriznie kell a blokklistákat.
- ellenőrizze az MX eszköztárat vagy a Multi RBL-t, hogy egy másik blokklista blokkolja-e Önt. Tegyük fel, hogy kiderül, hogy csak az UCE Protect-re vagy néhány hobbista blokklistára korlátozódik, blokkolva a tartományt. Ebben az esetben a probléma valószínűleg “hírnév-alapú”, és egy olyan probléma, amely idővel felépült, nem pedig konfigurációs probléma (nyílt továbbítás), feltört e-mail szerver vagy feltört e-mail fiókok.
de ne feledje, hogy nem minden blokklista működik ugyanúgy. Ha nem látja, hogy az Abusix vagy a Spamhaus blokkolja a forgalmat, akkor lehet, hogy egyike azon kevés blokklistáknak, mint például az UCE protect és a SORBS, amelyek büntetően blokkolnak egy hálózati tartományt vagy akár egy teljes ASN-t egy tárhelyszolgáltató vagy ASN számára. Ezt teszik, függetlenül attól, hogy ki más használhatja az IP-címeket ugyanazon a környéken. Ha a két lista egyike (UCE és SORBS) blokkolja, és nem más blokklisták, akkor Önnek vagy a tárhelyszolgáltatónak súlyos hálózati visszaélési problémája van.
hajtsa végre a következő levelezési kiberbiztonsági bevált gyakorlatokat
míg a fenti lépések a leggyorsabb módja annak, hogy visszatérjenek a pályára, a következők szilárd kiberbiztonsági gyakorlatok, hatékonyan kell védenie a felhasználó e-mailjét és a levelezőszervert, valamint csökkentenie kell a spam és az adathalász tevékenységet. Ha e-mailt nyújt szolgáltatásként (például internetszolgáltató, tárhelyszolgáltató, üzleti e-mail szolgáltató, CRM és e-mail marketing szolgáltató), és ma nem teszi meg ezeket a lépéseket, veszélybe sodorja vállalkozását.
blokkolja a spam-et, mielőtt elhagyja a hálózatot, és jelszó visszaállítja a blokkolt felhasználói fiókokat
blokkolja a felhasználók által küldött e-maileket, hasonlóan ahhoz, amit a bejövő e-mailekkel tenne, de más szabályokkal. Vessen egy pillantást az Inbound and outbound protection cikkre – mi a különbség és hogyan lehet helyes.
komolyan, ne csak rossz dolgokat küldj. Fáj a szállítás és a felhasználók által nem használja a rendszert, hogy figyelmeztesse őket, és védi őket. A veszélyeztetett számítógépet vagy feltört fiókot használó felhasználók tudni akarják.
a rossz színészek szemetet küldenek, tudniuk kell. Ha továbbra is észreveszi őket, akkor óvadékot kapnak, és egy másik szolgáltatóhoz mennek, mielőtt a cuccuk kijön, ami nem érdekel annyira, mint te.
vállalkozásként, oktatási intézményként, tárhelyszolgáltatóként vagy INTERNETSZOLGÁLTATÓKÉNT, ha kimenő spamszűrést ad hozzá, akkor képes lesz:
- blokkolja a levelezőszerverrel való kapcsolatokat a fertőzött gépeket használó távoli felhasználóktól.
- a szűrőkben blokkolja az üzeneteket az azonosított spam-tartományokkal vagy az adathalászhoz általában társított nulla hírnevű tartományokkal, valamint a rövid vagy online tárolási URL-ekkel (ne blokkolja a tartományokat, csak az URL-eket), amelyek spamhez társultak.
azzal mentheti meg magát a blokkolástól, hogy nem engedi, hogy ezek a veszélyeztetett rendszerek és a spam e-mailekhez kapcsolódó üzenetek továbbadódjanak a levelezőszerveren.
minden blokkolt felhasználó esetén azonnal végezze el a jelszó visszaállítását, és értesítse a felhasználót, hogy miért blokkolta a levelezését. Ha problémát okozó IP-címről van szó, tájékoztassa a felhasználót arról, hogy a csatlakozó IP (útválasztó vagy gép) sérült. Ha ez egy üzenet, amelyet a tartalom miatt blokkolnak, mondja el nekik, hogy ezért állította vissza a jelszót, csak arra az esetre, ha a fiókjuk veszélybe kerülne. Őszintén, meg fogják köszönni, hogy vigyáztak a biztonságukra.
végül a felhasználók és a rossz szereplők, akik ismételt jelszó-visszaállítást kapnak, egyszerűen láthatók a visszaállítási naplókban. Ez segít meglátni a problémákat, és kezelni őket az Ön által választott irányelvnek megfelelően.
kezelje a postmaster-címet, és állítsa vissza az NDR-ként visszaadott felhasználói fiókokat jelszóval.
keresse meg a címére visszaküldött hamis címzettek NDR-jét. Ez azt mutatja, aljas használata a domain a hálózaton. További információkért lásd az RFC5321 és a Microsoft Exchange Server támogatási cikkét.
ha egy üzenet visszatért a postamester címére, mondja el a felhasználónak, hogy miért állította vissza a jelszót, arra az esetre, ha a fiókja veszélybe kerülne. Őszintén, meg fogják köszönni, hogy vigyáztak a biztonságukra.
végül a felhasználók és a rossz szereplők, akik ismételt jelszó-visszaállítást kapnak, egyszerűen láthatók a visszaállítási naplókban. Ez segít meglátni a problémákat, és kezelni őket az Ön által választott irányelvnek megfelelően.
ha Ön tárhelyszolgáltató, internetszolgáltató vagy egyetem, az Abusix AbuseHQ képes kezelni ezeket a jelentéseket az Ön számára.
ellenőrizze a levelezőszerver hitelességét, és tegyen egy eltávolítási kérelmet a nem hiteles MTA-t tároló hálózathoz
győződjön meg arról, hogy nem blokkolja a domainjét, mert valaki más hamisítja Önt, vagy nincs egy ember-in-the-middle támadás. Az SPF nélküli domain, amely nem írja alá a kimenő e-mailt a DKIM-mel, a DMARC DNS TXT rekordok nem teszik lehetővé a számítógépes bűnözők számára, hogy hamisítsák az Ön személyazonosságát, és blokkolják a domaint.
a CXX vezetői vagy munkavállalói e-mail címeinek meghamisítása, valamint egy ember a közepén támadás lehetővé teszi a számítógépes bűnözők számára, hogy üzeneteket küldjenek az alkalmazottaknak vagy módosítsák az ügyfelek üzeneteit. Mindkettő nagyon veszélyes.
nézze meg az SPF, DKIM és DMARC DNS TXT rekordokat, hogy ellenőrizze és ellenőrizze, hogy a rekordok pontosak-e.
a DMARC rekordhoz adja hozzá a következő címkéket a jelentések lekéréséhez:
- “rua = mailto::”
ez a címke megmondja a vevőnek, hogy hol küldjön napi jelentéseket a hibákról. Ha Ön tárhelyszolgáltató, internetszolgáltató vagy egyetem, és ez a cím az Ön címe vagy a cím aliasa, - “fo:”
ez a címke tudatja a postaláda-szolgáltatókkal, hogy sikertelen üzenetmintákat szeretne. - “1:”
ez egy alapvető lehetőség az fo alatt: mivel ez azt mondja a vevőnek, hogy küldjön egy DMARC jelentést, ha bármilyen hitelesítési mechanizmus (SPF vagy DKIM) sikertelen “pas.”.
regisztráció a “Feedback Loops” (FBLs) és az akció felhasználók számára, akiknek magas a panasz/elküldött e-mailek aránya
néhányan úgy gondolják, hogy a feedback loops olyan dolog, amelyre feliratkozik, ha marketing e-maileket küld. Nem, uram. Értékesek bárki számára, aki e-mail szervert futtat, vagy Campust biztosít, tárhely, internetkapcsolati szolgáltatások.
ha Ön nagyvállalat, a leiratkozások kezeléséhez levelezőrendszert, CRM-et vagy e-mail szolgáltatót kell használnia. Ha feliratkozik a vállalati levelezőszerverre egy FBI szolgáltatásra, megtalálja a gazember osztályt vagy az alkalmazottak spamjét, amely a problémát okozza. Azt is látni fogja, hogy a sérült rendszerekkel vagy fiókokkal rendelkező alkalmazottak spamet küldenek, így jelszó-visszaállítást végezhet a fiókjukon, és értesítheti őket a problémáról.
összefoglalva
ha problémája van a kézbesítéssel, kövesse az első két lépést: figyelje a kimenő levelek naplóit, és ellenőrizze a spam blokklistákat.
hosszabb távú, szilárd kiberbiztonsági technikák végrehajtása:
- blokkolja a spam-et, mielőtt elhagyja a hálózatot, és figyelje a kimenő szűrési hibákat.
- a postamester címének kezelése.
- ellenőrizze az üzenetek hitelességét, és figyelje a hibákat a DMARC segítségével.
- végül regisztráljon a “Feedback Loops” – ra (Fbls), és figyelje a felhasználó panaszmennyiségét.
kövesse ezeket a kiberbiztonsági tippeket, és a felhasználók köszönetet mondanak Önnek a biztonságos levelezési művelet futtatásáért.
ha megosztott üzenetküldő szolgáltatást használ INTERNETSZOLGÁLTATÓKÉNT, Tárhelyszolgáltatóként, SaaS – ként vagy közösségi hálózati szolgáltatóként, beszéljen velünk az abusix Mail Intelligence és az AbuseHQ blokklistáinkról-az első SaaS visszaéléskezelő platformról. A tervezés, hogy a bejövő, kimenő mail szerver, és a hálózati visszaélés sokkal kezelhetőbb.