robert_cz

blokując logowanie na roota zyskujemy jeszcze jedną zmienną, nazwę użytkownika, która tego typu ataki utrudni.

Jedno z możliwych wyjaśnień tego, co się mogło stać: http://niebezpiecznik.pl/post/opis-grupy-atakujacej-ssh/ W związku z powyższym mocno zalecam, by osoby wystawiające odbiorniki "na świat" zrezygnowały z haseł które wydają im się że są bezpieczne i wygenerowały coś solidnego. Choćby przy pomocy http://www.dobrehaslo.pl/ sam tą stronę stosuje, wybierając "preset" dla paranoików, wyłączając znaki specjalne, a także zmieniając "małe litery" oraz "cyfry" na "małe litery i cyfry bez i,l,o,0,1". I oczywiście paranoicznie zmieniam jeszcze u siebie wygenerowany ciąg, przestawiając fragmenty tego co strona wypluła. Odpukać żaden z odbiorników, na których zastosowałem tego kalibru hasła nie został zainfekowany, a administruje nimi przez net już przeszło pół roku. Osobna sprawa, że każdy z nich inny zestaw dodatków niż @robert_cz. Potwierdzam, padłem ofiarą tegoo właśnie ataku. Co Wy na to żeby jednak zablokować roota w ssh? Zwiększyło by to odpornośna ten właśnie rodzaj ataku.

to może zmiana domyślnej konfiguracji żaby po trzecim złym haśle dawało bana na 15 min.? albo rezygnacja z roota ("PermitRootLogin no") do ssh i zrobienie osobnego użytkownika np. graterlia z prawami root-a do logowania przez ssh właśnie? Może domyślne: MaxSessions Specifies the maximum number of open sessions permitted per net- work connection. The default is 10. zredukować do 3, moim zdaniem spokojnie wystarczy, MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6. To można by też zmniejszyć do 3 np. MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6. takie moje propozycje.

Zmieniam to ale chwilę to potrwa. Ale to by potwierdzało, że chodzi o OpenSSH i tam jest jakiś błąd.

też tak mi się wydaje, i zastanawia mnie jaki był wektor ataku, mógłbyś napisać, jakie dodatkowe wtyczki miałeś zainstalowane, może będzie się dało porównać z poprzednim takim przypadkiem, też zgłoszonym na forum, o ile Twój poprzednik o tym napisał. Wszędzie klasycznie: iptv + epgimport + mc i nic więcej Nie wiem, może zbieg okoliczności, ale te dziwne pliki znalazłem tylko tam gdzie ssh maiłem na porcie 22, około 6 szt., a wszędzie tam gdzie było na innym porcie, około 4 szt. plików nie było.

Wycięte z wątku Lista błędów w GOS, bo to nie błąd w GOS. Nie wiem co jest, ale z aktualną wersją openssh - 6.7.p1-4 na domyślnym porcie mam co chwilę nowe pliki uruchomieniowe w folderze: /root i /bin np. /bin/ahsnfueirm /root/8005 /root/a06 etc. Virustotal mówi, że to coś takiego: https://www.virustotal.com/cs/file/64eee462375810e00d0b262523a53ee405b274f29451f85cb1f9bcd1497b1f33/analysis/ ahsnfueirm.zip

Po modyfikacji: << 08 Kwiecień 2015 >> [test] dodanie brakującego modułu bpamem.ko dla ADB5800xx; wszystko pięknie działa, wątek, moim zdaniem, do zamknięcia.

Hej, j00zek, te zmiany, to w release, czy test? Jedno bardzo teoretyczne pytanie, czy nasze boxy mają możliwość sprawdzania czy sprzętowo został podłączony kabel z urządzeniem po drugiej stronie?

Ten kawałek: case "$1" in start) start_info [ -f /var/run/ifstate ] && rm -f /var/run/ifstate doopt spoofprotect yes doopt syncookies no doopt ip_forward no echo -n "Configuring network interfaces... " wpa_supplicantcheck ifup -a echo "done." ;; popraw na: case "$1" in start) start_info [ -f /var/run/ifstate ] && rm -f /var/run/ifstate doopt spoofprotect yes doopt syncookies no doopt ip_forward no echo -n "Configuring network interfaces... " wpa_supplicantcheck ifconfig eth0 up sleep 3 ifup -a echo "done." ;;

