kafi

Masz wyraźnie napisane, że problem jest w HELO. Ustaw poprawnie hostname i zadbaj o poprawność revdns.

Zatem zasadnicze pytanie - czy chcesz mieć merytoryczne forum ze społecznością je rozkręcającą, czy też chcesz mieć miljon użytkowników po to, aby mieć wyższą cenę na allegro? Jeśli to 1) to raczej tych mogących to forum rozwijać będzie śmieszyć owy alert i nie będą się łaskawie prosić aby poczytać. Jeśli 2) to w sumie w pełni wpasowujące się w trend stron tu podawanych. A w sumie szkoda, bo graficznie skórka mi się nawet podoba.

Nie dziwne jest dla was to, że input policy jest ustawione na drop, a ataki przychodzą na port 22 na którym nic nie ma, no więc rozpoczyna się zabawa w connection tracking? Przecież w teorii w takiej konfiguracji jakiekolwiek pakiety (czy to SYN, czy SYN/ACK czy inne) powinny być z automatu dropowane. Jeśli nadal występuje problem to IMO nic innego nie pozostaje jak zewnętrzny firewall, bo to sam system nie wyrabia się.

Nie oszukujmy się. Ważne jest tylko dla promila paranoidalnych klientów bojących się sniffera w swojej sieci... Co wcale nie znaczy, że podejście polegające na braku szyfrowanego kanału transmisji dla m.in. owych delikwentów nie jest godne potępienia.

Pewnie standardowo jak to w Cisco - boot w rommon, zmiana confreg na taki pomijający ładowanie konfiguracji z nvram, potem reload, przejście do trybu uprzywilejowanego, copy startup-config running-config, zmiana hasła, copy running-config startup-config, przywrócenie confreg i restart.

Olej gugl. Użyj OpenStreetMap

Plik konfiguracyjny usługi SSH możesz edytorać poprzez directadminowy File Editor. http://twojserwer.pl:2222/CMD_ADMIN_FILE_EDITOR?file=%2Fetc%2Fssh%2Fsshd_config

To założenie jest błędne. W menedżerze jest link POMOC a w nim w ramce informacja, jak owa struktura katalogów powinna wyglądać: Jeśli wykona się wszystko zgodnie z instrukcją to jak najbardziej działa. Hint: C:\Users\Konrad>dir /s C:\data Wolumin w stacji C nie ma etykiety. Numer seryjny woluminu: 30D9-8A9D Katalog: C:\data 2013-01-02 13:47 <DIR> . 2013-01-02 13:47 <DIR> .. 2013-01-02 13:47 <DIR> LocalUser 0 plik(ów) 0 bajtów Katalog: C:\data\LocalUser 2013-01-02 13:47 <DIR> . 2013-01-02 13:47 <DIR> .. 2013-01-02 13:32 <DIR> kowalski 2013-01-02 13:33 <DIR> nowak 0 plik(ów) 0 bajtów

1) W menedżerze IIS przy tworzeniu nowego serwisu FTP masz opcję WŁĄCZ NAZWY HOSTA WIRTUALNEGO. Z tym, że szczerze mówiąc nie testowałem jej kompatybilności z klientami FTP. 2) W menedżerze IIS w konfiguracji poszczególnych serwisów FTP masz pozycję IZOLACJA UŻYTKOWNIKÓW FTP. Możesz tam zdefiniować albo twardą izolację (użytkownik nie wyjdzie poza swój homedir) albo miękką (użytkownik zaczyna pracę w homedirze, ale może wyjść do katalogu głównego serwera FTP).

Są różne rodzaje list, uwzględniające np. ip, zakres ip, adresacja systemu autonomicznego, domena maila, domena revdns... Z tym, że najpopularniejszy jest blacklisting adresacji (adresu bądź zakresu).

PTR to rekord w "domenie" in-addr.arpa. Ustawiany jest on (w dużym uproszczeniu) przez dysponenta klasy adresów IP. Napisz do dostawcy, aby ustawił ci RevDNS. Sam na swoim serwerze DNS tego nie zrobisz.

Ależ jak najbardziej jest proste Błędne koło weryfikacji DNS po prostu. Home wymusza, aby serwery DNS były poprawnie skonfigurowane do obsługi domeny. Hoster wymaga, aby przed konfiguracją DNS domena była wydelegowana. Solucja jej rozwiązania jest jak najbardziej dostępna: Czyli: hoster NIGDY w darmowym planie nie pozwoli na taką delegację. Jeśli home będzie oporny to albo możesz kupić u hostera konto premium, albo też przetransferować domenę do innego partnera NASK

Zjadł byś bardzo pyszną niesamowitą potrawę, przyrządzoną przez światowej sławy mistrza kuchni, podaną w... nocniku ? Też nie jestem za wielkim estetą, ale owa estetyka praiwe zawsze ma jakiś wpływ na odbiór firmy i świadczonych przez nią usług.

Ano to, że raport/tytuł tematu jest zatytułowany nie Podatność serwerów firm hostingowych na BEAST/CRIME tylko Bezpieczeństwo SSL serwerów firm hostingowych. A IMO na owe bezpieczeństwo SSL składa się także (szeroko pojęte) konfiguracja samego PKI.

