Ping vliegt om de zoveel tijd omhoog.

[eppie]

Hallo,

Ik heb nogal een rot probleem waar niet uitkom.

Ik heb een stel pc's op inet hangen via een debian router.
Maar sinds kort vliegt me ping zomaar in eens naar de 5000+ en soms naar de 10000+. Ook nu als ik dit type en heeft ook veel moeite gekost om deze pagina voor de dag te toveren , nou dacht ik dat ligt aan chello, niet dus want als ik me default route er uitgooi (213.46.80.1) en ga dan die dan pingen dan is me ping meteen weer normaal, maar maak ik hem weer als default route dan loopt de ping weer op .

code:

Kernel IP routing table
Destination     Gateway    Genmask     Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0    255.255.255.0   U     0  0     0 eth0
213.46.80.0     0.0.0.0    255.255.255.0   U     0  0     0 eth1
0.0.0.0    213.46.80.1     0.0.0.0     UG    0  0     0 eth1

ifconfig:
eth0    Link encap:Ethernet  HWaddr 00:80:48:C8:24:8F
        inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:155520 errors:0 dropped:0 overruns:0 frame:0
        TX packets:115103 errors:1 dropped:0 overruns:0 carrier:0
        collisions:18 txqueuelen:100
        Interrupt:10 Base address:0x6100

eth1    Link encap:Ethernet  HWaddr 00:80:48:C5:39:45
        inet addr:213.46.80.144  Bcast:213.46.80.255  Mask:255.255.255.0
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:385003 errors:0 dropped:0 overruns:0 frame:0
        TX packets:70394 errors:0 dropped:0 overruns:0 carrier:0
        collisions:16 txqueuelen:100
        Interrupt:11 Base address:0x6200

lo    Link encap:Local Loopback
        inet addr:127.0.0.1  Mask:255.0.0.0
        UP LOOPBACK RUNNING  MTU:16436  Metric:1
        RX packets:12 errors:0 dropped:0 overruns:0 frame:0
        TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:0

Ik had dus NIETS veranderd, dit is zo maar begonnen , ook ben ik dan van buitenaf niet meer te bereiken .

ALvast bedankt!

[deadinspace]

Loopt er niet toevallig vanaf een van de PCs een dikke upstream? Kun je proberen door ff de netwerk-kabel van je interne netwerk eruit te trekken.

[eppie]

Nee dat heb ik allemaal al gecheckt

Nu heb ik weer geen last van echt vaag.

Als ik alle kabels behalve inet er uithaal en alle services zoals ftp en http kill blijft de ping hoog, pas als ik de default route er uit gooi gaat ie meteen weer naar normaal. Maar ja dan kom je niet echtver op internet .

[Buffy]

Op maandag 20 mei 2002 22:45 schreef deadinspace het volgende:
Loopt er niet toevallig vanaf een van de PCs een dikke upstream? Kun je proberen door ff de netwerk-kabel van je interne netwerk eruit te trekken.

Zat ik ook aan te denken. Het verwijderen van de default route zou die upload onderbreken.
Hoewel je RX/TX in de ifconfig output niet echt hoog zijn.

Probeer eens de programma's netload en/of statnet(d) om te controleren wat er aan netwerk verkeer langskomt.

-oeps-

voortaan sneller typen

[leander]

Ik heb zoiets weleens gehad met een op hol geslagen netwatch-daemon (netwerkverbinding monitor).
Die herstartte om de haverklap m'n firewall e.a.

Wellicht iets om naar te kijken?

[eppie]

Op dinsdag 21 mei 2002 03:55 schreef Leander het volgende:
Ik heb zoiets weleens gehad met een op hol geslagen netwatch-daemon (netwerkverbinding monitor).
Die herstartte om de haverklap m'n firewall e.a.

Wellicht iets om naar te kijken?

Heb geen netwatch draaien

ik heb dit draaien:

