Koty na WHT, Fakty i Mity + Poradnik

[ToFFiK 33]

Korzystam z fail2ban'a od jakiś 2 lat, i też po instalacji nie było z nim żadnych problemów mimo licznych ataków, nawet na defaultowym konfigu dobrze chodzi (chyba że pozmieniamy porty, to cfg też trzeba w fail2ban zmienić)

 

Zmiejszenie przez niego zżeranej pamięci"

Dopisać do

 

/etc/default/fail2ban

na końcu

 

ulimit -s 256

Działa wg. mnie stabilnie z tą zmianą, a z ~200MB zużycie zmniejsza się do paru MB

[Pan Kot 1535]

Akurat port nie ma nic do rzeczy, fail2ban analizuje logi, a ścieżka logów się nie zmienia przy porcie .

[ToFFiK 33]

No tak, pomyliło mi się z innym programem

[Pan Kot 1535]

Ewentualnie port może mieć znaczenie przy banowaniu opcją iptables-multiports zamiast iptables-allports, ale zakładam że raczej warto banować "całkowicie", a nie jedynie dla danego portu .

[bryn1u 17]

Witam.

 

Bardzo ciekawy i pomocny tutrialik, wiec postanowilem sie pobawic na dedyku z vKVM. W sumie zrobilem wszystko wedle instrkucji i po reboocie juz nie moge sie dostac do servera. Zalogowalem sie do konsoli KVM i jedynie co to dostake takie cos:

Edytowano Luty 9, 2013 przez bryn1u (zobacz historię edycji)

[Pan Kot 1535]

"Can't work without intel_agp module!" "couldn't mount because of unsupported optional features"

 

Nabroiłeś z ext3 i grafiką, zbootuj ze starego kernela i jak chcesz się bawić zacznij od make defconfig i nie ruszaj ext3 oraz intel_agp (zaznacz jeśli jest odznaczone).

[bryn1u 17]

"Can't work without intel_agp module!" "couldn't mount because of unsupported optional features"

 

Nabroiłeś z ext3 i grafiką, zbootuj ze starego kernela i jak chcesz się bawić zacznij od make defconfig i nie ruszaj ext3 oraz intel_agp (zaznacz jeśli jest odznaczone).

 

Nie mam w ogole ext3. Zrobilem z make defconfig.

[Pan Kot 1535]

Dziwne, make defconfig powinien standardowo włączyć ext3. Włącz go w takim razie manualnie w filesystem options kernela.

Edytowano Luty 9, 2013 przez Archi (zobacz historię edycji)

[bryn1u 17]

I wielkie nic.

Skopiowalem OVH config do /usr/src/linux-3.2.38, wpierw nalozylem grsec, poszlo bez problemu pozniej config. Kompilacja tez przeszla bez blednie. Podczas menuconfig sprawdzilem czy sa zaladowane moduly. SA ! Zainstalowalem nowe jajko dpkg -i *.deb, ktory sie znajdowal w /usr/src i po rebocnie jedno wielkie g... A najlepsze jest to, ze jak odpalam server z pierwotnego jajka to tez nie wstaje. Juz wiem czemu ludzie nie lubia linuxa.

Kernel nowy 3.2.38-grsex



Kernel stary 3.2 - OVH




I co mozna zrobic oprocz strzelenia sobie w leb ?

[Pan Kot 1535]

Sprawdzić GRUB'a, OVH'owski kernel to plik "statyczny", on nie ma prawa się zepsuć, za to bootloader może...

[Pan Kot 1535]

Z racji, że akurat miałem ostatnio styczność z fallback'iem grub'a to dopisałem odpowiednią linijkę do punktu 1A, żeby już nie narażać Was na reinstalację dedyków od samego zera .

[Pan Kot 1535]

Update: Dodano kilka słów od DNS Amplifiaction w podpunkcie o atakach sieciowych oraz wpis o CloudFlare został poszerzony o cały punkt przeznaczony dla tej usługi.

 

Uwagi jak zawsze mile widziane.

 

P.S. Żądam zwiększenia maksymalnej ilości emotikonek w poście! Aż tak dużo ich nie używam .

Edytowano Kwiecień 2, 2013 przez Archi (zobacz historię edycji)

[mynod3 0]

Warto też wspomnieć o AppArmor i SELinux jako alternatywę dla grs, choć z tego co czytałem wymagają większego doświadczenia niż grs. Zresztą jest też chyba tak, że jak się chce zainstalować grs to trzeba wyłączyć App Armor lub SELinux zależnie od dystrybucji - tak mi się wydaje przynajmniej.

 

Archi mam pytanie bo zawsze mnie to ciekawiło. Co się dzieje po kompilacji własnego kernela z aktualizacjami? Trzeba umieszczać jakieś dodatkowe rezpozytoria zeby te patche działały? A co z oficjalnymi updateami np. jak się robi upgrade dystrybucji do nowej wersji? Nie nadpisze się kernel?

 

Swoją drogą ciekawy temat.

[t4t4v4 3]

apt-get nie wpływa na kernel z tego co mi wiadomo..

