My Shiny Weblog!

Едно от многото нови неща във FreeBSD 8.0 е поддръжката на ZFS. Друго такова е USB подсистемата в ядрото, тя е пренаписана с цел по-голяма гъвкавост. Аз изпробвах и двете, като минах един 500Gb USB хард диск на ZFS. Идеята на този диск е да бъде непрекъснато с мен, за да не си изгубя данните, ако решат да ми ограбват апартамента отново. Данните на него трябва да са криптирани, за защита от евентуална кражба на самия диск. При включване на диска в компютъра виждаме следното:

ugen2.2: <JMicron> at usbus2                                                                                                                 
umass0: <MSC Bulk-Only Transfer> on usbus2                                                                                                   
umass0:  SCSI over Bulk-Only; quirks = 0x0000                                                                                                
umass0:0:0:-1: Attached to scbus0
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <StoreJet Transcend > Fixed Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)

Хубавото на новата USB система е, че ugen драйвера не пречи на останалите драйвери, не е необходимо да се прекомпилира ядрото за някои глупави принтери например. В случая диска излиза, като da0. Криптография в самата ZFS все още не е имплементирана. По тази причина за криптографията на диска ще използваме GELI. Инициализираме и закачваме криптирания диск:

# kldload geom_eli
# geli init /dev/da0
# geli attach /dev/da0

За разлика от повечето други файлови системи, в ZFS не работи просто върху някакъв дял от диска. За да си направим ZFS файлова система, трябва да имаме т.нар. zpool. Той представлява някакво множество от устройства, върху които искаме да разположим нашата файлова система. В нашия случай за zpool използваме единствено целия криптиран диск da0.eli. По принцип за zpool можем да използваме различни дялове от дискове, цели дискове, файлове, и т.н. Например от там можем да конфигурираме RAID или да ползваме даден диск, като кеш на група от други дискове. Както и много други интересни неща. Повече информация има в man zpool. Нашия zpool има уникално име, в случая backup:

# kldload zfs
# zpool create backup /dev/da0.eli

По този начин зареждаме ZFS модула в ядрото, създаваме и закачваме в /backup новия zpool. Можем веднага да започнем да го ползваме, като файлова система, записвайки файловете директно на него. Ако го направим обаче, няма да можем да използваме предимствата на ZFS. За това ще създадем три отделни файлови системи на него, за отделните машини, на които ще правим backup:

# zfs create backup/eddie
# zfs create backup/marvin
# zfs create backup/bistromath

Файловите системи са създадени и закачени по местата си. Вече можем да работим с диска. Това са три различни, файлови системи. Можем да им задаваме различни опции и да ги закачваме на различни места. Те обаче използват един и същи zpool, дисковото им пространство е споделено. Те имат динамично нарастване и намаляване – когато записваме файлове в тях, те вземат пространство от общия zpool, когато трием – връщат пространството в общия zpool. Ако решим, че ни трябва още пространство можем просто да добавим ново устройство в този zpool. Понеже данните от едната машина са много, а подлежат на компресия – задаваме опцията за компресиране:

# zfs set compression=gzip backup/bistromath

По този начин всички записани данни, след задаване на опцията ще бъдат компресирани. Данните на другата машина са важни – за това искаме да записваме по две копия:

# zfs set copies=2 backup/marvin

Естествено, това не е RAID1, в случая имаме само един диск. Ако искаме RAID1 трябва да го организираме на ниво zpool. Правенето на такова копие може евентуално да ни спаси от лоши сектори по диска. За проверка на интегритета на данните се използват контролни суми, които са пуснати по подразбиране на всички файлови системи – checksum=on. Пълен списък с опциите има в man zfs. За проверка състоянието на backup можем да ползваме:

# zpool status
  pool: backup
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        backup      ONLINE       0     0     0
          da0.eli   ONLINE       0     0     0

errors: No known data errors

