Email címünk elrejtése

Mindennapos dolog, hogy ha valamit le akarunk tölteni, ahhoz először regisztrálnunk kell magunkat. Lehet, hogy te sem adod meg szívesen az email címedet, mert ki tudja, lehet, hogy továbbadják egy 3. fél részére, aki aztán eláraszt spammel. Aztán meg csak dohogunk, hogy vajon ki adta el jó pénzért az email címünket a bűnözőknek.

A jox.hu egyik oldalán ez egyik írás arról szól, hogy a Gmail egy apró trükkel igyekszik segíteni, hogy beazonosíthassuk a bűnös web oldalt, ahonnan továbbkerült a címünk.

Tegyük fel, hogy az email címed xxx@gmail.com. Ebben az esetben az űrlapon az xxx+www.urlap.hu@gmail.com címet add meg. A gmail ebben az esetben is továbbítja neked a levelet. Ha pedig az oldal tulajdonosa eladja a címedet, akkor azt a spam To: mezőjéből fogod tudni, ugyanis a spamben majd a xxx+www.urlap.hu@gmail.com cím fog ott szerepelni. A módszer gyengéje, amint azt a jox.hu kommentjei között valaki meg is jegyezte, hogy ez a módosított email cím tartalmazza a valódi címünket, és nem kell túl nagy fantázia a + jel utáni rész megtisztításához.

Szintén a regisztrációk okozta kockázatot hivatott orvosolni az MPP új szolgáltatása, az eldobható email címek. Az oldalukon be lehet állítani egy xxx@mpp.hu alakú címet, ill. megadhatjuk, hogy mennyi ideig (pl. 1 óra, 1 nap, … , 1 hónap) vagy hány levélig (1, 5, …, 100) történjen meg az átirányítás. A web oldalak, ill. a spammerek csak az xxx@mpp.hu címet találják meg, a valódi címünk rejtve marad előttük. A megadott nap/darab limit után pedig törlik az átirányítást. A szolgáltatás meglehetősen kellemes és ráadásul ingyen van.

De még az MMP ezen szolgáltatására sincs feltétlen szükségünk. Ha a szolgáltatónk engedi, hozzunk létre álnevet (alias), ami az email címünkre mutat. Ezután adjuk meg azt a regisztráció(k) során. Miután végeztünk, egy elegáns mozdulattal törölhetjük az aliast, és kész. Bye-bye spammerek és áruló web oldalak…

Ez utóbbi akkor igazán hatékony, ha az alias nincs semmilyen kapcsolatban a valódi címünkkel. Pl. ha xxx@ceg.hu az email címünk, akkor jó alias az abcde@aaa.ceg.hu, de még jobb az abcde@bbb.hu. Manapság már egy extra domain fenntartása csak pár ezer HUF évente. Kis befektetés, nagy haszon.

Ha pedig valamiért a fentiek egyike sem járható, akkor marad valamelyik freemail szolgáltató ingyenes email címe, amit csak a webes regisztrációra használunk, és a valódi, céges email címünket csak üzleti partnereinknek adjuk meg. Csak aztán ne felejtsük el néha kitörölni a sok spamet a freemail fiókunkból, ha ismét regisztrálni akarunk valahol…

A BSA APEH-kommandókat küld a cégekre

Az IT.news szerint az APEH és a BSA egy titkos megállapodást kötött, ezért a jövőben fel fog lépni az illegális szoftverhasználat és forgalmazás visszaszorítása érdekében. Ez az APEH szerint ugyanis jogsértő tevékenység, ami temérdek pénzhez segíti a feketegazdaságot, ill. több ezer bejelentett számítástechnikai munkahelytől fosztja meg a munkavállalókat.

Az APEH állítása szerint az illegális szoftverhasználat az egész nemzetgazdaságnak kárt okoz. Az adóhatóság a jövőben az illegális szoftverhasználat ellen büntetőeljárást fog kezdeményezni.

Noha van pár FUD a 2 rendőrség (sic!) közös állásfoglalásában, azzal mindenképpen egyetértek, hogy a szoftver lopása bűn. De van 1-2 dolog, ami nem hagy nyugodni.

