Szerteszana²

grin agymenései

[geek admin only] Banki spamek + spamassassin

2020-10-27 21:41 írta grin

Ez most csak az adminoknak szól, akik spamassassint használnak.

Nagy mennyiségű magyar bankos phishing indult mostanában. Közösségi jócselekedetként megosztom ez a configot. Az /etc/spamassassin/hubank.cf file-ba lehet pl. beírni.

(UPDATED: 2020/11/04)

#$Id: rule_hubank_hu.cf,v 6413efa4969d 2020/11/04 12:52:50 grin $

## hungarian fake bank email

if (version >= 3.004002)
 ifplugin Mail::SpamAssassin::Plugin::WLBLEval

enlist_addrlist (HUBANK) *@mkb.hu *@raiffeisen.hu
enlist_addrlist (HUBANK) *@otpbank.hu *@otp.hu
enlist_addrlist (HUBANK) *@budapestbank.hu
enlist_addrlist (HUBANK) *@cib.hu
enlist_addrlist (HUBANK) *@erstebank.hu
enlist_addrlist (HUBANK) *@kh.hu
enlist_addrlist (HUBANK) *@unicreditbank.hu
reuse  _FROM_ADDRLIST_HUBANKS
reuse  FROM_HUBANK_FAKE_RP

header          __FROM_ADDRLIST_HUBANKS  eval:check_from_in_list('HUBANK')
describe        __FROM_ADDRLIST_HUBANKS         Felado egy magyar bank

header          __EFROM_FROM_COUNTRY_HU  X-Envelope-from =~ /\@.+?\.hu>$/i
describe        __EFROM_FROM_COUNTRY_HU  X-Envelope-from address from .HU
score           __EFROM_FROM_COUNTRY_HU  -0.1

header          FROM_FROM_COUNTRY_HU    ALL =~ /^From +\S+\@\S+?\.hu\s/
describe        FROM_FROM_COUNTRY_HU    From " " hu
score           FROM_FROM_COUNTRY_HU    -0.01

## ehhez szükséges a  loadplugin Mail::SpamAssassin::Plugin::RelayCountry
## az init.pre file-ban.
header          RELAYCOUNTRY_BAD        X-Relay-Countries =~ /CN|KR|RU/
describe        RELAYCOUNTRY_BAD        Relayed through China/Korea/Russia at some point
score           RELAYCOUNTRY_BAD        2.0

header          RELAYCOUNTRY_HU         X-Relay-Countries =~ /^HU/
describe        RELAYCOUNTRY_HU         First untrusted relay is in Hungary
score           RELAYCOUNTRY_HU         -1.0

meta            FROM_HUBANK_FAKE_RP0    __FROM_ADDRLIST_HUBANKS && !__ENV_AND_HDR_FROM_MATCH
describe        FROM_HUBANK_FAKE_RP0    Hamisitott magyar bank email, eltero sender/from
score           FROM_HUBANK_FAKE_RP0    2.57

meta            FROM_HUBANK_FAKE_RP1    __FROM_ADDRLIST_HUBANKS && !__EFROM_FROM_COUNTRY_HU
describe        FROM_HUBANK_FAKE_RP1     Hamisitott magyar bank email (nem .hu)
score           FROM_HUBANK_FAKE_RP1     4.66

meta            FROM_HUBANK_FAKE_RP2    __FROM_ADDRLIST_HUBANKS && !RELAYCOUNTRY_HU
describe        FROM_HUBANK_FAKE_RP2     Hamisitott magyar bank email (nem magyar relay)
score           FROM_HUBANK_FAKE_RP2     6.66

meta            FROM_HUBANK_FAKE_RP3    __FROM_ADDRLIST_HUBANKS && RELAYCOUNTRY_BAD
describe        FROM_HUBANK_FAKE_RP3     Hamisitott magyar bank email (spamorszag relay)
score           FROM_HUBANK_FAKE_RP3     6.66

 endif
endif

