Skocz do zawartości

Web Hosting Talk

  • arubacloud.pl

    Partner technologiczny

    Aruba Cloud jest marką usług cloud na rynku europejskim. Została stworzona w celu dostarczenia firmom kompleksowych rozwiązań Cloud niezależnie od ich planów i projektów.

 

Treść o najwyższej reputacji


#360477 [Opinie] Zenbox.pl

Napisany przez UnixStorm.org na 02 marzec 2013 - 16:46

Powstrzymywałem się od wypowiedzi jak mogłem żeby mi też nie zarzucono, że atakuję konkurencję, ale czytając Tomku Twoje wypowiedzi w stylu:

 

Specyfikacja jest po pierwsze dla userów pro aby zobaczyli szczegóły a dla reszty aby pokazać, że konkurencję zostawiamy daleko w tyle

czuję się niejako wywołany do tablicy i coś skrobnąć od siebie też bym chciał.

 

Przede wszystkim, jak ktoś wyżej wspomniał, określenie o chmurze i jej wyższością nad innymi hostingami jest szczególnie nietrafione, albo wynika ze złego zrozumienia tego pojęcia bo niczym się praktycznie Wasza oferta nie różni od innych hostingów istniejących od dawna.

 

Argument, że jest to jedyna oferta typu out-of-the-box też jest dalekie od prawdy. W innych firmach hostingowych klient musi sam sobie wszystko instalować i konfigurować? Nie ma gotowego środowiska do pracy? Pewnie, że ma. Tym właśnie kierują się firmy hostingowe - udostępnić gotowy system i narzędzia dla klienta końcowego, aby bez przeszkód mógł zająć się tylko uruchomieniem własnej strony.

 

Podajecie też, że jest to hosting bez limitów. Przecież macie więcej (schowanych) limitów, niż większość firm hostingowych w tym kraju.

Przykład z Waszej specyfikacji: dopuszczalne obciążenie procesorów (średnie i chwilowe), limit procesów (16), max. liczba plików koncie (500k), limit IOPS, mnóstwo ograniczeń dot. MySQL, 10800s użycia MySQL na dobę, max. 2 GB na skrzynkę mailową, limit ilości wiadomości w skrzynce i wiele innych...

 

Przecież przy tak rygorystycznych limitach Wasz klient musi uważać i pilnować więcej limitów, niż przy przeciętnym hostingu za kilka zł, nie wspominając już o serwerach VPS. Przy tych limitów wielu klientów nawet nie wykorzysta tej liczby unikalnych odwiedzin bo skończą mu się inne limity.

 

Przy kontach w "typowej" ofercie klient jasno widzi co i jak. Nie obchodzi go ile odwiedzin będzie na stronie, tylko czy zmieści się w podstawowych limitach takich jak transfer i pojemność, a to praktycznie każdy rozumie przez problemów.

 

U siebie mamy klientów, którzy na kontach za "stówkę rocznie" osiągają po 50k unikalnych odwiedzin i więcej, w dodatku na ciężkich skryptach. Mamy nawet klienta, który na koncie bez limitu transferu (za ~500 zł/rok) generuje ponad 2.5TB transferu miesięcznie (!).

 

Osobiście nie widzę niczego innowacyjnego w zenboksie poza wyjątkowo niefajnym marketingiem i zupełnym brakiem szacunku do firmy, które na tym rynku są od wielu lat. Wasza oferta dopiero wystartowała, wszystkie problemy pojawią się wraz z napływem większej liczby klientów, a mimo to już teraz coś uderzyło Wam chyba za bardzo do głowy.

 

Kwestia wystawiania opinii za darmowe miesiące hostingu na futurehost i Wasze niezrozumienie oburzenia innych wtedy też przypominało mi obronę czegoś, co sami chcecie w podobnym stopniu wprowadzić u siebie, aby nie być posądzonym o to, że pierwsi taką formę wyrabiania sobie opinii stosujecie. Teraz rozumiem czego tak tego pomysłu broniliście.

 

Ktoś Wam też zarzucał, że trochę nie fair jest cała ta sytuacja. WHT rozwinęło się jakby nie patrzeć dzięki firmom hostingowych, a Wy to wykorzystaliście do własnych celów. Gdyby nie inne firmy hostingowe, to forum wiałoby pustkami. Nie wspominając o reklamach Waszej konkurencji, które płaci za reklamy tutaj. Wiem, że macie swoje zdanie, ale dla mnie i na pewno wielu innych osób to forum strasznie przez to wszystko straciło, nie będzie już nigdy obiektywne (już nie jest, mimo że uważacie inaczej), a jedynie zmierza w kierunku wojny ze tymi wszystkimi, którzy do tej pory starali się to forum napędzać.

 

Dla mnie całe to Wasze posunięcie jest wyjątkowo niesmaczne, włącznie ze sposobem Waszego marketingu, który momentami jest wręcz przykry. No ale.. życie wszystko weryfikuje i tak też będzie w tym przypadku bo niestety oferta zenbox nie wnosi niczego rewolucyjnego do polskiego hostingu, a nawet jest według mnie znacznie mniej atrakcyjna od przynajmniej połowy firm z tego forum.

 

PS. Są powody, dla których niektóre firmy hostingowe nie stosują niektórych rozwiązań uważanych przez Was za najlepsze. Wynika to już z doświadczenia i znanych problemów z takimi rozwiązaniami. Pewnie z czasem też je odkryjecie. Część Waszych "pomysłów" wdrażaliśmy u siebie kilka lat temu i szybko musiały zostać wycofane ze względu na problemy, jakie ze sobą niosły (często pojawiające się dopiero w momencie, kiedy pojawiało się już więcej użytkowników/danych).


  • 127


#360966 [Opinie] Zenbox.pl

Napisany przez admin@prohost.pl na 05 marzec 2013 - 17:39

@zenbox

Z czasem może przejdzie wam nadwrażliwość na to co ktoś powie/napisze. Każdy może mieć swoje zdanie. Jeśli ktoś od was myśli, że każda wypowiedź na wht która pośrednio dotyczy zenboxa jest walką z konkurencją to gratuluję wyobraźni. Z tego co widzę to zenbox ocenia wypowiedzi innych swoimi standardami - jak zenbox mówi o konkurencji jak o cieniasach to konkurencja musi tak samo. Wskazywanie, że coś konkurencja mówi nie zrobi z tego automatycznie kłamstwa ani nie skasuje znaczenia wypowiedzi.

 

Lepiej mieć mniej info ale bardziej wiarygodne. Jest coś takiego jak referencje. Blogerzy zgadza się są obecni w necie bardziej ale są też fanboyami i raz polecając coś tak szybko zdania nie zmieniają bo wyszłoby na to, że polecali np coś co jest tego nie warte - kto będzie wtedy liczył się z ich zdaniem :)


  • 112


#328917 Firmy, które mają userów WHT za de*ili mają się dobrze?

Napisany przez Prohost na 07 sierpień 2012 - 12:37

Nie widzę powodu do zdenerwowania:

1) Jakby ktoś był mądry to by nie reklamował tego forum klientom - bo zysk z tego jest generalnie zerowy. To forum nie generuje zysków dla firmy dodatkowych (jeśli o jakichś mozna mówić kiedy nie jest szeroko znane nawet szukającym w google hostingu - nie oszukujmy się ceneo to to nie jest) jeśli je ktoś zareklamuje dla klientów. Nie jest w stanie zwrócić kosztów tej reklamy. Nie mówie nawet o szkodach które można ponieść przez ewentualne złe opinie czy nawet przez pakowanie swoich klientów na reklamy innych firm.

2) Opinie jednopostowców z jednorazowej akcji nic nie znaczą przynajmniej dla większości osób tu zarejestrowanych.

3) Zarządzający forum nie bardzo wiedzą jak biznes portalowy działa i jak na nim zarobić a tym samym podnieść jakość - proponuję popatrzeć jak większe portale biznesowe to robią - można się wiele nauczyć. Wprowadzanie usług nie spełniających swoich zadań to problem braku podstaw pod nie. Nie można przeskoczyć kilku stopni w budowie i spodziewać się dobrego efektu.

4) Forum jest generalnie bardzo nudne - jedyną rozrywką czy też nową informacją jest albo czyjaś reklama albo temat jak ten gdzie się mogą userzy trochę ponapinać. Już lepiej na pudelka wchodzić tam przynajmniej codziennie jest kilkanaście nowych newsów. Jakbym nie miał firmy hostingowej to bym tu wcale nie wchodził - teraz co jakiś czas patrzę czy coś się dzieje ale się nie dzieje.

Jeśli ktoś wysyła swoich klientów na to forum to cieszcie się - zobaczą waszą reklamę/ofertę.

Dużo czasu minęło od wprowadzenia partnerów i moja rezygnacja z bycia jednym z nich okazała się być słuszna - ze starych partnerów nie został nikt bo nic to nie zmienia i tylko te pieniądze są marnowane które wpływają od nich - leci rotacja partnerów, leci... a rozwoju brak(jest coraz słabiej).
  • 92


#345481 [SQL] Benchmark - razem czy osobno

Napisany przez patryk na 01 grudzień 2012 - 19:27

Dodany obrazek

Ale zabawa! Nie wiem co lepsze, czy rajd barbórki czy forum..
  • 91


#352730 Security na Debianie, Fakty i Mity + Poradnik

Napisany przez Archi na 21 styczeń 2013 - 01:42