Tegyük fel, hogy Magyarország holnap, akár központi akarattal segítve, átáll nyílt forrású (open source) szoftverekre. (Ezeknek megvan az a kellemes tulajdonságuk, hogy az ún. szoftver lopás fogalmát eliminálják – azt a szoftvert ugyanis nem lehet ellopni, amit ingyen adnak). Kiváncsi vagyok, vajon összeomlik-e a nemzetgazdaság, csak mert mondjuk (worst case scenario) 10 cég összecsomagolna és hazamenne? Nem hinném, még akkor sem, ha a kassza valóban búcsút kellene mondjon az ő adó forintjuknak. Cserébe azonban sokkal olcsóbb lehetne egy kkv informatikai rendszerének fenntartása, és ez sokat javítana a versenyképességén is, ami szerintem sokkal nagyobb nyereség, mint az említett cégek vesztesége.

A zárt forráskódú szoftvertermékek gyártói szeretik felnagyítani az ő problémáikat – mondjuk, hogy nem fogy eléggé a Vista, és összetéveszteni egy (bármelyik) nemzet gazdasága egészének problémáival – nevezetesen, hogy sosincs elég adóforint a kasszában.

A másik FUD, amit nem hiszek el, hogy valóban több ezer új munkahelyet teremtene az, ha a BSA képviselte cégek termékeit – pl. Microsoft, Adobe, Symantec, … – jobban venné a nép? Kétlem. Ezeknek a brigádoknak ugyanis megvan az apparátjuk, hogy akár 10x ennyi terméket (jellemzően szoftvert) el tudjanak adni. Az Internet nyújtotta globális jelenlét pedig erősen megkérdőjelezi egy tokkal-vonóval ellátott nemzeti képviselet szerepét.

De további pozitív mellékhatása is lenne ennek. Jelenleg ugyanis jellemzően csak ezek a gyártók adnak terméktámogatást, mert csak ők ismerik kívülről-belülről a saját termékeiket. A monopol helyzet pedig – mint tudjuk – magasan tartja az árakat. Ha több (a gyártótól) független kisebb vállalkozás is képes lenne mondjuk Symantec terméktámogatást nyújtani, egyszerűen a verseny miatt olcsóbban kaphatnák meg a szolgáltatást a kkv (és az akár nagyobb) cégek (is) azt. Ebben az esetben jönne létre az a több ezer új munkahely. És a csomó adóforint.

Mert az ugyan igazságos, hogy ha a Vista mondjuk $199 pénzbe kerül, akkor mindenki fizesse is ki azt az összeget érte. Csak éppen nem okos dolog, ha egyébként nyugodtan tudnánk használni helyette egy ingyenesen elérhető alternatívát, és ennek ellenére a drágábbat választjuk, ami ha drágább is, de legalább nem jobb, mint az ingyenes vetélytársa.

Tudom, vannak olyan esetek, helyzetek és alkalmazások, amelyek csak egy adott cég platformján érhetőek el (jelenleg), elfogadom. Viszont ők fizessék is ki/meg a Vista/XP/Office/ISA/… temérdek pénzbe kerülő licence díjait. A többiek meg álljanak át nyugodtan egy olyan alternatív platformra (mondjuk Linuxra), amelyik sokkal olcsóbb, stabilabb és megbízhatóbb. Így egy kkv-nál elég lehet 1 (ha ugyan kell olyan sok) vindoze pc is, sokkal olcsóbbá téve az IT büdzsét. Annál is inkább, mert már most is több kisvállalkozás áll ugrásra (ill. ügyfélre) készen az ilyen igények kiszolgálására.

Biztos vagyok benne, hogy az emberek APEH iránti negatív érzelmei, most hogy a BSA rátett még egy lapáttal (politikailag korrekt kifejezéssel: ráreagált), elősegíti, hogy az emberek még egyszer  megfontolják a váltást.

Szabad egy táncra?


Az EFF egy igen különös helyzetbe gabalyodott, amikor Kyle Machulis ügyét elvállalták. Történt ugyanis, hogy Machulis egy olyan videot töltött fel a népszerű YouTube-ra, amelynek egy kb. 10 másodperces részletében egy koncerten résztvevő rajongók egy csoportja az ún. Electric Slide nevű tánc egy részletét táncolta – vagy legalábbis lelkesen imitálták. Kb. 03:35-03:50 körül látszik ez a videon.