Jószerencsét!

Pártállami Határzár, 2020

2020-09-01 15:45 írta grin
A #határzár-ról egy hetvenes évekbeli viccet mesélnék el.

Anyuka a fiához:

– Jenőke, ma a kiságyban kellene aludnod, mert Hans bácsiék jönnek látogatóba NSZK-ból.

– Igen anya.

Másnap anyuka megint keresi a gyereket:

– Jenőke, kiteszünk neked egy matracot, mert Heike néniék jönnek Hollandiából, és kellene a kiságy.

A gyerek morogva elmegy. Nem telik el egy nap, anyuka megint jelentkezik:

– Jenőke... izé, ma a kádban alszol, mert Steve és Elizabeth jönnek az USA-ból vendégségbe... – mire a gyerek dühösen felnéz az égre:

– Ez vasfüggöny?! EZ EGY SZAR!

ps: birka nép

Szovjet-típusú válaszok

2020-05-01 14:31 írta grin

Egy vicc a hatvanas-hetvenes évekből

…ami ismét aktuális.

Hajótörést szenved és egy lakatlan szigeten köt ki az angol, a német és a szovjet férfi.

A sziget amúgy kellemes, szép, zöld, nem is túl kicsi; nem lenne különösebb bajuk, víz is van, de a szigeten csak bogyókat, növényeket találnak ennivalóként. Telik-múlik az idő, és pár hét múlva már mindenki feszült, ideges.

Az egyik portyázásuk során hogy-hogy nem, találnak egy nősténykecskét. Tanakodnak, hogy megegyék-e, de a német azt mondja, hogy lássák be: az, hogy nincs a szigeten nő igencsak nagy probléma, és a kecskét esetleg lehetne ilyen célokra is használni. Nem túl sok ellenvetés hangzik el, így megegyeznek, hogy a kecskét nem eszik meg, hanem az őszinte szerelem eszköze lesz. Abban is megegyeznek, hogy minden nap egyikük hálhat vele, addig a többiek őket békén hagyják.

Na, az első nap elmegy a német. Egész nap és egész éjjel elvan, másnap kérdezik a többiek, hogy milyen volt?

A német lelkendezik. Olyan jó volt, olyan jó hozzábújni, olyan kedves, szelíd teremtés… Mindenki ámulva hallgatja. Másnap az angol megy el. Utána ő is hihetetlenül lelkesen mesél.

A harmadik nap a szovjeté, ő is elvonul a kecskével. Másnap reggel nézik, hát a szovjet ott horkol, a kecske meg sehol. Felrázzák:

– Hol van a kecske, Vologya?!

– Miféle kecske?

– Hogy-hogy miféle? Hát ami itt a szigeten volt. Hol van?

– Mi hol van?

– Vologya! Emlékszel, hajótörést szenvedtünk, ugye?

– Igen, így volt.

– Utána bogyókon éltünk és nem volt szex!

– Bizony, bizony!

– És találtunk egy nőstény kecskét és megegyeztünk, hogy nem esszük meg!

– Igen, pontosan így történt.

– Hol a kecske?!

– Nem tudom. Milyen kecske?

– Nézd, Vologya. Első nap én mentem el, reggel visszajöttem a kecskével! Így volt?

– Igen, emlékszem, így volt.

– Másnap az angol ment el vele, és reggel visszajött a kecskével! Ugye?

– Visszajöttek, pontosan.

– Tegnap pedig te mentél el a kecskével! Nem?

– De, én mentem el vele.

– És most reggel nincs itt! Vologya, te megetted a kecskét?!

Miféle kecskét?

Javasolt jelszókezelési irányelvek

2019-09-03 13:25 írta grin

Arról már írtam múltkor hogy milyen a jó jelszó, amit alkalmazz. Most arról szeretnék írni, ami ott csak lábjegyzetben szerepelt, hogy milyen jelszót követeljen meg egy szolgáltatás vagy server a felhasználóktól.