Serdecznie witam w moim malutkim temaciku. Z racji, że człowiek uczy się całe życie, a w kwestii bezpieczeństwa brakuje mi już pomysłów to postanowiłem założyć taki topic. Może się on przydać zarówno początkującym administratorom, jak i odpowiedzieć na moje pytania, można już powiedzieć "w miarę" obytego z tematem .

 

Ten poradnik pozwoli Ci co nieco podszkolić się z zakresu security, być może nawet i mi, jeżeli dasz mi taką możliwość ;). Zapraszam do... dość długiej lektury na temat bezpieczeństwa systemów linux, na bazie Debiana 7.0 Wheezy.

 

0) Zaczynając od fizycznego bezpieczeństwa to raczej pomijam nieatoryzowany dostęp - do datacenter nie tak łatwo się włamać więc to mamy z główki. Tutaj taki protip głównie dla początkujących adminów, że jeżeli chodzi o bezpieczeństwo fizyczne to przede wszystkim należy ustawić BIOS w opcję bootowania wyłącznie z HDD, do tego zabezpieczyć go hasłem, można tam jeszcze włączyć automatyczny start po odzyskaniu prądu no i oczywiście schować go w bezpieczne miejsce. Dla "paranoików" z KVM'ami bądź innym dostępem hardware polecam jak zawsze szyfrowanie dysków, chociażby TrueCrypt'em. Co do fizycznego dostępu to nie powinien on być możliwy - nawet wszystkie powyższe opcje nie dają żadnego bezpieczeństwa - pan Sławek przez godzinę bez problemu może rozkręcić serwer, zresetować CMOS'a i sobie poklikać, wbrew pozorom fizyczne bezpieczeństwo serwera jest tutaj naprawdę istotne.

A teraz część właściwa...


1A) Kernel, czyli jądro systemowe. Punkt odpada na ~80% VPS'ów, ogólnie na wszystkich, które dzielą jądro z serwerem-matką. Wyjątkiem jest pełna wirtualizacja (np. XEN), na której jądro idzie zmodyfikować. A więc na początku trzeba zadać sobie proste pytanie... czy kernel dostarczony z systemem jest dobry? Dla większości osób tak, ale dla nas nie. Już mówię dlaczego. Po pierwsze z kernela można wyłączyć wszystkie zbędne funkcje (głównie sterowniki do driverów), przez co po pierwsze mamy szybszy i mniejszy kernel (nie musimy kompilować zbędnych rzeczy), a po drugie daje to dodatkowe "bezpieczeństwo" idąc zasadą, że nie da się zabusować rzeczy, których nie ma . Tu serdecznie namawiam wszystkich posiadaczy dedyków do zabawy z jądrem, oczywiście nie na produkcyjnych serwerach, ale stworzenie dobrego configu pod danego dedyka jest naprawdę fajną sprawą. Pierw wypadałoby się wyposażyć w odpowiednie pakiety, jest to build-essential, ncurses-dev i może być również potrzebny gcc-4.7-plugin-dev, oraz oczywiście wszystkie inne, o ile debian odmówi nam posłuszeństwa . Swoją droga skoro już przy tym jesteśmy serdecznie polecam pakiet checkinstall, który ułatwia kompilację i instalację pakietów ze źródeł, aczkolwiek nie będziemy go używać w tym poradniku.


No więc jedziemy. Zacznijmy od tego... która wersja? Wersje na dzień dzisiejszy polecam trzy. Najnowszą, którą jest 3.8.X, stabilną, którą jest 3.2.X oraz starą-stabilną, którą jest 2.6.X. Ogółem kiedyś z najnowszymi kernelami było bardzo dużo problemów, ale na dzień dzisiejszy nie widzę przeciwwskazań do używania nawet wersji 3.8 - Sam ją posiadam z uptimem kilku tygodni i sprawuje się świetnie na dzień dzisiejszy. Wersja 2.6 jest o tyle zła, że prędzej czy później skończy się dla niej wsparcie, a do tego administrator powinien jednak dążyć do "modernizacji" swojego serwera, już w ogóle nie wspominając nic o tym, że nowszy kernel najczęściej jest szybszy, bezpieczniejszy i ogółem "lepszy", o ile dobrze się go skompiluje . No więc ściągamy wybranego kernela z kernel.org, rozpakowujemy za pomocą tar xvf i... no właśnie. Co dalej?

 

Tutaj należy wspomnieć o łatkach bezpieczeństwa na kernela. Po co one komu? Ano po to, że tak naprawdę zabezpieczenia kernela przydadzą nam się w każdej możliwej sytuacji, chociażby w sytuacji gdy wszystko zawiedzie, exploity się przedrą a kernel zwróci nam piękne "Acess Denied". Do tego bez "podmiany" kernela, a zatem rebootu maszyny nie ma opcji się tych łatek "pozbyć", więc stwarza to jako tako strażnika ostatecznego, przed którym jednak uciec się nie da. Co zatem polecam? Polecam łatkę grsecurity, która jest dostępne pod tym linkiem. Wybieramy wersję odpowiednią dla naszego dopiero co ściągniętego kernela, pobieramy ją, przechodzimy do folderu z naszym jądrem (cd linux-X.Y.Z) i wykonujemy komendę patch -p1 <../grsecurity-cyferki.patch, która spatchuje nam naszego kernela o łatkę grsecurity, o której powiem za chwilę. Teraz należy wykonać komendę make defconfig, następnie make menuconfig i już jesteśmy w samym środku konfiguracji.

 

Jak skonfigurować kernela?

 

Zacznijmy od tego, że nie ma administratora który ani razu nie doświadczył kernel panica . Uzbrój się w cierpliwość i miej świadomość tego, że tworzenie configa to proces, który zajmuje najdłużej, ale ma też swoje efekty. Komenda make defconfig nam nieco pomogła, ponieważ dała nam kernel "defaultowy" dla danej wersji, który jednak pozwala bez problemu się skompilować i zbootować. Tu tylko polecam przejść do zakłądki Security => Grsecurity, wybrać mode automatic, przeznaczenie pod server, virtualization none (chyba, że jesteśmy na VPS'ie, wtedy guest) i w zaawansowanych opcjach możemy jeszcze dodatkowo włączyć kilka wyłączonych opcji (np. hide kernel processess, /proc restrictions), które dodatkowo nam stworzą kolejną złudną barierę bezpieczeństwa. Tylko nie należy przesadzić - nie zaznaczać wszystkiego jak leci, a czytać co dana opcja robi, a jeśli nie jest się pewnym zostawić jak jest.

 

To teraz chwilkę o optymalizacji. Zacznijmy od tego, że jest wiele opcji, które polepszają nam działanie naszego jajka. Poczynając od kompilacji pod konkretny procesor (Processor Type => Processor Family), poprzez zabiegi optymalizacyjne (np. Optimize very unlikely/likely branches, Kernel compression mode), a kończąc na wyłączaniu zbędnych sterowników i driverów. Czy Twój serwer potrzebuje wsparcia dla kart dźwiękowych? Wsparcia dla kontrolerów do Playstation? Bezprzewodowego dostępu do internetu? Modułu podczerwieni? Bluetooth? To wszystko da się wyłączyć! Wystarczy naprawdę przyłożyć się do configa i odnaleźć potrzebne opcje.

 

Konfiguracja jajka nie jest prosta. Bez praktyki nie ma opcji żeby się tego nauczyć. Jest to zabawa bardzo niebezpieczna i trzeba się liczyć z tym, że często, jak nie zawsze nie wszystko pójdzie po naszej myśli. Ogółem na początku polecam wyłączać tylko "pewniaki", jak np. wsparcie dla wireless czy sound cards, a w miarę doświadczenia bawić się z resztą.

 

Jesteś gotowy? Twój config jest przygotowany? Zaczekaj...


Pamiętasz grsecurity, o którym wspomniałem wyżej? To jest miecz obusieczny, można zarówno dostać porządny boost do security, jak i spowodować totalną katastrofę. Nie zaczynaj kompilacji i instalacji bez dwóch podstawowych pakietów do obsługi grsecurity i paxa. Zainstaluj gradm2 i paxctl, możesz nawet przez apt-get'a. Jeśli coś nie pójdzie po naszej myśli to spróbujemy to naprawić...

 

Skoro config gotowy to możemy przejść do kompilacji. Komenda make deb-pkg, a następnie cd .. i dpkg -i *.deb załatwi sprawę, na koniec reboot i o ile wszystko poszło pomyślnie to system wstanie na nowym kernelu.

 

Dodatkowo przed rebootem można jeszcze niejako się ubezpieczyć "just in case" jakby kernel jednak nie wstał, a nie chcemy tracić czasu na reinstalację całego systemu. Z pomocą przyjdzie nam opcja fallback, dostępna w nowszych wersjach grub'a. Odnajdujemy plik /etc/grub.d/40_custom i na samym końcu pliku dopisujemy linijkę:

 

set fallback=2

Po dopisaniu tej linijki proszę nie zapomnieć o komendzie update-grub, która ją wdroży do grub.cfg.

 

A cóż takiego robi ten fallback? Jest to instrukcja dla grub'a, że jeżeli pierwszy (defaultowy) kernel się nie załaduje to powinien załadować kernel z pozycji "3". Czemu 3? Grub liczy standardowo od zera. Należy tutaj wspomnieć o tym, że kernel standardowo instaluje się z dwóch wpisów - normal i recovery. Dopóki nie zadamy sobie trudu całkowitego usunięcia recovery to na miejscu pierwszym będzie nasz nowy kernel, na miejscu drugim jego recovery, a na miejscu trzecim "normal" kernel, na którym prawdopodobnie teraz działamy. Tak więc ustawiamy fallback na 2 i upewniamy się, że na 3cim miejscu rzeczywiście znajduje się kernel, co do którego jesteśmy pewni, że jest sprawny.

 

Po reboocie komendą uname -r możemy sprawdzić aktualnie załadowanego kernela. Jeśli nie jest nim nasz nowy to znaczy, że coś poszło nie tak, od tego jest syslog, kern.log i jego koledzy z /var/log ;). Jeśli jednak uname zwraca nam piękny wynik, a my już niemal skaczemy z radości, że wszystko działa jak należy... To przechodzimy dalej.

 