Ja się szybko nie obrażam. :-) Przyznaję, że z poprzednią sprawą gst nie miałem racji i się do tego przyznałem, ale za to z np. skryptem uruchamiającym inadyn miałem rację i jeszcze w kilku przypadkach. Czasami po prostu łatwiej się uczyć na błędach, a najłatwiej na własnych. :-) A jak odpowiedzi szukam, a jej nie dostaję, to szukam dalej, czasem okazuje się, że rozwiązanie jest w innym miejscu niż podejrzewałem na początku, tak było np. z gst. A proszę sprawdźcie jak to jest u Was, po którym zapytaniu o DHCP dostajecie odpowiedź? Bo ja właśnie zmieniłem na model TD-W8951ND i rzeczywiście działa i wyrabia się w ostatnich sekundach po trzecim zapytaniu, chwilkę przed timeout Czy tak powinno być? Raczej nie bez powodu było to sleep 3, widocznie innym też tak robiło i ktoś wyliczył, że średnio to będą 3 s na uzyskanie linka. Mam nadzieje, że Wy też się nie obrazicie, ale nie huczy, bo istnieją alternatywy do Graterli i jak komuś nie zadziała dhcp, to wrzuca inną dystrybucję i z głowy. [Aktualizacja] okazuje się, po kilku testach, że sleep 3 jest jednak konieczne, bo tyle trwa link po stronie boxa, a nie routera. Bardzo bym prosił o tą drobną poprawkę w skrypcie /etc/init.d/network przed ifup -a ifconfig eth0 up sleep 3 z nią po prostu w 100% działa, było tak w Graterli do wersji skryptów co najmniej graterlia-scripts - 0.1.24, a nie było tego już na pewno od wersji graterlia-scripts - 0.1.41, a może wcześniej. Nie mam pośrednich wersji. [Aktualizacja2] A może żeby nie trzeba było czekać te 3 sekundy dać by "ifconfig eth0 up" gdzieś we wcześniejszym skrypcie przed network. Widziałem, że przy Arivie jest podobny problem z DHCP y zgłaszał go już ktoś.

A masz możliwość zobaczenia konsoli i tego ile jest zapytań DHCP?

No to bez restart przywróćmy: ifconfig eth0 up sleep 3 tux, ja Cie rozumiem, ale zrozum też pozostałe 70-80% posiadających sieć ze średniej półki, a nie z najwyższej jak u Was. A zapytam z ciekawości, na które zapytanie odpowiada Wasz sprzęt i po jakim czasie podnosi się interface?

Panowie, ja wiem, że jesteście perfekcjonistami i korzystacie ze sprzętu z górnych parametrów standardów ethernet, ale nie zapominajcie, proszę, że z 70% sieci domowych zbudowana jest za sprzętów z parametrami z środka standardów ethernet. Nie wydaje się Wam, że fakt "wysyłania w powietrze", przed podniesieniem interface, zapytań DHCP, raczej nie jest standardowym zachowaniem Nie odbierzcie tego źle, ale u konkurencji działa dhcp w 100%. Może błąd jest w nowej wersji busybox, że ifup -a przed uruchomieniem udhcp nie sprawdza, czy interface już jest up. (wykreślam, jednak busybox to nie ten trop) Popatrzę jak to było w starszych wersjach graterli, bo coś mi się wydaje, że w którejś z poprzednich było OK. [Aktualizacja] na poniższej wersji DHCP działa w 100%: Graterlia OS 2.1.0 *** 03.03.2014... *** BusyBox v1.21.1 Start network Reconfiguring network interfaces... ifdown: interface lo not configured ifdown: interface eth0 not configured udhcpc (v1.21.1) started Sending discover... Sending select for 192.168.1.108... Lease of 192.168.1.108 obtained, lease time 259200 route: SIOCDELRT: No such process adding dns 192.168.1.1 I w tej wersji w rcS było: echo "Start network" if [ $vfd == on ]; then # Ustawinienie i aładowanie obsługi sieci echo "Network init" > /dev/vfd else echo "nEt" > /dev/vfd fi sleep 1 if [ -e /etc/network/interfaces ]; then ifconfig eth0 up sleep 3 if [ -e /lib/modules/rt3070sta.ko ]; then insmod /lib/modules/rt3070sta.ko ifconfig ra0 up echo "rt3070 driver loaded" fi if [ -e /lib/modules/rt5370sta.ko ]; then insmod /lib/modules/rt5370sta.ko ifconfig ra0 up echo "rt5370 driver loaded" fi /etc/init.d/networking restart Wydaje mi się, że kluczowe było: ifconfig eth0 up sleep 3 [Aktualizacja2] Jeszcze w wersji Graterlia OS 2.1.1 było OK z graterlia-scripts - 0.1.24

sprawdziłem, network uogólniając robi ifup -a jeśl dobrze pamiętam + wyświetlanie o tym fakcie na wyświtlaczu. A co konkretnie masz na myśli żebym sprawdził?

tux, wygląda, że ten problem istnieje nie tylko u mnie i może zniechęcać mniej zaawansowanych. Moim zdaniem dodanie iplink set eth0 up gdzieś przed skryptem network rozwiązuje problem.

Ale Tux, okazało się, że moja hipoteza z tym, że to wina routera po sprawdzeniu za pomocą snifera pakietów, jest nierawdziwa. Winny jest box, który jeszcze przed fizycznym podniesieniem portu wysyła w poowietrze zapytania DHCP. stąd problem z timeout, bo czasem przez interfacee nie zdąży wyjść ani jedno zapytanie. Nie wiem gdzie leży przyczyna, czy ifup powinno poczeekać przed wysyłaniem zapytań o DHCP na podniesinie interface, ale wim, jak to załatać. Co Wy na to?

To ja proponuje dodanie link gdzieś we wcześniejszych skryptach, albo w skrypcie uruchamiania sieci i pause 2s.

