Pan Kot

Niewielka bo overhead to najczęściej CPU a nie I/O. I/O to najniższy poziom, który jest realizowany przez kernel po milionie innych rzeczy wyżej, takich jak caching, dirty page, delayed allocation i więcej. Nikt nie powinien się nawet zastanawiać nad overheadem LVMa, bo wyżej masz tryliard innych rzeczy do optymalizacji, takich jak sysctl, I/O governor, async journaling w ext4 i inne, które mają o wiele większy wpływ niż rzeczy nisko-poziomowe.

Jakby włamywacze działali tak jak robaki internetowe to świat byłby o wiele piękniejszy .

Canonical wyprzedaje to co stworzył Debian? A co to ma w ogóle do rzeczy, każdy pakiet ma swoją odrębną licencję (najczęściej GNU), polecam zaznajomić się z jej zasadami, a przynajmniej kwestią sprzedaży - http://www.gnu.org/philosophy/selling.html. To co robi Microsoft z Canonicalem mam w głębokim poważaniu szczerze mówiąc, bo nie zapowiada się, żeby Windows nagle stał się open-source (chociaż są pewne ruchy w tym kierunku, ostatnio otworzyli .NETa, co poprawiło wydajność i stabilność mojego ulubionego Mono, jednocześnie zdobywając mój respekt). Jak wbudują tam basha i pełne wsparcie dla formatu ELF to być może nie będę musiał już odpalać wirtualki do kompilowania moich androidów, tylko będę mógł to zrobić natywnie bez marnowania zasobów - mi się podoba. A jeśli zażądają za to udogodnienie chociażby grosza to grzecznie podziękuję i odpalę mojego VMware. "Koniec Ubuntu" to był w momencie gdy wziął się za nieco Canonical. Ten system dzisiaj nie oferuje niczego czego Debian nie byłby w stanie zaoferować, a przy tym jego "wolność" jest pod dużym znakiem zapytania. Do dziś pamiętam jak Canonical usilnie zmieniał, aż finalnie całkowicie wymazał z historii Ubuntu manifesto. Bardzo dobrym artykułem, który oddaje moje odczucia prawie, że w 100% jest https://micahflee.com/2013/01/why-im-leaving-ubuntu-for-debian/ Jedynym pozytywem w całej tej sytuacji są developerzy, ponieważ Ubuntu chcąc nie chcąc jest najpopularniejszą dystrybucją, a to się w oczywisty sposób przekłada na rosnącą siłę debiana i całej jego struktury oraz community. Developerzy pracujący przy Ubuntu często pracują również przy Debianie, a czasem i vice versa. Nie zmienia to jednak faktu, że Ubuntu nie jest tak wolne jak Debian, a Canonical zamiast poprawiać to co wymaga poprawy (heloł, wayland dzisiaj? Xorg powinien umrzeć wieki temu) to robi nikomu nie potrzebne "ficzery' jak naprawianie Gnome'a, który nie był zepsuty (tworząc Unity), albo tworząc tego Ubuntu One, o którym nawet nie chce mi się mówić. Tak więc... z punktu widzenia zapalonego debianowca - absolutnie mnie nie obchodzi ta sytuacja, ale jednocześnie jestem zadowolony że debian pośrednio nabiera siły, nawet jeśli nie widać tego gołym okiem . A to co się stanie z Ubuntu (i czy w ogóle coś się zmieni) absolutnie mnie nie dotyczy, bo na całe szczęście Debian jest tworzony przez community, a nie przez prywatną firmę . Oczywiście, każdy używa co uważa za słuszne. Mnie po prostu Ubuntu tak mocno zraził przez te wszystkie lata, że do dziś nie wiem jak można było popsuć tak dobrą bazę jaką jest Debian. Ubuntu miał w pewnym momencie naprawdę świetlaną przyszłość i był najlepszym OSem zarówno na serwery jak i desktopy, aż w pewnym momencie wszystko się zawaliło i obecnie jest wyborem wyłącznie z powodu bardziej przewidywalnego cyklu wydań niż debian, choć wiadomo jak to się przekłada na "stabilność" tych wydań. Mój testing się pięknie aktualizuje i świetnie działa już od 5 lat, a spróbuj ubuntu zaktualizować o dwa oczka wyżej i nie spierdzielić przy tym niczego .

