WebScarab jest narzędziem wykorzystywanym często przy testach aplikacji webowych (internetowych). Narzędzie jest dobre, ale ma jedną, podstawową wadę, zostało napisane w języku Java. W zasadzie aplikacja powinna nazywać się WebMule, bo demon szybkości to nie jest. Jednym z jego problemów jest szybkie zjadanie pamięci. Aplikacja dostaje domyślnie 64MiB do swojej dyspozycji i w niektórych sytuacjach jest to po prostu za mało. Co prawda można wymusić uruchomienie Garbage Collector, ale to nie wystarcza. W związku z tym przydatne może być zwiększenie pamięci dostępnej dla WebScaraba. A wykonać to można prosto, w parametrach wywołania java za pomocą opcji -Xmx . Przykładowo -Xmx128M daje 128MiB pamięci do dyspozycji.
Używam różnych systemów operacyjnych. Na stacjach roboczych głównie Windows XP, na serwerach Windows 2003, ale nie stronię również od Linuksa (głównie moje ulubione Gentoo) czy OpenBSD. Na desktopie nigdy nie mogłem się jednak do Linuksa przekonać, próbowałem różnych dystrybucji, ostatnio Ubuntu, przez krótki czas zainstalowanego BackTrack, ale to jakoś nie do końca mnie przekonywało. Ostatnio poświęciłem nieco czasu na zainstalowanie Gentoo na laptopie z KDE (jakoś KDE mnie bardziej pociąga niż Gnome, przynajmniej na chwilę obecną). Cóż, mam wrażenie, że system działa sprawniej niż Ubuntu, ale wszystko jeszcze przede mną... Może w końcu się do Linuksa na desktopie przekonam... Może...
Z uwagi na problemy, które występowały w poprzedniej konfiguracji IPSec, nieco zmieniłem konfigurację po stronie OpenBSD. Obecnie wykorzystuję isakmpd nie tylko do negocjacji kluczy, ale również do zestawiania tuneli.
Zamieniłem wcześniej opisywane IMQ na IFB. Działa to chyba lepiej, nie mam efektu zawieszenia maszyny w przypadku, gdy przez “interfejs” idzie ruch generowany lokalnie. IMQ przemawiało do mnie nieco bardziej z tego powodu, że ruch do “urządzenia” można było kierować przez reguły iptables, w przypadku IFB ruch należy kierować przez filtry tc z pakietu iproute, a ich składni nie lubię jakoś specjalnie. Na chwilę obecną filtr wygląda mniej więcej tak:
tc filter add dev eth0 parent 1: protocol ip prio 10 \
u32 match ip dst 0.0.0.0/0 flowid 1:1 \
action mirred egress redirect dev ifb1
Na interfejsie ifb1 mam normalne kolejki, które wcześniej miałem na interfejsie fizycznym (jak od strony wewnętrznej był tylko jeden). A jak to mniej więcej mam zorganizowane, przedstawiłem tutaj.
Oryginał tego wpisu dostępny jest pod adresem IFB zamiast IMQ
WEP jest słaby, to wie (prawie) każdy. Przez długi czas nie miałem możliwości pobawić się w łamanie WEP we własnym zakresie, w końcu się to zmieniło. Korzystając z mojego starego laptopa, BackTrack w mgnieniu oka udało mi się złamać (sprawdzone było tylko 56 kluczy!) klucz, który wykorzystuję u siebie w sieci. To tylko potwierdza, że moje uporczywe zabawy z zestawieniem tunelu IPSec między OpenBSD i laptopem, nie były bezcelowe. A o tym jak w chwili obecnej mam skonfigurowany IPSec po stronie OpenBSD opiszę niebawem. Konfiguracja różni się nieco od początkowej, ale za to nie mam uporczywych problemów, które opisywałem choćby tu, a spowodowane były prawdopodobnie zjawiskiem opisywanym tutaj.
Oryginał tego wpisu dostępny jest pod adresem Łamanie WEPa
Ponieważ w ramach kombinacji moja lokalna sieć się nieco rozbudowała i moja maszynka, która robi kształtowanie ruchu dorobiła się trzeciej karty sieciowej, potrzebowałem czegoś do kształtowania ruchu na grupie interfejsów. Coś takiego oferuje IMQ. Działa to nawet dość dobrze, no może poza jednym fragmentem z FAQ:
It seems to be pretty stable, a lot of people are using it without problems. There is one case which is not entirely clear at this time, enqueueing packets going to a gre tunnel and also enqueueing the encapsulated packets to the same imq device results in the kernel assuming the gre device to be deadlooped.
Another thing to note is that touching localy generated traffic may cause problems.
...cóż, wygląda na to, że rzeczywiście próba wpuszczenia w IMQ lokalnego ruchu w końcu powoduje problemy (chyba kernel panic, ale nie chciało mi się podłączać monitora, by to zweryfikować. Przykre jest to, że według innego FAQ problem jest znany i już we wrześniu 2005 roku trwały prace nad jego usunięciem, najwyraźniej wciąż bez sukcesu. Na razie nie pozostaje mi nic innego jak upewnienie się, że do IMQ idzie jedynie ruch inny niż lokalnie wygenerowany przez tę maszynę. A jak dalej będzie się wieszać, to przełożę tę kartę sieciową do drugiej maszyny i nieco przerobię swoją siec :)
Dostałem dzisiaj linka od osoby, o której wiem, że o godzinie, kiedy link ten został do mnie wysłany, nie siedziała przy komputerze, a więc na pewno tego linka mi nie wysłała. No więc do dzieła...
Wyobraźmy sobie taką sytuację – do firmy przyjmowana jest nowa osoba. Ta osoba będzie miała konta w kilku systemach. Hasła do tych kont trzeba jakoś przekazać. W firmie tej wdrożony jest system IdM, a wraz z nim wspominany już przeze mnie moduł do zarządzania hasłami. Za jego pomocą osoba może ustawić sobie hasło do swoich kont. Tylko jak przekazać hasło (a i login też) do modułu zarządzania hasłami?
Systemy Identity Management stają się w chwili obecnej coraz powszechniejsze. Wynika to z faktu, że ręczne wykonywanie operacji w coraz to większych i bardziej złożonych systemach informatycznych staje się po prostu niemożliwe. Wszystko przekłada się na pieniądze, mniej osób trzeba zatrudniać do obsługi całego systemu, zmiany wykonywane są szybciej, mniej jest błędów, coraz więcej rzeczy dzieje się po prostu automatycznie. Wszystko przyczynia się do zmniejszenia ilości telefonów do HelpDesk... Ale pozostaje jeszcze jedna zmora, hasła. Dlatego też w ramach wdrożenia systemu IdM często wdraża się również moduł wspomagający w tym zakresie użytkowników. Może to być witryna, w za pomocą której pracownicy mogą sobie zmienić hasła do swoich kont w dowolnym systemie. Tylko oczywiście do tej witryny trzeba się uwierzytelnić i tu pojawia się problem, co zrobić, gdy właśnie TO hasło zostanie zapomniane...