Jak wysłać maila?

1 lutego, 2012 (14:27) | linux | By: konrad

Ostatnio pojawił się pewien problem. Ktoś w firmie wymyślił, że będziemy do klientów wysyłać jakieś bardzo ważne dane za pomocą maila. Dane te występują w formie plików PDF i są na tyle wrażliwe, że trzeba je jakoś zabezpieczyć. Idea jak najbardziej słuszna, bo kto by chciał, aby dane o jego wynagrodzeniu czy stanie zdrowia były narażone na przeczytanie przez osoby niepowołane. Oczywiście to tylko przykłady, ale dość dobrze oddają zagrożenia, jakie czyhają na nas w dobie wszechobecnego i nielimitowane dostępu do Internetu (ACTA i jej podobne próby cenzurowania na razie pomijam).
Podstawowym założeniem dla zabezpieczenia poczty jest wykorzystanie ogólnodostępnej i dobrze zdefiniowanej metody szyfrowania oraz podpisywania treści. Konkretnie X.509, czyli infrastruktura klucza publicznego. Zrobiło się ciekawie, bo o ile wygenerowanie odpowiedniego certyfikatu (a właściwie pary klucz prywatny – certyfikat) nie jest specjalnie trudne, to wysłanie odpowiednio zabezpieczonego maila z poziomu konsoli Linuksa jest już pewnym wyzwaniem.
Żeby osiągnąć założony cel i zadowolenie klientów, musimy zrobić kilka rzeczy:

1. Musimy posiadać odpowiedni certyfikat do podpisywania maili. Ponieważ podpisywanie odbywa się za pomocą klucza prywatnego, a potwierdzenia autentyczności można dokonać przy użyciu (ogólnie dostępnego) certyfikatu – musimy takową w jakiś sposób zdobyć.
Można ją kupić w dowolnym centrum, jak np. VeriSign – wtedy będziemy wyglądać bardzo profesjonalnie, a nasz certyfikat będzie automatycznie rozpoznawany przez większość używanych obecnie programów. Jest to jedyna rozsądna opcja, jeżeli chcemy taką funkcjonalność oferować klientom. Jednak do testów wygenerowałem sobie certyfikat podpisany przez moje (światowo niezaufane :-)) centrum. Opisów, jak „zrobić” sobie taką infrastrukturę jest w Sieci całkiem sporo i nie będę tego teraz opisywał.

2. Musimy zebrać certyfikaty użytkowników, do których będziemy wysyłać maile. Szyfrowanie danych odbywa się za pomocą certyfikatu (dostępnego publicznie) i bez niego raczej ciężko nam będzie cokolwiek zrobić. Certyfikaty klientów nie muszą by wygenerowane przez zaufane centrum, a nam zależy wyłącznie na tym, aby klucze prywatne, które są z nimi powiązane, były odpowiednio bezpieczne.

3. Ktoś powinien nam dostarczyć odpowiednie dane, które będziemy wysyłać – w moim przypadku będą to pliki PDF, które wygeneruje SAP lub jakiś inny potwór, którego działania nie rozumiem.

4. Trzeba tego PDFa jakoś zaszyfrować, podpisać i wysłać.

I tu zaczynają się schody… o ile zaszyfrowanie i podpisanie maila jest operacją dość prostą:

cat ./plik.txt | openssl smime -encrypt cert_kogos.pem | openssl smime -sign -signer cert.pem -inkey privkey.pem

to wysłanie tego mailem w taki sposób, żeby było poprawnie wyświetlone w czytniku poczty, nie jest już takie oczywiste.

Próbowałem na różne sposoby, jednak za pomocą „czystej” konsoli nie udało mi się osiągnąć tego, co sobie wymyśliłem. Rozwiązaniem okazało się napisanie prostego skryptu w PERLu, który to wszystko po kolei zrobi:

#!/usr/bin/perl
use MIME::Lite;
use Crypt::SMIME;

