Skocz do zawartości

Bartosz Z

WHT Pro
  • Zawartość

    880
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    41

Posty napisane przez Bartosz Z


  1. Transparentne proxy i brak SSL. Słabe.

     

    Firewall.

     

    W którym miejscu brak SSL? Squid obsługuje terminowanie i rozszywanie SSL od dawna i nie zrezygnowali z tego w najnowszej wersji: http://wiki.squid-cache.org/Features/SslBump

    Jeśli klient ma skonfigurowanego VPNa, to nie widzę problemu w konfiguracji cerytfikatu Squida u klienta.

     

    Firewall i filtrowanie po docelowym IP jest również średnie, bo co w przypadku dopuszczenia domen zza CloudFlare (przykładowo)? Dopuszczamy całą ich adresację, więc wszystkie domeny korzystające z CloudFlare.

     

    W Squid działa transparentne proxy ssl bez instalowania certyfikatów u siebie. Tylko jak to wspiąć z vpn.

     

    Podejrzewam, że wystarczy wystawić Squida na podsieci VPNowej i przekierować ruch z portów 80 i 443 TCP na adres Squida.


  2. No nie do końca. Musiałby mieć tam coś bardzo nielegalnego żeby prokuratura czy policja się tym zainteresowała. W większości przypadków do blokady wystarczy poinformowanie usługodawcy, że właściciel serwera udostępnia materiały, do których nie ma praw autorskich lub po prostu z danego IP wysyłany jest spam lub przeprowadzane ataki. Usługodawca nie będzie nastawiał karku dla usera.

     

    Dlatego też takie rzeczy jak wirusy, exploity, botnety powinno się testować w postawionym u siebie labie. Jeżeli wymaga to zewnętrznego serwera, to używać go tak, aby nikt inny nie ucierpiał.

    Botnet jest bardzo, czy tylko troszkę nielegalny? ;)

    Blokada usługi po dowolnym zgłoszeniu to nieporozumienie. Za czasów pracy w hostingu olewałem takie zgłoszenia i odpisywałem, że potrzebujemy pisma z odpowiedniej instytucji. Grzecznościowo przekazywałem zgłoszenie do właściciela usługi, żeby zdjął nielegalne treści we własnym zakresie. Każdy to rozumiał. Nie w mojej gestii (jako administratora) jest weryfikowanie, czy osoba XYZ ma prawa autorskie do czegoś czy nie.

     

    Testowanie we własnym labie rozumiem. Ale testujesz po to, żeby później wrzucić to na "produkcję", a wystawianie CC botnetu z własnej adresacji to błąd :)


  3. KVM jest droższy od OpenVZ dlatego, że swoich zasobów nie dzielisz z innymi użytkownikami a masz je w stu procentach dla siebie. :)

     

    Oczywiście, że dzielisz (choćby IO i sieć). KVM umożliwia ballooning, a współdzielenie CPU nie jest niczym nadzwyczajnym.

     

    OpenVZ z jest tańszy ponieważ z pewnych powodów technicznych (wygooglaj sobie różnicę w wirtualizacjach) umożliwia wciśnięcie więcej maszyn, czyli większy overselling.

     

    Mógłbyś podać tę różnicę w poście? Overselling na KVM jest również możliwy, a przemyślany nie jest niczym groźnym dla klienta końcowego.


  4. Jeżeli już brać to z wirtualizacją KVM - tu dostajesz fizycznie tyle, ze ile zapłacisz, a te zasoby nie są współdzielone. Np. KVM w WEBH - na jednym rdzeniu chodzi to szybciej niż ten sam serwer z najbogatszej oferty ale z OpenVM

    Nie masz racji: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/form-Virtualization-Overcommitting_with_KVM-Overcommitting_virtualized_CPUs.html

     

    W OpenVZ/LXC można przydzielić gwarantowane zasoby.

    Mądry overselling to nic złego.

    • Upvote 1
×