Jeśli nie potrzebujesz dużej mocy obliczeniowej, a w tym wypadku raczej nie - to VPS w OVH będzie najlepszy.

Zbyt dużo zależności.

Od kiedy Ubuntu był "dobry i dobrze znany"? Co do tego drugiego to mogę się zgodzić, ale jak dla mnie to 98% ubuntowych rzeczy zawdzięcza się debianowi, na palcach jednej ręki mogę policzyć rzeczywiście dobre pakiety stworzone przez Canonicala, i nie zalicza się do nich ten szpetny DE. Jak dla mnie to zawsze był, jest i będzie Debian Testing dla ubogich zamrażany co pół roku .

Tak, csf jest w stanie bardzo łatwo wykrywać roboty, które na ślepo próbują się dostać do 22 i je wyciąć zanim narobią większych szkód. Po co akceptować połączenia od robaków i tracić na nie CPU? Po co dawać im w ogóle możliwość komunikacji z sshd? Przecież można przesunąć SSH i tym samym dodać sobie jedną belkę bezpieczeństwa więcej.

Oczywiście, że standardowe usługi, które muszą działać na standardowych portach takie jak HTTP, HTTPS, SMTP czy DNS trzeba zostawić, ale już takiego FTP niekoniecznie, chyba że chcesz zezwolić na logowanie anonimowe i potrzebujesz zrobić dostęp dla każdego.

RainLoop.

Załadować modprobe zanim się wpisze lsmod.

Jak masz kernel z modułami to lsmod | grep gre (90% przypadków). Jak bez (np. w OVH), to przeczytaj sobie /proc/config.gz i sprawdź czy masz CONFIG_NET_IPGRE=y. P.S. druga metoda też zadziała przy jądrach z modułami, tyle że wtedy będzie CONFIG_NET_IPGRE=m.

Jak partycja Ci się zajedzie na 100% to już jest ten moment w którym na ogół jest "za późno". Quota pozwala na sprecyzowanie procentów i wielkości, nie wyobrażam sobie fizycznej blokady /var/log, gdzie w przypadku jednego procesu żaden inny nie będzie mógł nic zapisać (a mogą to być naprawdę istotne rzeczy, takie jak lecący bruteforce na SSH, który musi wychwycić fail2ban/lfd). Właśnie cały sens tego magicznego ustrojstwa polega na tym, że jak jeden proces oszaleje, to żeby innym się nie oberwało - partycja /var/log czy podobna zamyka 1 kryminalistę wraz z 99 niewinnymi w jednej celi, idąc zasadą, że to któryś z tych 100 musi być winny. Dla mnie - całkowicie niepraktyczne, jak spodziewam się że nginx mi oszaleje to ustawiam quotę właśnie na niego, tak żeby ani miejsce na dysku ani inne procesy nie oberwały. Flagi nosuid noexec itp. popieram, są fajne i rzeczywiście mogą mieć zastosowanie, ale obecnie jest to armata do wbijania gwoździ. Jak się nad tym głębiej zastanowisz to zauważysz, że w zasadzie przed niczym to nie chroni, bo exploity sobie znajdą jakąkolwiek inną ścieżkę, a nodiratime przy domyślnym relatime dużo nie wnosi (ba, może wnieść problemy przy używaniu specyficznych aplikacji). Poza tym limitujesz wiele programów, i nie mówię tutaj tylko o takich php i podobnych, które używają go jako cache, ale również o popsutych pakietach i "dziwnych" kombinacjach (tak, patrzę na Ciebie wine), które bez execa w /tmp nawet nie będą działać. Sam kiedyś byłem zwolennikiem takiego montowania, ale po niezliczonych problemach i po przekalkulowaniu zalet i wad stwierdziłem, że to się mija z celem. Na exploity jest grsec, a na zapełnianie miejsca quota. Oczywiście, to tylko moje podejście, i nie twierdzę że tworzenie /tmp czy /var/log jako oddzielnej partycji musi być złe z definicji. Po prostu nie uważam tego za jakikolwiek dobry powód do tworzenia oddzielnych partycji, to może być "ekstra" dodatek jeśli już znajdziesz jakiś konkret dlaczego chcesz to rozbić na kilka partycji, ale na 100% nie jako główny powód.