apr-get upgrade nie nadpisuje kernela do nowej wersji - aktualizuje tylko apki i zmienia numerek systemu.

[Pan Kot 1535]

Generalnie jest tak, że kernel może być dostarczony w kilku wersjach. Standardowe dystrybucje debian/ubuntu (ale takie oryginalne z .iso) mają kernela zarządzanego apt-get'em. To się zgadza i w przypadku nowej wersji (i aktualizacji) numerek się zmienia, a nowy kernel jest dodawany do systemu + jako pierwszy bootowalny w grubie (no chyba, że ktoś ma customowe settingsy). Wyjątkiem jest fakt gdy jest to jakiś bugfix i numerek kernela się nie zmienia, wtedy jest nadpisywany na ten stary.

 

Jednak nie zawsze to tak wygląda. Przykładowo debian/ubuntu dostarczany przez OVH w dystrybucjach serwerowych w ogóle nie używa tego sposobu. Zamiast tego dostarczany jest obraz statyczny już skompilowanego kernela i z tego obrazu system bootuje. Różnica jest taka, że oczywiście apt-get go nie wspiera, ale jak najbardziej z takich kerneli również da się bootować, no i najczęściej dostarczają mniej problemów, jako że są "statyczne".

 

Generalnie apt-get jest ściśle związany z DPKG i wszystkie kernele, które nie są dostarczane jako static pliki, a instalowane za pomocą dpkg (tak jak np. nasz własny) się tam znajdą. Za pomocą komendy dpkg -l linux-* można wyszukiwać zarówno bibliotekę libc, headers'y (o ile są dostępne) jak i sam plik linux-image. W ten sam sposób można też kernele odinstalować.

 

Cała kompilacja kernela polega na ściągnięciu źródeł, potrzebnych pakietów do kompilacji (build-essential, gcc i jeszcze kilka), ewentualne zaaplikowanie patchy, stworzenie configa, skompilowanie całości i zainstalowania. Nic poza tym nie jest wymagane, jako że kernel linuxowy jest kernelem monolitycznym i kompiluje się jako jeden wielki bąbel.

 

Jeśli instalujesz kernela przez apt-get'a to apt-get ściąga już skompilowaną przez programistów wersję, którą dpkg po prostu instaluje. Dokładnie identycznie to działa jak u nas z tą różnicą, że nie przechodzimy przez fazę ściągania źródeł i kompilowania. No i oczywiście taki patch jest wtedy kompatybilny z apt-get'em.

[Zoel 9]

Ktoś tutaj pisał o fail2ban - da się go przyspieszyć (czy z racji jego budowy nie)? Pomimo ustawionej blokady po 3 próbach nieraz się ocknie jak w logach jest już 10 wpisów..

Edytowano Kwiecień 14, 2013 przez Zoel (zobacz historię edycji)

[Pan Kot 1535]

 

First of all, remember that Fail2ban is a log parser. It cannot do anything before something is written in the log files. Lots of syslog daemons buffer their outputs. This can impact performance of Fail2ban. Thus, it could be good to disable buffering of your syslog daemon.

It is quite difficult to evaluate the reaction time. Fail2ban waits 1 second before checking for new logs to be scanned. This should be fine in most cases. However, it is possible to get more login failures than specified by maxretry.

[Zoel 9]

Odnośnie Cloudflare warto wspomnieć o mod_cloudflare do Apache który zamienia IP z CF na prawdziwe.

Edytowano Kwiecień 14, 2013 przez Zoel (zobacz historię edycji)

[Pan Kot 1535]

Odnośnie Cloudflare warto wspomnieć o mod_cloudflare do Apache który zamienia IP z CF na prawdziwe.

 

Dodałem .

[Zoel 9]

Odnośnie DoS (jedno D):

 

I am under DoS attack. My cloud based server hosting company asked me to enable TCP SYN cookie protection to save my domain from SYN Attack. How do I turn on TCP Syn cookie protection under Ubuntu or CentOS Linux based server?

 

http://www.cyberciti.biz/faq/enable-tcp-syn-cookie-protection/

[Pan Kot 1535]

Odnośnie DoS (jedno D):

 

 

http://www.cyberciti.biz/faq/enable-tcp-syn-cookie-protection/

 

Od dawna w sysctl .

 

# Turn on syncookies for SYN flood attack protection

net.ipv4.tcp_syncookies = 1

[mynod3 0]

Mam kilka pytań odnośnie bezpieczeństwa, to są pytania z serii - "zawsze chciałem się o to zapytac ale się wstydziłem"

 

1. Czy przy pierwszej konfiguracji vps-a/dedyka (instalacja serwera, baz, firewalla) powinno się pracować na roocie czy przez sudo na userze? Ja to robie z roota a dopiero później blokuje roota jak już wszystko poinstalowane - ma to jakieś znaczenie w ogóle? Taka kolejność? Wydaje mi sie, że niektórych rzeczy nie da się zainstalować poprzez użytkownika + sudo.

 