$wiadomosc = MIME::Lite->new(
        From            => 'moj_adres@gmail.com',
        To              => 'odbiorca@wp.pl',
        Subject         => 'temat',
        Type            => 'TEXT',
        Data            => "Dzien dobry\n\nTRESC\n\n-- \nPozdrawiam,\nKonrad"
);

$wiadomosc->attach(
        Type            => 'application/pdf',
        Path            => 'tajne_dane.pdf',
        Filename        => 'tajne_dane.pdf'
);

{
    local $/=undef;
    open(MY_PKEY, "certs/moj_klucz.pem") || die "open failed: $!"; $privkey = ;
    open(MY_CERT, "certs/moj_cert.pem") || die "open failed: $!"; $cert = ;
    open(TO_CERT, "certs/cert_odbiorcy.pem") || die "open failed: $!"; $to_cert = ;
}

$smime = Crypt::SMIME->new();
$smime->setPrivateKey($privkey, $cert);
$smime->setPublicKey($to_cert);
$tmp = $smime->sign($wiadomosc->as_string);
open(MAIL, "|/usr/sbin/sendmail -t");
print MAIL $smime->encrypt($tmp);
close(MAIL);

No dobra, biblioteka MIME::Lite została tutaj użyta dość osobliwie, bo wcale nie do wysyłania maili, ale jest to najprostszy sposób sformatowania maila przed jego zaszyfrowaniem, na który wpadłem. Poza tym, PERLa właściwie nie znam, a ten kod powyżej to „składanka” z przykładów, które znalazłem gdzieś w Sieci.

Teraz muszę się jeszcze zająć tematem podpisywania samych PDFów. No bo skoro ma być tak super profesjonalnie, to dlaczego nie? :-)

Czego nie wiedziałem o Adaptecu?

24 stycznia, 2012 (09:21) | sprzęt | By: konrad

Dziś znowu będzie kolejny opis przypadku (ang. case study), tym razem o sprzęcie i odzyskiwaniu (dużej ilości) danych.

W jednym z oddziałów jest sobie serwerek, robiący bardzo ważne rzeczy. Do maszyny udało się kiedyś „wepchnąć” siedem dysków SCSI oraz kontroler Adaptec 2130. Dyski podzielone zostały na dwie macierze: RAID-1 (mirror, 2 dyski) na system, oraz RAID-5 na pięciu pozostałych dyskach na dane. Działało to przez ostatnich kilka lat bez żadnych problemów, dokładnie tak samo, jak podobne maszyny w innych miejscach. Niestety, w pewnym momencie urządzenie stwierdziło, że ma dość i postanowiło się zepsuć, dość dziwnie z resztą. Do tej pory widziałem już różne awarie sprzętowe – łącznie z wybuchem backplane’a, który osmalił kilka najbliżej zamontowanych dysków i zaczął niemiłosiernie śmierdzieć. Ale sytuacja, w której kontroler zgubił jednocześnie dwa dyski – a przynajmniej tak twierdził – była dla mnie czymś zupełnie nowym.
Pierwsze, co zrobiliśmy, to otworzenie obudowy i sprawdzenie, czy wszystkie kabelki są na swoich miejscach, czy dyski się kręcą i czy nie ma śladów pożaru. Po dokładnych oględzinach okazało się, że wszystko powinno działać poprawnie. Jednak nie działało.
BIOS kontrolera poprosił o zaakceptowanie „nowej” konfiguracji i bez tego nie chciał współpracować. Dalej było jeszcze gorzej – macierz zniknęła! Poza tym okazało się, że kontroler owszem, widzi wszystkie dyski, ale dwa z nich mają wyjątkowo dziwne wielkości (na poziomie 100MB każdy). Co ciekawe, modele dysków wyświetlane były poprawnie. Wszelkie próby nakłonienia sprzętu do zmiany błędnych wartości (poprzez wybieranie „rescan” we wszelkich możliwych miejscach) nie dały nic. Dopiero „initialize disks” pomogło i dyski zaczęły identyfikować się poprawnie. Ale co z tego, jak macierzy w dalszym ciągu nie było i zapowiadało się żmudne odtwarzanie systemu z kopii zapasowej, która znajdowała się w innej lokalizacji (backup off-site)?
I w tym momencie z pomocą przyszła strona producenta kontrolera. Okazało się, że w przypadku utworzenia nowej macierzy z tego samego zestawu dysków i z tymi samym parametrami, jest szansa na dostęp do znajdujących się tam danych. Szczegóły opisane są na tej stronie. Szczęśliwie poprzednio tworzyliśmy tą macierz w sposób wyjątkowo standardowy, więc nie miałem problemów z „odtworzeniem” parametrów.
Po restarcie okazało się, że faktycznie zawartość macierzy ocalała i mogłem się dostać do danych. Oczywiście pierwsze, co zrobiłem, to skopiowanie tego wszystkiego w inne miejsce, ale cała procedura zaoszczędziła kilkunastu/kilkudziesięciu godzin, które zajęłoby odtwarzanie tego wszystkiego z zewnątrz.