ZFS ни предлага най-различни и доста полезни опции, но за мен най-важното е решаването на проблема с фрагментацията на свободното дисково пространство. Поддръжката на ZFS в 8.0 се води за стабилна, но аз предпочитам да изчакам преди да започна да я ползвам навсякъде. Във версиите преди 8.0 се изискваше сериозен tuning на паметта на ядрото, за използване на ZFS. Това изискване вече го няма, но е препоръчително наличието на поне 2Gb RAM. Не успях да намеря достатъчно информация по темата за използането на GELI със ZFS. Може би този подход крие някакви проблеми?

root@eddie:~# tcpdump -i xl1 -en arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl1, link-type EN10MB (Ethernet), capture size 96 bytes
14:07:59.991955 00:16:01:fb:c0:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 92.247.243.79 tell 1.1.1.1            
14:08:00.010110 00:16:01:fb:c0:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 77.71.14.171 tell 1.1.1.1             
14:08:00.040147 00:16:01:fb:c0:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 212.5.32.252 tell 1.1.1.1             
14:08:00.040177 00:16:01:fb:c0:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 87.254.169.41 tell 1.1.1.1            
14:08:00.410212 00:16:01:fb:c0:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 82.7.244.193 tell 1.1.1.1             
14:08:00.410244 00:16:01:fb:c0:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 89.38.1.72 tell 1.1.1.1               
14:08:00.460462 00:16:01:fb:c0:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 92.232.114.92 tell 1.1.1.1            
14:08:00.490200 00:16:01:fb:c0:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 82.2.88.210 tell 1.1.1.1              
14:08:00.490231 00:16:01:fb:c0:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 89.215.227.133 tell 1.1.1.1

Едно е да си квартален ланаджия. Друго е да продаваш Интернет върху равноправна Ethernet мрежа. Трето е да ползваш неуправляеми суичове. Четвърто е да си окабелил цяла София. Но да си квартален ланаджия, продаващ Интернет върху Ethernet мрежа, окабелил цяла София и ползващ глупави суичове вече постижение. Това е черешката върху тортата – златна комбинация между изтънчена простотия, печалбарство, некомпетентност, оптимизъм и непукизъм.

От извесно време насам ми се върти идеята да започна да пиша на тема компютърни трикове. Причината за това е, че съм почнал да забравям нещата, с които не се занимавам всекидневно. Има работи, които преди години правех с лекота, а в момента дори не мога да си спомня начина, по който съм ги правил. Естествено по-голямата част от тях съм ги намирал в Интернет, но за да ги намеря пак са необходими усилия. Дали тези усилия са по-големи от описването им тук – тепърва ще експериментирам. И така, няма по-универсален инструмент от OpenSSH, ползвам го навсякъде. Ето някои основни неща, които правя с него:

• Backup на файлови системи

  /sbin/dump -L0 -h0 -u -f - / | /usr/bin/gzip -c | /usr/bin/ssh -c blowfish backup@marvin dd of=eddie-root-backup-`date "+%d.%m.%Y"`.dump.gz

  Идеята е проста – четем файловата система с dump, архивираме данните през тръбата с gzip, подаваме към ssh връзката, а от другата страна ги поемаме с dd. Важно е да не бавим много и двете машини, по тази причина ползваме gzip за архиватор и blowfish за криптиране на връзката (няма по-бърз и толкова сигурен шифър за x86).
• Отдалечен http proxy сървър

  ssh -L 3128:127.0.0.1:3128 eddie

  По този начин пренасочваме порт 3128 към същия порт на отдалечената машина, през ssh връзката. Интересното в случая е, че този порт там слуша само на localhost интерфейса. Остава да се пусне proxy сървър на този порт (може и нещо друго да се пусне). Един добър избор е 3APA3A tiny proxy – малък е и има много проста конфигурация:

  daemon
  auth none
  external 10.0.0.1
  internal 127.0.0.1
  proxy

  ssh тунела ни спестява автентикация в proxy сървъра, както и един отворен порт на отдалечената машина. Връзката между браузера е proxy сървъра е криптирана.