Zacznij od http://www.webhostingtalk.pl/topic/41538-security-na-debianie-fakty-i-mity-poradnik/ - trochę się już zestarzał, ale nadal żywy, może kiedyś znajdę chwilę, żeby to odświeżyć. Nie polecam pisać wszystkich regułek iptables samemu, w tym celu można np. użyć CSF, który lepiej to wszystko przygotuje i się tym zajmie. Oprócz definiowania otwartych portów warto też definiować jakiego stanu się spodziewamy. Przykładowo, pierwsza regułka jaka się powinna znaleźć w firewallu to zezwalanie na wszystkie połączenia TCP w stanie RELATED oraz ESTABLISHED. Jak masz taką regułkę, to możesz sprecyzować, że pakietów na porcie 22 (lub jakimkolwiek innym, jak już go zmienisz) spodziewasz się tylko w stanie SYN, z racji że wszystkie inne albo podpadają pod RELATED/ESTABLISHED, albo są nieautoryzowane (nieprawidłowe) i absolutnie nie chcemy tracić na nie więcej zasobów niż to wymagane. Praktyczne porady? Są w linku wyżej. Najważniejsze - wyrzucić usługi, z których korzystasz na niestandardowe porty (zmiana 22 SSH to podstawa). Firewall ze wszystkimi trzema łańcuchami obowiązkowo na DROP + regułki, które jak najbardziej dokładnie precyzują jakiego ruchu się spodziewasz. Sama obsługa SSH to tak jak powiedziałem 2 regułki - SYNy input na konkretny port, i obsługa related/established.

Oczywiście, że dużo gorszy - zwykłe DV masz od LE albo nawet darmowego StartSSL czy WoSign.

Tyle, że do VPSa nie dokupisz drugiego dysku, a jeśli to zrobisz do dedyka to pierwsze co zrobisz to zaorasz całość i postawisz RAID1, a nie LVMa na dwa dyski. Przy swapie chodziło mi o jego użycie.

Twój serwer jest akurat bardzo łatwo dostępny, a to co robisz nie dość że nie ma ŻADNEGO SENSU z punktu widzenia potencjalnego kupującego, to jeszcze łamie regulamin kimsufi, za co bardzo szybciutko możesz dostać bana na wszystkie swoje jakże ważne dedyki w panelu. Tak więc radzę zamknąć temat i nie próbować nikogo naciągnąć, zanim jakiś miły użytkownik złoży report na abuse@ovh.net.