Optymizm wręcz porażający. Na jakiej podstawie twierdzisz, że owy raport coś poprawi? Pierwsza sprawa - napisany przez niewiadomo-kogo tak naprawdę. Imienia i nazwiska jakiegokolwiek brak. Ot po prostu brak jakiegokolwiek autorytetu znanego w branży albo środowisku nauki. Dla przeciętnego Kowalskiego informacja, że wspomniane ataki są niebezpieczne jest równie prawdziwa jak wymysły wikipediowych profesurów. Sorry Winnetou. Świata tym się nie zawojuje. Tym bardziej, że na owej liście istnieją firmy, które już nie istnieją, niektóre mają błędy w stylu umieszczenia w tabeli adresu wywołującego alert o błędnym CN (czyli autor się nie wysilił nawet, aby takie błahostki zrobić poprawnie, to co dopiero jakość wykonania innych bardziej skomplikowanych rzeczy/analiz?) Cóż. Jak brakuje merytorycznych argumentów obalających krytykę, to zaczynają się pomówienia... PS: Ja wcale nie neguję, że znaczna część wspomnianych serwisów ma ustawienia SSL zgodne ze stockową konfiguracją Apache. Nie neguję też tego, że podanych dziur nie da się jakoś wykorzystać. Ale pisanie o elementarnym bezpieczeństwie SSL robiąc błędy w weryfikacji PKI będącej tak naprawdę fundamentem mechanizmu SSL i uznając, że to drobnostki to takie trochę dziwnawe...

Ano to, że w opisywanym przeze mnie przypadku CN certyfikatu wskazuje na domenę ok.com.pl. Czemu więc w owym raporcie jest wpisany ADRES https://regdos.com? Ano pewnie dlatego, że owy raport robiony był na odpierdziel PS: Dla mnie untrusted issuer* albo tym bardziej błąd weryfikacji CN w środowisku internetowym jest bardziej krytyczny niż podatności na wspomniane ataki. Bo skoro użytkownik ma w manualu do aplikacji informację w stylu (wejdź na stronę, kliknij AKCEPTUJ w okienku ostrzeżenia przeglądarki i dalej się baw) to jest to znacznie bardziej narażone na różnorakie ataki MITM niż jakieś specyficzne zaburzenia szyfrowania, przy których większość klienckich browserów będzie także alertować. PS2: Bezpieczeństwo SSL to nie tylko bezpieczeństwo samego szyfrowania. To także cała otoczka związana m.in. z bezpieczeństwem PKI. * - untrusted issuer != selfsigned. Bo jeśli np. via zasady grupy rozprowadzi się certyfikat CA na stacje klienckie, to nie ma nic złego w certyfikatach selfsigned. A nie będą z punktu widzenia klientów untrusted issuer.

Ano np. to, czy jest to, czy wspomniane podatności dotyczą konfiguracji strony firmowej, czy też strony klienta, czy też czegoś tam innego. Ponadto autor(zy?) tego zestawienia nie pofatygowali się nawet o sprawdzenie, czy analizują rzeczywiście to, co powinni... Ot taki przykład - w zestawieniu podany jest ADRES i NAZWA. Weźmy sobie takie regdos.com. Wejdźmy na podaną w tabelce https://regdos.com. No i co nas wita na wejściu? Ano przeglądarkowy alert SSL o niepoprawnym CN certyfikatu

A na jakiej podstawie mieli by honorowac to drugie konto (w sensie - przeksiegowac srodki)? Odeslac kase powiadasz... a na jakiej podstawie? Fakture korygujaca na "Kubusia Puchatka" mieli by wystawic? Wtedy to dopiero US by mial powody do kontroli Temat jest bardzo sliski. Bo czego bys nie zrobil, to w prawnym zakresie i tak bedzie bardziej lub mniej zle.

Cóż. Jak kogoś wiedza o VPSach kończy się na openvz, to pewnie ze swojej głupoty mu uszy więdną ze śmiechu. A jak ktoś ma szersze horyzonty, to pewnie słyszał o wirtualizacji via kvm-qemu i niczym dziwnym mu się to nie wydaje. Sam opis jest ciekawy i pod względem merytorycznym przydatny. Gdyby nie był tylko tak chaotycznie napisany

Akurat twoje pobożne życzenia możesz sobie mieć, ale prawodawstwo ma wyższy priorytet. A to, że wymagana jest papierowa cesja... to nic dziwnego. Ba! Dziwnym jest to, że większość usługodawców pozwala na nią bez weryfikacji. Bo umowa o świadczenie usług zawarta była z określonym podmiotem. A skoro się on ma zmienić, to niczym dziwnym jest obustronne oświadczenie - zrzekam się praw/przejmuje prawa związane z kontem. Nie ma wtedy niejasności, że ten to mi wykradł dane dostępowe i pozmieniał na swoje i ja jestem odcięty od konta i chcę przywrócenia go.

Żaden prawnik nie sformułuje tak jakiegokolwiek pisma. Zwłaszcza tego pogrubionego fragmentu

Problem może zapewne tkwić tutaj: kafi@work:~# telnet mail.witryneo.pl 25 Trying 217.160.109.208... telnet: Unable to connect to remote host: Connection timed out

killall -u LOGIN nazwa_procesu

Co implikuje totalną bezwartościowość tego zestawienia. Sorry Winnetou. Tworząc zestawienia i później je publikując trzeba to robić rzetelnie, a nie na odwal się. Że co? Sumarycznie danych przerzuci się tyle samo. Dowcip tylko taki, że łącze 20Mb łatwiej w danej chwili T przeciążyć niż łącze 100Mb.

Upewnij się, że możesz mieć zainstalowane klientom wersje Standard, a raportować Datacenter. (ewentualnie zastanów się, jak przeinstalujesz klientom te windowsy/zmienisz klucz produktu) A odnośnie Windowsa XP w SPLA... To zastanawia mnie zgodność jego z licencją SPLA. Która wyraźnie chyba mówi, że dostarczać należy najnowsze oprogramowanie, a raportowanie starego to właściwie tylko w przypadku kontynuacji. (pomijając fakt bajdurzenia o jakichkolwiek naklejkach... może z SA sie pomyliło?)