• Отадлечени X клиенти или QEMU

  Как да инсталираме Windows в QEMU на отдалечен компютър, до който имаме само ssh? Ами през ssh естествено:

  ssh -YC marvin
  qemu -localtime -hda windows.img -cdrom winxp.iso -boot d -net nic,model=rtl8139 -net tap,script=tapup.sh -m 256

  Ще видим добре познатия син прозорец с инсталацията на Windows. Естествено трябва да имаме работещ X, windows.img файла трябва да е достатъчно голям, а winxp.iso трябва да бъде инсталационния диск. По същия начин можем да пуснем произволен X клиент, като връзката с нашия сървър е криптирана през ssh и никакви отворени портове не ни трябват.
• Закачване на отдалечена файлова система

  sshfs marvin: /marvin

  В повечето случаи, особено когато не работим в един LAN, NFS не е нужен. Благодарение на FUSE, можем да закачим файлова система на отдалечена машина през ssh връзка. От извесно време работя с MacFUSE и ползвам често отдалечени файлови системи на доста машини.
• Escape sequences

  ssh -e \~ marvin

  По този начин казваме, че символа след ~ ще се използва за управляващ символ към ssh. Различните управляващи символи са описани в документацията. Използването им е удобно и пести време.

The application failed to initialize properly (0xc015002). Click on OK to terminate the application.

Любима моя грешка, в любима операционна система. След няколко дни разследване и ровене из блогове и форуми, с колегата разбрахме какъв е проблема. Имаме едно MinGW/Qt приложение, което е компилирано на SP3. При опит да се пусне на система, която е под SP3 излиза въпросната грешка. В пристъп на гениалност от M$ решили в SP3 да слагат разни неща от Vista. Така се родило чудовището наречено WinSxS без аз да разбера. SxS означава Side-by-Side. Това е една директория, живееща в C:\WINDOWS. Представлява някакъв кеш от библиотеки, чрез който линкера се оправя с различните версии на една DLL библиотека, които се налага да бъдат заредени в едно и също приложение. Хората по света се оплакват, че на Vista директорията достигала 5Gb. Всъщност за пореден път се сблъсквам с проблема, че XP SP1, SP2 и SP3 са три абсолютно различни операционни системи – имат повече разлики от колкото прилики. Естествено гореспоменатата грешка се появява по ред други причини и е достатъчно неинформативна, че да изгубиш няколко дни с нея. В такива случаи ме спасява Dependency Walker.

• Никога не е била POSIX съвместима по рождение и без допълнителни библиотеки
• Никога не е идвала с някакъв вид shell или нормален език за скриптово програмиране
• Потрбителските и системните файлове живеят на разни подобни странни места:

C:\PROGRA~1\INTERN~1\
C:\DOCUME~1\Administrator\MYDOCU~1\

• Във файловата система никога не е имало поддръжка за hard или soft links
• Изпълнимите файлове се заключват, когато има работещ процес
• Две програми не могат да пишат в един и същи файл
• Процесите нямат нормален stderr
• Стандартен набор от команди за вършене на каквато и да било работа липсва
• Нормален терминал няма и никога няма да има
• Линкера си търси библиотеките на най-невероятни места и по никакъв повод не се оправя с различни версии
• Всеки софтуер си ходи със собствени “динамични” библиотеки, които са хаотично разхвърляни по цялата файлова система.

Често пъти потребителите на популярната операционна система минават курс по “компютърна неграмотност”, където биват обучавани как да преудоляват особеностите на системата (изброените и един куп други). Там се обяснява и защо никога, ама никога да не “пипат” файлове, като:

naked_pics.zip                                .exe

Естествено първата част от името на файла прави по-голямо впечатление на компютърно неграмотните хора от втората (която често не се вижда). По тази причина гледането на “голи снимки” има дълготрайни ефекти върху функционалността на популярната операционна система.

[Paths]
Prefix = C:/Program Files/XXX

Function WriteToFile
  Exch $0 ;file to write to
  Exch
  Exch $1 ;text to write

  FileOpen $0 $0 a #open file
    FileSeek $0 0 END #go to end
    FileWrite $0 $1 #write to file
  FileClose $0

  Pop $1
  Pop $0