Igen ám, csakhogy ezt a táncot Richard Silver (aki kitalálta azt) szabadalmaztatta. Silver azt állítja, hogy Machulis home videoja megsértette az ő szabadalmi jogait, mondván ezek a lelkes rajongók annyira ügyetlenül adták elő az Electric slide-ot, hogy ezzel az előadással rossz fényt vetnek az ő táncára.

Silver a DMCA-ra (Digital Millennium Copyright Act) hivatkozott. Még jó – egy osztrák lagzi amatőr videosa szerint – hogy mi nem az USA-ban élünk, minket (még) nem nyomorít meg valami hasonló nonszensz jogi abszurditás.

Az EFF bírósághoz fordult, és beadványában azt szeretné elérni, hogy a bíróság mondja ki: Machulis videoja nem sértette meg Silver jogait, és belefér az ún. fair use kategóriába.

Maga a tánc – imho – nem egy nagy durranás, a használati utasítása kb. ez: lépés balra, lépés jobra, taps – néha van benne 1/4-es forgás is.

Julian Morrow Stupid Americans című riportja után én már semmin nem csodálkozom, ott bármi megtörténhet.

Spam károk és megoldások

Dr. Fehér Gábor készített egy dokumentumot Spam károk és megoldások címmel. Szó van az írásban arról, hogy mi a spam, ill. hogyan lehet ellene védekezni. Az külön kedves volt a szememnek, hogy megemlítette a Bayesian szűrést is, de két dologban nem értünk egyet. Fehér szerint a statisztikai szűrőkkel 2 probléma is van:

  1. folyamatosan tanítani kell a ham és a spam adatbázist
  2. a spam és ham szavak egyediek az egyes felhasználókra nézve, és nincs globális ham ill. spam táblázat

Az valóban igaz, hogy a statisztikai elven működő szűrőket tanítani kell ahhoz, hogy hatékonyan tudják osztályozni a leveleinket. Jó esetben, amikor harcra fogunk egy ilyen szűrőt, van valamennyi jó levelünk (=ham), ill. kéretlen levélszemetünk (=spam). Ha pedig így van, akkor a kezdeti tanítás igen egyszerűen, pár kattintással, esetleg néhány parancs kiadásával elvégezhető.

Miután elkészítettük az adatbázist, azután már csak akkor kell tanítani a szűrőnk “szótárát”, ha a spamszűrőnk hibásan jelölt meg egy levelet. Ahogy telik az idő, és a szűrő egyre jobban megismeri, hogy mely leveleket szeretjük, és melyeket nem, egyre pontosabb lesz, és egyre kevesebbet kell tanítani.

Én is használok egy ilyen elven működő szűrőt, jelenleg kb. 2000 ham, ill. ennél valamivel több spam levél szavait tartalmazza az adatbázisa. Mostanság már, ha heti 1 levéllel kell tanítani, akkor sokat mondok. Ezért saját tapasztalataim alapján állíthatom, hogy ha egy bizonyos idő (ha jobban tetszik levélszám) után már egyáltalán nem kell _folyamatosan_ tanítani.

Nem hallgatom el azt sem, hogy a spammerek időnként új dolgokat találnak ki, ezért ha néha mégis beesik egy spam, akkor azzal a levéllel (eseti jelleggel) tanítom a szűrőt, és kész. Mintha védőoltást kaptam volna, azt a fajta spamet nem látom többet. Probléma megoldva.

A másik tévedésre (miszerint nincs globális spam, ill. ham adatbázis) legyen elég annyi, hogy az én spamszűrőm alapértelmezésben kifejezetten globális adatbázist használ.

Amit Fehér hibaként ró fel – ti. hogy minden felhasználónak saját token adatbázisa van – az valójában rendkívüli előny. Hiszen így minden felhasználó testreszabhatja magának, hogy ő mit tart spam levélnek, ill. mit nem. Ez adja a lehető legnagyobb szabadságot a felhasználóknak. Nincs ugyanis többé az a kellemetlen helyzet, hogy a rendszergazda beállít valamit, vagy a gyártó ki tudja mi alapján állít össze egy uniformizált spam adatbázist, aztán reménykedjünk, hogy az nekünk is jó lesz. (Nem lesz jó, éppen úgy, mint az egyen méretű cipő, valakinek biztosan szorítani fog valahol).