Sprawdziłem i lampka, czyli "link" nie pojawia się na etapie u-boota, a powinien? Macie jakieś uboty do BSxA na których tak jest?

Z udhcpc_opts wycofuję się, bo jak sam zauważyłeś: "# automatically generated by enigma 2" Co do mojego drugiego pomysłu, to na 100% potwierdzony za pomocą huba i Wresharka, żebym miał dump całej transmisji po ethernet i jak się da samo ifup-a, to zanim "zapali się światełko", to już idą zapytania o dhcp. Idą 3, a z racji opóźnienia w podnoszeniu interface wireshark (czyli faktycznie wychodzi przez interface sieciowy tunera) widzi tylko jedno, lub wcale, zapytanie, na które jeśli wyjdzie router odpowiada. Spotkało mnie to już na 4 różnych routerach, więc problem wygląda na powtarzający się.

Ponownie proszę o darowanie mi postu pod postem, ale mam rozwiązanie. Po dodaniu do pliku "interfaces ostatniej linii dla eth0: udhcpc_opts -t 5 -T 5 # automatically generated by enigma 2 # do NOT change manually! auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp udhcpc_opts -t 5 -T 5 domyślnie jest tak: -t,--retries N Send up to N discover packets (default 3) -T,--timeout SEC Pause between packets (default 3) Można by nawet pomyśleć o: -b,--background Background if lease is not obtained jeszcze to posprawdzam, ale powinno wtedy działać w tle i pobrać IP jak się podłączy kabel już po uruchomieniu boxa. Mam inny pomysł, pytanie co na to tux. Po kilku testach z wiresharkiem zobaczyłem, że problemem nie są opóźnienia, tylko, że zapytania o dhcp zaczynają wychodzić przed fizycznym podniesieniem interface eth0 i dlatego serwer DHCP nie ma szansy odpowiedzieć przed timeout. Mój pomysł, to zmiana kosmetyczna w skrypcie network, przed ifup -a dać podniesienie if: iplink set eth0 up i pause 3s Można prosić o aktualizację w wersji base? Proszę nie pisać posta pod własnym postem!

Nie wiem, cokolwiek zmienię w tym pliku, to system podczas startu i tak to ignoruje, nawet popsułem tą linijkę i nic, dalej się odpala. To musi być gdzieś indziej wywoływane przy starcie i tam muszą być opcje.

Liczę na wybaczenie moderatorów. Wpis pod wpisem, żeby było widać, że uzupełniłem coś: Więc tak, podłączyłem kabel konsolowy i wynik taki: 1) start na zimno, hard reset: Start network Setting up IP spoofing protection: rp_filter. Configuring network interfaces... showSinglePic /boot/logo_.mvi VIDEO_SELECT_SOURCE MEMORY (Success) VIDEO_PLAY (Success) VIDEO_CONTINUE: (Success) VIDEO_CLEAR_BUFFER: (Invalid argument) udhcpc (v1.22.1) started Sending discover... Sending discover... Sending select for 192.168.1.12... Lease of 192.168.1.12 obtained, lease time 259200 route: SIOCDELRT: No such process adding dns 192.168.1.1 done. 2) soft reset: Start network Setting up IP spoofing protection: rp_filter. Configuring network interfaces... showSinglePic /boot/logo_.mvi VIDEO_SELECT_SOURCE MEMORY (Success) VIDEO_PLAY (Success) VIDEO_CONTINUE: (Success) VIDEO_CLEAR_BUFFER: (Invalid argument) udhcpc (v1.22.1) started Sending discover... Sending discover... Sending discover... failed... No lease, failing done. Teraz pytanie, wie ktoś jak zwiększyć czas przed timeout? Bo wygląda, że to timeout jest problemem.

Taki mi się zdarza problem z DHCP na BSxA. Radzę sobie z nim, ale postanowiłem się jednak podzielić. Podejrzewam, że chodzi o "wolniejsze" serwery DHCP na starszych routerach. Nie pobierają adresu IP z routera, pewnie jakiś timeout i wystarczy restart sieci i natychmiast pojawia się połączenie. Przy stałym IP tego nie mam. Jak mówicie, jak podłączę soie kabel konsolowy, to coś ciekawego zobaczę? PS. Tux, istniałaby opcja dla fanatyków przewijających się komunikatów z konsoli włączyć zamiast tapety uruchamiania klasyczne wyjście komunikatów z konsoli, a dopiero jak się enigma włączy żeby przejmowała kontrolę? Fajna opcja by był dla grzebaczy wszelakich :-)

Wstępnie myślałem nie o zmniejszeniu funkcjonalności, tylko o wydzieleniu obsługi DVD do osobnej opcjonalnej paczki, ale za słaby do tego jestem. ;-(

Słabo: /usr/bin/enigma2: error while loading shared libraries: libdvdnav.so.4: cannot open shared object file: No such file or directory /usr/bin/enigma2: error while loading shared libraries: libdvdread.so.4: cannot open shared object file: No such file or directory /usr/bin/enigma2: error while loading shared libraries: libdreamdvd.so.0: cannot open shared object file: No such file or directory Chyba to temat dla jakiegoś programisty jednak :-(