FunctionEnd
; StrReplace
; Replaces all ocurrences of a given needle within a haystack with another string
; Written by dandaman32

Var STR_REPLACE_VAR_0
Var STR_REPLACE_VAR_1
Var STR_REPLACE_VAR_2
Var STR_REPLACE_VAR_3
Var STR_REPLACE_VAR_4
Var STR_REPLACE_VAR_5
Var STR_REPLACE_VAR_6
Var STR_REPLACE_VAR_7
Var STR_REPLACE_VAR_8

Function StrReplace
  Exch $STR_REPLACE_VAR_2
  Exch 1
  Exch $STR_REPLACE_VAR_1
  Exch 2
  Exch $STR_REPLACE_VAR_0
    StrCpy $STR_REPLACE_VAR_3 -1
    StrLen $STR_REPLACE_VAR_4 $STR_REPLACE_VAR_1
    StrLen $STR_REPLACE_VAR_6 $STR_REPLACE_VAR_0
    loop:
      IntOp $STR_REPLACE_VAR_3 $STR_REPLACE_VAR_3 + 1
      StrCpy $STR_REPLACE_VAR_5 $STR_REPLACE_VAR_0 $STR_REPLACE_VAR_4 $STR_REPLACE_VAR_3
      StrCmp $STR_REPLACE_VAR_5 $STR_REPLACE_VAR_1 found
      StrCmp $STR_REPLACE_VAR_3 $STR_REPLACE_VAR_6 done
      Goto loop
    found:
      StrCpy $STR_REPLACE_VAR_5 $STR_REPLACE_VAR_0 $STR_REPLACE_VAR_3
      IntOp $STR_REPLACE_VAR_8 $STR_REPLACE_VAR_3 + $STR_REPLACE_VAR_4
      StrCpy $STR_REPLACE_VAR_7 $STR_REPLACE_VAR_0 "" $STR_REPLACE_VAR_8
      StrCpy $STR_REPLACE_VAR_0 $STR_REPLACE_VAR_5$STR_REPLACE_VAR_2$STR_REPLACE_VAR_7
      StrLen $STR_REPLACE_VAR_6 $STR_REPLACE_VAR_0
      Goto loop
    done:
  Pop $STR_REPLACE_VAR_1 ; Prevent "invalid opcode" errors and keep the
  Pop $STR_REPLACE_VAR_1 ; stack as it was before the function was called
  Exch $STR_REPLACE_VAR_0
FunctionEnd
Function RIF

  ClearErrors  ; want to be a newborn

  Exch $0      ; REPLACEMENT
  Exch
  Exch $1      ; SEARCH_TEXT
  Exch 2
  Exch $2      ; SOURCE_FILE

  Push $R0     ; SOURCE_FILE file handle
  Push $R1     ; temporary file handle
  Push $R2     ; unique temporary file name
  Push $R3     ; a line to sar/save
  Push $R4     ; shift puffer

  IfFileExists $2 +1 RIF_error      ; knock-knock
  FileOpen $R0 $2 "r"               ; open the door

  GetTempFileName $R2               ; who's new?
  FileOpen $R1 $R2 "w"              ; the escape, please!

  RIF_loop:                         ; round'n'round we go
    FileRead $R0 $R3                ; read one line
    IfErrors RIF_leaveloop          ; enough is enough
    RIF_sar:                        ; sar - search and replace
      Push "$R3"                    ; (hair)stack
      Push "$1"                     ; needle
      Push "$0"                     ; blood
      Call StrReplace               ; do the bartwalk
      StrCpy $R4 "$R3"              ; remember previous state
      Pop $R3                       ; gimme s.th. back in return!
      StrCmp "$R3" "$R4" +1 RIF_sar ; loop, might change again!
    FileWrite $R1 "$R3"             ; save the newbie
  Goto RIF_loop                     ; gimme more

  RIF_leaveloop:                    ; over'n'out, Sir!
    FileClose $R1                   ; S'rry, Ma'am - clos'n now
    FileClose $R0                   ; me 2

    Delete "$2.old"                 ; go away, Sire
    Rename "$2" "$2.old"            ; step aside, Ma'am
    Rename "$R2" "$2"               ; hi, baby!

    ClearErrors                     ; now i AM a newborn
    Goto RIF_out                    ; out'n'away

  RIF_error:                        ; ups - s.th. went wrong...
    SetErrors                       ; ...so cry, boy!

  RIF_out:                          ; your wardrobe?
  Pop $R4
  Pop $R3
  Pop $R2
  Pop $R1
  Pop $R0
  Pop $2
  Pop $0
  Pop $1

