Nie taki błąd straszny, jak go malują.

Dziś przeczytałem wpis na Niebezpieczniku o backdoorze w switchach. I z jednej strony ewidentny fail, a z drugiej błąd niezupełnie (czy też: nie tylko) tu leży…

  • Jaki administrator zostawia dostęp po SNMP włączony (niestety, sporo administratorów nie widzi w tym nic złego, zwłaszcza jeśli tylko RO jest)?
  • Jaki producent sprzętu ma w defaulcie włączone SNMP (niestety, wielu vendorów domyślnie włącza SNMP z domyślnymi community)?
  • Kto daje nieograniczony dostęp ze świata do klasy zarządzania swoich urządzeń?
  • Poznanie MAC mimo wszystko nie jest trywialne. Trzeba mieć dostęp albo po warstwie drugiej (ew. do odczytu tablicy ARP urządzenia, które ma dostęp po L2 do switcha), albo do wspomnianego SNMP.

Jasne, ludzie się mylą. Jasne, kwestię hasła serwisowego (padło pytanie, czy inne sprzęty mają coś takiego – chyba każdy sprzęt sieciowy ma możliwość przynajmniej resetu hasła przy podłączeniu się RSem, sporo ma hasła serwisowe – mam nadzieję, że tylko po RS dostępne). Jasne, taki zdalny backdoor nie powinien mieć miejsca. Ale czy to naprawdę dramat?

PS. Dziś spotkałem się z opinią (na szczęście od nikogo ode mnie z firmy), że trzymanie dokumentów firmy (nie najtajniejsze tajemnice, ale nie dane dostępne na publicznym WWW) na Google Docs to nic złego. W porównaniu z tym backdoor w switchu, którego można zneutralizować/zminimalizować to IMO pikuś.

Dziwny problem z Javą i siecią w Debianie.

Z programów napisanych w Javie korzystam raczej rzadko (wyjątkiem jest bloxer2, którym od dłuższego czasu wrzucam tu wpisy), więc nie zauważyłem tego wcześniej. Debian w wersji Squeeze, Java z repozytorium (wersja 6.20-dlj-1).

Jedna ze stron nie mogła załadować appletu i rzucała:

load: class VncViewer.class not found
[różności] 
Caused by: java.net.ConnectException: Network is unreachable

Ta sama aplikacja nie działała wcześniej na samodzielnie robionej Javie od Sun, z kolei działała (i nadal działa) na różnych wersjach Javy w Debianie Lenny. Na szczęście coś mi świtało, że ogólnie jest problem z IPv6 w Javie, szybkie gógiel potwierdził, więc pozostało znalezienie, co trzeba zmienić. Dobrzy ludzie z IRCa pomogli (!java ipv6), więc przybliżę rozwiązanie.

Winne jest zmienione domyślne ustawienie dla IPv6 w Debianie Squeeze. Okazuje się, że błąd jest zgłoszony, a działanie sieci pod Javą przywraca (tzn. w części aplikacji, niektóre działają bez problemu) ustawienie w pliku /etc/sysctl.d/bindv6only.conf:

net.ipv6.bindv6only = 0

Blokada portu 25 w Dialogu.

„Trochę” przespałem, a tymczasem Dialog poszedł w ślady TPSA, jeśli chodzi o blokowanie spamu wychodzącego z sieci.

Jak Dialog podaje w informacji prasowej, od dnia 18 maja rozpoczęli blokadę portu 25, służącego do wysłki pocztyspamu. Z tego co wiem, informacje do abonentów zostały wysłane w kwietniu, więc widać, że powoli firmy przestają podchodzić do tego działania superostrożnie i zaczynają po prostu wychodzić z założenia, że „informujemy i wyłączamy”. Nie ma co ukrywać, TPSA zrobiła dużo dobrego swoją odważną (ale też przemyślaną i bardzo starannie zaplanowaną) akcją.

Jeśli chodzi o większych polskich darmowych dostawców usług pocztowych, to i WP i Onet pozwalają na korzystanie z szyfrownia przy logowaniu do poczty, więc niezależnie od dostawcy warto zmienić ustawienia progrmu pocztowego tak, aby korzystać z szyfrowania. Nowy Thunderbird AKA Icedove nawet przy podaniu adresu email z WP lub Onetu sam sugeruje ustawienia z włączonym szyfrowaniem.

Ci, którzy nie mogą korzystać z szyfrownia, powinni zmienić sposób wysyłki poczty (TPSA postarała się bardziej niż Dialog z ilością instrukcji, dlatego linkuję do nich).

Jeśli chodzi o sposób usunięcia blokady, to – w przeciwieństwie do TPSA – użytkownik nie może sam odblokować portu 25, ale także w Dialogu taka możliwość istnieje. Aby odblokować port 25 w Dialogu należy skontaktować się z Dialogiem np. za pośrednictwem infolinii.