A legtöbb helyen még mindig 2003-at ír a naptár: ez volt az az év, amikor szegény Bill Burr elkészítette a ma már közismert „krixkrax jelszó, rendszeresen megváltoztatva” elvet, amiért 2017-ben bocsánatot kért a világtól, és ami olyan dolgokat mondott, mint például

  • a jelszó tartalmazzon legalább egy kisbetűt, egy nagybetűt, egy számot, egy írásjelet, egy kínai karaktert, egy hieroglifát, egy ősi magyar rovásjelet és egy láthatatlan karaktert,
  • a jelszót kötelező legyen másfél naponta megváltoztatni, és ellenőrizzük, hogy az elmúlt 150 jelszó nem ismétlődik,
  • a jelszó minimum 6, maximum 15 karakter lehet,
  • a jelszó ne tartalmazzon egymás mellett két számot, két betűt, két hieroglifát, stb…
  • alkalmazzunk jelszóemlékeztetőt, pl. „Mi a jó édes anyádnak… a neve?”

…mindezzel hatalmas örömöket okozva az emberek millióinak. A probléma nyilván az volt – mint az menet közben nyilvánvalóvá is vált –, hogy ezeket a jelszavakat az emberek nehezen jegyzik meg és könnyen elfelejtik, viszont a számítógépek könnyen feltörik. Cserébe viszont az emberek felírják azt egy PostIt™re és kiragasztják a monitorra. Vagyis adtunk a csillagnak egy pofont.

NIST Special Publication 800-63B

Az amerikai szabványügy viszont komolyan vette a problémát, és 2017-ben új irányelvet készített, ami szabványban határozza meg a digitális azonosítókkal szemben elvárt követelményeket. Ebben figyelembe vették nem csak azt, hogy mi lenne jó, hanem a múltbéli hibákat és az azokból kialakult káoszt is. Az eredmény egy modern, biztonságos jelszóhasználati ajánlás. Ebből szeretném kiemelni a jó jelszókezelés alapelveit.

A jó jelszókezelés

Az 5. fejezet 5.1.1 pontja szól a jelszavakról, azon belül is az 5.1.1.2 az ajánlott módszerekről. Az ajánlás lényeges részei:

  • a jelszó legalább 8 karakteres, és a rendszer képes legyen legalább 64 karakteres jelmondat kezelésére is; ideális esetben a jelszó hossza nem korlátozott;
  • a megadott jelszó nem kerül csonkításra kódolás vagy tárolás előtt;
  • a jelszó tartalmazhat nyomtatható ASCII (RFC0020) és Szóköz karaktert (az ismétlődő szóközök eltávolítása megengedhető, ha a jelszó hossza nem csökken a minimális alá), és javasolt a Unicode (ISO-10646) karakterek kezelése, normalizálás (NFKC/NFKD) után (minden U kódpont 1 karakterhossznak számít);
  • tilos a „jelszóemlékeztetők” használata („Mi volt a neve a gyerekkori Sahelanthropusodnak?”), illetve bármilyen jelszóra utaló „emlékeztető” mutatása azonosítatlan kérdezőnek;
  • új jelszó megadásakor szűrésre kerül, hogy ne legyen:
    • ismert betörésben vagy jelszópublikálásban érintett jelszó;
    • szótári szó;
    • ismétlődő sorozat („zzzzzz”, „123abc”);
    • kontextushoz kapcsolható szó (név, felhasználói név, szolgáltatás, dátum, vagy ezekből származó részek).
    és amennyiben emiatt kerül a jelszó elutasításra, a rendszer közölje a pontos okát, és kérjen új jelszót.
  • új jelszó megadásakor nyújtsunk segítséget „jelszóerősség” kijelzésével a biztonságos jelszó kiválasztásához, ez különösen fontos, hogy a rendszer segítse az előző pontban visszautasított okokból nem megfelelő jelszó helyett egy jó választását ahelyett, hogy az elutasított jelszó triviális módosításával próbálkozna a személy;
  • a jelszópróbálkozások száma és gyakorisága korlátozott;
  • semmilyen további korlátozás nem vonatkozik a jelszóra (mint amilyen a bizonyos karaktercsoportok használata, vagy bizonyos párok tiltása);
  • nincs jelszónak kötelező, véletlenszerű vagy periodikus változtatása, de automatikusan és azonnal meg kell változtatni bármilyen biztonsági incidens esetén;
  • engedélyezett a jelszó másolása és beszúrása, hogy a jelszavak kezelése jelszókezelővel is történhessen;
  • a felhasználó kérésére a jelszó láthatóvá válhat elküldés előtt, megkönnyíteni a gépelési hibák elkerülését (vagy az utoljára megadott karakter, például mobileszközök esetében);
  • a jelszavak tárolása titkosítási eljárással történjen, méghozzá olyannal, amit kifejezetten jelszavak tárolására fejlesztettek, vagy arra kifejezetten alkalmas;
  • lehetőleg a jelszó kódolás előtt Key derivation függvénnyel kerüljön feldolgozásra (mint amilyen a PBKDF2 [min. 10000 iteráció], a Balloon vagy az Argon2), a tárolás pedig hashed és salted (min. 32 bit) formában történjen.