FunctionEnd

Those who do not understand UNIX are condemned to reinvent it – badly

—Henry Spencer

root@eddie:~# dig @eddie gmail.com mx +short
50 gsmtp183.google.com.
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
10 alt2.gmail-smtp-in.l.google.com.
50 gsmtp147.google.com.
root@eddie:~# dig @eddie gmail.com a +short
209.85.171.83
66.249.91.83
64.233.161.83

root@eddie:~# dig @192.168.1.1 gmail.com mx +short
;; connection timed out; no servers could be reached
root@eddie:~# dig @192.168.1.1 gmail.com a +short
66.249.91.83
64.233.161.83
209.85.171.83

Чудя се на тези от БТК какъв им е всъщност проблема. Аз много лесно ще си пусна DNS кеш зад всеки ADSL ама не е това идеята. Първо, че ми губят времето второ, че техните трасета се товарят повече. Дали този феномен може да се обясни с нещо различно от мързел и простотия?

Според тази статия на dnes.bg заловеният наскоро Радован Караджич си имал сайт, че дори и email адрес.

“Д-р Драган Дабич живее на ул. “Юрий Гагарин” в Нови Белград. За специализирани въпроси, телевизионни участия или частни консултации, можете да се обърнете към него на адрес zacelivanjerana@dragandabic.com.

И днес сайтът му продължава да функционира, нищо, че “докторът” е в ареста и чака заминаването си за Хага.”

Една справка с whois базата данни показва, че това са глупости. Домейнът, който уж е ползвал Караджич е регистриран малко след като са го хвнали:

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: DRAGANDABIC.COM
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Name Server: NS1.DREAMHOST.COM
   Name Server: NS2.DREAMHOST.COM
   Name Server: NS3.DREAMHOST.COM
   Status: clientTransferProhibited
   Updated Date: 22-jul-2008
   Creation Date: 22-jul-2008
   Expiration Date: 22-jul-2009

>>> Last update of whois database: Wed, 23 Jul 2008 06:01:59 EDT <<<

Интересно каква е истината в случая. Първо си помислих, че някой български журналист е намерил нещо в Интернет и е решил, че е автентично. После обаче намерих и чужди новинарски сайтове, които пишат за това. Има нещо гнило в цялата работа.

Вчера си купих Seagate FreeAgent 500Gb External Hard Disk. Изключително тъпо име за хард диск, не знам как и защо са го измислили, но като изключим тази подробност – доволен съм от него. Идеята ми е да го ползвам, като backup диск, записвайки всички неща на него – сорс код, снимки, filesystem dumps. Освен това ще е много полезно да го разнасям насам-натам и да преписвам неща от разни клиентски компютри. За целта са необходми две важни неща. Първо – необходимо е всичко записано на диска да бъде криптирано. Второ – файловата система трябва да се чете на всякакви операционни системи. Както подозирах още преди да започна цялото упражнение, тези две простички неща не мога да бъдат постигнати с никакви стандартни средства.