Zepsuty YUM

17 stycznia, 2012 (14:45) | centos, linux | By: admin

Tym razem „case study” z nie-do-końca działającego systemu.

Mamy mało krytyczny serwer, świadczący pewne usługi dla użytkowników. Dopóki działa i robi swoje, nikt się do niego nie dotyka. Ale ostatnio zachciało mi się przejrzeć listę systemów i porobić trochę aktualizacji. Byłem dość mocno zdziwiony, jak po zalogowaniu i wpisaniu „yum clean all”, program zawisł. Dosłownie – nie reagował na nic, poza „kill -9”. Zacząłem przeglądać logi, porównałem konfigurację, wyłączyłem wszystkie pluginy – nadal nic. Następnym krokiem byłoby przeinstalowanie pakietu, ale w tym wypadku było to mało realne (no bo przecież do instalacji potrzebny jest właśnie YUM, który nie działa).
Poszedłem więc odrobinę inną drogą i ściągnąłem sobie ręcznie nową wersję bezpośrednio z repozytorium CentOSa (wget jest jednym z bardziej przydatnych narzędzi w ratowaniu systemu). „rpm -U yum…” i…. wisi!
Okazało się, że uszkodzeniu uległa baza pakietów (a dokładniej, pliki blokad) RPMa. Wystarczyło je usunąć:
rm -f /var/lib/rpm/__db*żeby wszystko wróciło do normy. Warto zapamiętać ;-)

Szyfrowanie w Linuksie

13 stycznia, 2012 (09:44) | centos, linux | By: konrad

Jest sobie zdalne centrum danych, w którym umiejscowione są krytyczne dla działania firmy systemy. A skoro są krytyczne, to robimy z nich backupy, dość często nawet i wyjątkowo regularnie. Niestety, kopie zapasowe są na tyle duże, że problematyczne jest kopiowanie ich przez istniejące łącza, a rozbudowa tych ostatnich tylko dla naszej wygody byłaby zdecydowanym przerostem formy nad treścią (co wcale nie oznacza, że nie robimy backupu „off site”, bo byłoby to dużym niedopatrzeniem i zaburzyło procedury DR).
Potrzebą techniczną jest posiadanie kopii niektórych baz danych, żeby można było w nich grzebać, psuć i niszczyć, a żeby żaden z klientów nie był z tego powodu smutny. Najprostszym rozwiązaniem jest podpięcie dysku USB do maszyny robiącej kopie bezpieczeństwa i przywiezienie takiego dysku (razem z zawartością oczywiście) do biura, gdzie będzie można się nad tym wszystkim znęcać.
Potrzebą biznesową jest za to konieczność zabezpieczenia przewożonych danych w taki sposób, aby potencjalnemu złodziejowi odechciało się walki z tymi zabezpieczeniami. Osobiście uważam to za bardzo rozsądny wymóg, którego warto przestrzegać i który (w skrajnych przypadkach) może w drastyczny sposób ograniczyć straty firmy.