Azt is hozzá kell tenni, hogy egyáltalán nem rossz az, ha egy adott cégnél egy globális spam adatbázist használnak. Ebben az esetben ugyanis nagyon hamar eléri az adatbázis azt a “kritikus tömeget”, amellyel már rendkívül precízen tudja osztályozni a leveleket.

Néhány helyen azonban ötvözik a két megoldás előnyeit. Készítenek egy globális adatbázist, amelyet odaadnak minden felhasználónak, akik aztán a továbbiakban testre tudják szabni, csak saját maguknak. Ha valaki pedig nem akar vagy tud a tanítással foglalkozni, az használhatja az alapértelmezett globális adatbázist.

Az egyénre szabott adatbázisoknak van egy további előnyük. Tegyük fel, hogy egy spammer addig teszteli a levelét egy bizonyos szűrővel, amíg az át nem csúszik rajta. Ez egyáltalán nem lehetetlen, főleg akkor, ha a spammer is megveszi azt a kereskedelmi spamszűrőt, ami az áldozatnál is védi a hálózatot. (Manapság már – szinte – minden appliance esetén lehetséges az ingyenes kipróbálás). De az már a lehetetlenséggel határos, hogy egy adott spam mondjuk 20-30 dolgozó 20-30 testre szabott (és ezért különböző) adatbázisán is átverekedje magát.

Érveimet, gondolataimat elküldtem a YellowCube blogba is, ahol hivatkoztak Fehér Gábor prezentációjára. Kiváncsi vagyok a folytatásra.

Spammerek használják a DNS szerveredet?

Vannak olyan morcos emberek, akik addig harcolnak a spammerek ellen, amíg a DNS szervereiket is hidegre teszik. Ez azért is felettébb kellemetlen a spammerek számára, mert a DNS számukra is az Internet infrastruktúra kritikus része.

Mert az még hagyján, hogy ha nem érhető el a spammer domainje, akkor hiába is illeszt egy web poloskát (1×1 pixel méretű átlátszó kép) a leveleibe, és így nem tudja nyomon követni, hogy valójában melyik kiküldött levelet olvasták el, ill. melyik landolt a spam folderben. Nagyobb probléma, hogy egy (több) új DNS szervert kell valahol máshol telepíteni, ha azt akarja, hogy a levelekben levő hivatkozásokra kattintva az érdeklődők el tudjanak jutni a Rolex órákat áruló web oldalakra.

Ezért azt találták ki egy ideje ezek az igen leleményes bűnözők, hogy nyitott DNS szervereket keresnek (hasonlóan az open relay SMTP szerverekhez), amelyek bárki számára végeznek rekurzív névfeloldást.

A trükk a következő: regisztrálnak egy spam domaint olyan DNS-eken, amelyek az ő irányításuk alatt vannak. Ezt bejegyeztetik valamely regisztrátorral. Ezután a fentebb említett rekurzív DNS szervereket ráveszik, hogy tárolják el ideiglenesen az ő spam domainjük adatait. Majd visszamennek a regisztrátorhoz, és módosíttatják
a spam domain paramétereit úgy, hogy a domain DNS-ei ezután már nem a spammer saját szerverei, hanem választanak párat abból a nagyszámú emberspammerbarát DNS szerverek közül. A regisztrátorok pedig nem sokat aggódnak amiatt, hogy vajon a (spammer) domain tulajdonosa jogosan használja-e az új DNS-eket.

Ezután pedig hadd szóljon, kiküldik a rengeteg spamet. Ha pedig valaki morcos lesz emiatt, és panaszt tesz a spammer DNS szerverére, annak szolgáltatójánál, lesz majd meglepi, hogy vajon miért vágták el a DNS szerverem Internet kapcsolatát?!

A megoldás egyszerű: mint sok esetben, az idő most is begyógyítja a sebeket, a felhasznált DNS szerverek a spammer domain adatait – mivel az valójában nem is az övéké – a TTL (time-to-live) paraméterben megadott idő múlva elfelejtik. Csakhogy egy spam kampány jó eséllyel lefut ennyi idő alatt.

Ha azonban még egy rövid ideig sem akarunk – akaratunk ellenére – részt venni a spammerek kampányában, akkor állítsuk be úgy a DNS szervereinket, hogy azok a világ számára _NE_ végezzenek rekurzív névfeloldást, kizárólag a saját felhasználóink számára.