code:

 PID TTY        TIME CMD
    1 ?   00:00:03 init
    2 ?   00:00:00 keventd
    3 ?   00:00:00 ksoftirqd_CPU0
    4 ?   00:00:02 kswapd
    5 ?   00:00:00 bdflush
    6 ?   00:00:00 kupdated
   96 ?   00:00:00 portmap
  186 ?   00:00:00 rpc.statd
  200 ttyS0    00:00:00 gpm
  205 ?   00:00:00 inetd
  219 ?   00:00:00 httpd
  221 ?   00:00:00 safe_mysqld
  224 ?   00:00:05 httpd
  225 ?   00:00:03 httpd
  226 ?   00:00:02 httpd
  227 ?   00:00:02 httpd
  228 ?   00:00:01 httpd
  231 ?   00:00:00 in.proftpd
  244 ?   00:00:00 mysqld
  246 ?   00:00:00 smbd
  248 ?   00:00:00 mysqld
  249 ?   00:00:00 mysqld
  266 ?   00:00:00 atd
  269 ?   00:00:00 cron
  273 tty2     00:00:00 getty
  274 tty3     00:00:00 getty
  275 tty4     00:00:00 getty
  276 tty5     00:00:00 getty
  277 tty6     00:00:00 getty
  880 ?   00:00:01 httpd
  882 ?   00:00:03 httpd
  883 ?   00:00:01 httpd
  884 ?   00:00:01 httpd
  886 ?   00:00:00 httpd
  924 tty1     00:00:00 bash
 1036 ?   00:00:06 sshd
 1191 ?   00:00:00 nmbd
 2836 ?   00:00:00 httpd
 2837 ?   00:00:00 httpd
 2877 ?   00:00:00 httpd
 2878 ?   00:00:00 httpd
 2944 ?   00:00:00 httpd
 2948 ?   00:00:00 httpd
 2951 ?   00:00:00 httpd
 2982 ?   00:00:00 httpd
 2983 ?   00:00:00 httpd
 2984 ?   00:00:00 httpd
 2989 ?   00:00:00 sshd
 2990 pts/0    00:00:00 bash
 2992 pts/0    00:00:00 ps

Als ik ftpd en httpd kill blijft de ping zo hoog dus dat is het niet

[wiho]

Met "tcpdump -i eth1" kun je al 't verkeer op je externe interface bekijken. Doe dat 'ns een tijdje om te zien of er inderdaad een periodieke traffic-burst plaatsvindt...

[deadinspace]

En als je latency zo hoog is en je gooit je default route eruit, dan kun je je gateway met een lage latency pingen?

Die hoge latency, heb je die dan ook naar je gateway (voordat je je default route eruit gooit)?

Op het moment dat je latency weer zo hoog is, wat is de load van je bak dan ('uptime' commando, laatste 3 getalletjes)?

Komt die hoge latency geleidelijk of ineens *plop* van 50 naar 5000 ms (ongeveer)?

[eppie]

Nou het zit zo, op moment nergens last van dus kan dat tcpdump nog niet doen.

Mijn ping gaat omhoog dus ik ping mijn default route (gateway), en die gaat dus dik hoog 5000+ .

Nou gooi ik me default route er uit (gateway), en ping die dan vervolgens dan heb ik METEEN weer een lage ping. En de load is gewoon 0.01 ofzo.

[Buffy]

Op dinsdag 21 mei 2002 20:06 schreef eppie het volgende:
Nou het zit zo, op moment nergens last van dus kan dat tcpdump nog niet doen.

Mijn ping gaat omhoog dus ik ping mijn default route (gateway), en die gaat dus dik hoog 5000+ .

Nou gooi ik me default route er uit (gateway), en ping die dan vervolgens dan heb ik METEEN weer een lage ping. En de load is gewoon 0.01 ofzo.

Misschien een beetje ver gezocht maar ik zag dat je ftp en http services hebt draaien.