Za dużo pytań, na które odpowiedzi można znaleźć w linku powyżej, więc tylko dodam 3 grosze tam gdzie uważam to za słuszne. Jeśli nie ma szyfrowania, to robienie oddzielnej partycji /boot jest głupotą i anarchizmem z kernela 2.4, gdy rzeczywiście miało to sens, z racji że można było na tej partycji robić wiele rzeczy takich jak ustawianie flagi boot, wrzucenie tam gruba (zamiast do mbra) i więcej. Obecnie nie ma to żadnego sensu (poza szyfrowaniem, o którym za chwilę) i jeśli nie masz dostatecznie dobrego powodu, żeby robić taką partycję to sobie odpuść. Jeśli chcesz mieć łatwą możliwość skalowania/resizowania partycji, to obowiązkowo trzeba wrzucić to do LVM. Najlepiej wszystkie partycje, czyli cały dysk, bo tylko takie rozwiązanie ma jakikolwiek sens, chociaż nie widzę żadnego sensu w partycjonowaniu serwera w 2016 roku. Po co chcesz stworzyć dodatkowe partycje? Jaki masz w tym cel? Mi jest znany tylko jeden dobry powód - szyfrowanie, ale do tego jeszcze wrócę jak napisałem wyżej. Dawno temu robiło się zabieg mający na celu rozrzucenie "zapełniających się" ścieżek takich jak /tmp czy /var/log na oddzielne partycje, żeby upewnić się, że nie zajadą dysku na 100% i będzie możliwe zalogowanie się do serwera. Ja uważam to za kompletny bezsens, od tego jest logrotate i syslog, żeby poprawnie skonfigurować te aspekty, a w najgorszym przypadku quota od limitowania konkretnych ścieżek. Po co sobie robić fizyczne bariery, gdy można zrobić wirtualne. I teraz dochodzimy do magicznego szyfrowania. Powiem to od razu, zanim w ogóle przejdę do szczegółów. SZYFROWANIE NA SERWERACH NIE MA ŻADNEGO SENSU, więc wybij sobie to z głowy zanim w ogóle się na to zdecydujesz, a żeby nie zostać gołosłownym to już mówię dlaczego. PO PIERWSZE, jeśli chcesz szyfrować rootfs czyli /, to obowiązkowo musisz zrobić dodatkową NIEZASZYFROWANĄ partycję /boot, na której ustawi się kernel z grubem. Żeby odszyfrować dysk potrzebujesz zbootowany kernel, który ma odpowiednie do tego narzędzia - sam bootloader GRUB, i to jeszcze umieszczony w 446 bajtach mbra (o ile ktoś nie ma GPT), nie ma żadnych narzędzi do odszyfrowania dysku, więc skończysz z niebootującym serwerem jeśli tego nie zrobisz. Następna kwestia, ext2 to kolejny anarchizm, którego się już nie używa. Partman w debianie nadal go proponuje na partycję /boot głównie z tego powodu, że nadal pozostaje bardziej kompatybilny ze starym sprzętem, starym grubem, starymi windowsami i starymi biosami, ale jeśli nie masz setupu z 2001 roku, i nie próbujesz zainstalować debiana 3.1 Sarge, to absolutnie nie ma żadnego powodu do pakowania się w ext2, który jest o wiele bardziej podatny na awarie niż ext4 z journalingiem. Teraz przechodzimy do sedna całego szyfrowania. Czy zdajesz sobie w ogóle sprawę PO CO szyfrujesz dysk? Po to, żeby nieuprawniona osoba mająca dostęp do dysku twardego twojego serwera nie była w stanie go odszyfrować i wejść w posiadanie informacji z niego. Teraz przeczytaj co sam napisałeś - jeśli serwer ma w ogóle się bootować, to musi znać to hasło. Jeśli zna to hasło, a dostęp do dysków ma wyłącznie twój provider (hosting), to po jaką cholerę utrudniasz sobie życie, degradujesz wydajność i mocno komplikujesz cały serwer? W imię czego przepraszam, że jak włamywacz włamie się do wybitnie strzeżonego DC, rodem z mission impossible, to wejdzie w posiadanie dysku z twojego serwera, a USB z hasłem już nie? Albo może myślisz, że jak policja zrobi wjazd na dyski to oczywiście będą tak wybitni, że na wiadomość o wymaganym kodzie do odszyfrowania rozłożą ręce, włożą dysk z powrotem i pójdą szukać dalej? Jeszcze wybitniejszym pomysłem jest szyfrowanie tylko jednej partycji takiej jak /home, i trzymanie klucza deszyfrującego bezpośrednio na partycji rootfs, jeszcze najlepiej w skrypcie na starcie co deszyfruje /home. To już są wybitne przypadki osób, które minęły się z powołaniem. JEDYNE zastosowanie szyfrowania na serwerach jest wtedy, gdy masz do niego albo fizyczny albo przez KVM dostęp, jesteś w stanie zarówno psychicznie jak i fizycznie wpisywać hasło przy każdym reboocie serwera, i dane są na tyle ściśle tajne, że nigdzie tego klucza nie zapisujesz i nikomu on nie jest użyczany. BTW, nawet w tym wypadku osoba robiąca wjazd na dysk po prostu sfreezuje aktualny stan serwera (są do tego specjalne narzędzia) i zrobi kopię dysku dokładnie taką jaka jest, a ty nawet nie zauważysz, że coś się dzieje. Szyfrowanie ma sens gdy komputer jest wyłączony, dyski i pamięci zimne, a policja robi Ci nalot na chatę i wyjmuje dysk. Wtedy z uśmiechem na ustach możesz powiedzieć "oj panowie, chyba zapomniałem klucza". Serwer z definicji działa 24/7, czyli jedyny powód do szyfrowania dysku automatycznie przestaje mieć jakiekolwiek znaczenie. I finalnie podkreślam, że szyfrowanie nie jest darmowe, degraduje wydajność I/O oraz CPU i nie ma żadnego zastosowania na serwerach, co zaznaczyłem zanim w ogóle zacząłem wyjaśniać dlaczego. Poza tym, kupując VPSa w firmie w 99.9% przypadków nie będziesz miał nawet MOŻLIWOŚCI zmienić układu partycji, zawsze będziesz miał jedną partycję rootfs i ew. swap (też nie zawsze). A jak partycjonujesz dedyka to jeśli nie masz dostatecznie dobrego powodu do rozrzucania tego na kilka partycji, to tego nie robisz - rootfs i swap, nic więcej, nic mniej, i żadne LVMy tylko fizyczne partycje. Swap ustawiasz na nie więcej niż 2 GB, bo w przypadku zajechania hdd 2 GB swapu i tak serwer będzie całkowicie zamrożony i nieresponsywny. Poza tym jeśli zajdzie ogromna potrzeba, zawsze można zrobić swap w pliku i włączyć go jako ekstra. TL;DR - rootfs na ext4, i max 2 GB swapu I lepiej traktuj swoją wirtualkę na vboxie jak pełnoprawnego dedyka, bo VPSy z którymi się spotkasz w najlepszym wypadku będą miały KVMa i będą przypominać takiego dedyka, a w najgorszym i średnim będą zwykłymi wirtualkami na OpenVZ.