Az eredeti cikk után van néhány komment, és az egyik olvasó megjegyzi, hogy ennél kicsit nehezebb a dolog, ha a spammer rá tudja venni valahogyan az egyik legitim felhasználónkat, hogy ő kérdezze le az ominózus spam domain adatait. De ez szerencsére nehezebb még egy spammer számára is.

Slackware Linux telepítő USB pendrive-on

Már korábban is szerettem volna, ha az USB kulcsra egy Linux telepítő is felkerül. Az új pendrive-val pedig már nem lehet több kifogás. Az alábbiakban azt mutatom meg, hogyan sikerült egy redukált Slackware telepítőt applikálni a pendrive-omra.

Az USB kulcsra csak a legszükségesebb csomagokat és egyéb kellékeket teszem fel, ha pedig utólag még szükség lesz valamire, azt majd letöltöm valamelyik Slackware tükörről vagy a pendrive másik partíciójára másolom. A művelethez szükség lesz egy Slackware telepítő CD-re (vagy DVD-re) esetleg egy friss ISO file-ra. Ha már van adat (bármi) a kulcsodon, végezz egy mentést róla.

Praktikus okok miatt hozzunk létre két partíciót az USB kulcson, hogy az alábbihoz hasonló módon nézzen ki az fdisk kimenete (nálam /dev/sda az USB pendrive):

fdisk -l /dev/sda

Disk /dev/sda: 2063 MB, 2063597568 bytes
64 heads, 62 sectors/track, 1015 cylinders
Units = cylinders of 3968 * 512 = 2031616 bytes


Device Boot Start End Blocks Id System
/dev/sda1 * 1 64 126945 6 FAT16
/dev/sda2 65 1015 1886784 6 FAT16

Én már el is készítettem a szükséges FAT16 filerendszert mindkét partíción:

mkdosfs -F 16 /dev/sda1
mkdosfs -F 16 /dev/sda2

A kisebbik (kb. 128 MB) partíción lesz a Slackware telepítő, a nagyobbikon (majdnem 1,9 GB) pedig az adatok (ez nálam mindenféle dokumentációt, konfigurációkat, mentéseket és ennek a site-nak a tartalmát jelenti).

Csatoljuk fel a kisebbik partíciót:

mount -t vfat /dev/sda1 /mnt/pendrive

Készítsük el rajta az alábbi szerkezetet:

ls -l /mnt/pendrive/

total 5006
-rwxr-xr-x 1 sj jogyerek 2375298 2007-02-14 18:06 bzImage
-rwxr-xr-x 1 sj jogyerek 2731362 2007-02-14 18:36 initrd.img
-r-xr-xr-x 1 sj jogyerek 8236 2007-02-14 20:34 ldlinux.sys
-rwxr-xr-x 1 sj jogyerek 830 2007-02-14 20:28 message.txt
drwxr-xr-x 6 sj jogyerek 2048 2007-02-14 21:11 slackware
-rwxr-xr-x 1 sj jogyerek 309 2007-02-14 20:30 syslinux.cfg

A slackware/ könyvtár ugyanaz, mint ami a standard telepítő CD-n is megtalálható. Nekem most elég az “A”, “AP”, “D” és az “N” kollekció:

ls -l /mnt/pendrive/slackware/

total 32
drwxr-xr-x 2 sj jogyerek 22528 2007-02-14 17:03 a
drwxr-xr-x 2 sj jogyerek 4096 2007-02-14 21:04 ap
drwxr-xr-x 2 sj jogyerek 2048 2007-02-14 21:11 d
drwxr-xr-x 2 sj jogyerek 4096 2007-02-14 17:03 n

Persze ezekből sem szerepel az összes csomag, csak azok, amelyeket szükségesnek ítéltem. Pl. az “n” könyvtár csak az alábbi csomagokat tartalmazza:

ls -l /mnt/pendrive/slackware/n/