Maar misschien ben je wel gehackt en hebben ze een rootkit bij je geinstalleerd.

Die rootkits zijn lastig op te sporen een kunnen zich zelfs in de kernel nestellen (als module) en allerlei syssteem calls vervangen zodat commando's als ls, ps, tcpdump, etc tegen je gaan liegen.

[eppie]

Op dinsdag 21 mei 2002 22:22 schreef Dawns_sister het volgende:

[..]

Misschien een beetje ver gezocht maar ik zag dat je ftp en http services hebt draaien.

Maar misschien ben je wel gehackt en hebben ze een rootkit bij je geinstalleerd.

Die rootkits zijn lastig op te sporen een kunnen zich zelfs in de kernel nestellen (als module) en allerlei syssteem calls vervangen zodat commando's als ls, ps, tcpdump, etc tegen je gaan liegen.

Ja klopt dat had ik hier voor op me redhat 6.1 bak daarom staat er nu debian op. Maar ik gebruik de nieuwste proftpd en apache en sshd. En anonymous ftp staat uit dus lijkt me sterk dat ze daar binnen zijn gekomen. Maar het zou goed kunnen
Iemand ook een idee hoe je een rootkit kan ondekken?

Ik zoek het ff uit iig bedankt!

[Buffy]

Op dinsdag 21 mei 2002 22:51 schreef eppie het volgende:

[..]

Iemand ook een idee hoe je een rootkit kan ondekken?

Als de rootkit in de kernel zit en zijn eigen bestanden verbergt dan kan je hem misschien vinden door de output te vergelijken van "ls -lAR /" in de "normale" situatie en als je met schone rescue disk opstart (dan wel eerste cd /mnt; ls -lAR ./)

Alles wat dan anders/extra is dan verdacht.


-edit-
Op dingen als logs en /proc na dan

-edit2-
-l optie aan ls toegevoegd.

[eppie]

Op dinsdag 21 mei 2002 22:59 schreef Dawns_sister het volgende:

[..]

Als de rootkit in de kernel zit en zijn eigen bestanden verbergt dan kan je hem misschien vinden door de output te vergelijken van "ls -AR /" in de "normale" situatie en als je met schone rescue disk opstart (dan wel eerste cd /mnt; ls -AR ./)

Alles wat dan anders/extra is dan verdacht.


-edit-
Op dingen als logs en /proc na dan

Dank je dat is een goed idee!

Alleen hoe maak ik zo'n rescue disk? gewoon kernel op diskette gooien?

[Buffy]

Op dinsdag 21 mei 2002 23:17 schreef eppie het volgende:

[..]

Dank je dat is een goed idee!

Alleen hoe maak ik zo'n rescue disk? gewoon kernel op diskette gooien?

Nee helaas, zelf een rescue disk maken is een hele klus!

Het is beter de rescue disks op de installatie cdrom van Debian te gebruiken.
Dan weet je zeker dat je een "schone" kernel opstart.

Dus booten van de installatie cdrom en Alt-F2 (of zoiets) om in de console te komen.

[Leon]

probeer je mtu eens aan te passen naar iets van 1450. Tenminste als je ADSL hebt. Heb ergens gelezen dat een mtu van 1500 problemen kan geven met ADSL...

Je kunt het in ieder geval proberen

[deadinspace]

Op dinsdag 21 mei 2002 20:06 schreef eppie het volgende:
Mijn ping gaat omhoog dus ik ping mijn default route (gateway), en die gaat dus dik hoog 5000+ .

Nou gooi ik me default route er uit (gateway), en ping die dan vervolgens dan heb ik METEEN weer een lage ping.

Ok, dan ligt het probleem vrij duidelijk bij jouw bak.
En een hoge upstream zou dit fenomeen in ieder geval verklaren; kijk de volgende keer dat je het probleem hebt zeker eens met iptraf: opstarten, en dan 'detailed interface statistics' en dan de netwerkkaart waar je modem aan hangt, dan kun je je upstream en downstream in kbit/s zien. Ook uit de optie 'ip traffic monitor' kun je misschien wat nuttigs halen.