Webh nie ma żadnej ochrony anty-ddos, a blackholing nie jest żadną ochroną. Od siebie polecam OVH, które powinno dostatecznie dobrze chronić ten serwer, vps na ssd kosztuje tam bagatela 5 euro na miesiąc, czyli 20 zł, powinno wystarczyć na start.

Porównanie z przysłowiowych czterech liter - prawidłowa alegoria byłaby gdybyś twierdził, że Słońce krąży wokół Ziemi bo tak dawno temu ktoś powiedział, zamiast wierzyć Kopernikowi, który twierdzi zupełnie inaczej, tylko dlatego że stare stwierdzenie jest "prawidłowe i sprawdzone". I tak, twierdzę że korzystanie z przestarzałej technologii, która nie jest już rozwijana mając nowsze i dużo lepsze alternatywy to czysta ignorancja lub skrajne lenistwo, często połączone z obawą przed technologią i głupotą. Sam Linus Torvalds kiedyś się odniósł do tej kwestii w bardzo negatywnym świetle, a jeśli ktoś żyje w takim ciemnogrodzie, że sam nie zauważa problemu w używaniu kernela z bazą sprzed 13 lat to ja jestem ostatnią osobą, która kogokolwiek namówi do swoich racji . Wystarczy tego offtopu swoją drogą.