Systemem wykonującym kopie bezpieczeństwa dla wspomnianych przeze mnie systemów jest Linux (konkretnie CentOS w wersji 5). Po przejrzeniu informacji dostępnych w Internecie okazało się, że metod szyfrowania systemów plików nie ma wcale tak dużo. Pierwszym kandydatem był TrueCrypt, którego z powodzeniem używam w wielu innych miejscach (zarówno zawodowo, jak i prywatnie), jednak – z niewiadomych mi przyczyn – był mało stabilny i potrafił wywalić całą maszynę. Znalazłem nawet informację, że problem faktycznie występuje i że zostanie to kiedyś poprawione. Ale potrzebowałem czegoś „na już”, więc zacząłem szukać dalej. Ostatecznie padło na LUKSa. Nie będę się specjalnie rozpisywał, co można za pomocą tego oprogramowania zrobić, bo jest to ładnie opisane na stronie domowej. Ograniczę się jedynie do krótkiej ściągawki, jak wykonać podstawowe czynności.

Załóżmy, że dysk, który chcemy „zaLUKSować” to /dev/sdd1. Podstawowym narzędziem, jakiego będziemy używać to „cryptsetup”.

Sprawdzanie, czy dane urządzenie nie jest już przypadkiem zaszyfrowane:
cryptsetup isLuks /dev/sdd1 2>>/dev/null && echo TAK || echo NIE
Jeżeli poprzednie polecenie dało wynik negatywny (czyli nie jest jeszcze zaszyfrowane), to możemy je „sformatować”:
cryptsetup luksFormat /dev/sdd1
Teraz warto sprawdzić, czy operacja się faktycznie udała i podejrzeć nagłówek LUKSa:
cryptsetup luksDump /dev/sdd1
Nastepnym krokiem jest „otworzenie” zaszyfrowanego urządzenia:
cryptsetup luksOpen /dev/sdd1 bkpPo tej operacji powinno nam się w systemie pojawić nowe urządzenie blokowe, do którego możemy uzyskać dostęp poprzez /dev/mapper/bkp.

Po zamontowaniu możemy sobie obejrzeć jego „stan”:
dmsetup info bkp
Jeżeli wszystko się zgadza (a przynajmniej nie ma żadnych rażących błędów), przystępujemy do tworzenia systemu plików:
mke2fs -j /dev/mapper/bkp

Na koniec wystarczy zamontować system plików w systemie:
mount /dev/mapper/bkp /mnt/usb…i cieszyć możliwością ukrywania naszych ściśle tajnych danych przed światem.

Po zakończeniu zabawy należy oczywiście odpowiednio wszystko pozamykać:
sync
umount /mnt/usb
cryptsetup luksClose bkp

Jak usunąć pliki starsze niż…

12 listopada, 2011 (20:48) | linux, windows | By: konrad

Do napisania tego postu skłoniło mnie pewne wydarzenie…

Kilka lat temu napisałem w VBscripcie prosty skrypt, który kasuje pliki starsze, niż zadana ilość dni. Niby nic wielkiego – tych kilku linijek kodu używam z powodzeniem do dnia dzisiejszego i zawsze działa to tak samo dobrze. Niedawno jeden z moich współpracowników potrzebował zautomatyzować pewien proces i musiał zrobić dokładnie to samo, co mój skrypt. Poszedł jednak zupełnie inną drogą i mój misterny kod został bez litości „zredukowany” do jednej linijki. Jest to doskonały przykład na to, że nie zawsze to, czego używamy od wielu lat jest na pewno najlepsze i najbardziej optymalne.
Na swoje usprawiedliwienie mogę napisać jedynie to, że mój skrypt powstał jako część większej całości i nie zastanawiałem się wtedy, czy istnieje jakieś specjalne polecenie, którym mógłbym wykonać zadaną czynność. Dopisałem po prostu kolejną część w języku, którego akurat używałem.