Op dinsdag 21 mei 2002 22:51 schreef eppie het volgende:
Ja klopt dat had ik hier voor op me redhat 6.1 bak daarom staat er nu debian op. Maar ik gebruik de nieuwste proftpd en apache en sshd.

Draai je Testing of Unstable, of draai je Stable?
In het laatste geval is het sterk aan te raden om security.debian.org (security updates voor Stable) in je sources.list op te nemen.
In alledrie de gevallen moet je ook regelmatig upgraden (Met apt-get update; apt-get upgrade), zodat je ook daadwerkelijk nieuwe versies van je software binnenhaalt.

Iemand ook een idee hoe je een rootkit kan ondekken?

Je kunt in ieder geval http://www.chkrootkit.org proberen.

[eppie]

Woody draai ik, maar ik ga dat ff allemaal proberen, bedankt!

[eppie]

Nou ik heb ff tcpdump -i eth1 en 0 gedaan.

code:

webserver:~# tcpdump -i eth1
tcpdump: listening on eth1
18:37:15.272800
874 packets received by filter
703 packets dropped by kernel
webserver:~# tcpdump -i eth0
tcpdump: listening on eth0
18:37:46.713558
19 packets received by filter
0 packets dropped by kernel
webserver:~#

Ik zie dat de kernel veel packets laat vallen maar waarom weet ik niet mischien een van jullie?

En me ping:

code:

webserver:~# ping 213.46.80.1
PING 213.46.80.1 (213.46.80.1): 56 data bytes
64 bytes from 213.46.80.1: icmp_seq=0 ttl=255 time=11786.5 ms
64 bytes from 213.46.80.1: icmp_seq=1 ttl=255 time=11539.3 ms
64 bytes from 213.46.80.1: icmp_seq=2 ttl=255 time=11191.0 ms
64 bytes from 213.46.80.1: icmp_seq=3 ttl=255 time=11626.1 ms
64 bytes from 213.46.80.1: icmp_seq=4 ttl=255 time=11269.6 ms
64 bytes from 213.46.80.1: icmp_seq=5 ttl=255 time=11172.6 ms
64 bytes from 213.46.80.1: icmp_seq=6 ttl=255 time=11531.0 ms
64 bytes from 213.46.80.1: icmp_seq=7 ttl=255 time=11543.9 ms
64 bytes from 213.46.80.1: icmp_seq=8 ttl=255 time=10855.3 ms
64 bytes from 213.46.80.1: icmp_seq=9 ttl=255 time=11270.0 ms
64 bytes from 213.46.80.1: icmp_seq=10 ttl=255 time=11161.7 ms
64 bytes from 213.46.80.1: icmp_seq=11 ttl=255 time=11201.9 ms
64 bytes from 213.46.80.1: icmp_seq=12 ttl=255 time=11329.1 ms

--- 213.46.80.1 ping statistics ---
24 packets transmitted, 13 packets received, 45% packet loss
round-trip min/avg/max = 10855.3/11344.4/11786.5 ms

Ben nu een poging aan het doen om iptraf te downloaden ff kijken wat die aangeeft.

En als ik de MTU verander dan zakt de ping even weer naar normaal maar binnen 5 sec zit hij weer aan de 3000

[Buffy]

Op woensdag 22 mei 2002 18:38 schreef eppie het volgende:
Ik zie dat de kernel veel packets laat vallen maar waarom weet ik niet mischien een van jullie?

Heb je een firewall draaien in de kernel?

En me ping:

code:

webserver:~# ping 213.46.80.1
--- 213.46.80.1 ping statistics ---
24 packets transmitted, 13 packets received, 45% packet loss
round-trip min/avg/max = 10855.3/11344.4/11786.5 ms