Ale co to jest? Czas liczony od pierwszego pakietu TCP, od dostania strony przy pomocy GET / czy do pełnego załadowania? Bo to są 3 różne rzeczy, które nijak się mają do siebie. To co liczy się dla usera to czas ładowania, od momentu gdy strona jest już wczytana i się doładowywuje, do momentu pełnego jej wczytania. Moja strona wczytuje się (w pełni) w ciągu 1.06 sekundy, i jest to wynik o 88% lepszy niż wszystkie inne testowane strony, wg pingdoma. Jeśli to 600 ms to czas całkowitego ładowania się strony, to jest dużo lepiej ode mnie, i nie widzę tu żadnego problemu. Jeśli natomiast tak nie jest (a dam głowę, że tak nie jest, bazując na innych odczytach) to należy się zastanowić dlaczego sprawa ma się tak jak się ma, czy winne jest łącze, aktualny routing, czy sam serwer który się nie wyrabia z odpowiedzią w czasie, a jak tak to dlaczego. Ślepo uważam, że w momencie skoków firma obsługująca twój serwer robi backupy lub inne prace konserwacyjne, które znacząco obniżają wydajność serwera, i stąd bierze się ten wynik. Być może I/O jest mocno orane i zanim web server się dokopie do plików to chwilę trwa, to jest najbardziej prawdopodobna wersja. Czy warto się przejmować? Według mnie nie, choć jeśli rzeczywiście są to odczuwalne dla ciebie utrudnienia (bo np. właśnie w tym czasie masz najwyższy ruch) to należy udać się na VPS/dedyka, gdzie masz pełną kontrolę nad tym jakie procesy się odbywają. A NAJLEPIEJ, to zgłosić się do supportu swojej firmy z pytaniem czym te wyniki są spowodowane, bo być może wystarczy ograniczyć "agresywność" backupu lub innych używanych rozwiązań i skoki nie będą zauważalne. A na pytanie "jakimi wartościami należy się przejmować" odpowiedź jest prosta - tymi, które wkur*iają userów. Nie ma konkretnych wymogów i różne serwisy odpowiadają w różnym czasie, ale generalnie jeśli strona odpowiada "za wolno", gdzie "za wolno" jest najczęściej precyzowane na powyżej 5 sekund, to należy się zastanowić dlaczego tak się dzieje. Tyle tylko, że te 5 sekund to czas ładowania, czyli od momentu wysłania requesta do załadowania przynajmniej podstaw strony (które się jeszcze doładowywuje), jeśli w twoim przypadku 600 ms to czas w którym user dostaje pierwszy plik od web servera, to cały serwis powinien się wczytać w nie więcej niż 1,5 sekundy.

Serio sądzicie, że ktoś traciłby czas na wystawianie takiego fake'owego ogłoszenia, żeby pogrążyć firmę, która już i tak znajduje się na dnie? Ja wątpię, ale w zasadzie to mnie to niewiele obchodzi, bo niezależnie od tego czy to by była prawda czy nie to zaufanie tej firmy będzie stało na poziomie 0 i niżej już nie zejdzie.

Wychodzenie z założenia, że wersja, która początkowo powstała 13 lat temu jest "dobra" bo ktoś do dzisiaj ją wspiera i jej używa jest tak zacofanym podejściem, że nawet nie chce mi się przedstawiać argumentów dlaczego jesteś głęboko w błędzie.

I jak już się nauczysz tego basha to popraw to `` w $() bo mamy 2016 rok.

O ile nic się nie zmieniło odkąd ostatni raz używałem tej komendy (a było to jakiś czas temu), to oczywiście że tak, jakby tak nie było to bym ci kazał zrobić cp -pr .

Nie, i dlatego też nie należy degradować wydajności (np. stawiając oddzielne instancje php-fpm, które nie mogą współdzielić cache'a) na rzecz wyimaginowanego bezpieczeństwa. Jeśli aplikacja wspiera chroota (bind wspiera), lub zapewnia inne możliwości kontroli dostępu (patrz php i open_basedir) to jailowanie powinno być ostatnią rzeczą na jaką się decydujemy, po zadaniu sobie pytań czy to co robimy jest warte zachodu. To co warto jailować to pojedyncze aplikacje, w szczególności te którego kodu nie możemy być pewni (patrz TS3), a nie te których zjailowanie spowodowałoby poważne utrudnienia w administracji czy nawet degradację wydajności (tak jak w przypadku php-fpm). Z chroota jak najbardziej warto korzystać, w szczególności jeśli aplikacja sama go oferuje.