Grsecurity, tym bardziej z włączonym PaXem to zabezpieczenie kolosalne. Przede wszystkim mogą być problemy z grub'em i jego wojną z paxem. Wszystkie logi znajdziemy w /var/log/syslog oraz /var/log/messages i one nam podpowiedzą co dalej. Przykładowo:

 

Spoiler

 

O kurde, no to mamy problem, co na to syslog?


Spoiler

 

No i mamy punkt zaczepienia. /usr/sbin/grub-probe. Na szczęście dzięki wcześniej zainstalowanemu paxctl mamy możliwość kontrolować takie rzeczy. Komenda paxctl -Cpemrxs daje nam możliwość "dodania" danego skryptu/programu do takiej "białej listy", aczkolwiek to złe określenie.

 

To kolejne zabezpieczenie grsecurity i paxa przed "podmianą kernela", chociaż w rzeczywistości nie jest to stworzone specjalnie na gruba. Grub będzie działał poprawnie gdy wykonamy poniższe komendy:

 

paxctl -Cpemrxs /usr/sbin/grub-probe
paxctl -Cpemrxs /usr/sbin/grub-mkdevicemap
paxctl -Cpemrxs /usr/bin/grub-script-check
paxctl -Cpemrxs /usr/lib/grub/i386-pc/grub-setup

 

 I to w sumie jest jedyna z takich "przypadłości paxa", o której trzeba wspomnieć. Jak najbardziej są aplikacje, które również z paxem będą się gryzły, ale od tego mamy /var/log/syslog, paxctl i trochę oleju w głowie. Nie ma ich jednak aż "tak dużo" i nie stanowią jakiegoś większego problemu...

 

Tutaj należy wspomnieć o tym, że jakakolwiek "podmiana" tych execów spowoduje również usunięcie flagi paxctl, więc należy o tym pamiętać. Jeszcze o tym wspomnę w odpowiedniej części poradnika...

 

 

1B) Grsecurity

 

Skoro już mamy tego grsecurity to wypadałoby się mu bliżej przyjrzeć. Wszystkie opcje mamy pięknie opisane i można samemu wywnioskować co on nam daje. A co nam daje? Chociażby lepsze możliwości chroota, restrykcje procesów wyłącznie dla danego usera, ochronę przed potencjalnie niebezpiecznymi aplikacjami i wywołaniami (PaX) i wiele innych opcji, które się bardziej bądź mniej przydają w security. Nie należy jednak traktować grsecurity jako opcji "jedynej i słusznej", jest to niewątpliwie narzędzie godne uwagi, które jest naprawdę potężne, ale nie daje nam ochrony "pierwszego rzędu" tylko ochronę "drugiego rzędu", tej o której większość osób zapomina. Tutaj należy wspomnieć o tak naprawdę głównym zastosowaniu grsecurity, a mianowicie RBAC. O RBAC można znaleźć strasznie dużo informacji, głównie w dokumentacji grsecurity, więc nie zamierzam jakoś bardziej rozwijać tego wątku. Powiem tylko tyle, że pięknie wprowadza politykę "najmniejszych przywilejów" i odpowiednio skonstruowany poważnie podnosi nasze złudne poczucie bezpieczeństwa :).

 

No dobra, można powiedzieć że jajko mamy za sobą. Co dalej?

 

 

2) OpenSSH

 

O tym można napisać całą książkę. Ile to osób ma całkowicie niezabezpieczone serwery SSH? Ile to osób atakują randomowe botnety, które bruteforcem przejmują roota? Ile to razy dowiedziałeś się, że Twój serwer rozsyła spam czy jest w botnecie? A czego to zasługa? Głównie wyżej wymienionego ustrojstwa.

 

Jest kilka prostych praktyk, które w zupełności wystarczą do w miarę dobrego zabezpieczenia OpenSSH. Zaczynamy od podstawowej i najważniejszej rzeczy, a mianowicie edytowania w pliku /etc/ssh/sshd_config, linijki:

 

# What ports, IPs and protocols we listen for
Port 1255
UseDNS no

 

 

Port, który podałem wyżej jest oczywiście przykładowy i powinieneś ustawić dowolny, który Ci się podoba. Byle inny od defaultowego 22! Większość botów wbrew pozorom nie skanuje danego serwera tylko na ślepo próbuje się połączyć z portem 22, nawet takim prostym zabezpieczeniem 95% robaków mamy z głowy. Co do UseDNS to będzie nam to potrzebne przy punkcie z firewallem CSF, ale ustaw od razu to będzie z głowy. Oczywiście to dopiero początek zabawy z OpenSSH...

 

Kolejnym krokiem jest wygenerowanie prywatnego klucza SSH, możemy do tego użyć chociażby programu PuTTYGen, który wygeneruje nam klucz prywatny i publiczny. Kluczem prywatnym się logujemy (W PuTTY będzie to SSH => Auth => Private key), a klucz publiczny (czyli plik ze środkiem zaczynającym się od ssh-rsa AAA...) wrzucamy do katalogu /root/.ssh/authorized_keys. Następnie upewniamy się, że logowanie po kluczu działa oraz wyłączamy całkowicie dostęp do roota bez klucza:

 

# Authentication:
LoginGraceTime 30
PermitRootLogin without-password
StrictModes yes
ClientAliveInterval 30
ClientAliveCountMax 3
MaxAuthTries 3
MaxSessions 3
DebianBanner no

 

 

Przy okazji dodałem też kilka innych opcji, które skutecznie bronią nas przed brute-forcem.

Po tym wszystkim restartujemy usługę czyli service ssh restart i możemy czuć się już w miarę bezpiecznie, serwera ssh na defaultowym porcie nie ma, a nawet jeśli ktoś go znajdzie to do roota się nie zaloguje bez klucza, który na dzień dzisiejszy jest prawie niemożliwy do podrobienia. Wyjątkiem jest user, ale tu mamy kolejne kombinacje nazw, których bot prawdopodobnie nigdy nie pozna, a zatem można powiedzieć że jest w porządku. Dodatkowo polecam jeszcze w środku pliku odszukać tą linijkę i zamienić ją na:

 

PasswordAuthentication no

 

A na samym końcu pliku dodać:

 

# Backup-Security
GatewayPorts no
KeepAlive yes
Match Group pass
PasswordAuthentication yes
# SFTP Jail
Match Group jail
ForceCommand internal-sftp
ChrootDirectory %h
AllowTcpForwarding no

 

Następnie stworzyć grupę pass oraz jail poprzez addgroup pass, addgroup jail i oczywiście addgroup naszuser pass, przez co zezwolimy mu na połączenie po kluczu oraz po haśle, a wszystkim innym taką opcję zabierzemy. Ot tak, dla security. Zauważ, że stworzyłem również grupę jail, o której wspomnę niedługo.

 

 

3A) Firewall

Nie ma security bez firewalla, nie ma firewalla bez default policy drop, nie ma administratora bez security. Wszystko się zazębia. Opcji jest kilka, ja zaproponuję mojego ulubieńca, czyli ConfigServer Security & Firewall. Standardowo paczkę pobierzemy stąd, i rozpakowany już zainstalujemy skryptem install.sh. Zanim jednak go zainstalujemy należy sprawdzić za pomocą skryptu csftest.pl czy nasz kernel, a konkretniej jego funkcje działają z CSF'em. Głównie są to moduły do netfiltera, także jeśli jakiegoś zabraknie nie ma problemu "dokompilować" go do kernela i jeszcze raz zainstalować. Oczywiście skrypt odpalamy komendą perl csftest.pl.

 

Teraz należy wspomnieć, że do CSF przyda się nam zaplecze w postaci panelu (Webmina), aczkolwiek oczywiście nie jest on wymagany do jego działania. Ja jednak posłużę się integracją Webmina z CSF i ułatwieniem sobie życia...

 

3B) Webmin

Do /etc/apt/sources.list dodajemy:

 

# Webmin
deb http://download.webmin.com/download/repository sarge contrib
deb http://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib

 

 

Następnie wykonujemy apt-get update && apt-get install sudo i jeżeli zauważymy problem z brakującymi kluczami GPG to posłużymy się taką komendą:

 

apt-get update 2> /tmp/keymissing; for key in $(grep "NO_PUBKEY" /tmp/keymissing |sed "s/.*NO_PUBKEY //"); do echo -e "\nProcessing key: $key"; gpg --keyserver subkeys.pgp.net --recv $key && sudo gpg --export --armor $key | apt-key add -; done

 

 