2. Co się dzieje z vpsem/dedykiem podczas dużego ddosu po udp, takiego, że programowy firewall nie jest w stanie go ogarnąć - szczerze to nigdy nie byłem ofiarą ddos - czy np. dedyk po prostu się wyłącza czy ciągle zamula? Czy może się uszkodzić maszyna? system?

 

3. Jaki polecacie IDS (tylko Tripwire przychodzi mi do głowy) oraz jaki dobry i prosty program do monitorowania ale taki, który by współpracował (bądź nie kolidował) z nginx oraz mariadb?

 

4. Czy da się z vpsa zrobić firewall i połączyć go z drugim vpsem na którym byłyby docelowe strony? Tak, żeby atakujący nie znał prawdziewgo ip gdzie stoi strona? O czym powinienem poczytać?

 

Z góry dzięki za odp

[t4t4v4 3]

1. Rób przez root'a, później wyłącz dostęp z zewnątrz na niego

2. Nic się nie dzieje.. DDoS to najbardziej prymitywny atak, który tylko zatyka łącze.
3. Munin
4. Można kombinować, tylko po co? Od maskowania IP masz chociażby CloudFlare.

[Pan Kot 1535]

1. Sudo to nic innego jak wykonywanie danej komendy na przywilejach roota. Zapewnia dokładnie taką samą kontrolę jak root, co więcej. Poprzez komendę sudo -i logujesz się na roota poprzez sudo, a więc nie masz już żadnych ograniczeń i komendy możesz wykonywać bez sudo. Co jest lepsze? Zależy, ja od zawsze mam roota domyślnie włączonego, tyle że po logowaniu kluczem więc brute-force tu nie zadziała, a jakby mi ktoś przejął klucz ssh to i tak by się dostał więc nie jest to ważne czy user czy root.

 

2. Oczywiście, że się dzieje. Chyba avatat nigdy nie miał doczynienia z DDoS'em . Kernel przyjmuje na klatę pakiety, a zatem wzrasta znacznie zużycie CPU, jeden wątek (thread) jest praktycznie całkowicie zatkany i nie ma żadnej opcji cokolwiek z tym zrobić. M.in dlatego też jeśli masz VPS'a bądź dedyka z tylko jednym thread'em (nie mylić z rdzeniem) to DDoS rozłoży Ci zarówno łącze jak i CPU.

 

3. Pytanie czy w ogóle potrzebujesz IDS'a. W rzeczywistości podążając za moim poradnikiem otrzymujesz out-of-box rozwiązanie i wystarczy analiza tego, co Ci wysyła CSF + Fail2Ban, nie ma opcji żeby CSF ukrył przed nami coś, co chcemy zobaczyć. IDS to po prostu taki nasłuchiwacz wszystkich pakietów, który je analizuje i ew. prowadzi jakąś akcję. Rzekłbym, że grsecurity też pełni rolę IDS'a, a konkretniej to pax z jego active response to attacks. Nie widzę żadnej potrzeby pośredniczenia się zbędnymi dodatkami kiedy mamy CSF'a i grseca. A co do monitoringu to munin rzeczywiście jest dobry, mamy jeszcze zabbixa, a ja osobiście korzystam tylko z cronowych checków danych usług w webminie, ponieważ nie potrzebuję nic więcej.

 

4. Oczywiście, że się da. Funkcja forward w sysctl + odpowiednie reguły mangle i jedziesz. Przecież dokładnie tak samo działa jakikolwiek VPN.

[kafi 2425]

Sudo to nic innego jak wykonywanie danej komendy na przywilejach roota.

Niekoniecznie na prawach roota.

 

 

 

Zapewnia dokładnie taką samą kontrolę jak root, co więcej.

Przy debilnej konfiguracji owszem. Ale można przecież pobawić się w ograniczenia dostępu w pliku sudoers

i stworzyć sobie np. klika poziomów dostępu do komend.

 

 

 

Funkcja forward w sysctl + odpowiednie reguły mangle i jedziesz

I po krótkiej jeździe dostaniesz informację, że serwerowniowy IPS wykrył emisję niedozwolonych pakietów

i nastąpił interface Ethernet 12/20/222 shutdown

 

 

 

4. Czy da się z vpsa zrobić firewall i połączyć go z drugim vpsem na którym byłyby docelowe strony? Tak, żeby atakujący nie znał prawdziewgo ip gdzie stoi strona? O czym powinienem poczytać?

Musisz postawić na tym drugim VPSie serwer proxy. Czy to nginx, squid, czy to prymitywny DNAT z użyciem iptables.

Tylko wtedy musisz pamiętać, że stockowo na docelowym serwerze jako REMOTE_ADDR dostaniesz IP serwera proxy a nie klienta.

 

---

 

PS: Czytając sobie ten początkowy post - za sugestię użycia paczek od debiana sarge (3.1 !!) powinieneś dostać solidnie po łapkach Przecież to nie ma prawa stabilnie działać (chociażby ze względu na problemy z wersjami bibliotek dynamicznych).

Edytowano Maj 1, 2013 przez kafi (zobacz historię edycji)