[/code]

Oeps!

Vanaf deze kant ziet het er overigens normaal uit:

code:

PING 213.46.80.144 (213.46.80.144): 56 data bytes
64 bytes from 213.46.80.144: icmp_seq=0 ttl=243 time=189.1 ms
64 bytes from 213.46.80.144: icmp_seq=1 ttl=243 time=165.3 ms
64 bytes from 213.46.80.144: icmp_seq=2 ttl=243 time=189.9 ms
64 bytes from 213.46.80.144: icmp_seq=3 ttl=243 time=167.2 ms
64 bytes from 213.46.80.144: icmp_seq=4 ttl=243 time=161.9 ms

--- 213.46.80.144 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 161.9/174.6/189.9 ms

[eppie]

Ja het was nou weer normaal, wou net iptraf doen maar toen was de ping alweer normaler. 140 is nou ook niet echt normaal

Draai wel iptables ja, maar het gekke is namelijk dat het zomaar opeens begonnen is en zo onvoorspelbaar is wanner het begint.

[wiho]

Op woensdag 22 mei 2002 19:26 schreef eppie het volgende:
Draai wel iptables ja

Post eens de output van "iptables -L -v -n". Dan zien we meteen waarom sommige packets eruit gefilterd worden.

[deadinspace]

Op woensdag 22 mei 2002 19:13 schreef Dawns_sister het volgende:
Oeps!

Merk op dat die packetloss 'fake' is. Omdat het zo lang duurt voordat die pings terugkomen zijn er een stuk of 11 gewoon nog niet teruggekomen op het moment dat hij de ping afbreekt. Deze worden door ping dan als 'lost' geteld.

Maar 11 seconden latency is natuurlijk onacceptable.

[eppie]

code:

webserver:/home/eppie/iptraf-2.7.0# iptables -L -v -n
Chain INPUT (policy ACCEPT 989K packets, 464M bytes)
 pkts bytes target     prot opt in     out     source          destination


Chain FORWARD (policy ACCEPT 325K packets, 19M bytes)
 pkts bytes target     prot opt in     out     source          destination

 468K  592M ACCEPT     all  --  eth1   *     0.0.0.0/0      0.0.0.0/0


Chain OUTPUT (policy ACCEPT 1106K packets, 1195M bytes)
 pkts bytes target     prot opt in     out     source          destination

Nou de output van iptables

Mijn ping is nou +- 3000 en heb ff iptraf gedraait, de log kan je hier vandaan halen: Hier dus

edit:
Ben er nog achter gekomen wanneer ik de mtu op 100 zet, en dan meteen ga pingen, dan is de ping laag en gaat in kleine stapjes (+-50 ms) weer omhoog. Hoe hoger me mtu hoe hoger die stapjes.

[wiho]

Er vallen me twee dingen op:

1. Het volume van je uitgaande (upstream) verkeer (1195M) is ongeveer 2.5 keer zo groot als het volume van je binnenkomede (downstream) verkeer (464M). Da's typischer voor een echte server dan voor een stel thuis-PC's. Nou staat er niet bij over welk tijdsinterval deze waarde's gemeten zijn, maar het zou kunnen dat je servers je volledige upstream bandbreedte opeten. Zelfs als je de server-processen uitzet, kosten al die verbindingen nog bandbreedte omdat jouw PC'tje (icmp) berichtjes verstuurt om te vertellen dat je servers niet beschikbaar zijn.

2. In je iptraf rapport zie ik een flinke hoeveelheid SYN packets, oftewel verbindingen die worden opgezet. Ook dit zou erop kunnen wijzen dat je bandbreedte simpelweg verbuikt wordt door grote hoeveelheden (pogingen tot) connecties met je (web)server.