Po zakończonym imporcie kluczy usuwamy zbędny plik rm /tmp/keymissing i instalujemy naszego webmina komendą apt-get install webmin. Następnie po instalacji wchodzimy na port 10000 naszego webservera (https://domena.pl:10000), logujemy się i oczywiście zaczynamy od konfiguracji. Można wybrać język polski jak ktoś sobie życzy, ale o wiele ważniejszą rzeczą jest ponownie zmiana portu, której możemy dokonać w Konfiguracja Webmina => Porty i Adresy, standardowo jakiś customowy port, może być to następny port po ssh bądź jakiś zupełnie inny, byle nie zapomnieć ;). Następnie odnajdujemy Moduły Webmina, stamtąd wybieramy Z pliku lokalnego i odnajdujemy plik /etc/csf/csfwebmin.tgz, po czym instalujemy go i voila, webmin może teraz dowodzić CSF!

 

Znajdujemy moduł w liście po lewej i możemy już pobawić się z configiem, który jest strasznie długi i naprawdę porządny. Nie zapomnijmy tylko później zmienić na samej górze opcji Testing na 0 i aktywować naszą zaporę. Fajnymi ułatwieniami, o których warto wspomnieć jest wstępnie zdefiniowany poziom zabezpieczeń (Firewall Security Level), który możemy ustawić od razu na High oraz opcja "Check Server Security", która nam powie jak jeszcze lepiej można tu coś zdziałać.

 

3C) LFD

LFD to dodatek do firewalla CSF. Jest to Log-Failure Daemon i jak nazwa wskazuje odcina dostęp osobom, które znajdą nasz serwer SSH i będą nas wkurzać swoją tysięczną sfailowaną próbą zalogowania. Wszystkie opcje LFD są do ustawienia w CSF i nie będę ich jakoś bardziej rozwijał, ponieważ wszystko jest w dokumentacji i oczywiście odpowiednich readme.

 

 

4) Dodatki

Dodatkami są rzeczy, które nie są wymagane, aczkolwiek mogą być przydatne jeśli należysz do podobnego typu osoby jak ja. Dajmy na to, mamy nginxa. Ale LFD nie jest kompatybilny z nginxem... A co jak bot będzie się przedzierał przez basic auth? Otóż to...

 

apt-get install fail2ban, kolejna zapora do naszego asortymentu. Mamy już co prawda LFD, ale fail2ban'a łatwiej mi ogarnąć pod nginx'a. Tworzymy sobie plik jail.local w /etc/fail2ban (w oparciu o jail.conf, czyli cp jail.conf jail.local) i dodajemy mu specjalne linijki:

 

Spoiler

 

Musimy jednak ulepszyć rulesy do Apache'a, na rulesy do Nginx'a. No więc przechodzimy do /etc/fail2ban/filter.d# i dodajemy:

 

apache-auth

Spoiler

No i mamy piękną kontrę na brute-force basic auth'a. service fail2ban restart i jedziemy dalej...

 

 

Drugim dodatkiem jest portsentry, którego również możemy zainstalować z poziomu apt-get install portsentry. Pełni on podobną funkcję co CSF i nie jest wymagany, ale z powodu tego że nigdy w przeszłości mnie nie zawiódł i służył mi już długie lata zanim odkryłem CSF postanowiłem go zostawić, ot jako dodatkową zaporę "just in case".

 

Po instalacji jedyne co trzeba zrobić to przerobić /etc/portsentry/portsentry.conf o:

 

BLOCK_UDP="1"
BLOCK_TCP="1"

 

I oczywiście service portsentry restart

 

 

5) Sysctl

Kolejna rzecz, która pomaga nam "dotweakować" kernel do naszych potrzeb. Niektóre z tych opcji są standardowo włączone, inne nie. Ważne jest to, że można jeszcze nieco podbudować naszą politykę security. Modyfikujemy plik /etc/sysctl.conf:

 

Spoiler

 

Sysctl nie jest mojego autorstwa. Ja tylko do niego dopisałem dwie interesujące mnie opcje, a mianowicie kernel.panic oraz vm.swappiness. Pierwsza z nich rebootuje nam automatycznie system w przypadku kernel.panica po 10 sekundach (nie ma potrzeby sprzętowego resetu), a druga zmniejsza ilość "swapowanej" pamięci do jakiegoś w miarę normalnego limitu, ponieważ w moim odczuciu defaultowa polityka jakoś się tak "spieszy" z tym swapem ;). Oczywiście możemy zmienić to na "swap only if needed", ustawiając na 0 i przy okazji nieco optymalizując użycie ramu, ale nie to jest tematem tego poradniczka.

 

 

6) Aktualizacje

 

Aktualny system to jedna z najważniejszych rzeczy, które trzeba mieć. Niby mamy "jako takie" zabezpieczenie vs 0day, ale co z tego skoro dziury są katastrofalne w skutkach? Jedziemy zatem, zainteresujmy się automatycznymi aktualizacjami. apt-get install unattended-upgrades to coś, co chcemy mieć. Następnie wykonujemy dpkg-reconfigure unattended-upgrades, włączamy je i przechodzimy do /etc/apt/apt.conf.d/50unattended-upgrades i zmieniamy parę istotnych kwestii...

Spoiler

To jest mój wpisik aktualizujący się po typie dystrybucji (w tym wypadku testing), jeśli chcesz bazować na codenamie zamiast tego to zakomentuj moje linijki, a odkomentuj te wyżej (z n=wheezy) i zmień wheezy np. na squeeze czy co tam masz za system ;).

 

Spoiler

Pamiętasz o katastrofalnym grubie i wojnie z paxem? Dzięki tym wpisom jesteśmy pewni, że takie coś nie stanie się podczas naszej nieobecności. Oczywiście możesz tu dodać swoje wpisy, usługi krytyczne których nie chcesz aktualizować, aczkolwiek przemyśl czy na pewno stawiasz stabilność ponad bezpieczeństwo. Do gruba nikt z zewnątrz się nie dostanie, ale już do apache'a... ;).

 

Spoiler

A tu jeszcze kilka dodatków do pomocy. Jak coś pójdzie nie tak będziemy mieli "lokalnego" mail'a na roocie. Dodatkowo wyłączyłem automatyczny reboot, w przypadku serwerów testowych zamiast produkcyjnych (albo takie, które można rebootować) polecam zostawić tą opcję włączoną.

 

No to tyle, mamy update'y które powinny działać i aktualizować nam system. Tutaj należy pamiętać o tym, że po 1 - skrypt nam nie zupdatuje NICZEGO, co wymaga naszej kontroli (np. nowy plik konfiguracyjny, niespełnione zależności), także weźmy to pod uwagę i nie bądźmy przekonani że wszystko działa jak należy ;). Do tego należy nadmienić, że jest to tylko skrypt ułatwiający robotę i albo przeglądamy co jakiś czas "maile" od naszych upgrade'ów albo sami na własną rękę wykonujemy apt-get upgrade. Wybór należy do Was.

 

 

7) Nawyki

Punkt niezwykle istotny, nawet najważniejszy ze wszystkich, a jednocześnie trudny do wykonania. Tu nie ma żadnych komend, programów czy opisów. W tym punkcie liczysz się Ty. Nawet najbardziej zabezpieczony system NIC nie da przeciwko wszelkiego rodzaju hackom, abusom i wykorzystywaniem dziur. Cóż więc zrobić? Przede wszystkim kieruj się polityką najmniejszych przywilejów. Masz usera, który musi mieć dostęp do panelu? Daj mu dostęp do panelu, a nie do całej maszyny! Pamiętasz grupę jail, którą robiliśmy dla OpenSSH? To jest początek - poprzez dodanie danego usera do grupy jail oraz zmianę ownera jego home (/home/user) zamykamy go całkowicie w module SFTP, nie dając dostępu do samej konsoli i dodatkowo chrootującym w swoim home. Teraz wystarczy stworzyć folder www, dać userowi do niego dostęp i voila. Szansa na popsucie reszty systemu jest minimalna, wyjście z chroota bez dostępu do terminala prawie niemożliwa. Możemy przyznać sobie +2 punkty do złudnego poczucia bezpieczeństwa. To tylko przykład na to jak można ograniczyć dostęp do tylko tego, czego rzeczywiście potrzebuje user. Dotyczy do wszystkiego - procesów, serwerów, daemonów, usług... Wszystkiego co jest odpalane na serwerze. Każda nowa usługa - potencjalne niebezpieczeństwo. Nie możesz stwierdzić, że np. taki nginx to proces w 100% bezpieczny więc nie trzeba się tym martwić. Nic bardziej mylnego. Ja mam nginx'a całkowicie oddzielonego od reszty systemu - każdy user/vhost na moim serwerze ma swojego workera, a ten worker ma dostęp jedynie do katalogu www, podobnie jest z php-fpm. Tak więc da się? Da się. Wszystko się da. Grsecurity dodatkowo zawiera w defaulcie parę porządnych łat na chroota, przez co można go porównywać z bardzo dobrym jail'em znanym z systemów BSD. Nie jest to jednak to samo, aczkolwiek na pewno jest to bezpieczniejsze rozwiązanie niż odpalanie z poziomu roota jakiś serwer gry ;). Pamiętaj - najmniejsze możliwe przywileje!

 

 

8) Jail w pliku

To oczywiście tylko jedna z koncepcji możliwości "dodatkowego" bezpieczeństwa. Sam zdecyduj czy Ci się przyda w Twoim przypadku.

 

Co chcemy osiągnąć? Chcemy zamknąc usera w konkretnym pliku, zamiast dawać mu dostęp do dysku. To ma swoje plusy i minusy, plusem jest to że poza ten plik fizycznie po prostu nie wyjdzie, minusem jest "elastyczność" tej metody.

 