Когато включих диска към лаптопа (Apple MacBook) стана ясно, че диска е форматиран с някакъв вид NTFS. Тази файлова система никога не е била стандартизирана. Как точно е правилно да се работи с нея знаят само в Microsoft. Мака може да го чете, но не може да пише по него. На диска имаше програма, която ми предлагаше да го конвертирам за Мак, тоест да го форматирам с HFS+. Това е една файлова система, която никога не е била стандартизирана. Как точно е правилно да се работи с нея знаят само в Apple. Windows XP няма стандартна възможност да чете HFS+. Всички open source операционни системи могат само да четат NTFS и HFS+. Някаква криптография се поддържа и в двете, но тя не върши работа за криптиране на целите файлови системи, става само за отделни файлове или директории. За криптиране на дялове може да се ползва TrueCrypt, като се създаде виртуален дял, като файл на диска. Оказа се обаче, че TrueCrypt предлага само FAT32, като файлова система в криптирания дял. Това очевидно няма как да стане за 500Gb диск, ако помня правилно максималния размер за FAT32 е 32Gb. Слагането на FAT32 дял върху диска, който може да се чете от всякъде е невъзможно по същата причина. Естествено съществуват доста глупави частични решения на проблема. Например няколко дяла за различните операционни системи, няколко дяла с FAT32, използване на TrueCrypt със скрити дялове и др. Тези неща ме накараха да се замисля – защо по дяволите няма отворена, стандартна файлова система за хард дискове, която да се чете навсякъде. Оптичните носители имат такава – ISO9660 с всичките й плюсове и минуси. Май минусите са й повече, но това за пореден път доказва, че е по-добре да има лош стандарт, от колкото никакъв.

Тъй като не ми се цепеше хард диска, нито ми се занимаваше с FAT32 или TrueCrypt. А глупавите и нестандартни NTFS и HFS+ въобще не са опция. Реших проблема с FreeBSD – GELI+UFS2. Сигурна файлова система – знам, че няма да имам проблеми с нея. Сигурна криптография – знам, че няма как да ми откраднат данните. Преносимостта на диска обаче си остана добро пожелание. Все пак се надявам да го накарам да работи на Мака, като накарам Parallels да предаде управлението на диска към FreeBSD във виртуална машина. За четене и писане от Windows машини и дума не може да става. Windows машините ще трябва да работят с хард диска по мрежата през FreeBSD.

Обикаляйки с новия ми MacBook по улиците на София и други големи градове ми прави впечатление следното нещо. Безплатен Интернет достъп може да се използва почти навсякъде. Има огромно количество 802.11 станции, които използват WEP или просто предлагат отворен достъп. Голяма част от тези точки са на някакви частни лица, които очевидно не са си направили труда да ги направят сигурни. По-голяма част са на фирми, които главно поради незнание и несъобразяване на последиците също не са ги направили сигурни. Една много голяма част от тези точки са БТК ADSL модеми, които предлагат 802.11, като допълнителна екстра, с някаква промоция на БТК, която стартира преди време. Много съм благодарен на БТК за тази промоция, вече мога да ползвам ADSL в целия град. Ползването на безплатна Интернет връзка е по-малкото зло в случая.

Много по-голям проблем, особено за фирмите, е неправомения достъп до информация. Освен, че всеки може да се свърже (асоциира) към дадена станция с отворен достъп, всеки може да подслушва трафика между станцията и отделните компютри свързани към нея. В случая с БТК ADSL модемите, това вклюва целия Интернет трафик на всички компютри в мрежата на станцията. По-важната част от този трафик, би трябвало да е криптиран сигунрно през HTTPS – комуникация с НОИ/НАП, както и банкови операции. Друг трафик, който може да представлява интерес е този между отделните компютри в мрежата. Оказва се, че голяма част от компютрите в такива мрежи се използват за обмен на файлове. Няколко пъти срещах цели споделени (shared) дискове с Windows XP. Естествено няма никакво значение дали те са споделени с парола или без, тъй като трафика между компютърите не е криптиран. Цялата тази работа ми е много интересна. След случая с болницата Токуда, чудя се до каква ли още информация може да се достигне с минимални усилия в тази посока. Сетих се за няколко доста прости, но ефективни неща, които ще опиша тук.