Je zou 't eens kunnen testen door met onderstaande iptables regel 't uitgaande webverkeer van je webserver te blokkeren, en alleen icmp echo-request pakketjes toe te staan (zodat je nog wel kan pingen).

code:

iptables -A OUTPUT -p tcp --sport 80 -j DROP
iptables -A OUTPUT -p icmp --icmp-type ! echo-request -j DROP

Als je ping nu niet meer omhoog schiet, weet je dus dat de verbindingen naar je webserver de schuldige zijn.

[eppie]

Thx, dat ga ik ff proberen, nou kan het weer niet want me ping is weer normaal .

Maar als het aan de webserver (of andere services) ligt, hoe kan ik dat dan oplossen?

Op die webserver draaien stel forums (3) die amper gebruikt worden, 10 bijzoekers per maand ofzo . En die ftp is niet anoniem.

edit:
Die oplossing van het blokken werkt perfect, bedankt!! Maar ik moet toch wel een webservertje kunnen draaien zonder dat er zo veel connecties naar toe worden gemaakt?? (waar komen ze trouwens vandaan en waarvoor )

[wiho]

Oeps. Ik ik heb scheef zitten kijken naar je iptraf report. Er staan maar 2 SYN-packets naar je webserver in. Zo veel wordt die dus toch niet aangesproken...

Wat ik wel vreemd vind is dat er vanaf 131.174.93.254:80 (de webserver www.citogroep.nl) SYN-packets worden verstuurd naar jouw PC-tje. Een webserver zet doorgaans zelf geen nieuwe verbindingen op, dus waarom die SYN-packets? Vreemd.

[wiho]

Op woensdag 22 mei 2002 22:58 schreef eppie het volgende:
Die oplossing van het blokken werkt perfect, bedankt!! Maar ik moet toch wel een webservertje kunnen draaien zonder dat er zo veel connecties naar toe worden gemaakt?? (waar komen ze trouwens vandaan en waarvoor )

Probeer nou eens uit te vogelen of 't komt doordat je je webserver de mond snoert (1ste iptables regel) of doordat je uitgaande icmp-packets tegenhoudt (2de regel). (Dus door maar een van die twee regels toe te passen en dan te kijken wat er met je latency gebeurt..)

[deadinspace]

Op woensdag 22 mei 2002 22:51 schreef wiho het volgende:

code:

iptables -A OUTPUT -p tcp --sport 80 -j DROP

Op woensdag 22 mei 2002 22:12 schreef eppie het volgende:
Mijn ping is nou +- 3000 en heb ff iptraf gedraait, de log kan je hier vandaan halen: Hier dus

Ik krijg een timeout op je link

[eppie]

Ja klopt het httpd verkeer werd tegen gehouden , maar was zo dom om er niet aan te denken dat je die log dan niet kan zien

code:

