Re: atak na serwer www - apache 1.3.x
Hej Bieniu, czy podzielisz się informacją jak zakończyła się sprawa z tym atakiem ddos - czy squid załatwił sprawę? On Thu, 9 Feb 2006, Marek Wyrzykowski wrote: Dobre i trafne Twoje pytanie to, czy squid da radę obsłużyć milion hitów/24h. Kto wie niech się odezwie :-) Znalazłem na stronie ... squida testy (http://www.squid-cache.org/Benchmarking/), z których wynika, że podwójny Pentium III 550Mhz (ale z FreeBSD) był wstanie obsłużyć nawet 480 zapytań/sek w szczycie, a przez okres około 12 h zapytania nadchodziły z prędkością ponad 350/s (to daje około 15 mln zapytań/12 h) - http://www.squid-cache.org/Benchmarking/Surrogate07/rrd/ Na podstawie tego artykułu - 1 mln. powtarzalnych zapytań/na dobę na nowocześniejszej maszynie Bienia nie powinien być problemem (zwłaszcza, że pliki mogły być puste), ale z testami to różnie bywa, stąd moje pytanie o finał historii. Pozdrawiam, Marek -- Pewnego dnia zostanie szuflada i klisza i cisza na pewno cisza zamiast ja Raz, Dwa, Trzy
Re: atak na serwer www - apache 1.3.x
Witaj Marek, W Twoim liście datowanym 24 lutego 2006 (12:42:18) można przeczytać: Znalazłem na stronie ... squida testy (http://www.squid-cache.org/Benchmarking/), z których wynika, że podwójny Pentium III 550Mhz (ale z FreeBSD) był wstanie obsłużyć nawet 480 zapytań/sek w szczycie, a przez okres około 12 h zapytania nadchodziły z prędkością ponad 350/s (to daje około 15 mln zapytań/12 h) - http://www.squid-cache.org/Benchmarking/Surrogate07/rrd/ Na podstawie tego artykułu - 1 mln. powtarzalnych zapytań/na dobę na nowocześniejszej maszynie Bienia nie powinien być problemem (zwłaszcza, że pliki mogły być puste), ale z testami to różnie bywa, stąd moje pytanie o finał historii. ustawilem ze squid ma dawac denied dla tych plikow: TCP_DENIED/403 1410 GET q.jpg dzisiejszy access.log wena:/var/log/squid# wc -l access.log 92426 access.log a to wczorajszy wc -l access.log.1 349108 access.log.1 wiec jak widac squid praktycznie spi, zarazone komputerki lacza sie do niego i dostaja denied :), pozostaje pokombinowac zeby podawal im puste pliki lub jakas fajna niespodzianke zamiast tablicy z access denied, ale ogolnie jest to bardzo dobre rozwiazanie, apache sobie teraz smacznie spi a squid nawet tego nie odczuwa jak tylko cos jeszcze uda mi sie stuningowac dam znac, wszystkim ktorzy pomogli w tej niecodzinnej sytuacji - dziekuje p.s. moze ostatecznie za pol roku sie to skonczy :D i poaktualizuja komputerki ludzie heheh -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
06-02-14, Szymon Nieradka [EMAIL PROTECTED] napisał(a): Marek Wyrzykowski napisał(a): Paweł Tęcza napisał(a): Pytanie tylko, czy squid obsluzy milion hitow dziennie, skoro Apache sobie nie poradzil z taka ich liczba... Poza tym kolejna usluga to przeciez zuzycie kolejnych zasobow. Dobre i trafne Twoje pytanie to, czy squid da radę obsłużyć milion hitów/24h. Kto wie niech się odezwie :-) Baj de łej, czy nie byłoby najłatwiejszym rozwiązaniem postawienie po drodze jakiejś maszynki (chociażby pentium 60 ;) 128 mb ram ) z dwoma NICami z regułĸą iptables ? Załatwi całkowicie ten problem i potencjalnie inne, nie obciąży ci maszynki, pozwoli lepiej sterować ruchem w razie podobnych problemów, ogólnie jest miłym i nie chamskim rozwiązaniem(tm) ? _Jedyne_ co trzeba mieć to taka maszynka ;) . pozdrawiam. -- Pozdrawiam, Wojciech Ziniewicz| [EMAIL PROTECTED] Powered by google.com | [wanna gmail?] http://silenceproject.org | :E
Re: atak na serwer www - apache 1.3.x
Witaj bieniu, W Twoim liście datowanym 10 lutego 2006 (20:33:08) można przeczytać: kurcze proboje dac squida jako transparent accel dla apacha - sytuacja wyglada tak: serwer apache chodzi na porcie 80 i ma wirtualki porobione domene www.domena2.pl skierowalem na ip_nr2 (ip2 jest podniesione na eth0) czyli apache zalatwiony squid chodzi na porcie 3128 i dziala przekierowanie na PREROUTING z ip2:80 na ip2:3128 iptables -t nat -I PREROUTING -i eth0 -p tcp -d ip2 --dport 80 -j DNAT --to ip2:3128 squid.conf jako accelerator dla httpd http_port 3128 # Port Squid-a httpd_accel_host ip2 #adres IP serwera http httpd_accel_port 80 #port serwera http httpd_accel_single_host on httpd_accel_with_proxy on httpd_accel_uses_host_header off i caly czas otrzymuje laczac sie na http://ip2/ od squida takie info chwilowo trace pomysly ERROR The requested URL could not be retrieved While trying to retrieve the URL: http://ip2/ The following error was encountered: Access Denied. Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect. squidowy access.log TCP_DENIED/403 1424 GET http://ip2/ - NONE/- text/html -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
bieniu gras napisał(a): Access Denied. Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect. hello, A co Tobie odpowiada telnet na ip2:80 z serwera na którym jest squid ... apache czy squid ?? pozdrawiam Marek Wyrzykowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Marek, W Twoim liście datowanym 13 lutego 2006 (14:59:45) można przeczytać: A co Tobie odpowiada telnet na ip2:80 z serwera na którym jest squid ... apache czy squid ?? no odpowiada mi squid jak w poprzednim mailu podawalem tyle ze podaje mi access denied nie wiem dlaczego przekierowanie portu 80-tego jest na port squida 3128 wiec obojetne czy telnetem czy czym wejdzie do squida podalem tez konfiguracje squida hm hm nie mam pomyslu -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Marek, W Twoim liście datowanym 13 lutego 2006 (14:59:45) można przeczytać: A co Tobie odpowiada telnet na ip2:80 z serwera na którym jest squid ... apache czy squid ?? a przepraszam nie zauwazylem ze mialo byc na tej samej maszynie co squid i apache: tam telnecik daje to: ~# telnet ip2 80 Trying ip2... Connected to ip2. Escape character is '^]'. hhh !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE403 Forbidden/TITLE /HEADBODY H1Forbidden/H1 You don't have permission to access / on this server.P HR ADDRESSApache/1.3.34 Server at ip2 Port 80/ADDRESS /BODY/HTML Connection closed by foreign host. hmmm dlaczego 403 ??? skoro virtualka na ip2 jest skonfigurowana odpowiednio ??? -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
bieniu gras napisał(a): H1Forbidden/H1 You don't have permission to access / on this server.P HR ADDRESSApache/1.3.34 Server at ip2 Port 80/ADDRESS /BODY/HTML Connection closed by foreign host. hmmm dlaczego 403 ??? skoro virtualka na ip2 jest skonfigurowana odpowiednio ??? prawa dostępu do plików :-) ?? pozdrawiam Marek Wyrzykowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
bieniu gras napisał(a): zmienilem virtualke na glowna domene i po telnecie idzie do strony jak powinno wiec to nie jest kwestia apacha - jest wszystko ok ale squid ciagle z zewnatrz jak sie wchodzi mi daje access denied TCP_DENIED/403 1406 GET http://ip2/ a w przegladarce mam komunikat squida jaki podawalem we wczesniejszym mailu czy IP_wirtualki != IP_głównej_domeny ??? Jeśli tak to czemu squid odwołuje się do ip2, a nie do ip_głównej_domeny ?? pozdrawiam Marek Wyrzykowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Marek, W Twoim liście datowanym 13 lutego 2006 (15:55:07) można przeczytać: czy IP_wirtualki != IP_głównej_domeny ??? Jeśli tak to czemu squid odwołuje się do ip2, a nie do ip_głównej_domeny ?? ip wirtualki = ip2 glowna domena to ip1 squid nasluchuje na ip2, jest przekierowanie iptablesami jesli ktos wchodzi na domene o ip2 np domena2.pl ktora w dns jest ustawiona na ip2 wtedy zostaje z portu 80 skierowany do squida na port 3128 i dalej squid akceleruje apacha ktory jest na ip1 i ma wirtualke dla ip2 http_port ip2:3128 httpd_accel_host ip1 caly czas squid jakos mi podaje access denied cholera, moze to kwestia innych jego ustawien jakis ACL z accessem ? -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj bieniu, W Twoim liście datowanym 13 lutego 2006 (16:13:36) można przeczytać: caly czas squid jakos mi podaje access denied cholera, moze to kwestia innych jego ustawien jakis ACL z accessem ? JASNA CHOLERA KURNA NO :d nie zauwazylem bylo: # Only allow cachemgr access from localhost http_access allow manager localhost http_access deny manager # Only allow purge requests from localhost http_access allow purge localhost http_access deny purge # Deny requests to unknown ports http_access deny !Safe_ports # Deny CONNECT to other than SSL ports http_access deny CONNECT !SSL_ports i ponizej deny dlatego jakby nie wpuszczalo nikogo :DD i stad z zewnatrz dostawalem access denied, dalem http_access allow all - i z tym poszlo wszystko - rozumiem ze tak powinno to wygladac jesli mam zamiar akcelerowac serwer httpd wpuszczac wszystkich ??? -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
bieniu gras napisał(a): http_access allow all - i z tym poszlo wszystko - rozumiem ze tak powinno to wygladac jesli mam zamiar akcelerowac serwer httpd wpuszczac wszystkich ??? proponuję raczej acl okdomains domena1.cus domena2.cus itd... :-) http_access deny !okdomains http_access allow all gdzie domena1.cus to np www.wena.pl ;-) pozdrawiam Marek Wyrzykowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Marek, W Twoim liście datowanym 13 lutego 2006 (16:38:48) można przeczytać: proponuję raczej acl okdomains domena1.cus domena2.cus itd... :-) http_access deny !okdomains http_access allow all ten zapis powoduje mi Bungled squid.conf line 1871: acl okdomains wena.net i potem squid sie zatrzymuje czyli chyba cos nie tak w tym ACl-u -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
bieniu gras napisał(a): Witaj Marek, W Twoim liście datowanym 13 lutego 2006 (16:38:48) można przeczytać: proponuję raczej acl okdomains domena1.cus domena2.cus itd... :-) http_access deny !okdomains http_access allow all ten zapis powoduje mi Bungled squid.conf line 1871: acl okdomains wena.net i potem squid sie zatrzymuje czyli chyba cos nie tak w tym ACl-u racja :-) acl okdomains dstdomain .wena.net pozdrawiam Marek Wyrzykowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Marek, W Twoim liście datowanym 13 lutego 2006 (17:07:03) można przeczytać: bieniu gras napisał(a): Witaj Marek, W Twoim liście datowanym 13 lutego 2006 (16:38:48) można przeczytać: proponuję raczej acl okdomains domena1.cus domena2.cus itd... :-) http_access deny !okdomains http_access allow all ten zapis powoduje mi Bungled squid.conf line 1871: acl okdomains wena.net i potem squid sie zatrzymuje czyli chyba cos nie tak w tym ACl-u racja :-) acl okdomains dstdomain .wena.net super - dzieki pozostaje jeszcze jedna kwestia :) teoretyczna ktora zostanie przetestowana :) otoz mam tez w konfigu: acl pliki_wormy urlpath_regex /etc/squid/pliki_wormy http_access deny pliki_wormy i tam dalem te nieszczesne pliki ddd.jpg, q.jpg i my_foto.zip ktore chca pobierac te zarazone kompy i pieknie squid daje access denied :) czyli apache zostanie odciazony poprzez squida, pytanie tylko czy squid wytrzyma to obciazenie - okolo miliona hitow dziennie :) i to po kilka tysiecy w kilka minut :D - na te wlasnie pliki druga sprawa to czy mozna jeszcze usprawnic squida zeby nie cachowal plikow wzasadzie a tylko w pamieci cos tam trzymal i to malej ilosci bo chodzi mi glownie o to zeby zapytania o pliki ktore wymienilem nie dochodzily do apacha :) i tylko tym sposobem to sie udalo to jest zalatwione ale nie chce zeby squid sie zbytnio meczyl - on ma pelnic role tylko i wylacznie filtra dla tej jednej domeny i nie dopuszczac zapytan o te durne pliki od wormow :) cachowanie na dysku jest dla mnie zbedne -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
bieniu gras napisał(a): pozostaje jeszcze jedna kwestia :) teoretyczna ktora zostanie przetestowana :) otoz mam tez w konfigu: acl pliki_wormy urlpath_regex /etc/squid/pliki_wormy http_access deny pliki_wormy Co do tych plików to bym ich nie blokował, wręcz przeciwnie :-). Niech squid na życzenie podaje te pliki i niech będę (co raczej oczywiste) o zerowej długości. Pięknie zmieszczą się w RAMie. czyli apache zostanie odciazony poprzez squida, pytanie tylko czy squid wytrzyma to obciazenie - okolo miliona hitow dziennie :) i to po kilka tysiecy w kilka minut :D - na te wlasnie pliki dlatego na początku tej dyskusji wspominałem, że to rozważania czysto teoretyczne, ale skoro squid ma za zadanie serwować cacheowane strony, to jest duża szansa, że sobie poradzi. druga sprawa to czy mozna jeszcze usprawnic squida zeby nie cachowal plikow wzasadzie a tylko w pamieci cos tam trzymal i to malej ilosci bo chodzi mi glownie o to zeby zapytania o pliki ktore wymienilem nie dochodzily do apacha :) i tylko tym sposobem to sie udalo Tu można trochę po eksperymentować. Jeśli nie możesz/chcesz cacheować całej domeny, to bym polecił squdowi tylko i wyłącznie obsługę niechcianych plików, przepuszczał bez cacheowanie pozostałe pliki z domeny, a resztę odrzucał czyli: acl pliki_wormy urlpath_regex /etc/squid/pliki_wormy acl bez_squida dstdomain .wena.net http_access accept pliki_wormy no_cache deny bez_squida http_access deny all choć nie wiem czy dobrze wyraziłem swoje myśli. to jest zalatwione ale nie chce zeby squid sie zbytnio meczyl - on ma pelnic role tylko i wylacznie filtra dla tej jednej domeny i nie dopuszczac zapytan o te durne pliki od wormow :) cachowanie na dysku jest dla mnie zbedne tu już jest zabawa z parametrami cache_mem cache_swap_low cache_swap_high maximum_object_size minimum_object_size i innymi tego typu. Na pewno proponuję, aby minimum_object_size 0 maximum_object_size 1 Jest jeszcze cache_dir i tajemniczy parametr read-only. Co to za parametr ??? Czy on wyłącza możliwość używania cache dyskowego ??? Może ktoś z Grupowiczów ma jakiś pomysł na te parametry tak aby squid obsługiwał 3 plik o zerowej długości i zajmował mało zasobów :-) pozdrawiam Marek Wyrzykowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Marek, W Twoim liście datowanym 13 lutego 2006 (19:43:23) można przeczytać: Co do tych plików to bym ich nie blokował, wręcz przeciwnie :-). Niech squid na życzenie podaje te pliki i niech będę (co raczej oczywiste) o zerowej długości. Pięknie zmieszczą się w RAMie. ok sproboje :) zaloze taki pliki w katalogu domeny o 0 wielkosci :) oby to nie pootwieralo polaczen apacha :) - bede testowac, wtedy najwyzej bede blokowac dlatego na początku tej dyskusji wspominałem, że to rozważania czysto teoretyczne, ale skoro squid ma za zadanie serwować cacheowane strony, to jest duża szansa, że sobie poradzi. wlasnie, tez rozmawialem ze znajomym o tym, ze skoro squid ma takie zadanie to i powinien sie wyrobic z taka iloscia zapytan Tu można trochę po eksperymentować. Jeśli nie możesz/chcesz cacheować całej domeny, to bym polecił squdowi tylko i wyłącznie obsługę nie o to chodzi ze nie moge :) bo moge tylko to jest taka masa polaczen ze chce squida tylko do tej wspomnianej akcji przystosowac, nie jest mi on potrzebny na serwerze, zmusila mnie ta sytuacja do tych eksperymentow niechcianych plików, przepuszczał bez cacheowanie pozostałe pliki z domeny, a resztę odrzucał czyli: acl pliki_wormy urlpath_regex /etc/squid/pliki_wormy acl bez_squida dstdomain .wena.net http_access accept pliki_wormy no_cache deny bez_squida http_access deny all choć nie wiem czy dobrze wyraziłem swoje myśli. bede testowac :) tu już jest zabawa z parametrami cache_mem cache_swap_low cache_swap_high maximum_object_size minimum_object_size i innymi tego typu. Na pewno proponuję, aby minimum_object_size 0 maximum_object_size 1 ok zastosowalem Jest jeszcze cache_dir i tajemniczy parametr read-only. Co to za parametr ??? Czy on wyłącza możliwość używania cache dyskowego ??? tego to ja tez nie wiem :) Może ktoś z Grupowiczów ma jakiś pomysł na te parametry tak aby squid obsługiwał 3 plik o zerowej długości i zajmował mało zasobów :-) wlasnie :) niech ktos jeszcze podzieli sie z nami swoja wiedza :) p.s. dziekuje bardzo za pomoc, mam nadzieje ze cala akcja zakonczy sie sukcesem, moze nawet bedzie warto splodzic jakis artykul o tym :) moze na debianusers.pl : pt. walka z wiatrakami -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Marek Wyrzykowski napisał(a): Paweł Tęcza napisał(a): Pytanie tylko, czy squid obsluzy milion hitow dziennie, skoro Apache sobie nie poradzil z taka ich liczba... Poza tym kolejna usluga to przeciez zuzycie kolejnych zasobow. Dobre i trafne Twoje pytanie to, czy squid da radę obsłużyć milion hitów/24h. Kto wie niech się odezwie :-) Może to pomoże: Pliki z wczorajszymi logami (i odrobiną z dzisiaj): squid # ls l access.log store.log -rw-r- 1 squid squid 110028238 access.log -rw-r- 1 squid squid 164617802 store.log squid # wc access.log 774947 7749470 110148175 access.log squid # wc store.log 1075807 13985491 165531951 store.log -- /// Szymon Nieradka
Re: atak na serwer www - apache 1.3.x
Witaj bieniu, W Twoim liście datowanym 9 lutego 2006 (21:56:51) można przeczytać: dobra to sproboje ustawic squida jak na razie mam tak: dalem przekierowanie iptablesami: iptables -t nat -A PREROUTING -i eth0 -p tcp -d ip_na_ktorym_bedzie_domena --dport 80 -j DNAT --to 127.0.0.1:3128 squid na localhoscie i ma ustawione: http_port 127.0.0.1:3128 cache_mem 8 MB http_access allow localhost # And finally deny all other access to this proxy http_access deny all httpd_accel_port 127.0.0.1:80 httpd_accel_host virtual httpd_accel_single_host on httpd_accel_uses_host_header on # Only allow cachemgr access from localhost http_access allow manager localhost http_access deny manager # Only allow purge requests from localhost http_access allow purge localhost http_access deny purge # Deny requests to unknown ports http_access deny !Safe_ports # Deny CONNECT to other than SSL ports http_access deny CONNECT !SSL_ports acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl to_localhost dst 127.0.0.0/8 acl SSL_ports port 443 563 # https, snews acl SSL_ports port 873 # rsync acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 563 # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl Safe_ports port 631 # cups acl Safe_ports port 873 # rsync acl Safe_ports port 901 # SWAT acl purge method PURGE acl CONNECT method CONNECT #tutaj sa wpisane pliki ddd.jpg, q.jpg oraz my_foto.zip aby squid nie pozwalal na przejscie acl pliki_wormy urlpath_regex /etc/squid/pliki_wormy http_access deny pliki_wormy i teraz laczac sie po ip http://ip_na_ktorym_jest_domena niestety mam connection timeout a widze ze pakiety przechodza: iptables -L -v -t nat Chain PREROUTING (policy ACCEPT 6163K packets, 350M bytes) pkts bytes target prot opt in out source destination 93 5580 DNAT tcp -- eth0 any anywhere ip_na_ktorym_jest_domena2tcp dpt:www to:127.0.0.1:3128 tylko jakby nie wiem squid nie puszcza dalej ??? -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
bieniu gras napisał(a): iptables -L -v -t nat Chain PREROUTING (policy ACCEPT 6163K packets, 350M bytes) pkts bytes target prot opt in out source destination 93 5580 DNAT tcp -- eth0 any anywhere ip_na_ktorym_jest_domena2tcp dpt:www to:127.0.0.1:3128 hello, Tak naprawdę to powinieneś zrobić REDIRECTa na squida, Po PREROUTINGu masz łańcuch INPUT, w którym dodatkowo trzeba otworzyć dostęp do squida. Proponuję coś następującego: iptables -t nat -I PREROUTING -i eth0 -p tcp -d ip_domeny --dport 80 -j REDIRECT --to-ports 3128 iptables -I INPUT -i eth0 -p tcp -d ip_domeny --dport 3128 -j ACCEPT -m jakieś_moduy_i_inne_wodotryski --..itd taka chytra sztuczka. Najfajniejsze w tym jest to, że na porcie 80 na tym samym IP co ip_domeny może działać sobie apache. Redirect w natcie zdejmuje odwołania z (zakładam) INTERNETU na port 80 nim one dojdą do apache i przekierowuje je na 3128 (potrzebny ACCEPT w INPUTcie). Inne odwołania np z localhosta na 127.0.0.1:80 trafiają do apache (jak na to pozwoliłeś) :-) Pozdrawiam Marek Wyrzykowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Marek, W Twoim liście datowanym 10 lutego 2006 (17:43:43) można przeczytać: Tak naprawdę to powinieneś zrobić REDIRECTa na squida, Po PREROUTINGu masz łańcuch INPUT, w którym dodatkowo trzeba otworzyć dostęp do squida. Proponuję coś następującego: iptables -t nat -I PREROUTING -i eth0 -p tcp -d ip_domeny --dport 80 -j REDIRECT --to-ports 3128 iptables -I INPUT -i eth0 -p tcp -d ip_domeny --dport 3128 -j ACCEPT -m jakieś_moduy_i_inne_wodotryski --..itd no fakt tak to bedzie musialo zostac rozwiazane :)) i squid niech sie poci i tam juz bede wywlac niechciane gowienka, pozostaje go dobrze skonfigurowac dla puszczania dalszego ruchu dla apacha, ktos z Was to juz robil moze taka chytra sztuczka. Najfajniejsze w tym jest to, że na porcie 80 na tym samym IP co ip_domeny może działać sobie apache. Redirect w natcie zdejmuje odwołania z (zakładam) INTERNETU na port 80 nim one dojdą do apache i przekierowuje je na 3128 (potrzebny ACCEPT w INPUTcie). Inne odwołania np z localhosta na 127.0.0.1:80 trafiają do apache (jak na to pozwoliłeś) :-) ano na tym porcie chodzi apache ze swoimi domenkami, dodatkowo poprostu zrobie virtualke na nim na tym wlasnie ip na ktorym bedzie sluchac squid i teoretycznie powinien mi wtedy on ruch przepuscic do tej domeny zgadza sie ? troche juz kombinowalem z konfigiem squida jesli ktos moze podpowiedziec to bede wdzieczny, gdyz poki co konfigurowalem squida w malej sieci ale dla userow za routerem a nie jako akcelerator dla apacha -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witam, Dnia czw, lut 09, 2006 at 09:24:32 +0100, bieniu gras napisał: Witaj Marcin, W Twoim liście datowanym 9 lutego 2006 (07:21:33) można przeczytać: Może wyłącz access.log/error.log dla tej domeny, to powinno go trochę odciążyć. sporoboje bo logi rosly niesamowicie :) POlecam jeszcze wylaczenie resolvowania adresow przez apacza, powinno to przyspieszyc czas jego odpowiedzi. Co do DNS balancingu - jeżeli masz ipka i łacze to wytrzyma, a tak jak mówiłeś, brakuje CI połaczeń w apaczu, postaw sobie trzy apacze w wirualnym systemie plików (http://qref.sourceforge.net/quick/ch-tips.pl.html) i ustaw w DNS trzy rekordy A wkazujace na te adresy (bez wspomnianego localhosta) - odciazy to apacza i pozwoli przerobic wiecej zapytan na raz. -- Pozdrawiam Michał Prokopiuk [EMAIL PROTECTED] http://www.sklep.linuxstuff.pl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
On Wed, Feb 08, 2006 at 05:34:20PM +0100, Robert PaneQ! Pankowecki (rupert) wrote: Dnia 08-02-2006, śro o godzinie 14:34 +0100, bieniu gras napisał(a): dawalem pliki 0 bajtow ale tu nie chodzi o ddos na lacze - wysysa to bardzo malo lacza, problem lezy w tym ze apache sie nie wyrabia :))) A może zwiększyć liczbę wątków / procesów dla apache, jeśli można, pamiętam, że dla serwera ntfs jest to możliwe więc może apach też takie coś oferuje, może wtedy lepiej by się wyrabiał ? :-) Jeśli zwiększysz MaxClients ponad to, co jest w stanie przyjąć pamięć na maszynie, to tylko zabijesz wydajność przy dużym obciążeniu - zacznie swapować i skończy się normalna praca. Pierwsze co bym zrobił, to ustawił MaxRequestsPerChild na jakąś wysoką wartość (lub na zero, z wszelkimi tego konsekwencjami), żeby nie musiał co chwilę nowych procesów tworzyć, bo to jest kosztowne. A wartość defaultowa w Debianie bardzo niska. Do tego MaxSpareServers też gdzieś wysoko (gdzieś w okolicy MaxClients), żeby nie ubijał procesów bez potrzeby przy chwilowej przerwie w ataku :-) -- Jacek Politowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
witam a mod_evasive testowales? wyglada iz powinien przynajmniej w jakims stopniu pomoc. pozdrawiam i powodzenia jr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
bieniu gras napisał(a): Witaj lista! wiem ze to troche OT i juz pisalem na liste o tym ale moze jeszcze mi jakos pomozecie: ktos w 3 wormach internetowych umiescil w kodzie moja domene www.wena.net do ktorej lacza sie zarazone komputery i proboja pobierac: q.jpg, ddd, jpg oraz my_photo.zip hello, Chcę zaproponować rozważania czysto teoretyczne. Nie sprawdziłem tego osobiście, ale może pomoże :-). W przypadku znacznego obciążenia serwera www, stawia się przed nim serwer cacheujący. W związku z tym treści stałe nie muszą podawane przez apache'a, dzięki czemu serwer www ma czas na zajmowanie się ważniejszymi rzeczami. Proponuję dlatego uruchomić choćby squida (nawet na tym samym kompie co apache) i tak go skonfigurować, aby wziął na siebie obsługę podawania w/w plików o zerowej długości, a resztę przepuszczał do apache. Przypominam, że jest to rozważanie teoretyczne i nie jest pewien czy to mam sens. Mimo to zapraszam do dyskusji :-). Pozdrawiam Marek Wyrzykowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witam, Dnia czw, lut 09, 2006 at 02:29:50 +0100, Marek Wyrzykowski napisał: bieniu gras napisał(a): Witaj lista! wiem ze to troche OT i juz pisalem na liste o tym ale moze jeszcze mi jakos pomozecie: ktos w 3 wormach internetowych umiescil w kodzie moja domene www.wena.net do ktorej lacza sie zarazone komputery i proboja pobierac: q.jpg, ddd, jpg oraz my_photo.zip hello, Chcę zaproponować rozważania czysto teoretyczne. Nie sprawdziłem tego osobiście, ale może pomoże :-). W przypadku znacznego obciążenia serwera www, stawia się przed nim serwer cacheujący. W związku z tym treści stałe nie muszą podawane przez apache'a, dzięki czemu serwer www ma czas na zajmowanie się ważniejszymi rzeczami. Proponuję dlatego uruchomić choćby squida (nawet na tym samym kompie co apache) i tak go skonfigurować, aby wziął na siebie obsługę podawania w/w plików o zerowej długości, a resztę przepuszczał do apache. Przypominam, że jest to rozważanie teoretyczne i nie jest pewien czy to mam sens. Mimo to zapraszam do dyskusji :-). Jak najbardziej ma sens - odciaza apacza :). Wymyslilem teraz tez, ze mozna by reguulkami mod_rewrite kierowac zapytania gdzies w kosmos, no ale to znowu angazuje apacza. Ale w przypadku apaczy trzech (pisalem o tym w poprzednim mailu) obciazenie sztuki zdecydowania spada. BTW, do Twojej doemny mam 20 hopow - nie bylo gdzies blizej serwera? WYkonczylbys atakujacych jakoscia lacz TP :D -- Pozdrawiam Michał Prokopiuk [EMAIL PROTECTED] http://www.sklep.linuxstuff.pl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Czesc! On Thu, Feb 09, 2006 at 02:36:07PM +0100, Michał Prokopiuk wrote: Dnia czw, lut 09, 2006 at 02:29:50 +0100, Marek Wyrzykowski napisał: Chcę zaproponować rozważania czysto teoretyczne. Nie sprawdziłem tego osobiście, ale może pomoże :-). W przypadku znacznego obciążenia serwera www, stawia się przed nim serwer cacheujący. W związku z tym treści stałe nie muszą podawane przez apache'a, dzięki czemu serwer www ma czas na zajmowanie się ważniejszymi rzeczami. Proponuję dlatego uruchomić choćby squida (nawet na tym samym kompie co apache) i tak go skonfigurować, aby wziął na siebie obsługę podawania w/w plików o zerowej długości, a resztę przepuszczał do apache. Przypominam, że jest to rozważanie teoretyczne i nie jest pewien czy to mam sens. Mimo to zapraszam do dyskusji :-). Jak najbardziej ma sens - odciaza apacza :). Pytanie tylko, czy squid obsluzy milion hitow dziennie, skoro Apache sobie nie poradzil z taka ich liczba... Poza tym kolejna usluga to przeciez zuzycie kolejnych zasobow. Ale w przypadku apaczy trzech (pisalem o tym w poprzednim mailu) obciazenie sztuki zdecydowania spada. Jesli maszyna jest za slaba dla jednego Apache'a, to przeciez ich mnozenie na tym samej maszynie nic tu nie pomoze. Pozdrawiam, P.
Re: atak na serwer www - apache 1.3.x
Michał Prokopiuk napisał(a): Jak najbardziej ma sens - odciaza apacza :). Wymyslilem teraz tez, ze ale czy problem wydajności nie przeniesie się na squida ??. Czy da on radę i czy się nie wywali, odcinając tym samym dostęp do wszystkich domen na tym serwerze ? Może ktoś wie jak jak z wydajnością i stabilnością squida w takiej sytuacji ?? Pozdrawiam Marek Wyrzykowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Paweł Tęcza napisał(a): Jak najbardziej ma sens - odciaza apacza :). Pytanie tylko, czy squid obsluzy milion hitow dziennie, skoro Apache sobie nie poradzil z taka ich liczba... Poza tym kolejna usluga to przeciez zuzycie kolejnych zasobow. Zasobami w tym przypadku bym sie nie przejmował. Trochę ramu dla plików o zerowym rozmiarze ;-), swap na dysku niepotrzebny. Dobre i trafne Twoje pytanie to, czy squid da radę obsłużyć milion hitów/24h. Kto wie niech się odezwie :-) Pozdrawiam Marek Wyrzykowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Michał, W Twoim liście datowanym 9 lutego 2006 (14:36:07) można przeczytać: Jak najbardziej ma sens - odciaza apacza :). Wymyslilem teraz tez, ze mozna by reguulkami mod_rewrite kierowac zapytania gdzies w kosmos, no ale to znowu angazuje apacza. Ale w przypadku apaczy trzech (pisalem o tym w poprzednim mailu) obciazenie sztuki zdecydowania spada. BTW, do Twojej doemny mam 20 hopow - nie bylo gdzies blizej serwera? WYkonczylbys atakujacych jakoscia lacz TP :D blizej sie nie dalo :))) bede probowac wlasnie ze squidem ktory bedzie na localhoscie a domenka bedzie na osobnym ip i squid zajmie sie blokowaniem wywolan ddd.jpg i innych pochadzacych z tych wormow a reszte pusci do apacha czyli squid z filtrowaniem + przkierowanie = transparent proxy bedzie dla domenki www.wena.net -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witam, Dnia czw, lut 09, 2006 at 02:54:46 +0100, Paweł Tęcza napisał: Ale w przypadku apaczy trzech (pisalem o tym w poprzednim mailu) obciazenie sztuki zdecydowania spada. Z tego co Bieniu pisał wyżej największym problemem był limit połaczeń w ramach jednego apacza. Poza tym apacz zuzywa mniej zasobow niz squid... -- Pozdrawiam Michał Prokopiuk [EMAIL PROTECTED] http://www.sklep.linuxstuff.pl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Michał, W Twoim liście datowanym 9 lutego 2006 (15:39:29) można przeczytać: Z tego co Bieniu pisał wyżej największym problemem był limit połaczeń w ramach jednego apacza. Poza tym apacz zuzywa mniej zasobow niz squid... ale mysle o squidzie ktory by tylko blokowal te 3 wywolania hmmm co do 3 apachy to tez dobra mysl tylko nie wiem do konca jak sie za to zabrac ... moge przeciez przekompilowac apacha i dam mu 600 polaczen tylko nie wiem czy wlasnie blokowanie squidem tych trzech getow nie byloby lepsze -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Z tego co Bieniu pisał wyżej największym problemem był limit połaczeń w ramach jednego apacza. Poza tym apacz zuzywa mniej zasobow niz squid... ale mysle o squidzie ktory by tylko blokowal te 3 wywolania hmmm Witam A ja jednak pomyślałbym jednak nad iptables - wydaje mi sie jednak, że filtr utworzony w ten sposób zeżre najmniej zasobów: iptables -t filter -A INPUT -p tcp --dport 80 - m string --string GET /jakiś_syf -j REJECT I do tego zastanowiłbym się poważnie nad umieszceniem tej regułki na samym początku łańcucha INPUT. Ew. można skrócić wyrażenie do sam_syf - być może zaoszczędzi to kilka cykli procesora. Za takim rozwiązaniem przemawia fakt, że netfilter działa w przestrzeni jądra i nie jest obciążony narzutami związanymi z obsługą dodatkowych procesów, opłączeń itp.., a w dodatku i tak przechodzi przez niego cały ruch sieciowy wpadający do kompa, więc jeśli spędziłes kiedyś parę nocek wymyślając różne dziwne regułki firewalla, to i tak netfilter ma kupę roboty przez tego natchnionego kolesia. A jeśli ktoś powie, że dzięki temu nie wie, czy atak już się skończył, czy też trwa dalej, to przypomnę o iptables -Lv ;) I jeszce pozwolę sobie wtrącic 0,03PLN do wątku DROP vice REJECT - REJECT odsyła komunikat ICMP port unreachable, który zmusza prawidłowo działający drugi koniec (czyli windzianą ofiarę) do zamknięcia połączenia, podczas gdy DROP tylko odrzuca pakiet nic nikomu nie mówiąc, powodując bardzo szybkie przepełnienie tabeli połączeń, w konsekwencji doprowadzając do odrzucania wszelkich nowych połączeń (czyli kończąc atak sukcesem;) -- Pozdrawiam Janes -- Pozdrawiam Artur Jankowski ITservice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Artur, W Twoim liście datowanym 9 lutego 2006 (18:45:36) można przeczytać: Z tego co Bieniu pisał wyżej największym problemem był limit połaczeń w ramach jednego apacza. Poza tym apacz zuzywa mniej zasobow niz squid... ale mysle o squidzie ktory by tylko blokowal te 3 wywolania hmmm Witam A ja jednak pomyślałbym jednak nad iptables - wydaje mi sie jednak, że filtr utworzony w ten sposób zeżre najmniej zasobów: iptables -t filter -A INPUT -p tcp --dport 80 - m string --string GET /jakiś_syf -j REJECT to rozwiazanie wydawac by sie moglo jest ok ale iptables -t filter -I INPUT -p tcp --dport 80 -m string --string GET /my_foto.zip -j REJECT iptables -t filter -I INPUT -p tcp --dport 80 -m string --string GET /q.jpg -j REJECT iptables -t filter -I INPUT -p tcp --dport 80 -m string --string GET /ddd.jpg -j REJECT tyle tylko ze niestety dochodza zapytania do apacha i dopiero wtedy sa blokowane czyli to nie wchodzi w gre - musi byc cos przed apachem -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
bieniu gras [EMAIL PROTECTED] wrote: Witaj Artur, W Twoim liście datowanym 9 lutego 2006 (18:45:36) można przeczytać: Z tego co Bieniu pisał wyżej największym problemem był limit połaczeń w ramach jednego apacza. Poza tym apacz zuzywa mniej zasobow niz squid... ale mysle o squidzie ktory by tylko blokowal te 3 wywolania hmmm Witam A ja jednak pomyślałbym jednak nad iptables - wydaje mi sie jednak, że filtr utworzony w ten sposób zeżre najmniej zasobów: iptables -t filter -A INPUT -p tcp --dport 80 - m string --string GET /jakiś_syf -j REJECT to rozwiazanie wydawac by sie moglo jest ok ale iptables -t filter -I INPUT -p tcp --dport 80 -m string --string GET /my_foto.zip -j REJECT iptables -t filter -I INPUT -p tcp --dport 80 -m string --string GET /q.jpg -j REJECT iptables -t filter -I INPUT -p tcp --dport 80 -m string --string GET /ddd.jpg -j REJECT tyle tylko ze niestety dochodza zapytania do apacha i dopiero wtedy sa blokowane czyli to nie wchodzi w gre - musi byc cos przed apachem Fakt - nie pomyślałem, że to otworzy połączenie do apacha, ale przećwicz to w praktyce - czy po zwiększeniu conn_limit i spare_servers, apache nie poradzi sobie z otwieranymi połączeniami. W tym przypadku serwer nie będzie obsługiwał żadnych zapytań, bo te po prostu do niego nie dotrą, więc jeśli będzie miał odpalonych wystarczająco dużo procesów potomnych, gotowych do obsługi żądania - wydaje mi się, że sobie poradzi. Powinno to wyglądać mniej więcej tak: ofiara firewall apache (a raczej jego gniazdo) SYN -ACCEPT - ok-start -ACCEPT-SYN, ACK ACK -ACCEPT GET /syf - REJECT - port unreachable FIN,ACK - ACCEPT - skoro nie chcesz, to konczymy zabawe happy end - ACCEPT - ACK Zdaje sobię sprawę, że nie jest to rozwiązanie idealne, ale nie zawsze warto dla trzech wróbelków, wytaczać całej dywizji ciężkiej artylerii... -- Pozdrawiam Artur Jankowski ITservice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Artur, W Twoim liście datowanym 9 lutego 2006 (21:01:57) można przeczytać: Fakt - nie pomyślałem, że to otworzy połączenie do apacha, ale przećwicz to w praktyce - czy po zwiększeniu conn_limit i spare_servers, apache nie poradzi sobie z otwieranymi połączeniami. juz podawalem moja konfiguracje i wyglada ona tak: MinSpareServers 15 MaxSpareServers 80 StartServers 15 MaxClients 256 i niestety zaraz po wlaczeniu domeny wysysa calkowicie wszystko apachowi :) kilka tysiecy to jest w 2 minuty :D W tym przypadku serwer nie będzie obsługiwał żadnych zapytań, bo te po prostu do niego nie dotrą, więc jeśli będzie miał odpalonych wystarczająco dużo procesów potomnych, gotowych do obsługi żądania - wydaje mi się, że sobie poradzi. Powinno to wyglądać mniej więcej tak: ofiara firewall apache (a raczej jego gniazdo) SYN -ACCEPT - ok-start -ACCEPT-SYN, ACK ACK -ACCEPT GET /syf - REJECT - port unreachable FIN,ACK - ACCEPT - skoro nie chcesz, to konczymy zabawe happy end - ACCEPT - ACK Zdaje sobię sprawę, że nie jest to rozwiązanie idealne, ale nie zawsze warto dla trzech wróbelków, wytaczać całej dywizji ciężkiej artylerii... niestety chcialbym zeby to byly wrobelki :) moze i wygladaja lagodnie ale pieknie wysysaja apacha :) jakby ziarno jadly pozostaje mi sprobowac ze squidem chyba a najlepiej jak polacze wiele z tych dzial i np iptables + squid powinien chyba lepiej sobie radzic z takim nawalem zapytan niz apache -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
atak na serwer www - apache 1.3.x
Witaj lista! wiem ze to troche OT i juz pisalem na liste o tym ale moze jeszcze mi jakos pomozecie: ktos w 3 wormach internetowych umiescil w kodzie moja domene www.wena.net do ktorej lacza sie zarazone komputery i proboja pobierac: q.jpg, ddd, jpg oraz my_photo.zip http://search.symantec.com/custom/update/query.html?filter=allnh=10hitsceil=100st=1context=gbhqt=wena.net oczywiscie idzie to tylko na jedna domene i to dokladnie na www.wena.net a nie wena.net oczywiscie rezultat jest taki ze tysiace komputerkow zarazonych chce te pliki a moj serwer www odpowiada bledem 404 powiem tylko ze dziennie mam 1 mln hitow w www.wena.net a odwiedzin 200 tysiecy :D to naprawde zabija apacha nawet ustawionego na 256 maxcon mam tez modul antyddosowy do apacha: mod_evasive cos tam wycina ale malo narazie ustawilem domene www.wena.net w DNS na 127.0.0.1 i sprawa jest teoretycznie zalatwiona poza tym ze nie moze tak byc przeciez zeby nie dziala wiecznie czy znacie jakas mozliwosc jeszcze jakby nad tym ddosem wormowym zapanowac ??? probowalem w httpd.conf: Location /ddd.jpg Deny from all ErrorDocument 403 http://localhost /Location Location /my_foto.zip Deny from all ErrorDocument 403 http://localhost /Location Location /q.jpg Deny from all ErrorDocument 403 http://localhost /Location ale to tez duzo nie dawalo, praktycznie paralizowalo to apacha i tak bo podawanie kodu 403 tez mu pozeralo zasoby moze probowac na firewallu iptablesami i stringiem ??? tak zeby przeuszczac wszystko oprocz get ddd.jpg q.jpg i tego my photo.zip ??? cos w stylu: iptables -t mangle -N apache iptables -t mangle -A apache -j ACCEPT iptables -t mangle -A INPUT -m recent --name apache --update --seconds 60 --rdest -j apache iptables -t mangle -A INPUT -m string --string GET ddd.jpg -m recent --name apache --rsource --set -j apache iptables -t mangle -A INPUT -m string --string GET /ddd.jpg -j DROP drop ? reject ?? jak, moze ktos podpowiedziec jeden kolega mowil tez o DNS balance w takich wypadkach ... albo jakies przekierowanie www.wena.net na www1.wena.net ??? hm pomozcie -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
On Wed, Feb 08, 2006 at 11:09:47AM +0100, bieniu gras wrote: Witaj lista! Hej! ktos w 3 wormach internetowych umiescil w kodzie moja domene www.wena.net do ktorej lacza sie zarazone komputery i proboja pobierac: Ale ktos mial wene... Przyjmij moje wyrazy wspolczucia ;) oczywiscie rezultat jest taki ze tysiace komputerkow zarazonych chce te pliki a moj serwer www odpowiada bledem 404 A moze zamiast serwowac komunikat bledu 40x moglbys udostepniac te wlasnie pliki o zerowej dlugosci? ;) Na pewno zmniejszyloby to ruch w sieci. czy znacie jakas mozliwosc jeszcze jakby nad tym ddosem wormowym zapanowac ??? probowalem w httpd.conf: Location /ddd.jpg Deny from all ErrorDocument 403 http://localhost /Location O ile wiem, w linijce z ErrorDocument zamiast adresu mozesz tez uzyc jakiegos napisu, np. Pocaluj mnie w nos! ;) Bedzie mial wprawdzie wiecej niz 0 bajtow, ale lepsze to niz komunikat bledu 40x. moze probowac na firewallu iptablesami i stringiem ??? tak zeby przeuszczac wszystko oprocz get ddd.jpg q.jpg i tego my photo.zip ??? Jesli do Twojego Apache'a w ogole nie maja dochodzic zapytania o te pliki, a to wydaje sie byc najlepszym rozwiazaniem, to trzeba je wycinac gdzies wczesniej, byc moze na firewallu. Niestety az taki biegly w iptables to ja nie jestem. cos w stylu: iptables -t mangle -N apache iptables -t mangle -A apache -j ACCEPT iptables -t mangle -A INPUT -m recent --name apache --update --seconds 60 --rdest -j apache iptables -t mangle -A INPUT -m string --string GET ddd.jpg -m recent --name apache --rsource --set -j apache iptables -t mangle -A INPUT -m string --string GET /ddd.jpg -j DROP drop ? reject ?? jak, moze ktos podpowiedziec A dziala zarowno DROP, jak i REJECT? Ja bym wybral REJECT, bo szybciej zakonczy polaczenie z klientem. jeden kolega mowil tez o DNS balance w takich wypadkach ... albo jakies przekierowanie www.wena.net na www1.wena.net ??? hm A co bedzie pod www1.wena.net? Pozdrawiam, P. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Paweł, W Twoim liście datowanym 8 lutego 2006 (12:09:06) można przeczytać: On Wed, Feb 08, 2006 at 11:09:47AM +0100, bieniu gras wrote: Witaj lista! Hej! ktos w 3 wormach internetowych umiescil w kodzie moja domene www.wena.net do ktorej lacza sie zarazone komputery i proboja pobierac: Ale ktos mial wene... Przyjmij moje wyrazy wspolczucia ;) oczywiscie rezultat jest taki ze tysiace komputerkow zarazonych chce te pliki a moj serwer www odpowiada bledem 404 A moze zamiast serwowac komunikat bledu 40x moglbys udostepniac te wlasnie pliki o zerowej dlugosci? ;) Na pewno zmniejszyloby to ruch w sieci. dawalem pliki 0 bajtow ale tu nie chodzi o ddos na lacze - wysysa to bardzo malo lacza, problem lezy w tym ze apache sie nie wyrabia :))) za duzo tego idzie milion hitow dziennie :P normalnie jakbym mial jakis portal O ile wiem, w linijce z ErrorDocument zamiast adresu mozesz tez uzyc jakiegos napisu, np. Pocaluj mnie w nos! ;) Bedzie mial wprawdzie wiecej niz 0 bajtow, ale lepsze to niz komunikat bledu 40x. tak juz myslalem nawet o podaniu jakiegos exploita na windowsa pod plikami ktore pobiera ... :D Jesli do Twojego Apache'a w ogole nie maja dochodzic zapytania o te pliki, a to wydaje sie byc najlepszym rozwiazaniem, to trzeba je wycinac gdzies wczesniej, byc moze na firewallu. Niestety az taki biegly w iptables to ja nie jestem. tez w iptablesach nie smigam poprostu proboje wykorzystywac regulki ktore kraza gdzies wsrod ludzi A dziala zarowno DROP, jak i REJECT? Ja bym wybral REJECT, bo szybciej zakonczy polaczenie z klientem. wstepnie probowalem z DROP i REJECT ale tym sposobem zamknalem caly ruch do apacha mimo ze string byl na get tych plikow :) bede walczyc A co bedzie pod www1.wena.net? myslalem tutaj o jakims dnsowym przkierowaniu hmmm sam nie wiem jak to rozwiazac z dns balancing ? ze czesc zapytan na www.wena.net szlo by na www1.wena.net ?? przynajmniej nie wiem co iles ... ktos z listy mi podpowiadal odnosnie takiego rozwiazania tak sobie mysle poki co domena www.wena.net idzie na 127.0.0.1 i ciekawy jestem jak za 2 tygodnie ja wlacze czy bedzie to nadal sie dzialo ale za wszelkie pomysly bede wdizeczny -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
On Wed, Feb 08, 2006 at 02:34:23PM +0100, bieniu gras wrote: Witaj Paweł, W Twoim liście datowanym 8 lutego 2006 (12:09:06) można przeczytać: [...] A moze zamiast serwowac komunikat bledu 40x moglbys udostepniac te wlasnie pliki o zerowej dlugosci? ;) Na pewno zmniejszyloby to ruch w sieci. dawalem pliki 0 bajtow ale tu nie chodzi o ddos na lacze - wysysa to bardzo malo lacza, problem lezy w tym ze apache sie nie wyrabia :))) za duzo tego idzie milion hitow dziennie :P normalnie jakbym mial jakis portal Moja porade oczywiscie nalezalo potraktowac z przymruzeniem oka :) A co bedzie pod www1.wena.net? myslalem tutaj o jakims dnsowym przkierowaniu hmmm sam nie wiem jak to rozwiazac z dns balancing ? ze czesc zapytan na www.wena.net szlo by na www1.wena.net ?? przynajmniej nie wiem co iles ... ktos z listy mi podpowiadal odnosnie takiego rozwiazania Jesli chcesz na DNSie odsiac czesc zapytan, to mozesz jednej nazwie domenowej przypisac kilka rekordow A. Dla przykladu, jesli pod jednym rekordem bedzie sie kryc wlasciwy adres IP, a pod dziewiecioma pozostalymi - adres IP w rodzaju 127.0.0.1, to serwer DNS taki jak bind na co 10. zapytanie powinien zwrocic klientowi na poczatku wlasciwy adres IP. W ten sposob ruch do Twojego Apache'a powinien sie zmniejszyc o 90%. Oczywiscie TTL musi byc odpowiednio krotki, zeby wyniki zapytan do DNSa nie cache'owaly sie zbyt dlugo. Tym sposobem mozesz wprawdzie pozbyc sie sporej czesci zapytan robali, ale musisz tez zdawac sobie sprawe, ze czlowiek, ktory bedzie chcial wejsc na Twoja strone moze nie miec tyle cierpliwosci, zeby 10 razy odswiezac strone. To rozwiazanie nie jest wiec idealne, ale jest chyba lepsze niz zupelne odciecie serwera? Ja bym uzyl go jako ostatecznosci i najpierw probowal odpowiednio skonfigurowac iptables. Pozdrawiam, P.
Re: atak na serwer www - apache 1.3.x
Dnia 08-02-2006, śro o godzinie 14:34 +0100, bieniu gras napisał(a): dawalem pliki 0 bajtow ale tu nie chodzi o ddos na lacze - wysysa to bardzo malo lacza, problem lezy w tym ze apache sie nie wyrabia :))) za duzo tego idzie milion hitow dziennie :P normalnie jakbym mial jakis portal A może zwiększyć liczbę wątków / procesów dla apache, jeśli można, pamiętam, że dla serwera ntfs jest to możliwe więc może apach też takie coś oferuje, może wtedy lepiej by się wyrabiał ? :-) -- -Robert Pankowecki vel rupert- http://www.pamix.pl - Flizeliny gg:1716969 || skype:kryptofiles || [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
Witaj Robert, W Twoim liście datowanym 8 lutego 2006 (17:34:20) można przeczytać: A może zwiększyć liczbę wątków / procesów dla apache, jeśli można, pamiętam, że dla serwera ntfs jest to możliwe więc może apach też takie coś oferuje, może wtedy lepiej by się wyrabiał ? :-) to stosowalem na samym poczatku :) wyssie i z 1000 :) to rozwiazanie odpada jako pojedyncze, ewentualnie moze byc wspomagajacym :) -- Pozdrowienia, bieniu gras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: atak na serwer www - apache 1.3.x
On Wed, Feb 08, 2006 at 11:09:47AM +0100, bieniu gras wrote: powiem tylko ze dziennie mam 1 mln hitow w www.wena.net a odwiedzin 200 tysiecy :D to naprawde zabija apacha nawet ustawionego na 256 maxcon Może wyłącz access.log/error.log dla tej domeny, to powinno go trochę odciążyć. Marcin -- Marcin Owsiany [EMAIL PROTECTED] http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