total 6190
-rwxr-xr-x 1 sj jogyerek 2897 2007-02-14 17:03 install-packages
-rwxr-xr-x 1 sj jogyerek 446 2007-02-14 17:03 install.end
-rwxr-xr-x 1 sj jogyerek 1297 2007-02-14 17:03 maketag
-rwxr-xr-x 1 sj jogyerek 5423 2007-02-14 17:03 maketag.ez
-rwxr-xr-x 1 sj jogyerek 493080 2007-02-14 17:03 ncftp-3.2.0-i486-2.tgz
-rwxr-xr-x 1 sj jogyerek 189 2007-02-14 17:03 ncftp-3.2.0-i486-2.tgz.asc
-rwxr-xr-x 1 sj jogyerek 324 2007-02-14 17:03 ncftp-3.2.0-i486-2.txt
-rwxr-xr-x 1 sj jogyerek 783961 2007-02-14 17:03 openssh-4.4p1-i486-1.tgz
-rwxr-xr-x 1 sj jogyerek 189 2007-02-14 17:03 openssh-4.4p1-i486-1.tgz.asc
-rwxr-xr-x 1 sj jogyerek 676 2007-02-14 17:03 openssh-4.4p1-i486-1.txt
-rwxr-xr-x 1 sj jogyerek 3479851 2007-02-14 17:03 openssl-0.9.8d-i486-1.tgz
-rwxr-xr-x 1 sj jogyerek 189 2007-02-14 17:03 openssl-0.9.8d-i486-1.tgz.asc
-rwxr-xr-x 1 sj jogyerek 561 2007-02-14 17:03 openssl-0.9.8d-i486-1.txt
-rwxr-xr-x 1 sj jogyerek 103393 2007-02-14 17:03 rp-pppoe-3.8-i486-2.tgz
-rwxr-xr-x 1 sj jogyerek 189 2007-02-14 17:03 rp-pppoe-3.8-i486-2.tgz.asc
-rwxr-xr-x 1 sj jogyerek 499 2007-02-14 17:03 rp-pppoe-3.8-i486-2.txt
-rwxr-xr-x 1 sj jogyerek 1274 2007-02-14 17:03 tagfile
-rwxr-xr-x 1 sj jogyerek 833414 2007-02-14 17:03 tcpip-0.17-i486-39.tgz
-rwxr-xr-x 1 sj jogyerek 189 2007-02-14 17:03 tcpip-0.17-i486-39.tgz.asc
-rwxr-xr-x 1 sj jogyerek 589 2007-02-14 17:03 tcpip-0.17-i486-39.txt
-rwxr-xr-x 1 sj jogyerek 599349 2007-02-14 17:03 wget-1.10.2-i486-2.tgz
-rwxr-xr-x 1 sj jogyerek 189 2007-02-14 17:03 wget-1.10.2-i486-2.tgz.asc
-rwxr-xr-x 1 sj jogyerek 398 2007-02-14 17:03 wget-1.10.2-i486-2.txt

Hogy a telepitő panaszkodását eleve kizárjuk, elég módosítani a “maketag” állományt, és csomagok leírásánál a hiányzókat kitöröljük, hogy csak az alábbi csomagok maradjanak:

"ncftp" "NcFTP file transfer utilities" "on" \
"openssh" "OpenSSH Secure Shell" "on" \
"openssl" "OpenSSL Secure Sockets Layer toolkit" "on" \
"rp-pppoe" "Connect to ADSL ISPs that use PPPoE" "on" \
"tcpip" "Basic TCP/IP network programs and daemons" "on" \
"wget" "WWW/FTP retrieval tool" "on" \

Természetesen arra is lehetőség van, hogy egy adott csomag alapértelmezésben ne legyen kiválasztva, ebben az esetben a leírása után szereplő “on” kapcsolót állítsuk át “off“-ra.

Az ISO file-ban is megtalálható isolinux/ könyvtár alól másoljuk az /mnt/pendrive alá az initrd.img és a message.txt file-okat, ez utóbbit – igény esetén – kedvünkre szerkeszthetjük.

A kernels/ könyvtár alól válasszunk ki egy kernelt, pl. sata.i, és az abban levő kernelt másoljuk a /mnt/pendrive könyvtárba:

cp kernels/sata.i/bzImage /mnt/pendrive

Végül hozzuk létre a /mnt/pendrive/syslinux.cfg file-t. Ez nagyon hasonlít az isolinux/isolinux.cfg állományra, nálam így néz ki (Figyelem! Ebben a példában a file 7 soros):

cat /mnt/pendrive/syslinux.cfg
default bzImage initrd=initrd.img load_ramdisk=1 prompt_ramdisk=0 ramdisk_size=6464 rw root=/dev/ram SLACK_KERNEL=bzImage
prompt 1
timeout 100
display message.txt
label bzImage
kernel bzImage
append initrd=initrd.img load_ramdisk=1 prompt_ramdisk=0 ramdisk_size=6464 rw root=/dev/ram SLACK_KERNEL=bzImage