webserver:~# cat /var/log/iptraf/ip_traffic-1.log
Wed May 22 18:59:49 2002; ******** IP traffic monitor started ********
Wed May 22 18:59:49 2002; UDP; eth1; 232 bytes; from 213.46.40.144:138 to 213.46.40.255:138
Wed May 22 18:59:49 2002; UDP; eth1; 78 bytes; from 213.46.40.144:137 to 213.46.40.255:137
Wed May 22 18:59:49 2002; UDP; eth1; 78 bytes; from 213.46.40.144:137 to 213.46.40.255:137
Wed May 22 18:59:49 2002; UDP; eth1; 78 bytes; from 213.46.40.144:137 to 213.46.40.255:137
Wed May 22 18:59:49 2002; UDP; eth1; 204 bytes; from 213.46.41.220:138 to 213.46.41.255:138
Wed May 22 18:59:57 2002; UDP; eth1; 216 bytes; from 213.46.41.220:138 to 213.46.41.255:138
Wed May 22 19:00:00 2002; UDP; eth1; 216 bytes; from 213.46.41.220:138 to 213.46.41.255:138
Wed May 22 19:00:01 2002; UDP; eth1; 78 bytes; from 213.46.84.37:137 to 213.46.84.255:137
Wed May 22 19:00:01 2002; UDP; eth1; 216 bytes; from 213.46.41.220:138 to 213.46.41.255:138
Wed May 22 19:00:01 2002; UDP; eth1; 78 bytes; from 213.46.84.37:137 to 213.46.84.255:137
Wed May 22 19:00:02 2002; UDP; eth1; 216 bytes; from 213.46.41.220:138 to 213.46.41.255:138
Wed May 22 19:00:02 2002; UDP; eth1; 78 bytes; from 213.46.84.37:137 to 213.46.84.255:137
Wed May 22 19:00:03 2002; UDP; eth1; 216 bytes; from 213.46.41.220:138 to 213.46.41.255:138
Wed May 22 19:00:04 2002; UDP; eth1; 78 bytes; from 213.46.93.8:137 to 213.46.93.255:137
Wed May 22 19:00:04 2002; UDP; eth1; 229 bytes; from 213.46.41.220:138 to 213.46.41.255:138
Wed May 22 19:00:04 2002; UDP; eth1; 78 bytes; from 213.46.93.8:137 to 213.46.93.255:137
Wed May 22 19:00:05 2002; UDP; eth1; 78 bytes; from 213.46.93.8:137 to 213.46.93.255:137
Wed May 22 19:00:08 2002; ******** IP traffic monitor stopped ********

Wed May 22 22:20:53 2002; ******** IP traffic monitor started ********
Wed May 22 22:20:53 2002; TCP; eth1; 46 bytes; from 212.49.157.194:41781 to 213.46.80.144:80; first packet
Wed May 22 22:20:53 2002; TCP; eth1; 1400 bytes; from 213.46.80.144:80 to 212.49.157.194:41781; first packet
Wed May 22 22:20:53 2002; UDP; eth1; 178 bytes; from 212.142.28.66:53 to 213.46.80.144:3020
Wed May 22 22:20:53 2002; ICMP; eth1; 56 bytes; from 213.46.80.144 to 212.142.28.66; dest unrch (port)
Wed May 22 22:20:53 2002; TCP; eth1; 1216 bytes; from 212.125.101.170:3010 to 213.46.80.144:2768; first packet
Wed May 22 22:20:53 2002; TCP; eth1; 40 bytes; from 213.46.80.144:2768 to 212.125.101.170:3010; first packet
Wed May 22 22:20:53 2002; TCP; eth1; 46 bytes; from 212.49.157.194:41804 to 213.46.80.144:80; first packet
Wed May 22 22:20:53 2002; TCP; eth1; 1400 bytes; from 213.46.80.144:80 to 212.49.157.194:41804; first packet
Wed May 22 22:20:54 2002; TCP; eth1; 185 bytes; from 64.4.12.194:1863 to 213.46.80.144:2769; first packet
Wed May 22 22:20:54 2002; TCP; eth1; 48 bytes; from 213.46.80.144:3021 to 216.239.39.100:80; first packet (SYN)
Wed May 22 22:20:54 2002; TCP; eth1; 48 bytes; from 216.239.39.100:80 to 213.46.80.144:3021; first packet (SYN)
Wed May 22 22:20:54 2002; TCP; eth1; 40 bytes; from 213.46.80.144:2769 to 64.4.12.194:1863; first packet
Wed May 22 22:20:55 2002; UDP; eth1; 78 bytes; from 213.46.84.37:137 to 213.46.84.255:137
Wed May 22 22:20:56 2002; UDP; eth1; 78 bytes; from 213.46.84.37:137 to 213.46.84.255:137
Wed May 22 22:20:57 2002; UDP; eth1; 78 bytes; from 213.46.84.37:137 to 213.46.84.255:137
Wed May 22 22:20:58 2002; TCP; eth1; 48 bytes; from 213.46.80.144:3022 to 216.239.39.100:80; first packet (SYN)
Wed May 22 22:20:58 2002; TCP; eth1; 40 bytes; from 213.46.80.144:3018 to 216.239.51.100:80; first packet
Wed May 22 22:21:00 2002; TCP; eth1; 46 bytes; from 216.239.51.100:80 to 213.46.80.144:3018; FIN sent; 1 packets, 46 bytes, avg flow rate 0.00 kbits/s
Wed May 22 22:21:00 2002; TCP; eth1; 46 bytes; from 216.239.51.100:80 to 213.46.80.144:3018; first packet
Wed May 22 22:21:00 2002; TCP; eth1; 40 bytes; from 213.46.80.144:3018 to 216.239.51.100:80; FIN acknowleged
Wed May 22 22:21:01 2002; TCP; eth1; 48 bytes; from 216.239.39.100:80 to 213.46.80.144:3022; first packet (SYN)
Wed May 22 22:21:02 2002; UDP; eth1; 235 bytes; from 213.46.84.37:138 to 213.46.84.255:138
Wed May 22 22:21:07 2002; TCP; eth1; 40 bytes; from 213.46.80.144:3018 to 216.239.51.100:80; Connection reset; 3 packets, 120 bytes, avg flow rate 0.00 kbits/s; opposite direction 1 packets, 46 bytes; avg flow rate 0.00 kbits/s
Wed May 22 22:21:14 2002; UDP; eth1; 78 bytes; from 62.163.174.162:137 to 62.163.174.255:137
Wed May 22 22:21:14 2002; UDP; eth1; 78 bytes; from 62.163.174.162:137 to 62.163.174.255:137
Wed May 22 22:21:15 2002; UDP; eth1; 78 bytes; from 62.163.174.162:137 to 62.163.174.255:137
Wed May 22 22:21:17 2002; ******** IP traffic monitor stopped ********