W linuxach istnieje bardzo fajna opcja montowania plików. Zacznij od utworzenia folderu, który chcesz zjailować. Może to być np. /home/klient3, czyli standardowo cd /home i mkdir klient3.

Teraz musimy określić jak duży przydział dysku chcemy mu dać. Dajmy na to, że utworzymy mu 100 mb:

 

dd if=/dev/zero of=klient3.jail bs=1M count=100

 

Taka komenda stworzy plik 100 megabajtowy w aktualnym folderze i zapełni go zerami. Ostatni parametr oczywiście określa wielkość pliku. Teraz potrzebujemy zamienić go na plik z partycją:

 

mkfs -t ext4 klient3.jail

 

ext4 to mój wybrany system partycji, możesz użyć innego np. ext3, fat czy xfs.

Ostatnim krokiem jest podmontowanie tej partycji:

 

mount /home/klient3.jail /home/klient3

 

 

Teraz wystarczy użytkownika wrzucić do chroota bądź jaila (np. przez SFTP Jail, o którym wspomniałem już wyżej) i mamy więzienie gotowe. Użytkownik nie będzie w stanie w swoje miejsce "wrzucić" więcej niż 100 mb w sumie, a czemu? Bo fizycznie plik mu na to nie pozwala ;).

 

Oczywiście tak jak pisałem metoda ma swoje plusy i minusy, to jest tylko koncepcja i należy ją dopracować we własnym zakresie. Można to traktować jako swoistą alternatywę dla zwyczajnej "quoty". Czy będzie to dobry pomysł? Zależy od przeznaczenia. Ja sądzę, że tak.

 

Podmontowywać partycję trzeba oczywiście za każdym restartem. Lekarstwem na to jest edycja pliku /etc/fstab bądź dodanie komendy mount np. do /etc/rc.local przed exit 0.

 

 

9) DoS? DDoS? UDP Flood? O co chodzi z atakami sieciowymi?

Możesz być pewny, że Twój serwer zainteresuje zarówno pożądanych użytkowników, jak i tych niepożądanych ;).

Zacznijmy od szybkiej powtórki sieci. Mamy kilka protokołów sieciowych - Najważniejszymi, które nas interesują sa TCP, UDP i ICMP.

 

Zacznijmy od najbardziej destrukcyjnego protokołu, a mianowicie UDP. Co to jest to UDP? Nie mam zamiaru wchodzić w szczegóły (odsyłam do cioci wikipedii), przedstawię jak się to ma do bezpieczeństwa. Więc tak, zacznijmy od tego że protokół UDP jest protokołem typu connectionless, połączenie po UDP między klientami jest tylko umowne, w rzeczywistości nie mamy wpływu na to jakie pakiety UDP do nas przylatują. Już wiesz co mam na myśli, prawda?

 

Tak, najskuteczniejszym i najbardziej destrukcyjnym DDoS'em jest UDP Flood. Polega na wysłaniu masakrycznie dużej ilości pakietów UDP, w efekcie zapychając maszynę i łącze. Pewnie sobie teraz powiesz "zaraz zaraz, mam przecież grsecurity, mam paxa, mam CSF, jak to?". Ano tak to. Te wszystkie zabezpieczenia są zabezpieczeniami software'owymi i tyczą się bardziej hacków niż ataków sieciowych. Czemu? Pakiet UDP i tak doleci do naszego kernela i dopiero jak już doleci to system zdecyduje co z nim dalej zrobić - czy zrealizować czy odrzucić. Nawet jeśli całkowicie zablokujesz protokół UDP na swoim serwerze to i tak nie ma to wpływu na UDP Flood. Jedyną skuteczną metodą jest odłączenie wtyczki od neta ;).

 

Każdy pakiet UDP obciąża zarówno łącze, jak i procesor. Dodatkowo może obciążyć inne rzeczy, takie jak ram czy więcej cykli procesora, jeżeli doleci do konkretnej usługi i zostanie przez nią wykonany. Dlatego właśnie firewall'e co najwyżej "minimalizują straty", jak ja to lubię mówić - można oszczędzić trochę zasobów sprzętowych, ale łącze? Nie ma szans...

 

UDP Flood to broń która położy każdego. Umierają przez nią zarówno małe serwisy, jak i ogromne spółki. Nawet tacy giganci jak PayPal nie mają nic do gadania. Wystarczy odpowiednio duży botnet, który wygeneruje taki ruch, żeby zapchać całą rurkę.

 

No więc co z tym fantem zrobić?

Po pierwsze - musisz zrozumieć jak działa DDoS. Wyobraź to sobie na zasadzie hydrauliki. Jeżeli zablokujemy najmniejszą rurkę do serwera to i tak nam to nic nie da bo pakiety nadal będą zapychać ją w 100%. Jeśli chodzi o wycinanie DDoS'a to należy wycinać go na brzegówce, która jest w stanie go shandlować. Najczęściej będą to brzegówki operatorskie bądź serwerowe, do których dostępu mieć nie będziesz. Prosty przykład - Mamy 100 rurek 100mbitowych połączonych do routera 10 gigabitowego. W przypadku DDoS'a >10 gigabitowego w nasze IP odłączymy również te 100 innych rurek, ponieważ brzegówka nie będzie w stanie tego shandlować. To oczywiście bardzo uproszczony schemat, w rzeczywistości mamy tzw. redundancję łącz, IP failovery i wiele innych rzeczy, ale chcę Ci zobrazować jak to mniej więcej działa.

 

Jak się bronić?

Jedynie sprzętowy firewall postawiony przed serwerem jest w stanie nas uchronić. O ile oczywiście, jak pisałem wyżej będzie w stanie shandlować DDoS'a. Różnica jest taka, że serwer ma hostować konkretne usługi i obsługiwać userów, a nie tracić cykle procesora na przyjmowanie zbędnego ruchu, prawda? Hardware firewall jest specjalnie stworzony po to, żeby serwer mógł odbierać jedynie pożądany ruch. Jest specjalnie zbudowany tak, żeby móc wycinać bardzo duże ilości pakietów, a jednocześnie zapewnić ciągłość usługi.

 

Z góry mówię, że nie są to byle jakie koszta. Bazując na OVH, instalacja takiego firewalla to koszt ponad 700 zł jednorazowo + 100 zł na miesiąc. Zauważ, że wziąłem pod uwagę tylko najniższy pakiet ;). Właśnie dlatego wszystkie firmy, które oferują zabezpieczenia anty-ddos mają takie koszta. Do tego pamiętaj, że sam firewall to nie wszystko, jest jeszcze rurka, prawda? To już bardziej zależy od infrastruktury, ale zapychanie rurek 100mbitowych to obecnie standard, nawet rurki 1 gigabitowe padają od trochę lepszego DDoS'a. Owszem, można sobie postawić "w miarę" bezpieczną infrastrukturę - 10 albo 100 gigabitową rurkę i firewalla, który ją obsłuży. Tylko sobie teraz policz koszta, myślę że w kilkunastu tysiącach na miesiąc się nawet nie zmieścisz ;).

 

 

Trochę o ogólnej koncepcji DDoS'a było na bazie UDP Flooda, to teraz czas na pozostałe protokoły.

 

TCP wyróżnia od UDP to, że mamy tu sekwencję SYN => SYN/ACK => ACK, połączenie musi zostać "zaakceptowane" przez serwer, żeby bot mógł cokolwiek zrobić. Oczywiście jak się domyślasz może nas "zasypywać" pakietami Syn, co się w praktyce nazywa Synflood'em i jak najbardziej zdaje to egzamin, ale tylko na niezabezpieczonych serwerach. Tu już mamy większe pole do popisu, abuse po TCP jest naprawdę trudny, można limitować SYN'y per IP i per total, przez co mamy o wiele większe pole do popisu niż przy UDP.

 

ICMP działa podobnie do TCP. Głównie chodzi tu o tzw. "ping of death" efekt. Było to skuteczne na serwerach z dużym downloadem i małym uploadem bo serwer odpowiadając na ping sam się floodował. Obecnie coraz rzadziej spotykana metoda ataku, wyparta przez UDP Flood.

 

Innymi dość popularnymi atakami (a nawet najpopularniejszymi bym rzekł) są ataki DNS Amplification - polegają na tym, że botnet zamiast wysyłać pakiety bezpośrednio do serwera to pośredniczy się niezabezpieczonymi serwerami DNS, w konsekwencji raz że oszczędza na łączu (request DNS waży mniej niż rzeczywiste sprawdzenie. Można uzyskać nawet do 50x więcej mocy), to dodatkowo w logach nie zobaczymy żadnego IP zombie, a jedynie otwarte serwery DNS. Zbrodnia doskonała?

Spoiler

Tak to się mniej więcej przedstawia w praktyke, w rzeczywistości nie jest to żaden "nowy" atak, a kolejna wariacja ataku zespoofowanego, który o ile jest możliwy do wykrycia to jest to naprawdę trudne do wykonania i nie obędzie się bez ścisłej współpracy z administratorem chociaż jednego takiego serwera DNS, o ile w ogóle prowadzi jakieś logi,a serwer nie znajduje się w Chinach... Prawidłowo przeprowadzony atak DNS Amplification w rzeczywistości sieje o wiele więcej destrukcji niż "tradycyjny" UDP Flood. Do tego zawsze można się pośredniczyć tymi "tradycyjnymi" metodami, w szczególności gdy sam serwer DNS już nie wyrabia z pomocą.

 

