abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 21:44 | Komunita

    Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.

    Ladislav Hagara | Komentářů: 0
    včera 14:22 | IT novinky

    Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.

    Ladislav Hagara | Komentářů: 12
    3.5. 22:33 | Nová verze

    Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.

    Ladislav Hagara | Komentářů: 2
    2.5. 22:22 | Komunita

    Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).

    Ladislav Hagara | Komentářů: 1
    2.5. 19:11 | IT novinky

    Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.

    Ladislav Hagara | Komentářů: 4
    2.5. 11:22 | Zajímavý projekt

    Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.

    Ladislav Hagara | Komentářů: 2
    2.5. 09:11 | Bezpečnostní upozornění

    Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.

    Ladislav Hagara | Komentářů: 2
    1.5. 20:00 | Komunita

    V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.

    Ladislav Hagara | Komentářů: 3
    1.5. 19:22 | IT novinky

    Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).

    Ladislav Hagara | Komentářů: 0
    30.4. 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

    Ladislav Hagara | Komentářů: 0
    Jaký filesystém primárně používáte?
     (58%)
     (1%)
     (8%)
     (21%)
     (4%)
     (2%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 521 hlasů
     Komentářů: 20, poslední dnes 00:19
    Rozcestník

    Dotaz: DDOS utok

    14.1.2014 09:55 Rishare
    DDOS utok
    Přečteno: 2855×
    Zdravim, uz nekolik dni je na mou linku vedeny DDOS utok, na apache chodi hromada takovychto requestu:
    62.35.200.3 - - [14/Jan/2014:08:42:32 +0100] "POST / HTTP/1.1" 403 276 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    112.200.49.196 - - [14/Jan/2014:08:42:32 +0100] "POST / HTTP/1.1" 403 276 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
    83.200.150.147 - - [14/Jan/2014:08:42:40 +0100] "POST / HTTP/1.1" 403 276 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"


    To se diky spolupraci s poskytovatelem (UPC) podarilo vicemene odfiltrovat, ovsem na sendmail je vedeny utok, ktery me znepokojuje vice (predpokladam, ze jde o brute hadani hesla, nebo jen snaha o vycerpani pameti). Na mailserveru vidim hromadu takovychto procesu:
    root 4817 0.0 0.3 7796 2948 ? S 09:06 0:00 sendmail: server 233.13.112.78.rev.sfr.net [78.112.13.233] cmd read
    root 4819 0.0 0.3 7796 2912 ? S 09:06 0:00 sendmail: server 62-193-57-73.as16211.net [62.193.57.73] cmd read
    root 4820 0.0 0.3 7796 2912 ? S 09:06 0:00 sendmail: server [194.250.70.41] cmd read
    root 4821 0.0 0.3 7796 2916 ? S 09:06 0:00 sendmail: server 109.209-31-46.rdns.acropolistelecom.net [46.31.209.109] cmd read
    root 4822 0.0 0.2 7352 2088 ? S 09:06 0:00 sendmail: startup with [147.30.142.123]
    root 4823 0.0 0.2 7352 2120 ? S 09:06 0:00 sendmail: startup with ip-125-252-84-90.asianetcom.net
    root 4824 0.0 0.3 7796 2900 ? S 09:06 0:00 sendmail: server [171.76.26.245] cmd read


    Linka, ackoliv v neni vytizena mnozstvim prenasenych dat, je prakticky nepouzitelna, ikdyz je web i mailserver vypnuty. Nemate prosim nejake napady, co s tim?


    Diky

    Řešení dotazu:


    Odpovědi

    16.1.2014 11:38 Jeason | skóre: 16 | Plzeň
    Rozbalit Rozbalit vše Re: DDOS utok
    to je otevreny server ? bez autorizace ?

    fail2ban bych instaloval jako prvni.
    17.1.2014 08:26 Filip Jirsák
    Rozbalit Rozbalit vše Re: DDOS utok
    Pokud je linka nepoužitelná kvůli příchozím paketům, může s tím něco udělat jedině ISP. Pokud kvůli odchozím, musíte zjistit, co u vás generuje ten odchozí provoz, a to nějak zpacifikovat. Pokud je linka nepoužitelná, přes to že přes ní netečou žádná data, je buď fyzicky poškozená, nebo nestíhá zařízení na jedné nebo druhé straně spoje.

    Fail2ban většinou moc neškodí (i když málokdy dělá něco užitečného). Ovšem malý DDoS útok je přesně ta výjimka, kdy fail2ban může situaci výrazně zhoršit. (Při velkém DDoS útoku vedeném na síťovou infrastrukturu už je jedno, co běží na cílovém počítači.)
    19.1.2014 11:33 Jeason | skóre: 16 | Plzeň
    Rozbalit Rozbalit vše Re: DDOS utok
    proc muze maly utok fail2ban zhorsit ?
    19.1.2014 21:00 Filip Jirsák
    Rozbalit Rozbalit vše Re: DDOS utok
    Protože zaměstná cílový počítač další zbytečnou činností - jednak sledováním těch selhání (pokud se to dělá procházením logů, je to hodně neefektivní), jednak vytvořením dlouhé sady pravidel pro firewall. A přesně o to - zaměstnat počítač něčím neužitečným - se útočník snaží. Pokud se navíc používají falešné zdrojové IP adresy (ICMP, UDP nebo útočník nepotřebuje navázat TCP spojení), blokují se tím IP adresy, které s útokem nemají vůbec nic společného - takže skutečným uživatelům zablokuje přístup fail2ban. Opět, znemožnit používat server skutečným uživatelům, to je přesně to, o co se útočník snaží.
    22.1.2014 03:45 Jeason | skóre: 16 | Plzeň
    Rozbalit Rozbalit vše Re: DDOS utok
    děkuji, takto jsem nad tim nepremyslel, ale je to logické.
    22.1.2014 16:47 iKoulee | skóre: 19
    Rozbalit Rozbalit vše Re: DDOS utok
    +1

    nejlepsi co se da v podobnem pripade delat je ulevit od vsech zbytecnosti

    pokud se jedna o nejaky SYN utok, tak zapnout syncookies a kompletne vypnout veskere firewally (v cetne odebrani modulu, protoze i samotny zavedeny netfilter spotrebovava hromadu vykonu a brzdi packety ve fronte o contracku snad ani netreba mluvit)

    pokud se jedna o utok na nejakou konkretni sluzbu, tak maximalne zjednodusit cestu pozadavku, pokusit se ho co nejdrive identifikovat a zastavit zpracovani

    nekdy byva nejlepsi obrana utok :-) pokud jde DOS z nejake cinske thaiwanske site (nebo podobneho mista kde nehrozi pritomnost regulernich klientu) tak zahltit mistni DNS muze pomoci (minimalne to donuti lokalni ISP zacit zjistovat co se deje)
    Even if you fall on your face, you’re still moving forward
    22.1.2014 19:34 v
    Rozbalit Rozbalit vše Re: DDOS utok

    No mě třeba pomohlo opačné řešení při útoku na web server apache. Se zapnutým syncookies a firewall nastavený na maximální počet navázání spojení z nějaké zdrojové adresy za jednotku času + maximální počet současných spojení z nějaké ip. To mi docela zabralo v první linii oproti DDOS útoku vedenému z několika zemí najednou (minimálně zdrojové IP takové byly), protože z každé z daných IP bylo vždy několik pokusů v podstatě najednou. Tím podstatným ale bylo řešit vyčerpání zdrojů na web serveru kvůli zpracovávání velkého množství requestů na dynamické weby v PHP a tím pádem 100% CPU využití pro běh php skriptů. Díky mod_qos a různým cachím v php byl server během útoku alespoň částečně dostupný i když reagoval strašně pomalu. V podstatě vše jsem vyřešil nasazením varnish cache před apache s vynucením cachování prakticky všeho.

    Nicméně v případě opravdu pořádného DDOS se podle mně prakticky nelze bránit ničím (teda pokud člověk nemá tolik serverů jako třeba Google apod. a nemůže rozložit zátěž).

    23.1.2014 01:27 iKoulee | skóre: 19
    Rozbalit Rozbalit vše Re: DDOS utok
    Pokud zahazujes SYN packety (limit poctu spojeni na IP) tak jsou syncookies vice mene zbytecne. Jinak iptables pomahaji jen v pripade hodne amaterskych pokusu.

    Ano vycerpani zdroju je to cemu se snazime branit, snazil sem se to napsat nejak obecne. Pokud jde konkretne o web na apache, tak je dulezite, aby utocnikovy pozadavky prosli jen na staticky obsah. Pokud treba vsichni roboti utoci na stejne URL (coz byva pomerne bezne) tak misto neho servirovat nejaky staticky soubor s napr javascript redirectem, zkratka tak aby tomu robot nerozumel, ale regulerni prohlizec ano. Obcas se vyplati odchytit si par paketu a prolezt logy, a podivat se jestli podle neceho nelze poznat utocnika od regulerniho klienta, (napr. nejaka zvlastnost/chyba v hlavickach http).

    jinak na zvladnuti bezneho DDOSu asi neni potreba farma ala google, vetsinou mezi serverem a botnetem byvaji jina uzka mista (treba pripojka do zahranicni konektivity) pak staci jen posilit vykon treba jen na 2 nasobek, ale hlavne dusledne posilit linku, protoze u vetsiny serveru (pokd aplikace neni napsana jak prase) dospejete k tomu ze 1Gbit je malo, protoze toho zvladnou upocitat vic
    Even if you fall on your face, you’re still moving forward
    23.1.2014 14:15 Filip Jirsák
    Rozbalit Rozbalit vše Re: DDOS utok
    Omezení počtu spojení z jedné IP adresy je úplně jiná kategorie, než fail2ban. V některých případech to může být dobré řešení. V popsaném případě (spoustu požadavků z jedné IP adresy najednou, a pak asi nějakou dobu nic), by fail2ban selhával přímo ukázkově – úvodní salvu by propustil, a až by bylo po všem, pak by IP adresu slavnostně zablokoval.

    Jinak pokud to jde a aplikace je na to připravená, připadá mi lepší dostat provoz až do aplikace a odmítnutí řešit až tam. Samozřejmě to předpokládá, že ta aplikace vůbec ustojí velký počet spojení a že dokáže ten škodlivý provoz obsloužit rychle. Ale v aplikaci je víc možností, jak škodlivý provoz identifikovat (jak píšete, anomálie v protokolu apod.), jednak je větší šance útočníka nějak omezit – pokud otevře spojení, počká na jeho uzavření a otevře další, můžete mu držet spojení otevřené atd. Nejlépe jde tohle řešit na aplikačním firewallu (v HTTP proxy server nebo load balancer), ten by měl právě umět požadavek zpracovat s minimální režií, ale zároveň vidí všechny podstatné informace.
    23.1.2014 20:14 iKoulee | skóre: 19
    Rozbalit Rozbalit vše Re: DDOS utok
    V podstate se vsim souhlasim.

    Jen mam dost spatne zkusenosti s ohledem na pripravenost aplikaci. Napr u runtime kompilovanych a interpretovanych jazyku je skoda obetovat na utocnika strojovy cas potrebny ke kompilaci a slinkovani skriptu. Oboje lze sice resit, ale aplikaci ktere by na to byli pripraveny je naproste minimum.

    Bohuze deployment do produkce vetsinou vypada jen tak, ze nekdo chytne git a udela check out do produkcniho prostredi, proto jako administrator radeji nenecham zavadne dotazy do aplikace ani dorazit.

    Even if you fall on your face, you’re still moving forward
    23.1.2014 21:53 Filip Jirsák
    Rozbalit Rozbalit vše Re: DDOS utok
    Souhlasím. Aplikaci jsem myslel v širším smyslu, včetně třeba proxy serveru nebo předřazené cache. Pokud tam je jen Apache v defaultní konfiguraci s nějakým skriptovaným bumbrlíčkem, větší nápor neustojí. Ale s takovou aplikací bude problém, i když se podaří část útoku odfiltrovat na firewallu. Pak by ale taková aplikace neměla být nasazována na místo, kde se určitá odolnost proti DDoS vyžaduje. Ale nemám problém s tím, když se na začátku řekne, že DDoS se považuje za nepravděpodobný, případná několikahodinová nedostupnost je přípustná a náklady na ochranu by převýšily přínosy - není to žádná ostuda.
    24.1.2014 21:32 Rishare
    Rozbalit Rozbalit vše Re: DDOS utok
    No obavam se, ze mi moc veci (predevsim aplikaci typu fail2ban) na me strane moc nepomuze, protoze ikdyz primo na vstup zapojim notebook, ktery ma vsechny porty zavrene, presto je linka temer nepouzitelna. Pokud ovsem zustanu na tom stejnem kabelu, jen zmenim na jinou IP (mam nastesti k dispozici vice verejnych IP), tak hned vse jede v poradku.

    Nechci prepisovat DNS zaznamy na jinou verejnou IP, protoze se obavam, ze by velice rychle doslo i k jejimu zahlceni. Zatim jsem zvolil provizorni reseni, ze veskery traffic z vnitrni site vedu pres jinou verejnou IP a servery vystavene pro venek zustavaji na IP pod utokem. Paradoxni je, ze obe verejne IP bezi pres ten stejny ethernetovy kabel.
    25.1.2014 09:35 Filip Jirsák
    Rozbalit Rozbalit vše Re: DDOS utok
    Nerozumím tomu vašemu popisu. Nejdřív píšete, že když na tu linku připojíte počítač s tou IP adresou, na kterou je veden útok, je linka nepoužitelná. Pak zase píšete, že i když tam máte připojený server s danou IP adresou, linka je pro jiné IP adresy pořád použitelná.

    Pokud je to tak, že kapacita linky vyčerpaná není, ale je pomalá komunikace na jedné IP adrese, musí to omezovat ISP – má nastavený limit na šířku pásma pro tu IP adresu.

    Nejdřív ale musíte zjistit, v čem je skutečný problém. Pokud si myslíte, že jde o DDoS útok, zjistěte něco o těch příchozích paketech – jestli směřují na jeden port, co je to vůbec za protokol, jestli jsou opravdu z různých zdrojových adres, kolik jich je. Z toho, co jste popsal, totiž také vůbec nemusí jít o DDoS útok, ale mohl vám ISP jenom přiškrtit pásmo pro danou IP adresu.
    29.1.2014 13:21 Rishare
    Rozbalit Rozbalit vše Re: DDOS utok
    S ISP (UPC) docela svizne komunikujeme a zadny limit tam pry nastaveny neni. Pri mereni rychlosti linky pres ruzne webove sluzby to dokonce ukazuje temer dvojnasobne rychlosti, nez jake mame ve smlouve.

    Rad bych o prichozich paketech zjistil vic, nemam vsak v tehle oblasti moc zkusenosti. Nemohl byste mi pro to prosim nejake nastroje doporucit?
    29.1.2014 13:45 alkoholik | skóre: 40 | blog: Alkoholik
    Rozbalit Rozbalit vše Re: DDOS utok
    tcpdump
    29.1.2014 17:53 Rishare
    Rozbalit Rozbalit vše Re: DDOS utok
    Tak jsem neco zkousel, ale moc chytry z toho nejsem. Jde o mailserver za firewallem:
    [root@mail ~]# tcpdump -X -l -w - port 25 | strings -a
    
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
    2DO~
    220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
    2DO~
    220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
    220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
    500 5.5.1 Command unrecognized: ",Z'C~D/
    2D](\
    220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
    f<fG
    f<fG
    220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
    2D<K
    500 5.5.1 Command unrecognized: "
    (T7@
    _e\gO
    2DK(
    2D\gO
    K(}	uL
    _b\gO
    2DK(
    z}	uMP
    [`\gO
    2DK(
    z}	uMP
    {#RHi[Y
    fpm_qw
    2D\gO
    K(}	uM
    2D<K
    (j}@
    2D]=
    ?rGa
    ]?*P
    ]=}{:
    500 5.5.1 Command unrecognized: "bc[
    ]=}{;
    2D]=
    500 5.5.1 Command unrecognized: "
    500 5.5.1 Command unrecognized: "
    2D<K
    500 5.5.1 Command unrecognized: "
    \bF2
    2D\bF2
    2D\gO
    K(}	uM
    220 mujserver.cz ESMTP Sendmail 8.13.1/8.13.1;
    \bF2
    \bF2
    2D\bF2
    2DK(
    z}	x8P
    X%}P
    X%}P
    @)e{
    h}Wv
    O0tn
    0R%@
    (R+@
    (R,@
    
    [root@mail ~]# tcpdump -ni eth0 'dst 192.168.50.68' |head -n 30
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
    17:45:38.218437 IP 192.168.50.55.45795 > 192.168.50.68.ssh: . ack 200739613 win 1323 <nop,nop,timestamp 144251835 171133595>
    17:45:38.218507 IP 192.168.50.55.45795 > 192.168.50.68.ssh: . ack 113 win 1323 <nop,nop,timestamp 144251835 171133595>
    17:45:38.453184 IP 190.239.157.188.59769 > 192.168.50.68.smtp: F 578564534:578564534(0) ack 2511328731 win 16616
    17:45:38.692882 IP 190.239.157.188.59769 > 192.168.50.68.smtp: R 1:1(0) ack 160 win 0
    17:45:39.331688 IP 178.248.39.10.60333 > 192.168.50.68.smtp: R 706985253:706985253(0) ack 2520855258 win 16384
    17:45:39.455043 IP 122.164.190.40.29535 > 192.168.50.68.smtp: R 2077333757:2077333757(0) ack 2514071860 win 16384
    17:45:39.539647 IP 81.93.6.152.14054 > 192.168.50.68.smtp: F 120277023:120277023(0) ack 2510789905 win 65202
    17:45:39.616262 IP 81.93.6.152.14054 > 192.168.50.68.smtp: R 1:1(0) ack 38 win 0
    17:45:40.079257 arp who-has 192.168.50.68 tell 192.168.50.1
    17:45:40.395685 IP 86.64.144.172.53573 > 192.168.50.68.smtp: F 1520487877:1520487877(0) ack 2515604318 win 2920 <nop,nop,timestamp 925174499 171133420>
    17:45:40.398128 IP 192.168.50.55.45795 > 192.168.50.68.ssh: . ack 1185 win 1323 <nop,nop,timestamp 144254014 171134140>
    17:45:41.491866 IP 82.71.5.240.34948 > 192.168.50.68.smtp: F 289190999:289190999(0) ack 2519538730 win 254
    17:45:41.626310 IP 82.71.5.240.34948 > 192.168.50.68.smtp: R 1:1(0) ack 79 win 0
    17:45:41.650807 IP 181.66.39.65.54786 > 192.168.50.68.smtp: F 3796169060:3796169060(0) ack 2514954746 win 16938
    17:45:41.878169 IP 181.66.39.65.54786 > 192.168.50.68.smtp: R 1:1(0) ack 240 win 0
    17:45:41.880095 IP 181.66.39.65.54786 > 192.168.50.68.smtp: R 3796169061:3796169061(0) win 0
    17:45:42.528168 IP 86.64.144.172.53573 > 192.168.50.68.smtp: R 1520487878:1520487878(0) win 0
    17:45:42.528632 IP 86.64.144.172.53573 > 192.168.50.68.smtp: R 1520487878:1520487878(0) win 0
    17:45:42.808445 IP 72.8.1.186.33348 > 192.168.50.68.smtp: F 15125237:15125237(0) ack 2507305667 win 16296
    17:45:42.979094 IP 72.8.1.186.33348 > 192.168.50.68.smtp: R 1:1(0) ack 187 win 0
    17:45:43.268603 IP 181.165.69.204.2047 > 192.168.50.68.smtp: S 1437914439:1437914439(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,sackOK>
    17:45:43.271060 IP 192.168.50.55.45795 > 192.168.50.68.ssh: . ack 2257 win 1323 <nop,nop,timestamp 144256887 171134858>
    17:45:43.396337 IP 176.249.19.176.64706 > 192.168.50.68.smtp: S 1686973645:1686973645(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
    17:45:43.457368 IP 176.249.19.176.64706 > 192.168.50.68.smtp: . ack 2529639876 win 16425
    17:45:43.471707 IP 176.249.19.176.64706 > 192.168.50.68.smtp: P 0:1024(1024) ack 1 win 16425
    17:45:43.500534 IP 90.207.238.101.domain > 192.168.50.68.32768:  4458 NXDomain*- 0/1/1 (103)
    17:45:43.552884 IP 181.165.69.204.2047 > 192.168.50.68.smtp: . ack 2516948740 win 64000
    17:45:43.561819 IP 181.165.69.204.2047 > 192.168.50.68.smtp: P 0:1024(1024) ack 1 win 64000
    17:45:45.438570 IP 81.20.147.34.1839 > 192.168.50.68.smtp: S 2628082629:2628082629(0) win 65535 <mss 1460,nop,nop,sackOK>
    17:45:45.498282 IP 81.20.147.34.1839 > 192.168.50.68.smtp: . ack 2530633455 win 65535
    49 packets captured
    49 packets received by filter
    0 packets dropped by kernel
    
    30.1.2014 08:25 Filip Jirsák
    Rozbalit Rozbalit vše Re: DDOS utok
    To vypadá, jako by na ten mailserver byl přesměrovaný nějaký šifrovaný protokol. Každopádně tímhle způsobem to těžko vyřešíme, na to máme zoufale málo informací – nevíme nic o topologii sítě, o konfiguraci firewallu, o běžících službách… Pravděpodobně pokud si k tomu počítači sedne někdo, kdo tomu trochu rozumí, najde a vyřeší chybu za 10 minut. Doporučuji tedy sehnat někoho, kdo se vám o ten server bude starat – provozovat veřejný server bez znalostí sítí opravdu není možné.

    Pokud na straně UPC není žádné omezení, pak nevím, co znamená věta z dotazu „To se diky spolupraci s poskytovatelem (UPC) podarilo vicemene odfiltrovat“. Nebo to znamenalo, že UPC vám poradilo, co si máte na serveru nastavit? Každopádně z toho, co zatím víme, takřka jistě nejde o externí DoS útok a už vůbec ne o DDoS. Spíš to tipuju na chybnou konfiguraci – serverů, firewallu nebo něčeho takového.
    31.1.2014 13:04 marek
    Rozbalit Rozbalit vše Re: DDOS utok

    Dobry den.

    DDOS s 5 packety za sekundu je opravdu "masivni".

    Podobne chovani jsem zazil u adslmodemu, ktery natoval-routoval.

    Ono se dost setri - takze dokazal udrzet jen asi 256 spojeni.

    Vzhledem k tomu, ze utocnik spojeni nezavira, tak vam to i pri jednom utoku za sekundu do peti minut vycerpa.

    Marek

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.