[Buffy]

Op woensdag 22 mei 2002 22:58 schreef eppie het volgende:

edit:
Die oplossing van het blokken werkt perfect, bedankt!! Maar ik moet toch wel een webservertje kunnen draaien zonder dat er zo veel connecties naar toe worden gemaakt?? (waar komen ze trouwens vandaan en waarvoor )

Probeer een zoiets als:

code:

iptables -A input  -p tcp --dport www -j ACCEPT \
       -m state --state NEW  -m limit --limit 1/s --limit-burst 5"
iptables -A input  -p tcp --dport www -j ACCEPT \
       -m state --state ESTABLISHED
iptables -A input  -p tcp --dport www -j LOG \
       -m state --state NEW
iptables -A input  -p tcp --dport www -j DROP 


iptables -A output -p tcp --sport www -j ACCEPT \
       -m state --state ESTABLISHED

Hiervoor heb je wel de connection tracking en limit modules nodig in je kernel.

De input met limit optie staat 1 nieuwe www verbinding per seconden toe met een burst van 5 (na de burst mag dan 5 seconden geen nieuwe www verbinding meer worden gemaakt.

Voeg eventueel de optie -d 213.46.80.144 en/of -i eth1 aan de input regels toe.

Zelfde kan je doen voor ftp maar dat is ietsje ingewikkelder omdat je rekening moet houden met active en passive ftp.

Lees ook de iptables en NAT howto's als je server echt wilt beveiligen voor aanvallen.

PS: output regel is eigenlijk overbodig omdat je de default policy op ACCEPT hebt staan.


Ik heb overigens je ip en je gateway een tijdje gepingd vanavond (1 ping per minuut).
Zoals je ziet ligt het probleem aan jouw kant van de gateway .



line 1 is 213.46.80.1
line 2 is 213.46.80.144

[eppie]

Mooie grafiek

Nogmaals allemaal bedankt voor jullie reply's

Ik ga het bovenstaande even proberen. Moet eerst even nieuwe kernel compilen