Z tego punktu chcę, żebyś wyciągnął jeden wniosek. Nie ma 100% ochrony przed DDoS'em, nawet najlepszy firewall idzie położyć, a żadna infrastruktura nie będzie nigdy odporna na ruch "całego świata", a przecież my wszyscy możemy być zombie np. takiego Microsoftu, ktoś widział kod Windowsa? ;).

 

10) CloudFlare

Słów kilka o kolejnych warstwach ochrony należy wspomnieć. Ostatnio furorę robi niejaki CloudFlare, który muszę przyznać że nawet zdaje egzamin. Polega to na tym, że lokujemy serwer "za" chmurą CloudFlare, przez co atakujący nie zna docelowego IP i może jedynie walić "w to co widzi", a to z kolei jest warstwa CloudFlare, która na pewno ma lepsze zabezpieczenia niż nasz dedyk. Minusem jest to, że wspiera póki co jedynie HTTP(S), więc jeśli hostujesz serwer gry, serwer głosowy bądź cokolwiek takiego to niestety nie jest to rozwiązanie dla Ciebie.

 

Jest to rozwiązanie naprawdę fajne, darmowe (w najniższym planie) i poprawiające dość znacznie security. Trzeba tylko dokładnie wiedzieć jak działa cała "chmurka", żeby przypadkiem samemu sobie nie wykopać grobu po drodze...

 

Przykładowo. Mamy basic auth wspomniany już wyżej. Wszystko pięknie i cudnie, prawda? No właśnie nie, przecież CF Działa w ten sposób:

 

User [IP:1.2.3.4] ==> Chmura [IP:5.6.7.8] ==> Dedyk (IP:8.8.8.8)

Dedyk (IP:8.8.8.8) ==> Chmura [IP:5.6.7.8] ==>User [IP:1.2.3.4]

 

Tak więc wszelkie próby basic auth'a w rzeczywistości w logach pokażą się jako 5.6.7.8, a nie 1.2.3.4! Dlatego też trzeba wiedzieć dokładnie jak chmura CloudFlare działa i nie wpadać w złudne poczucie bezpieczeństwa ;).

 

Jak więc sobie z tym poradzić? Chociażby na przykładzie nginxa i bloku http, który powinno się umieścić w nginx.conf:

 
        # Cloudlare
        real_ip_header  CF-Connecting-IP;
        set_real_ip_from 204.93.240.0/24;
        set_real_ip_from 204.93.177.0/24;
        set_real_ip_from 199.27.128.0/21;
        set_real_ip_from 173.245.48.0/20;
        set_real_ip_from 103.21.244.0/22;
        set_real_ip_from 103.22.200.0/22;
        set_real_ip_from 103.31.4.0/22;
        set_real_ip_from 141.101.64.0/18;
        set_real_ip_from 108.162.192.0/18;
        set_real_ip_from 190.93.240.0/20;
        set_real_ip_from 188.114.96.0/20;
        set_real_ip_from 197.234.240.0/22;
        set_real_ip_from 198.41.128.0/17;
        set_real_ip_from 2400:cb00::/32;
        set_real_ip_from 2606:4700::/32;
        set_real_ip_from 2803:f800::/32;
        set_real_ip_from 2405:b500::/32;
        set_real_ip_from 2405:8100::/32;
Nie ma w tym zapisie nic misternego, IP'ki pochodzą z oficjalnej whitelisty, a całosć sprowadza się do dodania odpowiedniego header'a  ;). Pewno jest o wiele ładniejsze rozwiązanie tego problemu, toteż jakby ktoś znalazł chętnie wysłucham  :). Dostępne są również inne rozwiązania np. dla apache'a jeśli ktoś by szukał czegoś w tym temacie.
 
 
Co dalej?
Jak dobrze wiemy z CF'em kompatybilne są tylko niektóre protokoły. A co z SSH? A co z FTP? A co z innymi? Hmm...
 
Tu się tworzy pierwszy problem. Jeśli potrzebujemy "direct'u" tylko dla siebie (SSH/FTP), a nie dla całego świata to bardzo dobry posunięciem jest całkowity brak direct'ów na naszej domenie "docelowej". O wiele lepiej je ulokować na jakiejś domenie "ukrytej", niezwiązanej na pierwszy rzut oka z naszą. Czemu? Jeśli komuś będzie zależeć to nawet metodą brute-force (chociaż są lepsze metody) znajdzie nasz direct typu dajrekt.domena.pl, a zatem pozna IP naszego serwera i w tym momencie całe CF pójdzie się... no właśnie.
 
Tak długo póki nasza "schowana" domena nie będzie w jakikolwiek sposób powiązana z "główną", a wiedzieć o niej będziemy tylko my i ew. administracja to szanse są naprawdę nikłe i możemy mieć CF "na medal". No chyba, że ktoś wpadnie na pomysł brute-force'a naszej prywatnej domeny z poszukiwaniem jakiś directów  :).
 
Niestety często nie da się tego tak obejść i np. hostujemy poza stroną także serwer TS3. W tym wypadku bez direct'a nie da rady, rozwiązaniem pośrednim mniej bezpiecznym jest po prostu zrobienie direct'a typu ts.domena.pl, całą resztę puścić przez CF'a, a do głównej domeny ewentualnie dodać jeszcze wpis SRV. Oczywiście w tym wypadku CF nie ma już dużo do gadania bo IP jest na wyciągnięcie ręki, ale zawsze kolejny layer chociaż do głównej domeny, prawda? Rozwiązaniem ciutkę lepszym jest rozdzielenie tego na 2 niezależne serwery, wtedy jeden hostuje stronę www i ew. inne usługi (kompatybilne z CF), a drugi typowe directy. W przypadku ataku DDoS raz, że uchronimy przynajmniej ten serwer za CF, a dwa że zapewniamy sobie jakiś kontakt z userami, zawsze to lepsze niż totalny krach, oczywiście koszta, koszta i jeszcze raz koszta...
 
Podsumowując CF nawet w darmowej wersji oferuje naprawdę porządny dodatkowy layer security. Dla większości firm posiadających tylko stronę www będzie to wręcz idealne rozwiązanie, a jeśli nawet to będzie za mało to zawsze można przejść na ofertę płatną, z ochroną DDoS z prawdziwego zdarzenia. Na dzień dzisiejszy nie widzę przeciwwskazań używania CF (poza faktem, że mają "kontrolę" nad naszymi serwerami DNS  ;)). Obecnie mają serwery ulokowane w 29 datacenter na świecie, awaria jakiegokolwiek z nich nie pociągnie za sobą całej infrastruktury. Oczywiście "czas pokaże" czy z tym stwierdzeniem się zbytnio nie pomyliłem, ale sądzę, że CF naprawdę zdaje egzamin i usługa jest warta głębszej analizie.
 
11) ???
A w tym punkcie wkraczasz Ty, drogi czytelniku. Masz sugestię? Chciałbyś tutaj coś dopisać? Tak jak napisałem - człowiek uczy się całe życie. Daj mi znać, a chętnie dopiszę wszystko, co uznam za warte przeczytania.
 
Mam nadzieję, że rzuciłem trochę światła na pojęcie security, szczególnie młodym administratorom, którzy nie wiedzą gdzie zacząć. Dzięki za przeczytanie, a komentarze jak zawsze - mile widziane.

 


  • 89


#254311 Serwerownia od podstaw

Napisany przez kafi na 26 maj 2011 - 22:49

Zakładając że wymiar przeciętnego dysku 3,5" to
101,6 x 25,4 x 146,05
v = 377 cm^3

A wymiar przeciętnej szafy 42u to
2000 x 800 x 800
v = 1280000 cm^3

Więc można by przyjąć, że w szafie zmieści się ok. 3 tys. dysków.
Obecne dyski mają chyba maksymalnie 3TB, więc sumarycznie do szafy zmieści się 9PB "danych".


Osobne jest pytanie o sens przepłacania za szafę rack po to, aby robiła za półkę na dyski twarde :)
[ Post ofc. pół żartem, pół serio; ale jakie pytanie, taka odpowiedź :) ]
  • 89


#252891 Przenosiny Unixstorm do nowego DC

Napisany przez UnixStorm.org na 18 maj 2011 - 08:29

Na pewno nie opóźnienia, bo te nie są najlepsze.
...



9 ms to "nienajlepsze"? Naprawdę, jeśli mamy dyskutować to niech to będzie dyskusja na trochę poważniejszym poziomie niż "jest be bo mam 5 ms więcej niż do ATM"...

Do czego zmierzam... Pingi są lepsze niż do np. beyond.pl (1-3 ms), lepsze niż do Onetu (1-2 ms) i gorsze od ATM o około 5-6 ms. Czy ktoś analogicznie mówi, że beyond jest zły, bo ma "nienajlepsze pingi"? Albo czy dla kogokolwiek z usług hostingowych będzie odczuwalne 5-6 ms?

Jeśli już nawet mam się trzymać tematu pingów (tylko nie wiem jaki to ma sens? przecież nie będziemy tam hostować serwerów gier) to wypada wspomnieć, że będą niższe, niż u większości naszej konkurencji w Polsce, więc jak się ma do tego wypowiedź wyżej?

Tak na marginesie, nasze IP w 3SF: 91.227.122.1

W serwerach gier utarło się, że każda 1 ms to porażająca różnica mimo, że 95% tych osób zupełnie nie rozumie działania ani sieci, ani nawet własnych serwerów gier - o tym niżej.


Do czego zmierzam? Odczują prawdopodobnie pewien dyskomfort osoby, które korzystają systemu banowania AMXBans na serwerach Counter-Strike (dłużej będzie wszystko przetwarzane).