PS: Az Ön „titok꧁𓁵قᬎজ⠮щडφઊשひಊギആᠪ𐲍ᚫࠇඉᜈஐ༆𠂢꧂” jelszava nem tartalmaz számot és legalább két székely rovásjelet… 😁

Az adatbázisok szerzői jogi védelméről

2019-06-11 11:27 írta grin

Rendszeresen előkerülő kérdés, hogy abban az esetben, amikor valaki fog egy csomó szerzői jog által nem védett adatot (például egy település összes utcájának nevét) és azokból csinál egy listát (ami készülhet kézzel vagy számítógéppel), és ezt a listát nyilvánosságra is hozza, akkor mit lehet ezzel az adatbázissal jogszerűen csinálni.

A Szerzői jogi törvény (1999. évi LXXVI. törvény) vonatkozik erre az esetre, és nézzük, hogy mi ebben a kérdésben az én véleményem. Tegyük hozzá, hogy nem vagyok jogász, semi bíró, sem egyéb szakember, mindössze nagyrészt 20 éve foglalkozom szerzői jogi esetekkel.

Elöljáróban, egy mondatban:

A védelem az adatbázis egészére, vagy jelentős részére vonatkozik, és ott is általában a közvetlen másolásra vagy számítástechnikai automatizmus általi átvételre, és csak akkor, ha az adatbázis tartalmának válogatása kreatív tevékenység eredménye („nem automatizmus”).

Rövid összefoglaló

  • csak akkor esik védelem alá, ha „tartalmának összeválogatása, elrendezése vagy szerkesztése egyéni, eredeti jellegű” (7.§ (1)), vagyis ha az adatbázis tartalmának összeállítása nem kreatív tevékenység (mert például „minden” házszámot, „minden” utcanevet, „minden” természetben előforduló, egyértelmű adatot, stb. tartalmaz) akkor az nem esik védelem alá.
  • csak akkor illeti meg védelem az adatbázis előállítóját, ha az „az adatbázis tartalmának megszerzése, ellenőrzése vagy megjelenítése jelentős ráfordítást igényelt.” (Kérdéses, hogy a közpénz ráfodítása hogyan számít e szempontból, illetve hogy az amúgy is törvény által előírt kötelezettségként előállított adatbázisból publikált rész-adatbázis esetén, ami gyakorlatilag automatikusan és további jelentős ráfordítás nélkül előáll, ezt hogyan veszi a T. bíróság figyelembe.)
  • általánosságban az adatbázisok védelme csak az adatbázis egészét vagy jelentős részét érinti (7.§(3), 84/A.§ (1)), beleértve nyilvánosságra hozatalt is (84/A.§(1)(b), 26.§(8))
  • rendszeresen is lehet az adatbázis jelentéktelen részét kimásolni, ha „az nem sérelmes az adatbázis rendes felhasználására és indokolatlanul nem károsítja az adatbázis előállítójának jogos érdekeit.” (Ha egy adatbázist szabadon elérhetően publikálnak, akkor vélelmezhetően nem sérti a további publikáció az előállító érdekeit, és nem sérelmes az egyéb felhasználásokra sem.)
  • jelentéktelen részt akár rendszeresen is fel lehet használni (84/B.§(1))
  • magáncélra az adatbázis jelentős része is használható (84/C.§ (1)), de nem hozható nyilvánosságra.