Подходящите точки за достъп (802.11 станции) са много, и са разпръснати из града. Необходимото време, което човек трябва да престои в обхвата на една точка се определя от броя на компютрите в нея, както и информацията на тях, която ни интересува. Идеалният вариант за обхождане е с кола, карайки бавно из задръстванията на София. Нещо като комбинация от wardriving и piggybacking. За да бъде ефективна тази работа, тя трябва да бъде автоматизирана. Би било глупаво човек да цъка на мака в колата и да рови папките на нещастниците, които са ги споделили. Хубавото на тази “атака” е, че тя може да бъде проведена на няколко пъти. Например може минавайки първия ден с компютъра през задръстването на Граф Игнатиев, човек да събере информация колко са интересните точки и да си опише кои компютри от тях ще сканира. На следващия ден може да си свали част от необходимата му информация и така нататък. Вероятността собствениците да се усетят е доста малка.

Първото нещо, което ни е необходимо е програма от сорта на iStumbler или KisMAC. Втората може много повече неща, но пък не е толкова удобна за ползване. Една такава програмка може да ни подскаже коя мрежа/станция би била интересна за нас. Също така може да ни сортира отделните станции по определени критерии, така че да можем да ги ровим наред. Няма да говоря за кракване на WEP, защото материали на тази тема бол, а и отворените мрежи са предостатъчно. След като си харесаме мрежа, можем се асоциираме към нея. Почти със сигурност ще получим IP адрес от мрежата, но това не е толкова важно. Вече асоциирани в нея можем да използваме tcpdump или Wireshark за да видим какво “тече” по нея и кои компютри са активни. Всички Windows машини се познават веднага благодарения на NetBIOS broadcast съобщенията. От тях става ясно кой/къде/какво е споделил, както и имената на отделните компютри в мрежата. Ето защо, каквото и да искаме да правим за повечето мрежи ще е много полезно да имаме Samba. По този начин ще можем да работим лесно с отделните споделени неща. Друго полезно нещо в случая, което вече имаме при положение, че ползваме Mac OS – MacFUSE. Някакъв Linux също би свършил добра работа в това отношение, идеята е да можем да закачваме файлови системи в user space на операционната система. Това предлага бърз, лесен и сигурен достъп до файловете, които ни вълнуват.

И така, до тук елементарно можем да напишем програма, която намира подходяща мрежа, намира подходящ компютър в нея и закачва част от неговата файлова система към нашата. Колко елементарно се пише тя няма да коментирам тук, само ще кажа, че подобна програма може да бъде написана на Apple Script или да бъде направена с помощта на Automator, без човек да е чувал що е то програмиране. Най-интересната част от тази мой идеи е какво да правим от тук нататък. Би било глупаво просто да ровим файловете или да преписваме на локалния диск всичко, което намерим. Всъшност няма никаква нужда да преписваме каквото и да било, поради простата причина, че информацията ще си бъде там и на следващия ден – просто е необходимо да отидем да си я вземем, стига да решим, че ни трябва. Някъде около 90% от намерената информация изобщо няма да ни интересува (не съм сигурен за процента, написах го наизуст). Трябва някакси да подберем информацията, а защо не и да търсим в нея. Този проблем адски много напомня за проблема за търсене и класифициране на информация в Интернет. Разбира се, този той е решен много елегантно от Google. Как точно – те си знаят. Всъшност нас не ни интересува, нашата задача може да бъде решена с техните алгоритми, просто трябва да използваме Google Desktop Search for Mac. Това е една доста добра и удобна програма, която ни позволява да направим индекс на файловата система и да използваме алгоритмите на Google за търсене в този индекс. По този начин много удобно можем да ровим локално из чат логове, PDF документи, man страници, сорсове на програми и още какво ли не. Тъй като споделените файлове на хората стават част от нашата файлова система, необходимо е само да пуснем индексирането на Google. Когато то приключи, можем да се развържем от съответната машина и да преминем към следваща. Разбира се, всичко това може да става автоматично, чрез програмата, която ще напишем. Резултатът е, една хубава SQLite база данни, която ние си пазим върху хард диска на мака. Ако сме били достатъчно хитри да си закачваме файловите системи на отделните компютъри към директории с точно определени имена – вече знаем кой файл, на кой чужд компютър се намира. След време, ако търсейки в индекса от вкъщи си харесаме нещо – просто можем да отидем и да си го копираме цялото. Какво ли би излезнало от едно такова търсене, например за – “пин код”, “договор”, “пълномощно”, “фактура”, “строго секретно”, ...