Mój skrypt, który wygląda tak:Option Explicit
'
' Skrypt kasuje wszystkie pliki z katalogu "path", które są starsze, niż "max_age" dni
'
Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
Dim path : path = "c:\what\ever"
Dim folder : Set folder = FSO.GetFolder(path)
Dim max_age : max_age = 3
Dim file, age
'
For Each file In folder.Files
age = CStr(DateDiff("s", file.DateLastModified, Now))
age = age\(3600*24)
If age > max_age Then
WScript.Echo Now & " - kasuje plik: " & path & "\" & file.Name
FSO.DeleteFile(path & "\" & file.Name)
End If
Next
'
WScript.Quit

został zastąpiony taką oto linijką:forfiles -p "C:\what\ever" -s -m *.* -d -3 -c "cmd /c del @path"

 

 

A co w przypadku Linuksa? Tutaj – szczęśliwie – zawsze używałem konstrukcji, którą chyba dość trudno będzie uprościć:

find /sciezka/do/plikow/* -mtime +10 |xargs rm -rf

Wiem, że można użyć parametru „exec” finda i zapisać powyższe jakoś tak:
find /sciezka/do/plikow/* -mtime +10 -exec rm -rf {} \;
jednak połączenie z xargs wydawało mi się zawsze bardziej „poukładane” :-)

Firewall w ESXi 5.0

10 listopada, 2011 (14:43) | vmware | By: konrad

Mam pod opieką kilka maszynek wirtualizujących opartych o platformę VMware. Nie używam nawet vShpere – po prostu hypervisory zainstalowane na sprzęcie, podpięte do zewnętrznych zasobów dyskowych i już. Wszystkie takie serwery podłączone są do centralnego systemu „nadzorczego”, którego rolę pełni Nagios. Jeżeli chodzi o hypervisory, to tak właściwie ma on niewiele do zrobienia – bada PINGiem, czy host żyje i odpytuje o czas systemowy (ntp) sprawdzając, czy przypadkiem maszyna nie znalazła się w przyszłości.
Do tej pory wszystkie te systemy działały na wersji ESXi 3.5, jednak przyszło mi do głowy, że warto by było spróbować czegoś odrobinę nowszego. I tak pojawił się pierwszy egzemplarz wersji piątej. Po pierwszych testach okazało się, że system jest stabilny, wspiera wszystko, czego używamy i ogólnie wygląda całkiem fajnie. Tylko Nagios go wyraźnie nie polubił, bo ciągle raportował problemy z czasem. Po intensywnym klikaniu we wszystko, co się da (podejście rodem z SAPa :-)) wyszło mi, że za pomocą konsoli ESXi niewiele osiągnę.
Okazało się, że VMware gruntownie przebudował firewalla swojego supervisora i – niestety – nie uwzględnił w standardzie możliwości odpytywania hosta o czas systemowy. Rozwiązanie problemu oczywiście istnieje i nie jest nawet bardzo skomplikowane:

1. Musimy włączyć możliwość logowania się na supervisora za pomocą SSH – robi się to z konsoli systemowej w taki sposób.

2. Logujemy się jako root na naszego hosta (oczywiście za pomocą odblokowanego wcześniej SSH).

3. Tworzymy plik, który będzie opisywał „usługę” odpowiedzialną na serwer NTP na lokalnym hoście i otwierał dla nas port udp/123:cat < /etc/vmware/firewall/ntp.xml
<ConfigRoot>
<service>
<id>NTP server</id>
<rule id='0000'>
<direction>inbound</direction>
<protocol>udp</protocol>
<porttype>dst</porttype>
<port>123</port>
</rule>
</service>
</ConfigRoot>
EOF

4. Musimy teraz przeładować konfigurację zapory:esxcli network firewall refresh

5. W konsoli administracyjnej ESXa powinna nam się pojawić nowa usługa, którą możemy teraz włączyć:

6. Warto jeszcze – tak na wszelki wypadek – sprawdzić, czy serwer NTP jest faktycznie włączony i czy będzie sam startował przy uruchamianiu systemu:~ # /etc/init.d/ntpd status
ntpd is running
~ # chkconfig --list ntpd
ntpd on
~ #

I to wszystko. Jeżeli wszystko się uda, to możemy cieszyć się serwerem czasu na hoście ESXi :-)

Oczywiście sam tego wszystkiego nie wymyśliłem. Skarbnicą wiedzy o hypervisorach ESXi jest ten blog. Opisana tu procedura oparta została o ten wpis.

Jak przesłać dane ze zdalnego systemu?

29 października, 2011 (21:05) | linux | By: konrad

Załóżmy, że mamy system, który stoi sobie na drugim końcu świata (o ile świat ma dwa końce). Dostęp do tegoż systemu mamy wyłącznie przez SSH i żadna inna usługa na nim nie pracuje. Mam wprawdzie uprawnienia administratora, jednak host strzeżony jest przez „wielkiego ogniomura”, który nie pozwala podróżować pakietom innym, niż tym z inicjałami tcp/22 i nie jesteśmy w stanie nic na to poradzić. I chcemy z tego wspaniałego systemu pobrać plik. W sumie nic prostszego:

[kbechler@flame .ssh]$ scp kbechler@lupus:~/lico-update.sh ~
kbechler@lupus's password:
lico-update.sh 100% 19KB 18.9KB/s 00:00
[kbechler@flame .ssh]$

Trudne to jakoś specjalnie nie było.

A teraz spróbujmy zrobić to samo, ale z urządzeniem blokowym (bo chcemy zrobić kopię zapasową odmontowanej partycji):

[kbechler@flame .ssh]$ scp kbechler@lupus:/dev/sda2 ~
kbechler@lupus's password:
scp: /dev/sda2: Permission denied
[kbechler@flame .ssh]$

Hmmm, brakuje nam trochę uprawnień :-\
Ale możemy przecież zrobić tak, aby te uprawnienia uzyskać:

[kbechler@lupus ~]$ sudo chmod 644 /dev/sda2

I co teraz?

[kbechler@flame .ssh]$ scp kbechler@lupus:/dev/sda2 ~
kbechler@lupus's password:
scp: /dev/sda2: not a regular file
[kbechler@flame .ssh]$

Upsss….chyba niewiele to dało. Przywróćmy lepiej poprzednie prawa:
[kbechler@lupus ~]$ sudo chmod 64 /dev/sda2

No dobra, to co możemy zrobić? Ano możemy połączyć siłę SSH z wielce użytecznym narzędziem dd oraz potokami:

[kbechler@flame ~]$ ssh kbechler@lupus "sudo dd if=/dev/sda2" | dd of=~/sda2
kbechler@lupus's password:
4116480+0 records in
4116480+0 records out
2107637760 bytes (2.1 GB) copied, 70.9355 seconds, 29.7 MB/s
4116480+0 records in
4116480+0 records out
2107637760 bytes (2.1 GB) copied, 75.0957 seconds, 28.1 MB/s
[kbechler@flame ~]$

Tadam!

W zależności od tego, co tak naprawdę przesyłamy, możemy do kompletu zaprosić jeszcze jakiś kompresor:

[kbechler@flame ~]$ ssh kbechler@lupus "sudo dd if=/dev/sda2 | bzip2 -9" | bzip2 -d | dd of=~/sda2
kbechler@lupus's password:
4116480+0 records in
4116480+0 records out
2107637760 bytes (2.1 GB) copied, 74.1963 seconds, 28.4 MB/s
ex4116480+0 records in
4116480+0 records out
2107637760 bytes (2.1 GB) copied, 107.966 seconds, 19.5 MB/s
[kbechler@flame ~]$

W sumie tyle :-)

DELL z Allegro

28 października, 2011 (20:02) | sprzęt | By: konrad

Ostatnie kilka miesięcy w moim miejscu pracy przyniosło wiele nieoczekiwanych projektów. Przez pewien czas realizowaliśmy wszystko bez większych problemów, jednak w pewnym momencie natknęliśmy się na dość poważną przeszkodę – posiadany przez nas park maszynowy przestał się wyrabiać. Pomimo dość sporej, jak na dotychczasowe potrzeby, mocy, każde kolejne przedsięwzięcie coraz trudnej było upchnąć w istniejących zasobach. A ponieważ sprawy budżetowania czegokolwiek dla IT to bardzo smutny element mojej pracy, to wszelkie pomysły wymiany obecnego sprzętu lub zakupu nowiutkich maszynek bardzo szybko wylądowały w koszu. Trzeba było jednak coś wykombinować i w tym momencie przyszedł mi do głowy pewien pomysł – przecież nie muszę mieć bardzo szybkich maszyn, o ile będzie ich wystarczająco dużo :-) I tak zacząłem buszować po Allegro w poszukiwaniu jakiejś małej i w miarę taniej platformy, na której moglibyśmy testować wszystkie pomysły, nie zużywając zasobów infrastruktury produkcyjnej. Ostatecznie wszedłem w posiadanie drogą kupną DELLa PowerEdge 1950 z dwoma Xeonami za oszałamiającą kwotę 2070 PLN brutto. I tak się zaczęło – dzięki „nowej strategii zakupowej” udało nam się powymieniać większość naprawdę leciwych maszyn (których lata świetności i ważność gwarancji dawno już minęła) i dokupić trochę zabawek, co pozwoliło na zrównoważenie coraz większego zapotrzebowanie na zasoby. Jasne, że oszczędzanie w taki sposób nie zawsze jest opłacalne/możliwe – dla systemów strategicznych nadal podstawową zasadą jest zakup nowych elementów z rozszerzoną gwarancją. Jednak do testów lub dla systemów, których dłuższa (nawet kilkudniowa) niedostępność nie jest dużym problemem, nie zawsze warto kupować nowych maszyn, które kosztują często 3-4 razy więcej, niż te poleasingowe.
Pokuszę się jeszcze o malutką reklamę. Wszelkie „prawie nowe” DELLe kupuję w jednym miejscu i jestem wyjątkowo zadowolonym (no dobra, marudnym także) klientem. Nie dość, że ceny są bardzo konkurencyjne, to jeszcze sprzęt, który dostaję jest dokładnie taki, jakiego potrzebuję. Chcę drugi procesor? Nie ma sprawy – da się zrobić. Potrzebuję więcej ramek do dysków, mniej pamięci i 6 sieciówek? Nic prostszego – wystarczy wysłać maila z opisem. „Naprawdę polecam tego allegrowicza” :-)))

Jak włamać się do SAPa :-)

5 sierpnia, 2011 (21:27) | sap | By: konrad

Jakiś czas temu pisałem, jak można „odblokować” użytkownika SAP grzebiąc bezpośrednio w bazie. Pomimo, że jest to sposób dość wygodny i bardzo przydatny, to SAP ma dość ciekawą (i czasami bardzo przydatną cechę). Okazuje się, że użytkownik SAP* jest na tyle specjalny, że istnieje nawet wtedy, kiedy nie ma właściwego dla siebie wpisu w samym systemie. Innymi słowy – da się „na niego” zalogować nawet w sytuacji, w której tabela USR02 nie zawiera rekordu opisującego użytkownika o tej nazwie. Fajne, no nie?
Ale do rzeczy – jeżeli mamy fizyczny dostęp do bazy danych, a nie jesteśmy w stanie dostać się do samego SAPa, to możemy po prostu usunąć z tabeli USR02 wpis dla użytkownika SAP* i zalogować się na używając hasła „PASS”. Z jednym, czasami dość istotnym zastrzeżeniem – wartość parametru login/no_automatic_user_sapstar musi być równa zero. Jeżeli tak nie jest, to niestety opisana przeze mnie sztuczka nie zadziała.

Identyfikacja podatności

3 sierpnia, 2011 (21:58) | centos, linux | By: konrad

Praca „informatyka” nie składa się wyłącznie z klikania i pisania na klawiaturze. Czasami trzeba wyjrzeć zza monitora i zmierzyć się ze światem. A na świecie (przynajmniej tym mnie otaczającym) żyją ludzie zwani audytorami. W szczególności często spotykaną przeze mnie odmianą tych ostatnich są audytorzy z zakresu szeroko rozumianego IT. Są i mnie męczą. Czemu właściwie nie ma się co specjalnie dziwić – w końcu ktoś im za to męczenie mojej skromnej osoby płaci. A dlaczego mnie męczą? Ano dlatego, że chcą informacji. Niekoniecznie zależy im na tym, żeby te informacje były w 100% zgodne z rzeczywistością, ale muszą coś do swoich sprawozdań wpisać. I tu zaczyna się lekki kłopot. O ile o strukturze swojej sieci, procedurach dostępu do danych, mechanizmach tworzenia kopii zapasowych mogę powiedzieć dużo, to z raportami testów identyfikacji podatności (ang. vulnerability scan) do tej pory było u mnie dość kiepsko. No bo niby audyty są bardzo ważne i wszyscy o tym doskonale wiedzą, ale jakoś nikt nie chciał wydać worka pieniędzy na oprogramowanie do przeprowadzania odpowiednich skanów. Tak było do tej pory…

Ponieważ kilka dni temu zostałem po raz kolejny wymęczony (tym razem za pomocą ankiety) przez audyt, postanowiłem przyjrzeć się sytuacji na rynku skanerów bezpieczeństwa i spróbować coś u siebie w firmie wdrożyć. Do tej pory najlepiej pracowało mi się z Nessusem i od niego zacząłem. Program wygląda naprawdę fajnie (z ciekawości przetestowałem sobie nawet bezpłatną wersję „dla domu”) i jest jednym z najbardziej popularnych skanerów. Ma tylko jedną wadę – cena usługi ProfessionalFeed wynosi 1.200 USD rocznie. I nawet pomimo tego, że według mnie Nessus wart jest tych pieniędzy, to jestem dziwnie spokojny, że nie byłoby łatwo przeforsować takiego wydatku. Kolejnym strzałem była Retina. Produkt równie dojrzały i uznany, co Nessus, to i cena dość podobna. Co dalej? Kiedyś był SATAN, ale znalazłem tylko coś, co nazywało się SARA i nie jest już rozwijane. Kolejną witryną, jaką odwiedziłem była strona domowa projektu SAINT. Niestety, w tym przypadku nie znalazłem nawet konkretnej ceny interesującego mnie produktu. Na tym etapie działania wiedziałem, że mam do wybory trzy produkty, z czego jeden znam, lubię i jest prawdopodobnie najtańszy. Ale to jeszcze nie koniec…

OpenVAS logoNie wiem skąd się tam wziąłem, ale w pewnym momencie moim oczom ukazała się strona domowa projektu OpenVAS. O ile udało mi się zorientować, jest to fork Nessusa, który rozpowszechniany jest na licencji GNU. Składa się z kilku współpracujących ze sobą modułów i zestawu testów, które stanowią o sile tego rozwiązania. Co ciekawe, same testy (Network Vulnerability Tests) napisane są w języku NASL opracowanym dla Nessua – kolejna rzecz, która mi się spodobała. Postanowiłem zainstalować OpenVASa na jakiejś maszynie i zobaczyć, ile to cudo jest warte. W CentOSie 5.6 instalacja przebiegła bez problemu i po niedługim czasie miałem gotowe rozwiązanie do skanowania swoich zasobów…

Na razie jestem z odkrycia bardzo zadowolony i w wolnych chwilach staram się tego w jakiś sensowny sposób użyć. Pomimo pewnej „toporności” interfejsu (używam Greenbone Security Assistant), wydaje mi się, że zaprzyjaźnię się z OpenVASem na dłużej. Ciekawe tylko, co powiedzą audytorzy, jak zobaczą raporty utworzone w jakimś abstrakcyjnym systemie, który nie jest „ogólnie uznany przez środowisko” :-)