Przede wszystkim, nie żyjemy tylko Counter-Strikiem. Użytkownicy serwerów gier to nie są nasi jedyni klienci i nie mamy zamiaru tworzyć dedykowanej oferty dla klientów, którzy planują wykupywać konta za kilka zł/m-c pod pojedyncze bazy MySQL do serwerów gier, więc taki argument również mnie nie przekonuje. Mamy świadczyć jak najlepsze usługi dla wszystkich klientów, a nie skupiać się na tym, aby pewna cząstka klientów miała 4-5 ms mniej do swojej bazy MySQL...

Kolejna sprawa, o czym pisałem wyżej. Większość użytkowników serwerów gier ogranicza swoje porównania do uruchomienia "ping" z "wiersza poleceń" i na tej podstawie wysuwa wnioski, ale... czy wiesz, że serwer gry NIE wysyła zapytania do MySQL na bieżąco? Zakładając, że większość serwerów publicznych działa na 250 FPS, to każde zadanie jest przez nie wykonywane co 4 ms (!), a nie od razu. To oznacza, że na prawie każdym serwerze CS 1.6 plugin amxbans czeka około 4 ms na samo wysłanie zapytania do bazy MySQL i kolejne 4 ms czeka na odpowiedź. To daje teoretycznie 8 ms nawet wtedy, kiedy czas dostępu do bazy wynosi 1 ms. Powiedz mi teraz... czy wiedziałeś o tym i czy odczuwałeś problemy na swoich serwerach gier z powodu tych 8 ms opóźnienia?

Powiem więcej... Ludzie kupują u nas konta pod takie bazy do swoich serwerów gier w każdej możliwej lokalizacji, również do serwerów w Livenecie, Nephax lub OVH. W takim przypadku ich pluginy łączą się do nas również przez kilka ms - czy z tego powodu działają im wolniej? A co z użytkownikami, którzy konta pod bazy wykupują w innych firmach niż nasza? Poza nami prawie nie ma firm oferujących tego typu usługi w ATMANie. Oznaczałoby to, że albo 100% użytkowników serwerów gier kupuje konta u nas, albo kupują również w innych polskich lokalizacjach i nie czują różnicy.

Ponawiam, jeśli mamy prowadzić taką dyskusję to niech będzie ona poparta ciut większą wiedzą i argumentami lepszymi niż ICMP (które co więcej mogą mieć inny priorytet niż UDP). Od wczoraj już setka klientów dziala w 3SF, jak dotąd mają się bardzo dobrze i jestem pewny, że użytkownicy, o których piszesz nawet nie zauważą, że coś się zmieniło po przeniesieniu.


No nie do końca, bo de facto nie ma żadnej umowy tylko regulamin. A regulamin nie przewiduje lokalizacji. Więc jeśli potraktujemy tę tabelkę z parametrami jako ofertę (bo innej nie ma; proszę mnie poprawić, jeśli się mylę) to jednym z punktów jest lokalizacja (ATMAN). Więc klient kupuje serwer w danej lokalizacji.

Więc jeśli przeniósłby Pan serwer do Holandii, powstałby problem prawny, trochę podobny do WikiLeaks czyli właściciela danych na serwerze i prawa, któremu podlegają. Więc gdybym trzymał u siebie w mysql-u np. bazę mailingową, albo jakąś bazę konkursową (dane osobowe) i one wywędrowałyby do Holandii, to miałbym problem.

Oczywiście w tym przypadku poruszamy się po kraju, co nie zmienia faktu, że lokalizacja jest jednym z punktów oferty :)


Gdybyśmy zmieniali kraj to sytuacja wyglądałaby inaczej. W tej jednak sytuacji zmieniamy serwerownię na inną, również w Polsce. Jak zauważono, w Regulaminie nie gwarantujemy, że każde konto będzie dożywotnio w jednej lokalizacji. Zagwarantowanie czegoś takiego jest niemożliwe i podchodzi wręcz pod biznesowe samobójstwo. Żadna Polska firma takich zapisów/gwarancji nie posiada, a niektóre nawet z tego forum zmieniały lokalizacje po kilka razy - nigdy jednak nie było tego typu "ataków" z powodu zmiany DC, więc nadal nie rozumiem dlaczego my mamy być wyjątkiem...


Opis w tabeli z kontami WWW (odnośnie DC) jest od kilku miesięcy i opisuje aktualną lokalizację, a nie lokalizację, w której dożyjemy emerytury. Z innej strony.. co by było, gdyby ATMAN np. stracił łącza od TPSA? Czy wtedy też ma się wiązać z drastycznymi krokami bo klienci stracili bezpośredni dostęp z łącz TP? Albo... część klientów z ATMANa przeniosła się do Telehouse (po cichaczu) - czy tutaj też ma być sytuacja jak wyżej? Nawet mogłoby się zdarzyć, że ATMAN zrezygnuje z kolokacji w tym DC i wszyscy klienci będą musieli się wynieść np. do Telehouse - czy wtedy też mamy zamykać firmę?

Z oczywistych powodów nie da się zagwarantować zawsze tej samej lokalizacji, tych samych serwerów, tych samych łącz, tych samych pracowników i tego samego adresu siedziby firmy. Nie popadajmy więc w paranoję. Regulamin jest umową zawartoą pomiędzy nami, a klientami webhostingowymi i ta umowa zostaje podtrzymana. Nie naruszamy żadnych jej warunków, a nawet SLA zostanie zachowane po zmianie lokalizacji. Troszkę mam wrażenie, że robimy tutaj niepotrzebny szum o zupełnie normalną rzecz, która dzeje się w prawie każdej firmie hostingowej, a w niektórych nawet po kilka razy w ciągu kilku lat.

Jeśli jednak którykolwiek z naszych klientów poczuje się z tego powodu poszkodowany to jak najbardziej może napisać do nas reklamację i do każdej takiej sprawy będziemy podchodzić indywidualnie.
  • 77


#298825 Chłopak szuka pomocy w spawie ataku w unixstorm

Napisany przez UnixStorm.org na 18 luty 2012 - 10:54

Witam,

Widzę, że trzeba rozwiać kilka wątpliwości...
Przede wszystkim zacznę od tego, że osoba, która jest właścicielem tego konta nie będzie pociągana do odpowiedzialności.
W ostatnich dniach zgłosił się faktyczny sprawca wraz z przyznaniem do winy.

Jeśli chodzi o samo "zabezpieczenie", to każdy kto twierdzi, że można zabezpieczyć się przed *każdą* metodą ataku wychodzącego i przychodzącego po prostu nie wie co mówi i albo jeszcze go nic podobnego nie spotkało, albo brakuje mu trochę wiedzy w temacie aby wypowiadać się kompetentnie w takich sprawach. Zwłaszcza, jeśli nawet z jego serwerów wychodzą ataki DoS, a to zdarza się również u firm wypowiadających się w tym wątku.

To, w jaki sposób użytkownik doprowadził do problemów (krótkich, ale jednak) zostało już odpowiednio zablokowane i drugiej takiej sytuacji nie będzie.

Nie chodzi tutaj jednak o sam fakt uruchomienia tego, a o zwyczajną bezmyślność ludzi - za każdym razem "graczy Counter Strike'a" - którym wydaje się, że mogą bezkarnie robić co tylko im się spodoba, a tłumaczenie "dałem konto koledze" rozwiąże problem.
Tak nie jest. My odpowiadamy za działania naszych klientów, a klient za działania użytkowników, którym udostępnił swoją usługę.

Tutaj nie chodziło też o "włamanie" na konto tego użytkownika jak kilka osób sugerowało.
W skrócie - właściciel konta dał dostęp do FTP "koledze". Ten zaczął umieszczać wszelkiej maści śmieci na koncie i masowo je uruchamiać bawiąc się w script kiddie. Były to skrypty do ataków DoS, exploity na inne oprogramowania, itd. Chłopak z pełną premedytacją i wiedzą co robi uruchamiał to bez żadnych konsekwencji.

Takich sytuacji jest mnóstwo. I u nas, i w innych firmach. Większość nie kończy się żadnymi większymi problemami poza zablokowaniem takiego konta, ale bądźmy poważni... Najwyższy czas nauczyć się co wolno, a czego nie. Jeśli kupuję serwer w jakiejś firmie, daję dostęp do niego koledze, który następnie narusza wszelkie możliwe przepisy to mówienie, że jestem tutaj pozbawiony jakiejkolwiek odpowiedzialności jest absurdem.

Tego typu małolatów bawiących się w hackerów i atakujących strony "cs-a" kolegów są tysiące w tym kraju i będą nadal, ale to nie znaczy, że my mamy to tolerować.

Właściciel otrzymał od nas wszystkie logi, który ewidentnie pokazują kto, co i jak zrobił. Nie było tutaj przypadku ani też działań bez jego wiedzy.

Reasumując, usługa nie zostanie odblokowana bo klient naruszył warunki regulaminu. Nie jest dla nas ważne, czy zrobił to jego kolega, czy on sam. Nie będziemy jednak dochodzić dalszych rekompensat od tej osoby, a o tym co zrobić z faktycznym sprawcą będziemy myśleć później.

Raczej "trzeba się było zabezpieczać" by jeden user nie mógł wyłożyć całej sieci


Ty akurat w tym temacie nie powinieneś się wypowiadać bo z Twoich serwerów już kilkukrotnie leciał DoS/DDoS w naszą stronę.
  • 76