Igény szerint több kernelre is hivatkozhatunk, csak készítsünk neki egy bejegyzést a syslinux.cfg-ben, ill.a kernelt is másoljuk a /mnt/pendrive alá.

Ha idáig eljutottunk, akkor futtassuk a “syslinux /dev/sda1” parancsot, amely elkészíti a
/mnt/pendrive/ldlinux.sys állományt.

A syslinux program a “syslinux” csomagban található, és szükségünk lesz még a “floppy
nevű csomagra is (az mcopy parancshoz).

Ha elkészültünk ezzel is, akkor csatoljuk le a pendrive-ot (umount /mnt/pendrive), indítsuk újra a gépet, és szükség szerint állítsuk be a BIOS-ban, hogy az USB eszközről boot-oljon a gépünk. Ha mindent jól csináltunk, akkor a Slackware szokásos telepitő üzenete köszönti az olvasót.

Megcsinálhatom?

Az ember azt hinné, hogy azt a néhány futóbolondot, akik a világ megjobbításáért tesznek valamit ingyen és szerelemből, senki nem bántja. Történt ugyanis, hogy Bob Jacobsen, akinek a vasúti terepasztal volt a hobbija, írt egy programot, ami lehetővé tette, hogy számítógéppel lehessen vezérelni a terepasztalt. És hogy a világ, ha csak egy kicsit is, de valóban jobb lehessen, ingyen elérhetővé tette a programját, mi több, még a forráskódot is megosztotta a világgal, hogy aki akarja, még jobbá tehesse vagy módosíthassa a kódot.

Eddig még szép volt a világ, de jött a KAM Industries nevű cég, akik valami hasonló projektben utaztak, és próbálták a bejegyzett szabadalmi jogukat érvényesíteni. Nehogy már valami senki belezavarjon az üzletükbe.

Jacobsen információkat kért arról, hogy pontosan mivel is sértette meg ő a KAM szabadalmát, mire postafordultával kapott is egy számlát $203,000 összegről, mivel – állítólag – az a kb. 7000 felhasználó, akik ingyen letöltötték a nyílt forrású programot, és ezzel fejenként legalább 29 dollár kárt okoztak a KAM-nak.

A KAM ezen kívül írt Jacobsen akadémiai szponzorának, és bekérte az ő összes levelezését. Jacobsen egy idő után megírta nekik levélben, nem hinné, hogy a KAM keresete megállna a bíróságon. Azt ismegemlítette, hogy az ő “problémás” szoftvere már azelőtt elérhető volt, hogy a KAM bejegyeztette volna a szabadalmát, és ezt a KAM ügyvédeinek is tudniuk kellene.

Ezek az öltönybe bújt gonosztevőkügyvédek azonban állították, ők nem is hallottak arról, hogy Jacobsennek a már megjelent munkája esetleg semmissé tenné az ő szabadalmukat, és továbbra is állították, hogy Jacobsen megsértette azt.

Bár nyilvánvaló, hogy a KAM szabadalmi bejegyzése ennek fényében érvénytelen, még nincs vége történetnek. Az mindenesetre kiderült, hogy az efféle szabadalmi jogok hátráltatják a nyílt forrású fejlesztőket (is). Sőt, még egy kisvállalkozás is fegyverként foghatja azt az érdekeit sértő fejlesztőkre.

Józan ésszel egyszerűen felfoghatatlan, hogy miért baj az, ha egy adott problémát egymástól függetlenül 2 vagy több csoport is megold. Persze megértem én azt, hogy ha mind a kettő hasonló tudású, minőségű, stb. és az egyik ingyen elérhető a felhasználók számára, akkor az a kereskedelmi megoldás piacát csökkenti, aminek az utóbbi részvényesei nyilván nem örülnek.

De a világ – ha a szabad versenyt nem korlátozzák – már csak ilyen: a ragadozók (=felhasználók) először a gyengébb példányokat likvidálják (=nem szívesen választják a gyengébb megoldást). Főleg ha az legalább még drágább is.

Bérgyilkos spam