A szerzői jogi törvény vonatkozó részei

7. § (1) Szerzői jogi védelemben részesül a gyűjtemény, ha tartalmának összeválogatása, elrendezése vagy szerkesztése egyéni, eredeti jellegű (gyűjteményes mű). A védelem a gyűjteményes művet megilleti akkor is, ha annak részei, tartalmi elemei nem részesülnek, illetve nem részesülhetnek szerzői jogi védelemben.
(3) A gyűjteményes mű szerzői jogi védelme nem terjed ki a gyűjteményes mű tartalmi elemeire.

60/A. § (1) E törvény alkalmazásában adatbázis: önálló művek, adatok vagy egyéb tartalmi elemek valamely rendszer vagy módszer szerint elrendezett gyűjteménye, amelynek tartalmi elemeihez – számítástechnikai eszközökkel vagy bármely más módon – egyedileg hozzá lehet férni.

61. § (1) Szerzői jogi védelemben részesül a gyűjteményes műnek (7. §) minősülő adatbázis.

84/A. § (1) Ha a törvény eltérően nem rendelkezik, az adatbázis (60/A. §) előállítójának hozzájárulása szükséges ahhoz, hogy az adatbázis tartalmának egészét vagy jelentős részét
a) másolat készítése útján [18. § (1) bek. b) pont] többszörözzék (a továbbiakban: kimásolás);
b) a nyilvánosság számára hozzáférhetővé tegyék az adatbázis példányainak terjesztésével vagy – a 26. § (8) bekezdésében szabályozott módon – a nyilvánossághoz való közvetítéssel (a továbbiakban: újrahasznosítás).
(3) Az adatbázis előállítójának hozzájárulása nélkül ismételten és rendszeresen nem másolható ki, illetve nem hasznosítható újra az adatbázis tartalmának jelentéktelen része sem, ha ez sérelmes az adatbázis rendes felhasználására, vagy indokolatlanul károsítja az adatbázis előállítójának jogos érdekeit.
(5) Az adatbázis előállítóját akkor illetik meg az (1)–(3) bekezdésben szabályozott jogok, ha az adatbázis tartalmának megszerzése, ellenőrzése vagy megjelenítése jelentős ráfordítást igényelt.

84/B. § (1) Nem szükséges az adatbázis előállítójának hozzájárulása ahhoz, hogy a nyilvánosságra hozott adatbázist jogszerűen felhasználó személy az adatbázis tartalmának jelentéktelen részét – akár ismételten és rendszeresen is – kimásolja, illetve újrahasznosítsa.

84/C. § (1) Magáncélra bárki kimásolhatja az adatbázis tartalmának jelentős részét is, ha az jövedelemszerzés vagy jövedelemfokozás célját közvetve sem szolgálja. E rendelkezés nem vonatkozik a számítástechnikai eszközökkel működtetett adatbázisra. (4)168 A szabad felhasználásnak az (1)–(3a) bekezdésben szabályozott eseteire a 33. §-t megfelelően alkalmazni kell.

Visszajelzés

Ha valaki jogvégzett úgy véli, hogy jól írtam, vagy nem jól írtam, akkor örömmel veszem a visszajelzést.

Szerteszana²

Szerteszana²

grin agymenései