W moim laptopie ProBook 4320s firma HP zamontowała ClickPad (często mylony z ToutchPad) firmy Synaptics. W systemie Linux występuje problem z poprawnym działaniem prawego przycisku. Ostatnio rozwiązałem ten problem.
Mój system to Debian Wheezy oraz X.Org X Server 1.11.4.
Jeżeli nie mamy jeszcze pliku xorg.conf to należy go sobie wygenerować. W sekcji ServerLayout nic nie zmieniamy, dodajemy tylko nową InputClass.
Section "InputClass"
Identifier "Touchpad"
MatchIsTouchpad "yes"
Driver "synaptics"
Option "MinSpeed" "0.5"
Option "MaxSpeed" "1.0"
Option "AccelFactor" "0.050"
Option "TapButton1" "1"
Option "TapButton2" "2"
Option "TapButton3" "3"
Option "VertTwoFingerScroll" "1"
Option "HorizTwoFingerScroll" "1"
Option "VertEdgeScroll" "1"
Option "CoastingSpeed" "8"
Option "CornerCoasting" "1"
Option "CircularScrolling" "1"
Option "CircScrollTrigger" "7"
Option "EdgeMotionUseAlways" "1"
Option "LBCornerButton" "1" # LButton
Option "RBCornerButton" "3" # Rbutton
Option "EmulateTwoFingerMinZ" "35"
Option "EmulateTwoFingerMinW" "8"
EndSection
Pogrubiona linia rozwiązuje cały problem - w prawym dolnym rogu znajduje się prawy (3) przycisk. Przed edycją xorg.conf można jeszcze przetestować działanie tej opcji za pomocą polecenia synclient.
Wednesday, March 21, 2012
Monday, February 27, 2012
Ochrona phpMyAdmin (i nie tylko) przez ips_outline.py
Ostatnio w logach serwera apache zauważyłem częste próby odgadnięcia ścieżki, pod którą znajduje się phpMyAdmin. Postanowiłem przyjrzeć się problemowi i skonfigurować swój prosty system IPS do reagowania na takie incydenty.
Podczas analizy tego typu zdarzeń zauważyłem faktyczną potrzebę rozszerzenia możliwości mojego skryptu o obsługę wyrażeń regularnych, a dokładnie chodzi o współpracę z AWK.
Tak mogą wyglądać przykładowe logi świadczące o ataku:
Problem z opisaniem takich logów do postaci zaimplementowanej w skrypcie ips_outline.py[1][2] polega na tym, że można tam podać maksymalnie trzy podciągi identyfikujące wpis do logu. W powyższych przykładach cechą wspólną jest zwracany kod serwera HTTP "
Myśląc o selektywnym wyszukiwaniu danych w logach od razu na myśl przychodzi mi najlepsze narzędzie do tego stworzone, czyli AWK. W przyszłości mam zamiar zmodyfikować mój skrypt, tak aby potrafił współpracować z tym językiem, dlaczego? Najlepszą odpowiedzią na te pytanie będzie opis jak poradziłem sobie z tymi incydentami oraz jakie są minusy takiego rozwiązania.
Pierwszą rzeczą jaką musimy zrobić to napisanie kodu AWK, który ujednolici przedstawione logi do takiej postaci, aby ips_outline.py nie miał z nim problemów. Wystarczy nam jeden ciąg identyfikujący, adres IP do zablokowania i wyszukiwana ścieżka. W systemie Debian używany jest MAWK[4] ale nic nie stoki na przeszkodzie, aby czerpać z dokumentacji GAWK[5] zwłaszcza jeżeli przedstawione przykłady są dla Ciebie niezrozumiałe.
Zanim jednak napiszemy taki kod prosty przykład. Jeżeli mamy frazę "
kod zadziała, ale dla "
teraz jest ok.
Mój kod AWK, który wybiera złe adresy wygląda następująco:
Wyniki (o ile istnieją w access.log) będą miały postać:
Sprawdzenie rekordu źródłowego:
Twoje logi mogą mieć inny format!
Kod AWK wybiera linie/rekordy, które:
- w kolumnie 9 obowiązkowo mają wartość "404" (podciąg również będzie dopasowany!)
- w kolumnie 7 wystąpi podciąg "admin" lub "my" lub "php", niezależnie od wielkości znaków
- podciąg "php" nie może być poprzedzony kropką (wyłączenie błędów 404 z np. "index.php")
następnie drukuje "block", IP i ścieżkę.
Teraz sprawdzony kod AWK możemy wrzucić w skrypt i korzystając z możliwości pisania do /dev/ips wysyłać tam jego wyjście. Proponuje w katalogu domowym /root założyć skrypt webcheck.sh:
Zawartość skryptu wyglądałaby następująco:
Ostatecznie dodajemy wpis do crona:
Skrypt będzie uruchamiany co minutę i będzie wysyłał wyprodukowane wpisy przez AWK do /dev/ips, skąd pobierze je i przeanalizuje ips_outline.py. Czas więc powiedzieć dla ips_outline.py czego ma szukać. Do rule.ips dodajemy regułę:
Składnię reguł opisywałem w ostatnim wpisie o ips_outline.py.
Reguła:
- nazywa się "web phpmyadmin"
- szuka rekordów zawierających ciąg "block"
- pobiera z niej adres IP znajdujący się po ciągu "block" i między znakami spacji: " "[IP]" "
- wstawia regułę blokującą z użyciem adresu IP w miejscu "param" ("1" po regule)
- uaktywnia wstawienie reguły przy drugim wystąpieniu pasującego rekordu
- ustawia czas, w którym ma wystąpić (w tym przypadku dwukrotne) dopasowanie na jedną minutę.
Jeżeli chodzi o czas jednej minuty to jego znaczenie nie ma większego wpływu w tym przypadku, chyba że chcemy "łapać" logi między dwoma wywołaniami skryptu webcheck.sh. Wtedy należy ustawić go na 2 minuty. W przeciwnym razie ips_outline.py i tak otrzyma wszystkie logi w pierwszej sekundzie minuty, a kolejne w pierwszej sekundzie kolejnej minuty.
Pozostało już tylko zresetować skrypt:
Skrypt działa poprawnie i zaczął blokować ale przyjrzyjmy się dokładnie jak wygląda blokowanie.
Dziś w nocy ok. godz. 1 miał miejsce atak, skrypt zablokował go i wysłał do mnie e-maila o treść:
Podczas analizy tego typu zdarzeń zauważyłem faktyczną potrzebę rozszerzenia możliwości mojego skryptu o obsługę wyrażeń regularnych, a dokładnie chodzi o współpracę z AWK.
Tak mogą wyglądać przykładowe logi świadczące o ataku:
60.174.109.133 - - [25/Feb/2012:01:32:41 +0100] "GET //phpmyadmin/ HTTP/1.1" 404 182 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:41 +0100] "GET //phpMyAdmin/ HTTP/1.1" 404 183 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:42 +0100] "GET //myadmin/ HTTP/1.1" 404 180 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:43 +0100] "GET //MyAdmin/ HTTP/1.1" 404 181 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:44 +0100] "GET //admin/ HTTP/1.1" 404 178 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:44 +0100] "GET //Admin/ HTTP/1.1" 404 179 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:46 +0100] "GET //PMA/ HTTP/1.1" 404 178 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:46 +0100] "GET //PMA/ HTTP/1.1" 404 178 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:46 +0100] "GET //phpadmin/ HTTP/1.1" 404 181 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:47 +0100] "GET //mysqladmin/ HTTP/1.1" 404 183 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:48 +0100] "GET //mysql/ HTTP/1.1" 404 179 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:48 +0100] "GET //sqladmin/ HTTP/1.1" 404 181 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:49 +0100] "GET //sql/ HTTP/1.1" 404 177 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:50 +0100] "GET //webadmin/ HTTP/1.1" 404 181 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:50 +0100] "GET //db/ HTTP/1.1" 404 176 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:51 +0100] "GET //dbadmin/ HTTP/1.1" 404 180 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:52 +0100] "GET //mysqldb/ HTTP/1.1" 404 180 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:53 +0100] "GET //webdb/ HTTP/1.1" 404 178 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:53 +0100] "GET //sqlmanager/ HTTP/1.1" 404 183 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:54 +0100] "GET //mysqlmanager/ HTTP/1.1" 404 184 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:55 +0100] "GET //phpmanager/ HTTP/1.1" 404 182 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:55 +0100] "GET //pmadb/ HTTP/1.1" 404 178 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:56 +0100] "GET //admin/phpmyadmin/ HTTP/1.1" 404 184 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:57 +0100] "GET //admin/phpMyAdmin/ HTTP/1.1" 404 186 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:57 +0100] "GET //admin/mysql/ HTTP/1.1" 404 183 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:58 +0100] "GET //admin/pma/ HTTP/1.1" 404 182 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:59 +0100] "GET //mysq/phpmyadmin/ HTTP/1.1" 404 186 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:59 +0100] "GET //phpMyAdmin-3.3.10.2/ HTTP/1.1" 404 190 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:32:59 +0100] "GET //phpMyAdmin-3.3.10.2/ HTTP/1.1" 404 190 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:33:00 +0100] "GET //phpMyAdmin-3.4.2.1/ HTTP/1.1" 404 190 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:33:00 +0100] "GET //phpMyAdmin-3.4.2.1/ HTTP/1.1" 404 190 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:33:02 +0100] "GET //phpmyadmin2/ HTTP/1.1" 404 183 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:33:03 +0100] "GET //PHPMYADMIN/ HTTP/1.1" 404 183 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:33:03 +0100] "GET //phpMyAdmin-2.8.1/ HTTP/1.1" 404 190 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:33:03 +0100] "GET //phpMyAdmin-2.8.1/ HTTP/1.1" 404 190 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:33:04 +0100] "GET //phpMyAdmin-2.8.0.2/ HTTP/1.1" 404 191 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro" 60.174.109.133 - - [25/Feb/2012:01:33:04 +0100] "GET //phpMyAdmin-2.8.0.2/ HTTP/1.1" 404 191 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro"
Problem z opisaniem takich logów do postaci zaimplementowanej w skrypcie ips_outline.py[1][2] polega na tym, że można tam podać maksymalnie trzy podciągi identyfikujące wpis do logu. W powyższych przykładach cechą wspólną jest zwracany kod serwera HTTP "
404" oraz wystąpienia ciągów "php", "admin", "my" w adresie. Sprawa komplikuje się o tyle, że mogą te ciągi występować zarówno w małych, jak i dużych znakach np. "Admin" i "admin", a nawet "ADMIN". Poza tym wcale nie muszą występować razem np. "phpadmin", "MyAdmin", "Admin". Ciąg "404" występuje zawsze ale równie dobrze morze być częścią nazwy pliku, np. zdjęć z aparatu "DSC 04041". Trzeba więc szukać go w określonej kolumnie, a obecnie ips_outline.py nie potrafi wyszukiwać tak selektywnie. Skrypt można pobrać ze strony projektu[3].Myśląc o selektywnym wyszukiwaniu danych w logach od razu na myśl przychodzi mi najlepsze narzędzie do tego stworzone, czyli AWK. W przyszłości mam zamiar zmodyfikować mój skrypt, tak aby potrafił współpracować z tym językiem, dlaczego? Najlepszą odpowiedzią na te pytanie będzie opis jak poradziłem sobie z tymi incydentami oraz jakie są minusy takiego rozwiązania.
Pierwszą rzeczą jaką musimy zrobić to napisanie kodu AWK, który ujednolici przedstawione logi do takiej postaci, aby ips_outline.py nie miał z nim problemów. Wystarczy nam jeden ciąg identyfikujący, adres IP do zablokowania i wyszukiwana ścieżka. W systemie Debian używany jest MAWK[4] ale nic nie stoki na przeszkodzie, aby czerpać z dokumentacji GAWK[5] zwłaszcza jeżeli przedstawione przykłady są dla Ciebie niezrozumiałe.
Zanim jednak napiszemy taki kod prosty przykład. Jeżeli mamy frazę "
my"echo my | awk '{if($0 ~ /my/) print "ok"}'kod zadziała, ale dla "
My", "MY" już nie, dlatego:echo wmYs| awk '{if($0 ~ /[Mm][Yy]/) print "ok"}'teraz jest ok.
Mój kod AWK, który wybiera złe adresy wygląda następująco:
awk '{if ( ($9 == "404") && (($7 ~ /[Aa][Dd][Mm][Ii][Nn]/)||($7 ~ /[Mm][Yy]/)||($7 ~ /[^.][Pp][Hh][Pp]/)) ) print "block "$1" "$7 }' /var/log/apache2/access.logWyniki (o ile istnieją w access.log) będą miały postać:
block 207.171.3.132 //admin/index.phpSprawdzenie rekordu źródłowego:
grep "//admin/index.php" /var/log/apache2/access.log207.171.3.132 - - [27/Feb/2012:01:03:39 +0100] "GET //admin/index.php HTTP/1.1" 404 185 "-" "-"Twoje logi mogą mieć inny format!
Kod AWK wybiera linie/rekordy, które:
- w kolumnie 9 obowiązkowo mają wartość "404" (podciąg również będzie dopasowany!)
- w kolumnie 7 wystąpi podciąg "admin" lub "my" lub "php", niezależnie od wielkości znaków
- podciąg "php" nie może być poprzedzony kropką (wyłączenie błędów 404 z np. "index.php")
następnie drukuje "block", IP i ścieżkę.
Teraz sprawdzony kod AWK możemy wrzucić w skrypt i korzystając z możliwości pisania do /dev/ips wysyłać tam jego wyjście. Proponuje w katalogu domowym /root założyć skrypt webcheck.sh:
touch webcheck.sh
ls -l webcheck.sh
-rw------- 1 root root 0 02-25 17:57 webcheck.sh
chmod u+x webcheck.sh
vim webcheck.sh
Zawartość skryptu wyglądałaby następująco:
#!/bin/sh
awk '{if ( ($9 == "404") && (($7 ~ /[Aa][Dd][Mm][Ii][Nn]/)||($7 ~ /[Mm][Yy]/)||($7 ~ /[^.][Pp][Hh][Pp]/)) ) print "block "$1" "$7 }' /var/log/apache2/access.log >> /dev/ips
Ostatecznie dodajemy wpis do crona:
crontab -e
* * * * * /root/webcheck.sh > /dev/null
Skrypt będzie uruchamiany co minutę i będzie wysyłał wyprodukowane wpisy przez AWK do /dev/ips, skąd pobierze je i przeanalizuje ips_outline.py. Czas więc powiedzieć dla ips_outline.py czego ma szukać. Do rule.ips dodajemy regułę:
web phpmyadmin;;block,NULL,NULL;;block, , ;;iptables -I INPUT 3 -s param -j DROP;1;2;00:01:00Składnię reguł opisywałem w ostatnim wpisie o ips_outline.py.
Reguła:
- nazywa się "web phpmyadmin"
- szuka rekordów zawierających ciąg "block"
- pobiera z niej adres IP znajdujący się po ciągu "block" i między znakami spacji: " "[IP]" "
- wstawia regułę blokującą z użyciem adresu IP w miejscu "param" ("1" po regule)
- uaktywnia wstawienie reguły przy drugim wystąpieniu pasującego rekordu
- ustawia czas, w którym ma wystąpić (w tym przypadku dwukrotne) dopasowanie na jedną minutę.
Jeżeli chodzi o czas jednej minuty to jego znaczenie nie ma większego wpływu w tym przypadku, chyba że chcemy "łapać" logi między dwoma wywołaniami skryptu webcheck.sh. Wtedy należy ustawić go na 2 minuty. W przeciwnym razie ips_outline.py i tak otrzyma wszystkie logi w pierwszej sekundzie minuty, a kolejne w pierwszej sekundzie kolejnej minuty.
Pozostało już tylko zresetować skrypt:
echo stop >> /dev/ips
/root/ips_outline.py > /dev/null &
Skrypt działa poprawnie i zaczął blokować ale przyjrzyjmy się dokładnie jak wygląda blokowanie.
Dziś w nocy ok. godz. 1 miał miejsce atak, skrypt zablokował go i wysłał do mnie e-maila o treść:
IPS 2012.2.27 1:4:1 web phpmyadmin: iptables -I INPUT 3 -s 207.171.3.132 -j DROP n=2 ip=207.171.3.132 [timeline: 0:0:0 in time 00:01:00]
Jak widać timeline to 0:0:0, czyli wszystko dzieje się w jednej sekundzie z jego punktu widzenia. Dzieje się tak ponieważ dostaje logi raz na minutę. Właśnie, co minutę a co dzieje się podczas tej minuty?. Zobaczmy.
Jak widać wszystkie próby miały miejsce w ciągu niespełna minuty, więc skrypt jeszcze nie mógł zareagować bo czekał na logi od AWK uruchamianego co minutę.
Ostatni atak przed zablokowaniem miał miejsce o 01:03:53, ale do tej poty bot zdążył wykonać 78 prób. Następnie sprawdzam ile razy próbował po zablokowaniu, hy zabawne również 78. Można więc powiedzieć, że ta metoda działa ale w tym wypadku zapobiegła połowie prób ataku.
Oczywiście i tak to jest bardzo dobry wynik, ponieważ załóżmy, że mechanizm ten zablokowałby tylko ostatnią próbę, albo nawet wcześniej bot odgadłby ścieżkę do phpMyAdmin, to ile zdążyłby zrobić w ciągu niespełna pozostałej minuty? Chyba niewiele.
Mimo wszystko ten przypadek zainspirował mnie do rozbudowania ips_outline.py o możliwość wyszukiwania ciągów za pomocą AWK, tak aby mógł blokować od razu nawet takie przypadki.
Oh, oczywiście, nie wiem czemu wspominam o tym na sam koniec ;) ale najlepszą ochronę dla phpMyAdmin jest używanie reguł Order Deny,Allow w konfiguracji apache, co zresztą praktykuje.
Tuesday, January 31, 2012
Nagrania z linux.conf.au (LCA) 2012
Oto najciekawsze nagrania (moim zdaniem), które udostępniono na kanale YouTube.
Raport z prac nad jądrem w poprzednim roku 2011.
Prezentacja możliwości systemu plików btrfs.
Raport z prac nad jądrem w poprzednim roku 2011.
Prezentacja możliwości systemu plików btrfs.
Wednesday, January 25, 2012
Anonymous wzywają polskich członków do zaprzestania ataków DDoS
To nie codzienne wydarzenie, gdy sami anonimowi wzywają do zaprzestania ataków na serwery. Oto ich apel:
"Ataki na strony polskich władz MUSZĄ zostać zaprzestane
--------------------------------------------------------
Mówiliśmy to już wcześniej i powiemy jeszcze raz. Ataki na strony zarówno Polskiego rządu jak i Unii Europejskiej nie pomagają w walce z ACTA. Jesteśmy w stałym kontakcie z polskimi organizacjami pozarządowymi które poinformowały nas o tym, że ataki niszczą ponad trzy lata ich trudnej współpracy z rządem w tworzeniu prawodawstwa odpowiednio odnoszącego się do internetu i chroniącego podstawowe wolności internautów oraz możliwości negocjacji wstrzymania podpisu Polski pod ACTA. Jeśli potrzebujecie kolejnych dowodów przeczytajcie słowa wygłoszone przez Polskiego premiera Donalda Tuska:
- Nie ustąpimy w żadnym wypadku wobec szantażu - oświadczył premier, odnosząc się do ataków na niektóre strony internetowe administracji państwowej. Szef rządu zapewnił, że jak na razie nie możemy mówić o zagrożeniach dla funkcjonowania państwa. - Nie wyobrażam sobie, aby polski rząd, polski parlament, polski premier ustępował przed kimś, kto mówi: "nie podpisuj, bo inaczej opublikujemy kompromitujące dane o twoich urzędnikach". Tego typu metody uważam za niedopuszczalne - powiedział Tusk.
Poinformował, że sprawdzane są zabezpieczenia stron, które zostały lub mogą zostać zaatakowane. Dodał, że jak na razie nie możemy powiedzieć o zagrożeniu dla funkcjonowania państwa ze względu na ataki na strony internetowe. Według niego są one raczej dokuczliwe i skuteczne propagandowo. - Nie ma żadnego powodu, żeby wzniecać alarm - uspokajał premier.
http://wiadomosci.gazeta.pl/wiadomosci/1,114884,11024567,Tusk__Dalem_upowaznienia_ambasador__by_podpisala_ACTA.html
Ataki DDOS zwróciły uwagę świata na toczącą się sprawę podpisania ACTA przez Polskę. Teraz tydiące Polaków wyszły na ulicę po to by manifestować swój przeciw. Nadszedł czas by pozwolić działać procesom politycznym i społecznym skierowanym przeciwko ACTA. Wszelkie ataki na strony polskiego rządu jak i Unii Europejskiej powinny zostać wstrzymane. Strony te służą przecież komunikacji krajowych i unijnych władz ze społeczeństwem. Jeśli lubisz DDOSować dla samego DDOSowania prosimy wybierz zamiast tego stronę swojej szkoły/uczelni.
Anonymous"
http://pastebin.com/1mDAceCF
Monday, January 9, 2012
Samba - monitorowanie dostępu do plików
Gdy udostępniasz ważne dane przez dysk/udział sieciowy przydatnym może okazać się monitorowanie operacji wykonywanych na nich. Mówiąc krótko, chodzi o wyjaśnienie rzekomych okoliczności, w których pliki "zniknęły". Oczywiście odzyskasz je z kopii ale niesmak niewyjaśnionych okoliczność pozostanie. Dlatego zdecydowałem się na logowanie dostępu do zasobów sieciowych Samby.
Do tego celu należy użyć modułu vfs_full_audit. Przedstawię przykładową konfigurację, które loguje udane otwarcie, usunięcie oraz tworzenie katalogów. Operacji jest bardzo dużo, pełna lista dostępna w opisie modułu.
Wpis dla konkretnego udziału:
[...]
...
vfs objects = full_audit recycle
full_audit:prefix = %I|%m|%u
full_audit:success = open unlink rmdir write rename
full_audit:failure = none
full_audit:facility = LOCAL7
full_audit:priority = NOTICE
Do tego celu należy użyć modułu vfs_full_audit. Przedstawię przykładową konfigurację, które loguje udane otwarcie, usunięcie oraz tworzenie katalogów. Operacji jest bardzo dużo, pełna lista dostępna w opisie modułu.
Wpis dla konkretnego udziału:
[...]
...
vfs objects = full_audit recycle
full_audit:prefix = %I|%m|%u
full_audit:success = open unlink rmdir write rename
full_audit:failure = none
full_audit:facility = LOCAL7
full_audit:priority = NOTICE
Moduł nie loguje operacji nie udanych, oczywiście można to zmienić. Dwie ostatnie opcji mówią z jakim priorytetem ma traktować serwer logów te wpisy. Działania na plikach zapisywane są w /var/log/syslog, przynajmniej w systemie Debian. Przykładowy wpis wygląda mniej więcej tak:
Jan 9 08:38:20 prv smbd[25400]: 192.168.1.2|admin-laptop|admin|open|ok|r|gdata/doc/plan0911/SP0911x13+.xlsx
Jan 9 08:38:20 prv smbd[25400]: 192.168.1.2|admin-laptop|admin|open|ok|w|gdata/doc/plan0911/SP0911x13+.xlsx
Jan 9 08:44:10 prv smbd[25400]: 192.168.1.2|admin-laptop|admin|unlink|ok|gdata/doc/plan0911/~$SP0911x13+.xlsx
Tu widzimy jakie operacje zostały wykonane na pliku, został otwarty i usunięto (unlink) plik tymczasowy, oczywiście został on wcześniej utworzony i to również zostało odnotowane. Z bardziej przydatnych operacji należałoby wymienić write (zapis), i rename (zmiana nazwy) na wypadek jakby zagubiony katalog po prostu uzyskał inną nazwę przez innego użytkownika.
W opcji full_audit:prefix wymieniłem jakie dane identyfikujące wykonawcę tych operacji chcę znać, pełną listę możliwych informacji można znaleźć w smb.conf (5) - sekcja "VARIABLE SUBSTITUTIONS"
Ponadto dla wpisu vfs objects oprócz wartości full_audit wpisałem również recycle. Moduł recycle dodaje dodatkową funkcjonalność, dla każdego udziału, który go zawiera tworzy katalog .recycle i przenosi tam pliki usuwane. Dzięki temu możemy odzyskać pliki usunięte w ciągu tego samego dnia, których nie ma jeszcze w kopii przyrostowej.
Oczywiście należy pamiętać, że nie wszystkie udziały mogą być warte przechowywania usuniętych plików (kopie zapasowe również będą je zawierać i zajmować więcej miejsca) oraz logowania wszystkich zdarzeń. Mi na razie wystarczą te trze, czyli dostęp do pliku (otworzył, usuną) oraz tworzenie katalogów.
Wednesday, December 28, 2011
Podsumowanie roku przez Google
Już coroczny przegląd statystyk wyszukiwania i tego co się wydarzyło w mijającym roku 2011.
Więcej na www.googlezeitgeist.com
Jest też podsumowanie tego co oglądano najczęściej na YouTube.
Więcej na www.googlezeitgeist.com
Jest też podsumowanie tego co oglądano najczęściej na YouTube.
Lista najczęściej oglądanych dostępna na:
Monday, December 26, 2011
Konfiguracja maszyny wirtualnej na KVM
KVM jest coraz atrakcyjniejszym rozwiązaniem oferującym wirtualizację, do tego jest standardowo w jadrze systemu Linux, więc nic nie musimy dodatkowo instalować.
Do pełnej wirtualizacji lepiej nadają się systemy uniksowe, jeżeli chcesz wirtualizować systemy z rodziny Windows niezbędne będzie użycie sterowników parawirtualizowanych dla systemu Wondows jako gościa.
Dlatego KVM świetnie nadaje się do wyrtualizacji serwerów Linux. Jeżeli chcesz postawić serwer WWW w bezpiecznym środowisku, czy zbudować wirtualną sieć z serwerami Linux, KVM jest świetnym rozwiązaniem.
W końcu, co najważniejsze, to zanosi się na to, że KVM ma szansę stać się w najbliższej przyszłości numerem 1 wśród rozwiązań wirtualizacyjnych dla platformy Linux. Więcej informacji na ten temat można znaleźć na stronie Open Virtualization Alliance oraz na stronie projektu www.linux-kvm.org.
Przedstawię w jaki sposób używać KVM. Ponieważ używam dystrybucji Debian, będzie to sposób konfiguracji charakterystyczny dla tego systemu, tzw. "Denian's way". Co prawda określenie to odnosi się głównie do konfiguracji sieci, ale może również kojarzyć się z nieużywaniem specjalnych narzędzi tworzonych przez Red Hat, takich jak Virsh.
Pierwsze co musimy przygotować to wirtualne karty sieciowe dla naszych gości. Do tego trzeba zbudować most, tworzący wirtualny przełącznik, którego co najmniej jeden port będzie rzeczywistym interfejsem sieciowym. Dzięki niemu będziemy przekazywać połączenia między siecią wirtualną a rzeczywistą. Oczywiście sposobów konfiguracji może być wiele, my zakładamy, że host gości będzie miał połączenie z internetem.
Do stworzenia mostu musimy mieć zainstalowaną paczkę bridge-utils, chyba że w naszym systemie dostępne jest już polecenie brctl. Sam most będziemy tworzyć poprzez modyfikację pliku /etc/network/interfaces, a nie brctl.
Natomiast do stworzenia wirtualnych interfejsów, które mamy zamiar później dołączyć do mostu
być może potrzebna jeszcze będzie paczkę vtun, jeżeli jeszcze jej nie mamy. Po instalacji tej paczki należy ręcznie zamontować jej moduł: modprobe tun. W przyszłości system podczas startu załaduje go sam. Do zarządzania tymi interfejsami będzie nam jeszcze potrzebne narzędzie tunctl, które zawiera paczka uml-utilities.
Teraz możemy już przystąpić do konfiguracji interfejsów, więc odpalamy w vim'e plik /etc/network/interfaces i z przykładowej konfiguracji:
Teraz należy zresetować sieć skryptem /etc/init.d/networking i sprawdzić czy istnieją wszystkie interfejsy tap (polecenie ifconfig) oraz czy poprawnie został stworzony most i dodane do niego interfejsy. Dla konfiguracji, którą przedstawiłem wynik polecenia brctl show powinien być następujący:
Do pełnej wirtualizacji lepiej nadają się systemy uniksowe, jeżeli chcesz wirtualizować systemy z rodziny Windows niezbędne będzie użycie sterowników parawirtualizowanych dla systemu Wondows jako gościa.
Dlatego KVM świetnie nadaje się do wyrtualizacji serwerów Linux. Jeżeli chcesz postawić serwer WWW w bezpiecznym środowisku, czy zbudować wirtualną sieć z serwerami Linux, KVM jest świetnym rozwiązaniem.
W końcu, co najważniejsze, to zanosi się na to, że KVM ma szansę stać się w najbliższej przyszłości numerem 1 wśród rozwiązań wirtualizacyjnych dla platformy Linux. Więcej informacji na ten temat można znaleźć na stronie Open Virtualization Alliance oraz na stronie projektu www.linux-kvm.org.
Przedstawię w jaki sposób używać KVM. Ponieważ używam dystrybucji Debian, będzie to sposób konfiguracji charakterystyczny dla tego systemu, tzw. "Denian's way". Co prawda określenie to odnosi się głównie do konfiguracji sieci, ale może również kojarzyć się z nieużywaniem specjalnych narzędzi tworzonych przez Red Hat, takich jak Virsh.
Pierwsze co musimy przygotować to wirtualne karty sieciowe dla naszych gości. Do tego trzeba zbudować most, tworzący wirtualny przełącznik, którego co najmniej jeden port będzie rzeczywistym interfejsem sieciowym. Dzięki niemu będziemy przekazywać połączenia między siecią wirtualną a rzeczywistą. Oczywiście sposobów konfiguracji może być wiele, my zakładamy, że host gości będzie miał połączenie z internetem.
Do stworzenia mostu musimy mieć zainstalowaną paczkę bridge-utils, chyba że w naszym systemie dostępne jest już polecenie brctl. Sam most będziemy tworzyć poprzez modyfikację pliku /etc/network/interfaces, a nie brctl.
Natomiast do stworzenia wirtualnych interfejsów, które mamy zamiar później dołączyć do mostu
być może potrzebna jeszcze będzie paczkę vtun, jeżeli jeszcze jej nie mamy. Po instalacji tej paczki należy ręcznie zamontować jej moduł: modprobe tun. W przyszłości system podczas startu załaduje go sam. Do zarządzania tymi interfejsami będzie nam jeszcze potrzebne narzędzie tunctl, które zawiera paczka uml-utilities.
Teraz możemy już przystąpić do konfiguracji interfejsów, więc odpalamy w vim'e plik /etc/network/interfaces i z przykładowej konfiguracji:
auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet dhcp
auto eth0tworzymy coś takiego:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet manual
# RouterOS
iface tap0 inet manual
pre-up tunctl -b -u grzesiek
pre-up ifconfig tap0 up
post-down tunctl -d tap0
# Fedora 16
iface tap1 inet manual
pre-up tunctl -u grzesiek -t tap1
pre-up ifconfig tap1 up
post-down tunctl -d tap1
# CentOS 6
iface tap2 inet manual
pre-up tunctl -u grzesiek -t tap2
pre-up ifconfig tap2 up
post-down tunctl -d tap2
# CentOS 6 x86_64
iface tap3 inet manual
pre-up tunctl -u grzesiek -t tap3
pre-up ifconfig tap3 up
post-down tunctl -d tap3
iface br0 inet static
address 10.0.0.1
netmask 255.255.255.0
gateway 172.16.16.101
broadcast 10.0.0.255
network 10.0.0.0
bridge_ports eth0 tap0 tap1 tap2 tap3
bridge_maxwait 0
bridge_stp off
bridge_fd 0
auto eth0To moja przykładowa konfiguracja na laptopie. Zmieniamy konfigurację eth0 na manual, natomiast całą konfiguracje wpisujemy dla br0, naszego nowego mostu. Jak widzimy do tego mostu należą eth0, tap0, tap1, tap2, tap3. Każdy interfejs tapX jest oddzielny dla każdego hosta, w ich konfiguracji należy zmienić nazwę użytkownika, z jakim prawami jest tworzony nowy interfejs. W moim przypadku jest to "grzesiek".
auto tap0
auto tap1
auto tap2
auto tap3
auto br0
Teraz należy zresetować sieć skryptem /etc/init.d/networking i sprawdzić czy istnieją wszystkie interfejsy tap (polecenie ifconfig) oraz czy poprawnie został stworzony most i dodane do niego interfejsy. Dla konfiguracji, którą przedstawiłem wynik polecenia brctl show powinien być następujący:
Teraz możemy sobie wybrać jakąś lokalizacje na przechowywanie obrazów i stworzyć obraz przykładowym poleceniem: qemu-img create -f raw routeros.raw 800M.
bridge name bridge id STP enabled interfaces
br0 8000.72a5b61e39bf no eth0
tap0
tap1
tap2
tap3
To polecenie stworzy obraz dysku o nazwie routeros.raw i rozmiarze 800 MB.
Następnie dla wygody tworzymy skrypt, który skonfiguruję zaporę dla wirtualnych hostów, aby przekazywać im połączenie internetowe:
#!/bin/sh
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -d 0/0 -j MASQUERADE
Nie zapomnij włączyć przekazywania pakietów, odkomentuj linię net.ipv4.ip_forward=1 w pliku /etc/sysctl.conf i wydaj polecenie sysctl -p. Reguły te przekazują połączenie przez interfejs bezprzewodowy do sieci wirtualnej. Możemy dla wygody zapisać ten skrypt pod nazwą network.sh w katalogu, w którym będziemy przechowywać obrazy wirtualnych hostów i uruchamiać przed korzystaniem z nich. Oczywiście można dodać go do /etc/rc.local aby system robił to automatycznie.
Kolejnym krokiem jest stworzenie skryptu dla każdego hosta, tu przykładowy dla RouterOS:
#!/bin/sh
# -boot d z cdrom
kvm -hda /virt/routeros.raw -cdrom /virt/iso/mikrotik-5.8.iso -boot c -m 256 -net nic,macaddr=DE:AD:BE:EF:24:13 -net tap,ifname=tap0 -enable-kvm -smp 1 -daemonize & #-nographic
Skrypt zapisujemy pod nazwą routeros.sh i za jego pomocą uruchamiamy wirtualny host. Watro wyjaśnić znaczenie poszczególnych opcji:
-hda - wskazuje na dysk host
-cdrom - wskazuje na obraz płyty w wirtualnym napędzie
-boot - decyduje o kolejności botowania, c oznacz dysk z opcji -hda, z oznacz obraz z -cdrom
-m - ilość pamięci przeznaczonej dla hosta
-net nic,macaddr - definiuje adres MAC interfejsu hosta
-net tap,ifname - wskazuje wirtualny interfejs przeznaczony dla danego hosta
-smp - ilość rdzeni przeznaczony dla hosta
-daemonize - uruchamia hosta w trybie demona, nie wyświetla jego terminalu w bieżącym, dzięki temu host może pracować jako serwer i nie blokować terinala
-nographic - nakazuje nie wyświetlać okna z monitorem hosta
Jeżeli pierwszy raz uruchamiamy hosta z pustym dyskiem i chcemy zainstalować system z obrazu to opcję -boot ustawiamy na d, po instalacji na c. gdy już skonfigurujemy ustawiania sieci w hoście i uzyskamy dostęp zdalny możemy użyć opcji -nographic, aby nie wyświetlał się zbędny ekran serwera.
Gdyby maszyna wirtualna się nie uruchomiła należy sprawdzić, czy mamy załadowane moduły kvm oraz dla procesorów Intel kvm_intel, a dla AMD kvm_amd. Oczywiście jeżeli procesor wspiera wirtualizację wszystko powinno działać bez zarzutu.
Subscribe to:
Posts (Atom)