#346047 e24cloud.com - Beyond

Napisany przez kafi na 05 grudzień 2012 - 10:28

Fakt, faktem to tylko sprzęt i każdemu mogło się przydarzyć.

Ale czy nie przypadkiem lud bierze ową chmurzastą usługę właśnie po to, aby jakieś magiczne mechanizmy wyeliminowały jakikolwiek wpływ sprzętu? Bo sorry winnetou, awaria kontrolera macierzy powoduje całkowity pad usługi?
To czym to się różni od budżetowego VPS w jakiejś firmie nie chwalącej się obłoczkami?
  • 71


#275297 SERWERY PO HOSTING

Napisany przez Miłosz na 09 październik 2011 - 15:55

Tak coś czuje, że albertw po prostu szuka idealnego przepisu na biznes. A ten przepis mamy mu właśnie podać. W dodatku myśli, że jak ma 40-50k pln, dostęp do kilku łącz, dziesiątki maszyn, to zaraz będzie mieć setki klientów. Ba, mało tego.. mamy mu wywróżyć ile klientów upchnie na te maszyny. A potem się jeszcze rzuca, że nikt nie podaje mu dokładnej liczby.

Chcesz próbować? To próbuj! Zobacz jak łatwo jest ściągnąć klientów i utrzymać całą infrastrukturę. Nikt za ciebie nie ułoży planów hostingowych i nie powie jak ściągnąć klientów. Policzyłeś już sobie koszta? Opłaca się?
2700 netto za jedno łącze jak pisałeś, to wychodzi ponad 30k netto rocznie. A drugie łącze? Inne opłaty? Czy jak umoczysz kupę kasy, to wrócisz na forum i będziesz pisał, że ten i ten i tamten mówili tak, tak i siak, a ja straciłem miljony. Nikt tutaj nie weźmie odpowiedzialności za Twój biznes. Odpalaj, zbieraj klientów, monitoruj, testuj.. zobaczysz jak będzie się biznes kulać.

Można się także zastanowić nad zasponsorowaniem kilkuset obiadów miesięcznie dla dzieci ze szkół podstawowych.
  • 68


#359394 Polska chmura obliczeniowa Oktawave startuje w wersji komercyjnej

Napisany przez alien na 24 luty 2013 - 22:41

Ja w sporej części podzielam opinię nrm i Adama.

W stabilnych, długookresowych projektach storage TIER3 w OctaWave nie ma uzasadnienia ekonomicznego.

 

TIER-3 to jest wg. OW < 100 000 IOPS w random 4k read/write. Czyli mniej więcej klasa high-endowych rozwiązań na PCI-E. Przy czym jak na szybko przeliczyłem na przykładzie ceny Intela 910 800 GB, dwa takie dyski kosztować będą tyle ile w OW cennikowo zapłacimy za przestrzeń 800 GB TIER-3 przez zaledwie jeden miesiąc. Jasne, do tego reszta sprzętu, koszt wiedzy co kupić i jak zrobić, koszt poskładania rozwiązania (załóżmy wynajęcie zewnętrznej dobrej firmy do setupu). No niech będzie, że wyjdzie drugi miesiąc rozwiązania w OW, choć IMHO mocno w tym miejscu przeszacowałem.

 

Ale po tych dwóch miesiącach mamy rozwiązanie prawie za darmo (prąd przy cenie TIER-3 w Octawave jest już pomijalny). Przy storage'u nie podkreślałbym jakoś przesadnie kosztu obsługi, bo raz porządnie zrobione rozwiązanie jest w zasadzie bezobsługowe, z dokładnością do sprzętu zapasowego. Pamiętajmy też, że w OW dopłaca się za pakiety IOPsów w miesiącu, czego nawet nie biorę pod uwagę, aby nie komplikować (ale przy TIER-3 będzie to spory koszt wg. cennika OW.). We własnym rozwiązaniu ograniczeni jesteśmy tylko przewidywaną ilością cykli P/E. Czyli znów własne rozwiązanie górą.

 

 

Tak, rozwiązanie OctaWave w stylu TIER-3 ma sens, ma bardzo duży sens - przy małej skali.

 

Jeśli ktoś nie potrzebuje 800 GB w TIER-3, ale 5 GB to rozwiązanie OW może być niezłe. Nie potrzeba browaru, aby napić się piwa. Ale jeśli ktoś potrzebuje większy wolumen to polityka OW go odrzuci. Jak pokazuje nrm, Octawave jest bardzo mało elastyczny cenowo. Po koleżeńsku doradzę, że użytkownik na 100GB powinien mieć bardziej przekonującą go cenę, ponieważ w większym stopniu zapewnia Wam zwrot z inwestycji.

 

 

Na koniec dodam, że piszę to nie by się jakoś szczególnie dziwić. Ja rozumiem, że na takich usługach Octawave może chcieć mieć duże przebicie cenowe.

 

Ale po raz kolejny osoba z ramienia Octawave pokazuje, że na tym forum z PR solidnie przegina i po prostu czuję poważny dysonans między poziomem wypowiedzi Octawave a oczekiwanymi standardami technicznego forum.

 

Jeśli OW uważa, że w świetle mojej mocno skróconej analizy (i raczej na korzyść dla OW) nadal ich rozwiązanie jest tak skandalicznie tanie, to proszę, czekam na poprawienie moich błędów w wyliczeniach... Albo o przyznanie, że robi z czytelników tego forum idiotów.


  • 67


#332977 VPS w Polsce do 300 PLN brutto/rok

Napisany przez beliq na 30 sierpień 2012 - 01:12

Oczekiwałem jakiejś elastyczności usługodawców z ofertami, tak jak to było za dawnych lat tutaj.

Serio? Byli tu tacy, którzy dawali rabaty 10000% na usługę z uśmiechem na twarzy?
No i od kiedy sprzedaż znacznie poniżej kosztów jest definicją elastyczności? :D
  • 67


#234069 Z: Panel zarządzania kontami www

Napisany przez nrm na 09 styczeń 2011 - 14:17

Nie odpływajcie koledze od tematu, wszak nie było o kosztach. Ja wiem, że prowadzicie jednoosobowe działalności w mieszkaniach rodziców, na ogół z niskim ZUSem i praktycznie bez większych kosztów, ale powinniście chyba zrozumieć, że firmy zatrudniające ileś osób na etatach, płacące niestety ogromne koszty pracy, koszty biur i pokrewne NIE są w stanie robić softu za miskę ryżu.
  • 67


#347870 Trochę o kei.pl ale bardziej ogólnie

Napisany przez nrm na 19 grudzień 2012 - 21:06

zmyślone, nie fałszywe

Możesz mi wyjaśnić tą subtelną różnicę pomiędzy tym, że coś jest "zmyślone" ale broń boże nie "fałszywe"?!?

J.w. Podawanie nieprawdziwych danych to od razu ban na konto. Bez dyskusji. Brawa dla KEI.
  • 65


#350527 [Wrocław] Hosting Meeting #5

Napisany przez nrm na 09 styczeń 2013 - 12:06

Ludzie mówią, że zabierasz przyczepkę z sobą bo musisz gdzieś zmieścić swoje ego ;)
  • 61


#317213 Ile stron upychacie na jedną maszynę?

Napisany przez vorren na 30 maj 2012 - 06:18

Ile kanapek zrobisz z jednej szynki, sporego kawałka sera i jednego krzaka pomidorów?
  • 60


#350214 Serwer dedykowany test na 14 dni

Napisany przez nrm na 06 styczeń 2013 - 22:03

Potrzebuje serwera deydkowanego na testy do max 14dni i jesli wszystko bedzie mi pasować to biorę maszynke :)


http://www.youtube.com/watch?v=jmsghvDgwIo
  • 59


#347869 Trochę o kei.pl ale bardziej ogólnie

Napisany przez Prohost na 19 grudzień 2012 - 20:56

Większość firm od razu takie konto kasuje. Podawanie nieprawdziwych danych to oszustwo. Jak się z kimś zawiera umowę to się podaje prawdziwe dane.
  • 57


#249984 pisanie z niezabezpieczonych serwerów pocztowych

Napisany przez guziec na 25 kwiecień 2011 - 11:18

zaktualizowane i posortowane[color="#0000ff"]
[...]
vihost.pl - mail.vihost.pl
vipower.pl - smtp.vipower.pl[/size][b]

forpsi.pl - problemy ze znalezieniem serwera smtp, prawdopodobnie smtp.forpsi.net ktory odrazu odrzuca


dig forpsi.pl mx +short
10 mx.forpsi.com.

Bez urazy - ale daruj sobie te 'testy', bo widać że nie masz pojęcia o protokole SMTP ani o tym jak działają serwery poczty.

darmowe serwisy poczty łatały tę dziurę pare lat temu, prawdopodobnie w związku ze spamem niewiadomego pochodzenia
"profesjonalne" najwyraźniej przegapiły ten moment


Jaką "dziurę"? To nie jest dziura, serwery SMTP przesyłają maile pomiędzy sobą bez autoryzowania się. Jeśli na niektórych zostałeś "odpałowany" to raczej z powodów filtrów SPF, greylisty albo innych warunków o których nie masz pojęcia.
  • 53


#361607 [Opinie] Mintshost.pl

Napisany przez Pitu na 09 marzec 2013 - 16:44

Dlaczego w takim razie nie zablokujecie swojej strony? Używacie czyjegoś szablonu, którego kod żywcem skopiowaliście i na początku nie usunęliście nawet odnośników.


  • 52