И така, оставям останалите подробности на читателите. Много съм любопитен какво би станало, ако някои с MacBook и такава програма се поразходи около Президентството, Народно Събрание, или пък около БНБ. Може би дори Министерство на Вътрешните Работи? ДСК на Плиска също е една интересна дестинация. Очаквам коментари, препоръки и отзиви.

Това е един доста добър резултат. Все съм виждал много спам, но толкова много не бях. Такъв резултат се постига с много усилия. Най-напред трябва да се инсталира една машина със Slackware и sendmail, F-Prot и MailScanner. На нея да се хостнат около 100 пощенски кутии на POP3, с автентикация през /etc/passwd. След това машината да се остави да отлежи, в продължение на около 3 години – нищо да не се пипа по софтуера (и хардуера, стига да работи). Най-трудното е търпението, човек трябва или да е достигнал до нирваната на мързела, или нищо да не разбира от пощенски сървъри, а може би и двете условия са необходими за постигане на резултата.

• Между 5 и 10 писма в минута – спам
• Пощенски кутии с размер по 400-500 Mb
• Perl процеси с интересни имена
• Директория ”/var/tmp/ /” (това последното е space)
• Пикове в натоварването, пълно блокиране на машината – около 3 за 10 минути

След като смених хард диска, с нова инсталация на FreeBSD+Qmail+Vpopmail+SpamAssassin+CourierIMAP нещата тръгнаха. Но стана ясно, че машината продължава да се задръства от многото спам. Поиграх си доста да настроя SpamAssassin и QmailScanner по начин, който да не задръства. Спама се оказа доста лесен за разпознаване, повечето писма събират по 20-40 точки от необходими 5. Всичко това е с Razor, Pyzor и DCC. Трябва да помисля още, може би ще е добре да вдигна минималните точки за спам или да спра част от защитите. Идеята е целия спам да може да ходи автоматично в кофата за боклук, или поне да не се товари машината излишно.

Feb  7 00:58:01 mailer spamd[91668]: spamd: connection from localhost [127.0.0.1] at port 54603
Feb  7 00:58:01 mailer spamd[91668]: spamd: checking message <000601c86913$068bcc3d$e14ab999@lxgqrq> for kkirov@ncrrp.org:58
Feb  7 00:58:04 mailer spamd[91668]: spamd: identified spam (26.5/5.0) for kkirov@ncrrp.org:58 in 2.9 seconds, 2347 bytes.
Feb  7 00:58:04 mailer spamd[91668]: spamd: result: Y 26 - DIGEST_MULTIPLE,DOS_OE_TO_MX,DRUGS_ERECTILE,HTML_MESSAGE,PYZOR_CHECK,RAZOR2_CF_RAN
GE_51_100,RAZOR2_CF_RANGE_E4_51_100,RAZOR2_CF_RANGE_E8_51_100,RAZOR2_CHECK,RCVD_IN_PBL,RDNS_NONE,URIBL_AB_SURBL,URIBL_BLACK,URIBL_JP_SURBL,UR
IBL_OB_SURBL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL scantime=2.9,size=2347,user=kkirov@ncrrp.org,uid=58,required_score=5.0,rhost=localhost,r
addr=127.0.0.1,rport=54603,mid=<000601c86913$068bcc3d$e14ab999@lxgqrq>,autolearn=spam
Feb  7 00:58:04 mailer qmail-scanner[97147]: SA:SPAM-QUARANTINED:RC:0(77.185.199.6):SA:1(26.5/5.0): 3.521749 2311 heinrich@tirol.com kkirov@n
crrp.org Viagra_helping_you <000601c86913$068bcc3d$e14ab999@lxgqrq> 1202338681.97149-0.mailer.ncrrp.org:414 1202338681.97149-1.mailer.ncrrp.org:883 orig-mailer.ncrrp.org120233868054097147:2311
Feb  7 00:58:04 mailer spamd[71173]: prefork: child states: II

Това беше поредната оферта за Виагра, от която няма да се възползвам.