Desavil

Witam, mam do swojego serwera podpiętych kilka adresów IP. W jaki sposób mogę ustalić ten, który jest widoczny, np. jak robię ping do innego serwera to jako źródło ten serwer widzi mój ustalony adres IP. Analogicznie, jak np. wchodzę z serwera na jakąś stronę przez curl. System to Debian 7.0.

Powiem tak, od momentu, kiedy zainstalowałem na tej maszynie serwer OpenVPN teraz jak jakby głównym IP (widocznym jako wychodzący, jak gdzieś się łącze) serwera jest IP ustawione w eth0:0, czyli podawane w przykładach: bbb.bbb.bbb.bbb zamiast aaa.aaa.aaa.aaa eth0 Link encap:Ethernet HWaddr 00:22:4d:99:65:ea inet addr:aaa.aaa.aaa.aaa Bcast:aaa.aaa.aaa.255 Mask:255.255.254.0 inet6 addr: fe80::222:4dff:fe99:65ea/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:96943225442 errors:0 dropped:266537 overruns:0 frame:0 TX packets:118442165497 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:39642630200933 (36.0 TiB) TX bytes:106495000623161 (96.8 TiB) Interrupt:20 Memory:fe600000-fe620000 eth0:0 Link encap:Ethernet HWaddr 00:22:4d:99:65:ea inet addr:bbb.bbb.bbb.bbb Bcast:bbb.bbb.bbb.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:20 Memory:fe600000-fe620000 eth0:1 Link encap:Ethernet HWaddr 00:22:4d:99:65:ea inet addr:ccc.ccc.ccc.ccc Bcast:ccc.ccc.ccc.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:20 Memory:fe600000-fe620000 eth0:2 Link encap:Ethernet HWaddr 00:22:4d:99:65:ea inet addr:ddd.ddd.ddd.ddd Bcast:ddd.ddd.ddd.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:20 Memory:fe600000-fe620000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3006187632 errors:0 dropped:0 overruns:0 frame:0 TX packets:3006187632 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1447588822651 (1.3 TiB) TX bytes:1447588822651 (1.3 TiB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.1.1.1 P-t-P:10.1.1.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:1178 errors:0 dropped:0 overruns:0 frame:0 TX packets:1092 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:96472 (94.2 KiB) TX bytes:91728 (89.5 KiB) /etc/network/interfaces auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address aaa.aaa.aaa.aaa netmask 255.255.254.0 network aaa.aaa.aaa.0 broadcast eee.eee.eee.255 gateway aaa.aaa.aaa.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 8.8.8.8 8.8.4.4 auto eth0:0 iface eth0:0 inet static address bbb.bbb.bbb.bbb netmask 255.255.254.0 gateway bbb.bbb.bbb.1 auto eth0:1 iface eth0:1 inet static address ccc.ccc.ccc.ccc netmask 255.255.254.0 gateway ccc.ccc.ccc.1 auto eth0:2 iface eth0:2 inet static address ddd.ddd.ddd.ddd netmask ddd.ddd.ddd.0 gateway ddd.ddd.ddd.1

Ping i curl to tylko przykłady. Chodzi mi o cały ruch tego typu, gdyż w niektórych aplikacjach tego ustawić nie można.

Uruchomiłem sobie serwer VPN zgodnie z tym poradnikiem - https://www.e24cloud.com/pl/Dla-deweloperow/Jak-to-zrobic/Konfiguracja-bezpiecznego-tunelu-VPN-na-systemie-Linux-Debian Ale chyba niestety nie działa prawidłowo, gdyż połączenie jest bardzo wolne. Jak wykonuje, np. ping dopiero po kilkudziesięciu sekundach dostaje odpowiedź i potem leci z 20 odpowiedzi i znów pauza za kilkadziesiąt sekund i znów leci. Zmieniłem typ połączenia na TCP i działa, szybko i bezproblemowo.

Witam, czy istnieje możliwość, aby zablokować logowanie do komputera po podłączeniu do niego myszki/klawiatury/monitora? Najlepiej jakby wyświetlał się w tym miejscu mój ustalony komunikat. Chcę, aby logowanie do systemu działało wyłącznie przez SSH.

Dzięki, sprawdzę czy działa z tym rekordem A.

Witam, od kilku godzin męczę się z zablokowaniem na moim serwerze ruchu wychodzącego. Mam postawionego jednego VPS'a na OpenVZ (za NATem) i chcę dla niego zablokować cały ruch wychodzący z poziomu matki, tak aby maksymalnie ruch ten wyszedł na matkę i z niej już nigdzie dalej. Za pomocą iptables. Fizyczny interfejs sieciowy to: eth0 Wirtualny: vnet0 Mógłbym prosić o jakiś przykład? Pozdrawiam!

Witam, muszę ograniczyć dla kilkuset portów limit połączeń na nie. Obecnie używam ipset oraz iptables, ale wydaje mi się że nie do końca działa to prawidłowo, być może coś źle to skonfigurowałem. Co dokładnie chcę osiągnąć? Mamy porty przykładowo: 5000, 5001, 5002, 5003, 5004 i jednego użytkownika, np. z adresem IP: A. Chcę, aby na każdy z tych portów ilość połączeń użytkownika A była liczona oddzielnie. Przykładowo jeżeli umożliwię 5 połączeń to na każdym z tych portów z adresu IP A będzie mogło być po 5 połączeń (w sumie 25 połączeń z adresu IP: A). I tak dla każdego adresu IP osobno (nie sumuje się to), każdy nowy adres IP z którego są połączenia dla nich są one liczone oddzielnie dla każdego z portów. Jeżeli ktoś będzie próbował nawiązać, np. 8 połączeń z danym portem to zablokuje mu nowe połączenia tylko na ten port z którym próbuje nawiązać te 8 połączeń, a nie na wszystkie porty serwera. Obecnie to wygląda mniej więcej tak: ipset create limit_polaczen bitmap:port range 5000-5005 ipset add limit_polaczen 5000 ... ipset add limit_polaczen 5005 iptables -I INPUT -m set --match-set limit_polaczen dst -p tcp --syn ! -i lo -m connlimit --connlimit-above 5 -j DROP Wydaje mi się, że obecnie jeżeli ktoś przekroczy 5 połączeń to blokuje go na wszystkie porty, a nie wyłącznie na ten na którym przekracza tę ilość. Dziękuję za pomoc.

Do samego serwera może dojść, to mi akurat tutaj nie przeszkadza. Chodzi o to, aby do aplikacji się nie dostał, bo wtedy ją automatycznie "zabija".

Możesz podać jakiś przykład?

Ok, spróbuję tak jak piszesz. Mój firewall generalnie zaczyna się tak: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m conntrack --ctstate NEW -p tcp --tcp-flags SYN,RST,ACK,FIN,URG,PSH ACK -j DROP iptables -A INPUT -m conntrack --ctstate NEW -p tcp --tcp-flags SYN,RST,ACK,FIN,URG,PSH FIN -j DROP iptables -A INPUT -m conntrack --ctstate NEW -p tcp --tcp-flags SYN,RST,ACK,FIN,URG,PSH FIN,URG,PSH -j DROP iptables -A INPUT -m conntrack --ctstate INVALID -p tcp ! --tcp-flags SYN,RST,ACK,FIN,PSH,URG SYN,RST,ACK,FIN,PSH,URG -j DROP iptables -A INPUT -p icmp -m limit --limit 2/second --limit-burst 2 -j ACCEPT Czy jak na końcu tego dodam te ~4k regułek to będzie dobrze? Rozumiem, że: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT Jest traktowane podobnie jak != syn bo ESTABLISHED to już nawiązane połączenie. PS. Dlaczego w swoim przykładzie (oczywiście wiem czym one się różnią, ale w przypadku ataku i tak będą kolejne połączenia, a co za tym idzie będę dodatkowo zapychał sobie łącze wysyłając odpowiedź z komunikatem - bynajmniej tak mi się wydaje): -j REJECT --reject-with tcp-reset Użyłeś REJECT, zamiast DROP?

Slowloris, sockstress i inne podobne ataki (uprzedzam, nie chodzi o żadne usługi www typu apache2/nginx itp.) Tak, sumuje to jako całość, więc musiałoby być to oddzielnie. Ale jak to ma się do wydajności przy 4000 regułek iptables?

Tylko jest jeden "mały" problem. Muszę dodać to ograniczenie dla ponad 4000 portów. Nie wydaje mi się, aby iptables podołał z tyloma regułami, stąd też użyłem ipset'a.

Witam, nie będę zadawał pytania, który system lepiej wybrać bo takich tematów jest sporo. Ja osobiście od zawsze praktycznie korzystam z Debiana i jak dla mnie jest najlepszy, ale teraz zostałem zmuszony przenieść jeden z serwerów na system CentOS. Obecnie mam tam Debiana i wirtualizację OpenVZ, jednak większość dziwi się dlaczego stawiam OpenVZ na Debianie, skoro powinno się to robić na CentOS'ie. Dlatego też rozważam przeniesienie się na ten system. Wcześniej nie miałem z nim większej styczności, jednak zarządzanie pakietami w nim jest nieco inne niż w Debianie. Stąd też moje pytanie, czy lepiej używać domyślnego yum, czy też mogę zainstalować sobie apt i korzystać z niego (a już super byłoby, gdyby działało aptitude)? Jakie macie o tym zdanie? Pozdrawiam!

Witam, postawiłem sobie DirectAdmina na kontenerze OpenVZ. Niestety nie wiem dlaczego, ale podczas tworzenia nowego użytkownika pojawia się taki błąd: Błąd z systemem quoty setquota: Mountpoint (or device) / not found or has no quota enabled. setquota: Not all specified mountpoints are using quota. Szukałem rozwiązania w internecie, w helpie DA ale niestety nie znalazłem odpowiedniego rozwiązania. Próbowałem ustawić też na matce dla CT coś takiego: vzctl set 100 --quotaugidlimit 10000 --save Ale też to niestety niczego nie zmienia. Ma ktoś może jakiś pomysł w jaki sposób mógłbym to naprawić?

Ok, napiszę co do tej pory udało się osiągnąć i co nadal nie działa. Po pierwsze, zmiana w pliku /usr/local/directadmin/conf/directadmin.conf zmiennej quota_partition=/ na quota_partition=/dev/simfs To rozwiązuje problem, który opisałem w pierwszym poście. Po restarcie DA/systemu przy próbie dodania użytkownika w panelu DA wyświetla się nowy błąd: Błąd z systemem quoty setquota: Quota write failed (id 1017): Invalid argument Jak w systemie wykonam którąś z komend - quotacheck -vguma lub quotacheck -um /dev/simfs Błąd się nie wyświetla i dodaje prawidłowo użytkownika (w/w komendy należy wykonać zawsze po restarcie kontenera, w innym wypadku błąd z setquota się pojawia ponownie), natomiast po wpisaniu komendy - repquota -a zwraca ona następujący wynik: *** Report for user quotas on device /dev/simfs Block grace time: 00:00; Inode grace time: 00:00 Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- testt -- 100172 0 0 45 0 0 Czy w miejscu soft oraz hard limits nie powinien być czasem ustawiony limit? Bynajmniej na serwerze, gdzie bezpośrednio zainstalowane jest DA bez wirtualizacji, jest tutaj limit tyle ile zostało przydzielone. Ponadto, zauważyłem jeszcze jedną różnicę. Na drugim serwerze w tym miejscu - Block grace time: 00:00; Inode grace time: 00:00 wyświetla się Block grace time: 7 days; Inode grace time: 7 days. Nie wiem, czy też to ma może jakiś zasadniczy wpływ na ten problem. Jak ręcznie ustawię limit za pomocą komendy - setquota testt 1024 1024 0 0 /dev/simfs wyświetla się ten limit użytkownika w wyniku polecenia - repquota -a, ale po restarcie systemu już jest zarówno w soft jak i hard limit - 0, czyli coś nadal tutaj nie działa. W ustawieniach kontenera są dodane takie opcje: QUOTAUGIDLIMIT="10000" DISK_QUOTA="yes" Tutaj wynik z matki - dyski na tym serwerze to 2x120GB SSD (większość przydzielona na: /): df -h System plików rozm. użyte dost. %uż. zamont. na udev 10M 0 10M 0% /dev tmpfs 3,2G 308K 3,2G 1% /run /dev/md2 110G 26G 79G 25% / tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 6,3G 0 6,3G 0% /dev/shm /dev/md1 193M 40M 144M 22% /boot /home/vz/private/100 29G 3,2G 26G 12% /home/vz/root/100 none 3,0G 4,0K 3,0G 1% /home/vz/root/100/dev none 615M 1,1M 614M 1% /home/vz/root/100/run none 5,0M 0 5,0M 0% /home/vz/root/100/run/lock none 1,2G 0 1,2G 0% /home/vz/root/100/run/shm none 100M 0 100M 0% /home/vz/root/100/run/user Zauważyłem jeszcze coś takiego po wykonaniu komendy - /etc/init.d/quota restart, może dlatego to nie wstaje po restarcie kontenera?: [....] Turning off quotas...quotaoff: quotactl on /dev/simfs [/]: No such device quotaoff: quotactl on /dev/simfs [/]: No such device done. [warn] Checking quotas...[....] Warning: user quota not configured in filesystem `/dev/pts.' ... (warning). [warn] Warning: group quota not configured in filesystem `/dev/pts.' ... (warning). done. [....] Turning on quotas...quotaon: using //aquota.group on /dev/simfs [/]: No such device quotaon: using //aquota.user on /dev/simfs [/]: No such device

Dlatego - http://www.webhostingtalk.pl/topic/49189-blad-z-systemem-quoty-directadmin/ Żaden administrator nie umie naprawić tego problemu (a było już ich kilkanaście) i chcę spróbować, czy może zmiana systemu na CentOS coś tutaj zmieni.

Tak. Zachęcam do zobaczenia tego tutoriala, oraz ogólnie przejrzenia tych filmów -

Dodam, że system operacyjny to Debian 7.0, 64bit.

Witam, zlecę naprawienie problemu, który został szczegółowo opisany w tym temacie na forum - http://www.webhostingtalk.pl/topic/49189-blad-z-systemem-quoty-directadmin/ Osoby chętne proszę o kontakt na PW. Pozdrawiam!

Witam, dla pewnej usługi kilka minut po jej uruchomieniu (wygląda to na ustawiony cron co 1 min u atakującego), gdyż o pełnej minucie zaczyna się atak - obserwuję bardzo duży ruch z jednego adresu IP, na port mojej usługi. Nie jest to jakiś atak co zapychałby łącze, nie przekracza on 1Mbps, ale zapycha usługę ilością zapytań w bardzo krótkim odstępie czasu. Logi: Client Server State Idle A Speed 37.187.41.198:42650 x.x.x.x:25565 ESTABLISHED 2s 0 B/s 37.187.41.198:42077 x.x.x.x:25565 ESTABLISHED 0s 132 KB/s 37.187.41.198:42076 x.x.x.x:25565 ESTABLISHED 1s 0 B/s 37.187.41.198:42067 x.x.x.x:25565 ESTABLISHED 0s 0 B/s 37.187.41.198:42075 x.x.x.x:25565 ESTABLISHED 2s 0 B/s 37.187.41.198:42078 x.x.x.x:25565 ESTABLISHED 4s 0 B/s 37.187.41.198:42060 x.x.x.x:25565 ESTABLISHED 0s 0 B/s 37.187.41.198:42063 x.x.x.x:25565 ESTABLISHED 0s 0 B/s 37.187.41.198:42653 x.x.x.x:25565 ESTABLISHED 0s 0 B/s 37.187.41.198:42079 x.x.x.x:25565 ESTABLISHED 1s 0 B/s 37.187.41.198:42074 x.x.x.x:25565 ESTABLISHED 2s 0 B/s 37.187.41.198:42647 x.x.x.x:25565 ESTABLISHED 3s 0 B/s 37.187.41.198:42080 x.x.x.x:25565 ESTABLISHED 2s 0 B/s 37.187.41.198:42073 x.x.x.x:25565 ESTABLISHED 1s 0 B/s 37.187.41.198:42072 x.x.x.x:25565 ESTABLISHED 3s 0 B/s 37.187.41.198:42066 x.x.x.x:25565 ESTABLISHED 0s 0 B/s 37.187.41.198:42081 x.x.x.x:25565 ESTABLISHED 1s 0 B/s 37.187.41.198:42658 x.x.x.x:25565 ESTABLISHED 3s 0 B/s 37.187.41.198:42651 x.x.x.x:25565 ESTABLISHED 0s 0 B/s 37.187.41.198:42071 x.x.x.x:25565 ESTABLISHED 1s 0 B/s 37.187.41.198:42656 x.x.x.x:25565 ESTABLISHED 3s 0 B/s 37.187.41.198:42660 x.x.x.x:25565 ESTABLISHED 8s 0 B/s 37.187.41.198:42062 x.x.x.x:25565 ESTABLISHED 1s 0 B/s 37.187.41.198:42648 x.x.x.x:25565 ESTABLISHED 0s 0 B/s 37.187.41.198:42644 x.x.x.x:25565 ESTABLISHED 1s 0 B/s 37.187.41.198:42070 x.x.x.x:25565 ESTABLISHED 2s 0 B/s 37.187.41.198:42065 x.x.x.x:25565 ESTABLISHED 3s 0 B/s 37.187.41.198:42654 x.x.x.x:25565 ESTABLISHED 3s 0 B/s 37.187.41.198:42645 x.x.x.x:25565 ESTABLISHED 4s 0 B/s 37.187.41.198:42069 x.x.x.x:25565 ESTABLISHED 0s 132 KB/s 37.187.41.198:42649 x.x.x.x:25565 ESTABLISHED 0s 0 B/s 37.187.41.198:42652 x.x.x.x:25565 ESTABLISHED 1s 0 B/s 37.187.41.198:42061 x.x.x.x:25565 ESTABLISHED 0s 64 KB/s 37.187.41.198:42064 x.x.x.x:25565 ESTABLISHED 0s 0 B/s 37.187.41.198:42657 x.x.x.x:25565 ESTABLISHED 1s 0 B/s TOTAL 328 KB/s Connections 1-35 of 40 Unpaused Unsorted 23:39:21.976516 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 13713:15161, ack 1, win 0, options [nop,nop,TS val 1054079415 ecr 88469701], length 1448 23:39:21.976538 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 15161, win 351, options [nop,nop,TS val 88469712 ecr 1054079415], length 0 23:39:21.976519 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 15161:16609, ack 1, win 0, options [nop,nop,TS val 1054079415 ecr 88469701], length 1448 23:39:21.976543 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 16609, win 362, options [nop,nop,TS val 88469712 ecr 1054079415], length 0 23:39:21.976692 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [P.], seq 16609:18057, ack 1, win 0, options [nop,nop,TS val 1054079415 ecr 88469701], length 1448 23:39:21.976703 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 18057, win 374, options [nop,nop,TS val 88469713 ecr 1054079415], length 0 23:39:21.976740 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 18057:19505, ack 1, win 0, options [nop,nop,TS val 1054079415 ecr 88469701], length 1448 23:39:21.976749 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 19505, win 385, options [nop,nop,TS val 88469713 ecr 1054079415], length 0 23:39:21.976799 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 19505:20953, ack 1, win 0, options [nop,nop,TS val 1054079415 ecr 88469701], length 1448 23:39:21.976808 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 20953, win 396, options [nop,nop,TS val 88469713 ecr 1054079415], length 0 23:39:21.976922 IP 198.ip-37-187-41.eu.42067 > x.x.x.x.25565: Flags [.], seq 33985:35433, ack 1, win 0, options [nop,nop,TS val 1054079415 ecr 88469702], length 1448 23:39:21.977033 IP 198.ip-37-187-41.eu.42067 > x.x.x.x.25565: Flags [.], seq 35433:36881, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.977146 IP 198.ip-37-187-41.eu.42067 > x.x.x.x.25565: Flags [.], seq 36881:38329, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.977261 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 20953:22401, ack 1, win 0, options [nop,nop,TS val 1054079415 ecr 88469701], length 1448 23:39:21.977273 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 22401, win 408, options [nop,nop,TS val 88469713 ecr 1054079415], length 0 23:39:21.977263 IP 198.ip-37-187-41.eu.42067 > x.x.x.x.25565: Flags [.], seq 38329:39777, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.977373 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 22401:23849, ack 1, win 0, options [nop,nop,TS val 1054079415 ecr 88469702], length 1448 23:39:21.977382 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 23849, win 419, options [nop,nop,TS val 88469713 ecr 1054079415], length 0 23:39:21.977482 IP 198.ip-37-187-41.eu.42067 > x.x.x.x.25565: Flags [.], seq 39777:41225, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.977587 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 23849:25297, ack 1, win 0, options [nop,nop,TS val 1054079415 ecr 88469702], length 1448 23:39:21.977597 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 25297, win 419, options [nop,nop,TS val 88469713 ecr 1054079415], length 0 23:39:21.977695 IP 198.ip-37-187-41.eu.42067 > x.x.x.x.25565: Flags [.], seq 41225:42673, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.977824 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 25297:26745, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.977833 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 26745, win 414, options [nop,nop,TS val 88469714 ecr 1054079416], length 0 23:39:21.977826 IP 198.ip-37-187-41.eu.42067 > x.x.x.x.25565: Flags [.], seq 42673:44121, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.977935 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 26745:28193, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.977946 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 28193, win 409, options [nop,nop,TS val 88469714 ecr 1054079416], length 0 23:39:21.978047 IP 198.ip-37-187-41.eu.42067 > x.x.x.x.25565: Flags [.], seq 44121:45569, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.978129 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 28193:29641, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.978138 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 29641, win 404, options [nop,nop,TS val 88469714 ecr 1054079416], length 0 23:39:21.978241 IP 198.ip-37-187-41.eu.42067 > x.x.x.x.25565: Flags [.], seq 45569:47017, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.978347 IP 198.ip-37-187-41.eu.42654 > x.x.x.x.25565: Flags [.], seq 29641:31089, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 23:39:21.978355 IP x.x.x.x.25565 > 198.ip-37-187-41.eu.42654: Flags [.], ack 31089, win 399, options [nop,nop,TS val 88469714 ecr 1054079416], length 0 23:39:21.978454 IP 198.ip-37-187-41.eu.42067 > x.x.x.x.25565: Flags [.], seq 47017:48465, ack 1, win 0, options [nop,nop,TS val 1054079416 ecr 88469702], length 1448 Nie ma chyba czegoś takiego jak atak TCP ZeroWindow (w logach Wiresharka tak podaje w informacjach o pakiecie), bardziej wydaje mi się, że jest to jakiś Socketstress. Czy ma ktoś jakiś pomysł jak za pomocą iptables mogę ograniczy te połączenia, aby nie zasypywały usługi? Oczywiście DROP na IP jest już zrobione, ale jaki to będzie miało sens jeżeli atakujący zmieni IP, powinno to być automatycznie, stąd też piszę do Was z prośbą o pomoc.

Tak, zgadłeś. Jakieś rozwiązanie oparte o iptables na ten atak jest? Próbowałem różnych kombinacji z connlimit i niestety nie było widać, aby atakujący się na nie "złapał". Też zgłoszę oczywiście abuse.

Co masz na myśli?

Tak, ale kernel mam zainstalowany taki: 2.6.32-openvz-042stab093.4-amd64

Też nic, robiłem to też wcześniej. Wynik polecenia mount: /home/vz/private/101 on / type simfs (rw,relatime,usrquota,grpquota) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) none on /dev type devtmpfs (rw,nosuid,noexec,relatime,mode=755) none on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) none on /run type tmpfs (rw,nosuid,noexec,relatime,size=629148k,mode=755) none on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) none on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1258280k) none on /run/user type tmpfs (rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755) Polecenie df: Filesystem Size Used Avail Use% Mounted on /dev/simfs 29G 3.1G 26G 11% / none 3.0G 4.0K 3.0G 1% /dev none 615M 1.1M 614M 1% /run none 5.0M 0 5.0M 0% /run/lock none 1.2G 0 1.2G 0% /run/shm none 100M 0 100M 0% /run/user