Nem akartam hinni a szememnek, amikor először megláttam ezt az angol nyelvű szöveget. A spam azzal kezdődik, hogy megnyugtatja az embert: noha valaki $50,000 pénzt fizetett neki (=egy bérgyilkosnak), hogy végezzen velünk, ő azonban követ minket pár napja, és megállapította, hogy ártatlanok vagyunk, ezért mégsem akar megölni. Ellenben szüksége lenne 80,000 US dollárra, különben is mi az a mi életünkért?

Ezért gyorsan át kellene utalni először $20,000 összeget a megadott bankszámlára. Ezután majd összefutunk valahol, és átadom neked a megbízómra nézve terhelő hangfelvételt, amin éppen nyélbeütjük a likvidálásod szerződését. Ezzel elmehetsz a rendőrségre, és szépen utalod a további 60,000 USD-t.

Az FBI egyik különleges ügynöke szerint azonban nem kell megijedni ez ún. scam (=átverés), amit az is erősít, hogy több nyelvtani hiba is van a levélben, úgyhogy az valószínűleg valahonnan a tengerentúlról származik.

Tőzsde spam

Manapság senkinek nem kell már a spamben tukmált Rolex vagy \/iagra, és már (talán) elfogytak azok a hiszékenyek is, akik az afrikai hercegeket segítenék (bőkezű ellenszolgáltatás ellenében) örökségükhöz, vagy akiket a spanyol lottó sok millió Euro összegű nyereménye meg tud még szédíteni – noha soha nem töltöttek ki egyetlen szelvényt sem.

A spammerek ezért mostanában új célpontot találtak maguknak: a tőzsdét. Kinéznek valami gyengén szereplő részvényt, amiből felvásárolnak egy jó adagot. Ilyen volt pl. az amerikai Southern Cosmetics részvénye, amelyet darabonként mindössze 1 centért meg lehetett venni. Ezután kiküldenek egy csomó spamet, amelyben az adott részvényeket reklámozzák, hogy az hű de milyen jó, és vásárlásra biztatnak.

Ilyen nincs, és mégis van, hihetetlen, de sokakat megszédített a csábítás. Az említett kozmetikai cég részvénye pár nap múlva már 6,6 centet ért. A spammerek pedig 100*(6,6-1/1) = 560% haszonnal adhattak túl a bevásárolt részvényeken. Egyszóval kaszáltak rajta rendesen.

Azok pedig, akik jól bevásároltak vele, hamarosan rádöbbentek, hogy az adott részvény valójában nem sokat ér, és annak árfolyama hamar vissza is esett a korábbi filléres értékre.

Spammer trükkök

A mai nap arra lettem figyelmes, hogy spammerek – az egyik ügyfelünk hibásan megírt php script-je segítségével – laza 30k spamet küldtek ki. Az első gondolatom az volt, hogy megnézem az Apache naplóját, és megkeresem, kié a legtöbb HTTP kérés. Ez azonban nem vezetett eredményre, biztosra vettem, hogy nem a top10 látogatók voltak az elkövetők.

Szerencsére kezembe került a spam egy példánya, valami fogyókúra dologról van szó benne (ha érdekel, elküldöm). Már csak azt kellett megoldani, hogy ha valaki ezt a spamet küldi el az űrlapnak, akkor az valahogy ne sikerüljön.

Ebben pedig a modsecurity nevű Apache modul volt a segítségemre. Még jó, hogy előző nap megkaptam az aktuális Linuxvilágot, amiben pont írtam erről a modulról. A lényeg az, hogy be tudtam állítani azt, hogy ha valaki ezt a bizonyos spamet akarja elküldeni, akkor az Apache egy 403-as hibát küld a spammernek (vagy a bot-jának).

Ehhez annyit tettem, hogy az említett spamből vettem egy mintát, majd készítettem egy modsec. szabályt SecFilterSelective POST_PAYLOAD “intensive medical procedures”, és voila! kapásból meglett az illető a modsecurity naplójában.

Egyébként egy HTTP POST kérés átlag kb. 120 email címet tartalmazott. A slusszpoén pedig az volt a fogás nyomán, hogy ugyanezt a spamet más site-on keresztül is küldték. De legalább mostmár sikertelenül. Tudom, hogy ez csak egy gyors tűzoltás volt, a probléma megnyugtató megoldása az lesz, ha minden érintett kijavítja a hibát a php script-jében…