Zyxel T-56 ping spikes

  • 4 September 2023
  • 43 reacties
  • 1364 Bekeken
C
Reputatie 1

Hi all, pardon the engels, I am seeing the weirdest latency spikes to my new Zyxel T-56 modem, from devices directly attached to it. 

64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=0.555 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.533 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=516 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=0.578 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=210 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=0.568 ms

 

If I run a tcpping to google.com , so that is now LAN to WAN, and not just LAN to router. 

 

255  ams16s37-in-f14.1e100.net (172.217.23.206)  6.677 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  7.382 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  554.650 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  7.165 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  6.706 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  6.652 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  6.536 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  7.220 ms

 

I see the same thing?

This is weird how it gets these spikes, on LAN being directly attached I would expect to see max maybe 2ms. Not 516ms. Is this router getting overloaded, or is the hardware just kinda cheap? 

Tommie van Odido 8 maanden geleden

Hey @ChaosMonkey, welcome to our Community!

Good that you are sounding the alarm for this. I immediately went to check for you and I see that you have your own router/switch connected. Could you run these two commands if you have unplugged everything and are only connected directly wired to your laptop/desktop? Ping -n 50 1.1.1.1 & Ping -n 50 8.8.8.8 in CMD. Do this with only the Zyxel modem connected to your network with a wired connection. Suppose you have a VPN, disable it too.

Bekijk origineel

43 reacties

P
Reputatie 2

@ChaosMonkey 

 

Could you provide some screenshots (can use the ones here with the tests u did strictly with the zyxel). Maybe if we get more people to post it becomes a priority issue and we get a fix soon.

P
Reputatie 2

Nothing from my pc to the router, except a 5ms spike that I only saw once, rest of them were all sub 1ms. The issues seem to be strictly when connecting to the actual internet, not LAN. And no idea about the first part to be honest, I just picked up that it flags my computer sending ping of death attacks to multiple gameservers, doesnt seem to be anything else though like google servers or twitch etc...

C
Reputatie 1

Ive picked up some weird routerlogs aswell toward gameservers, my computer is apparently sending ping of deaths to different servers, if I had to guess there might be something with the firewall configurations on these things, personally scared to disable it and test if i still have the spikes with it off haha. Mostly have these suspicions because of how my ping would load instantly with dos protection off on some games where it took ages to load before, i can only assume it has to do something with security.

Is the ping of death originating from your PC from running long pings to check your latency?
It’s kind of funny how the router logs pings of death as a security thing, because this was patched in the linux kernel and doesn’t cause issues, so it shouldn’t even feature as some security warning as it can’t harm the device.

I tried to disable the firewall, it didn’t really make an impact at all. I saw port scans and connection attempts to ports that were not open, even with UPnP disabled. While this should be a simple iptables firewall, the CPU seems to get overloaded and then the whole device slows down.

 

Have a look if your latency also spikes to 400ms if you just run a long ping from your PC to the router.

 

I wonder if it’s not due to these bugs https://itwire.com/business-it-news/security/linux-devices-vulnerable-to-ping-of-death-attack.html.

 

Would also be awesome if this could be referenced https://javapipe.com/blog/iptables-ddos-protection/.

My setup will allow me to actually help and even Man-In-The-Middle packet capture to inspect what is causing the slowness, but I would also need access to the admin console of the router to get a linux shell to make changes to the core tcp stack and firewall to see how we can address this. If Odido’s policies can allow for this, I am willing to help fix this.

P
Reputatie 2

Ive picked up some weird routerlogs aswell toward gameservers, my computer is apparently sending ping of deaths to different servers, if I had to guess there might be something with the firewall configurations on these things, personally scared to disable it and test if i still have the spikes with it off haha. Mostly have these suspicions because of how my ping would load instantly with dos protection off on some games where it took ages to load before, i can only assume it has to do something with security.

C
Reputatie 1

Do you not have any latency spikes at all anymore after replacing the t-56? That sounds great. I think truly a firmware patch is needed and a look into what the cause might be to these spikes @Sven-Odido @Tommie van Odido 

Except for some oddness within the AMS-IX data center doing some odd route flip flop at a much higher rate than it should, my latency has been really stable. I used to feel that 200-400ms (600ms at times) latency spikes a lot in games as well. Since disconnecting the T56 I have had none of that. It’s been a month that it has been smooth. Except for that route change that will cause a spike, I don’t see the other constant or high 200-600ms spikes, within a 100 packets sent with a long running ping.

 

Curious enough, I can disconnect my Mikrotik and connect the T56, and within half an hour I will see the latency spikes. Disconnect the T56 and reconnect my Mikrotik, and boom immediate smooth ping. Same public IP address, or I can force a new one (in both swaps). So it’s not even that it’s an issue with my IP address. It seems to purely be the router. My guess is something is looking for these devices and then trying to do something towards them.

P
Reputatie 2

Do you not have any latency spikes at all anymore after replacing the t-56? That sounds great. I think truly a firmware patch is needed and a look into what the cause might be to these spikes @Sven-Odido @Tommie van Odido 

P
Reputatie 2

@ChaosMonkey Did you ever end up resolving this issue? Me and some others are experienceing ur same issue.

@pockeyhockyes, I managed to get a very stable ping by ditching the Odido provided router.

Do you also have the new T56, did you try disabling/enable the DoS protection? Does your latency also bounce around and on occasion the connection drops?  

 

What appeared to be the cause of my latency spikes, was patched out from causing issues in the linux kernel long ago. Also to note the logs weren’t so great when it came to seeing what the cause was, gaining full console access, via UART/SSH, could probably give a better idea of what is going on.

 

@Sven-Odido, seems this could be a common problem then?

Personally the connection doesnt drop at all for me. Its very stable and the uptime is great but then every couple minutes i will get 400-600ms latency spikes, yes i tried to disable DoS protection it seemed to work for a bit but ended up falling back to what was happening before. What’s interessting though is that if I disable DoS protection my ping in a certain game would load instantly where as it would take ages before with having DoS protection on. I am not on linux, windows machine here.

C
Reputatie 1

@ChaosMonkey Did you ever end up resolving this issue? Me and some others are experienceing ur same issue.

@pockeyhock yes, I managed to get a very stable ping by ditching the Odido provided router.

Do you also have the new T56, did you try disabling/enable the DoS protection? Does your latency also bounce around and on occasion the connection drops?  

 

What appeared to be the cause of my latency spikes, was patched out from causing issues in the linux kernel long ago. Also to note the logs weren’t so great when it came to seeing what the cause was, gaining full console access, via UART/SSH, could probably give a better idea of what is going on.

 

@Sven-Odido , seems this could be a common problem then?

P
Reputatie 2

@ChaosMonkey Did you ever end up resolving this issue? Me and some others are experienceing ur same issue.

S
Rank
Reputatie 7
Badge +4

I dont have any insights in that part of the network. Im still looking into the spike happening when the port scans are happening. 

 

 

Helpt hier soms Tommie van Odido
C
Reputatie 1

@Sven-Odido Well I think I found the cause of my latency variation. Interesting that the route doing hit this exchange or IP when going to google. It seems your interconnect (well I am guessing it’s the interconnect) is overloaded, perhaps old or buggy firmware? 

Have a look at these ping results, I took it on my router as well. So then there is nothing in the path that can cause any issues. 

 

 

To my knowledge, with fibre, this should never be the case. It’s normal to see a hop in between have packet loss but if the latency goes up from that hop and travels onwards, then that hop is the issue. 

An avg of 18ms, that puts me somewhere close to Mora in Mydrid. 
Already I am sitting at 6ms for 30km, when the avg for fibre is 1ms per 100km. Which is already a bit high. 

S
Rank
Reputatie 7
Badge +4

Not a problem, would it then be okay if I swap back to the mikrotik and only switch to the T56 when you have some time? 
​​​

Yess Of course, I will let you know when the T56 need to be connected again. 

 

Helpt hier soms Tommie van Odido
C
Reputatie 1

@Sven-Odido you can have a look now, maybe we need a faster way to communicate, because these attacks come the moment this router turns on

I havent had time yet to dive into this. When a lot of port scans etc are happening at the same time its normal to see a slight increase in latency for a few pings. But not the amount you are seeing. I will have to look more into that when I have more time on my hands, Sorry for the inconvenience.

Also keep in mind that when a lot of ICMP pings are sent by one host, the DOS protection on the T56 will kick in as well. 

Not a problem, would it then be okay if I swap back to the mikrotik and only switch to the T56 when you have some time? 

 

I am curious ipv6 needs ICMP in order to work, is the T56 DoS protection setup in a way that it would allow that without raising any flags? It seems to only trigger on the ICMP request count number, so if you ping and stop and ping and stop it seems to not flag it. 

S
Rank
Reputatie 7
Badge +4

@Sven-Odido you can have a look now, maybe we need a faster way to communicate, because these attacks come the moment this router turns on

I havent had time yet to dive into this. When a lot of port scans etc are happening at the same time its normal to see a slight increase in latency for a few pings. But not the amount you are seeing. I will have to look more into that when I have more time on my hands, Sorry for the inconvenience.

Also keep in mind that when a lot of ICMP pings are sent by one host, the DOS protection on the T56 will kick in as well. 

Helpt hier soms Tommie van Odido
C
Reputatie 1

Hi @Tommie van Odido , 

 

Odido connects with smardc to the AMS-IX right? If I do a traceroute to 9.9.9.9 I see the same IP address twice. And it’s always when it goes from your 10.10.10.x range to the 80.249.x.x range where the latency spikes happen. (When the router isn’t being attacked and failing) .
When I do a traceroute to 8.8.8.8 (google) it doesn’t seem to run through the AMS-IX , and the ping is a lot more stable. Maybe there is an issue with your connection and routing at AMS-IX? 

 

C
Reputatie 1

@Sven-Odido you can have a look now, maybe we need a faster way to communicate, because these attacks come the moment this router turns on

C
Reputatie 1

Hey @ChaosMonkey, I've messaged @Sven-Odido to take a look at your connection but he can't see anything at the moment because the MikroTik is connected. Could you connect the Zyxel and take out the MikroTik in between? Then we can check the connection!

Hi @Tommie van Odido , well yes I unplugged the Zyxel because I want a stable connection. 
I have reconnected the Zyxel now. It was barely 30 seconds since it got a new IP address, and I moved from .118 to a .120 subnet and immediately I see this 


Sep 20 14:11:48 kern.alert kernel: [  156.597862] UDP PORT SCAN ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=216.131.89.252 DST=5.132.120.x LEN=1500 TOS=0x00 PREC=0x00 TTL=5 ID=0 DF PROTO=UDP SPT=52415 DPT=37207 LEN=1480 
Sep 20 14:12:01 kern.alert kernel: [  169.949677] UDP PORT SCAN ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=89.184.168.213 DST=5.132.120.x LEN=1500 TOS=0x00 PREC=0x00 TTL=9 ID=0 DF PROTO=UDP SPT=39937 DPT=37207 LEN=1480 
Sep 20 14:13:14 kern.alert kernel: [  243.173178] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=6856 DF PROTO=TCP SPT=42381 DPT=1080 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:14 kern.alert kernel: [  243.173180] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=47025 DF PROTO=TCP SPT=48579 DPT=60088 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:14 kern.alert kernel: [  243.173182] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=39797 DF PROTO=TCP SPT=42757 DPT=8000 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:14 kern.alert kernel: [  243.173207] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=24989 DF PROTO=TCP SPT=35647 DPT=45554 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:14 kern.alert kernel: [  243.173209] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=8550 DF PROTO=TCP SPT=57091 DPT=1080 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:15 kern.alert kernel: [  244.198202] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=39054 DF PROTO=TCP SPT=36549 DPT=5521 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:17 kern.alert kernel: [  246.212050] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=64885 DF PROTO=TCP SPT=55707 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:17 kern.alert kernel: [  246.212052] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=28483 DF PROTO=TCP SPT=36763 DPT=8080 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:22 kern.alert kernel: [  250.431698] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=56367 DF PROTO=TCP SPT=47297 DPT=8123 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:22 kern.alert kernel: [  250.431700] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=611 DF PROTO=TCP SPT=44243 DPT=34002 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:22 kern.alert kernel: [  250.431706] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=17186 DF PROTO=TCP SPT=44723 DPT=8118 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:22 kern.alert kernel: [  250.431728] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=30961 DF PROTO=TCP SPT=44313 DPT=8291 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:30 kern.alert kernel: [  258.614956] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=43047 DF PROTO=TCP SPT=44341 DPT=3128 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:30 kern.alert kernel: [  258.614957] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=39801 DF PROTO=TCP SPT=42757 DPT=8000 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:30 kern.alert kernel: [  258.614959] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=6860 DF PROTO=TCP SPT=42381 DPT=1080 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:30 kern.alert kernel: [  258.614985] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=61062 DF PROTO=TCP SPT=41211 DPT=33002 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:30 kern.alert kernel: [  258.614987] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=15474 DF PROTO=TCP SPT=59503 DPT=8123 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:46 kern.alert kernel: [  274.725769] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=29997 DF PROTO=TCP SPT=58295 DPT=8888 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:46 kern.alert kernel: [  274.725771] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=4 DF PROTO=TCP SPT=38833 DPT=9001 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:46 kern.alert kernel: [  274.725777] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=20097 DF PROTO=TCP SPT=38013 DPT=8118 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:46 kern.alert kernel: [  274.725799] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=52411 DF PROTO=TCP SPT=36189 DPT=8888 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:46 kern.alert kernel: [  274.725824] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=30377 DF PROTO=TCP SPT=52321 DPT=8123 WINDOW=64240 RES=0x00 SYN URGP=0 
 

Tommie van Odido
Rank
Reputatie 7
Badge +9

Hey @ChaosMonkey, I've messaged @Sven-Odido to take a look at your connection but he can't see anything at the moment because the MikroTik is connected. Could you connect the Zyxel and take out the MikroTik in between? Then we can check the connection!

Life is too short to drink bad wine!
C
Reputatie 1

@ChaosMonkey, could you run the tests with only the Zyxel? 

We do not have a lot of customers using Linux haha. Therefore we do not have a Linus manual. 

hi @ChaosMonkey : for Linux these test are not so dififcult  if you know how to use the command line.

Download the appropiate CLI client from https://www.speedtest.net/nl/apps/cli install it and run the test. I don’t know if they have a CLI client for non x86_64 hardware. When I run this client on my box I get something like:

[louis@lair ~]$ speedtest

   Speedtest by Ookla

      Server: ColoCenter bv - Zoetermeer (id: 3242)
         ISP: T-Mobile Thuis
Idle Latency:     4.72 ms   (jitter: 0.25ms, low: 4.46ms, high: 5.11ms)
    Download:   275.14 Mbps (data used: 311.8 MB)                                                   
                  4.93 ms   (jitter: 0.49ms, low: 3.92ms, high: 18.98ms)
      Upload:   389.91 Mbps (data used: 502.5 MB)                                                   
                  4.89 ms   (jitter: 7.02ms, low: 3.87ms, high: 222.81ms)
 Packet Loss:     0.6%
Re-running that test gives me better results (from another remote server)

I don’t feel however that this will give you much: your observation that there is a route flapping in your path indeed could be related. When the route (in the Odido network) flaps seems to be the point where packet loss occurs (the next hop after the first flapping router seems to show some packet loss when that happens. @Tommie van Odido: please ask the network guys to have a look at that. It may however be related to the second issue below when a DOS attack occurs?

The router going down when you are DOS’ed is another issue however.  The Zyxel should not be affected by it. You could try to disable the DOS protection under “beveiliging → firewall to see if that helps. It may be a case where the firewal is to pro-active and reporting on all threats (even on closed ports!) takes so much resources that the router hangs or reboots. @Tommie van Odido you may want to check with network people if this needs to be reported to Zyxel

The DOS attack may be triggered on the IP-address as soon as you get identified and you IP-address gets found out, so you cannot rule out that the attack is directed to you.

I may be wrong, but to me it all looks like being related to a DOS attack on you.

 

 

 

That is a good hunch, however I have now had multiple IP addresses, and when I connected with my mikrotik this wasn’t an issue. So between that and the logs showing a scan happening, I think this is automated, and going after certain devices on a block of IP addresses. Turning off the DoS protection made no difference. 

I have been told that this type of attack shouldn’t be an issue in any linux based devices as they patched the kernel for it, it should just drop the packets. 

I guess that the Zyxel (as most routers like your Mikrotik) is Linux based, hence my  hunch that turning DOS protection off might stop it from trying to analyse incoming traffic. Too bad that it did not work out. The fact that the Mikrotik is not affected (at least not as much, the route flapping is still there) as the Zyxel is indeed important. One more thing to try might be to turn UPNP off (hamburger menu → thuisnewerken → UPNP). This will probably break some games. UPNP might still allow something in your network out on some ports, including port 8000.  Check if  UPNP is enabled on the Mikrotik ip/upnp/print or the ip → upnp menu on Webfig or Winbox). To the best of my knowledge it is by default off

I still can not exlude the possibility that something you do invites this DOS attack (but the Zyxel should not be affected by it!!!), nor can I exclude the IP-scanning theory… 

I hope that @Tommie van Odido can find some help from the Odido network guys

I can test the UPnP on the Zyxel, I do actually have it on the mikrotik. I had a look at the games I play and naturally I can see it on the mikrotik. Nothing around port 8000, I did list the ports that do get used earlier. 
Also have a look what my mikrotik is picking up  connection-state:new src-mac 00:0e:00:00:00:04, proto TCP (SYN), 162.142.125.138:33690->5.132.1xx.xx:57223, len 44

I see it going for random ports , port 23, then 81, 89, 3393, 10258, these look like common open ports. 

L
Rank
Reputatie 6
Badge

@ChaosMonkey, could you run the tests with only the Zyxel? 

We do not have a lot of customers using Linux haha. Therefore we do not have a Linus manual. 

hi @ChaosMonkey : for Linux these test are not so dififcult  if you know how to use the command line.

Download the appropiate CLI client from https://www.speedtest.net/nl/apps/cli install it and run the test. I don’t know if they have a CLI client for non x86_64 hardware. When I run this client on my box I get something like:

[louis@lair ~]$ speedtest

   Speedtest by Ookla

      Server: ColoCenter bv - Zoetermeer (id: 3242)
         ISP: T-Mobile Thuis
Idle Latency:     4.72 ms   (jitter: 0.25ms, low: 4.46ms, high: 5.11ms)
    Download:   275.14 Mbps (data used: 311.8 MB)                                                   
                  4.93 ms   (jitter: 0.49ms, low: 3.92ms, high: 18.98ms)
      Upload:   389.91 Mbps (data used: 502.5 MB)                                                   
                  4.89 ms   (jitter: 7.02ms, low: 3.87ms, high: 222.81ms)
 Packet Loss:     0.6%
Re-running that test gives me better results (from another remote server)

I don’t feel however that this will give you much: your observation that there is a route flapping in your path indeed could be related. When the route (in the Odido network) flaps seems to be the point where packet loss occurs (the next hop after the first flapping router seems to show some packet loss when that happens. @Tommie van Odido: please ask the network guys to have a look at that. It may however be related to the second issue below when a DOS attack occurs?

The router going down when you are DOS’ed is another issue however.  The Zyxel should not be affected by it. You could try to disable the DOS protection under “beveiliging → firewall to see if that helps. It may be a case where the firewal is to pro-active and reporting on all threats (even on closed ports!) takes so much resources that the router hangs or reboots. @Tommie van Odido you may want to check with network people if this needs to be reported to Zyxel

The DOS attack may be triggered on the IP-address as soon as you get identified and you IP-address gets found out, so you cannot rule out that the attack is directed to you.

I may be wrong, but to me it all looks like being related to a DOS attack on you.

 

 

 

That is a good hunch, however I have now had multiple IP addresses, and when I connected with my mikrotik this wasn’t an issue. So between that and the logs showing a scan happening, I think this is automated, and going after certain devices on a block of IP addresses. Turning off the DoS protection made no difference. 

I have been told that this type of attack shouldn’t be an issue in any linux based devices as they patched the kernel for it, it should just drop the packets. 

I guess that the Zyxel (as most routers like your Mikrotik) is Linux based, hence my  hunch that turning DOS protection off might stop it from trying to analyse incoming traffic. Too bad that it did not work out. The fact that the Mikrotik is not affected (at least not as much, the route flapping is still there) as the Zyxel is indeed important. One more thing to try might be to turn UPNP off (hamburger menu → thuisnewerken → UPNP). This will probably break some games. UPNP might still allow something in your network out on some ports, including port 8000.  Check if  UPNP is enabled on the Mikrotik ip/upnp/print or the ip → upnp menu on Webfig or Winbox). To the best of my knowledge it is by default off

I still can not exlude the possibility that something you do invites this DOS attack (but the Zyxel should not be affected by it!!!), nor can I exclude the IP-scanning theory… 

I hope that @Tommie van Odido can find some help from the Odido network guys

Ik ben ook maar een klant die wel eens andere klanten probeert te helpen.
C
Reputatie 1

@ChaosMonkey, could you run the tests with only the Zyxel? 

We do not have a lot of customers using Linux haha. Therefore we do not have a Linus manual. 

hi @ChaosMonkey : for Linux these test are not so dififcult  if you know how to use the command line.

Download the appropiate CLI client from https://www.speedtest.net/nl/apps/cli install it and run the test. I don’t know if they have a CLI client for non x86_64 hardware. When I run this client on my box I get something like:

[louis@lair ~]$ speedtest

   Speedtest by Ookla

      Server: ColoCenter bv - Zoetermeer (id: 3242)
         ISP: T-Mobile Thuis
Idle Latency:     4.72 ms   (jitter: 0.25ms, low: 4.46ms, high: 5.11ms)
    Download:   275.14 Mbps (data used: 311.8 MB)                                                   
                  4.93 ms   (jitter: 0.49ms, low: 3.92ms, high: 18.98ms)
      Upload:   389.91 Mbps (data used: 502.5 MB)                                                   
                  4.89 ms   (jitter: 7.02ms, low: 3.87ms, high: 222.81ms)
 Packet Loss:     0.6%
Re-running that test gives me better results (from another remote server)

I don’t feel however that this will give you much: your observation that there is a route flapping in your path indeed could be related. When the route (in the Odido network) flaps seems to be the point where packet loss occurs (the next hop after the first flapping router seems to show some packet loss when that happens. @Tommie van Odido: please ask the network guys to have a look at that. It may however be related to the second issue below when a DOS attack occurs?

The router going down when you are DOS’ed is another issue however.  The Zyxel should not be affected by it. You could try to disable the DOS protection under “beveiliging → firewall to see if that helps. It may be a case where the firewal is to pro-active and reporting on all threats (even on closed ports!) takes so much resources that the router hangs or reboots. @Tommie van Odido you may want to check with network people if this needs to be reported to Zyxel

The DOS attack may be triggered on the IP-address as soon as you get identified and you IP-address gets found out, so you cannot rule out that the attack is directed to you.

I may be wrong, but to me it all looks like being related to a DOS attack on you.

 

 

 

That is a good hunch, however I have now had multiple IP addresses, and when I connected with my mikrotik this wasn’t an issue. So between that and the logs showing a scan happening, I think this is automated, and going after certain devices on a block of IP addresses. Turning off the DoS protection made no difference. 

I have been told that this type of attack shouldn’t be an issue in any linux based devices as they patched the kernel for it, it should just drop the packets. 

C
Reputatie 1

Hey @ChaosMonkey, hmm could you run a couple of speedtests for me? Then I will forward this to our tech guys.

The instructions for this can be found on our website. 

Please follow all the steps carefully, please share the screenshots in the topic instead of to our e-mail. We cannot process an application with missing steps.

Would this still be behind the Zyxel or behind my mikrotik as the edge router?

Curious why you have no guide for linux? That would be my go to, to make sure nothing is running the background.

Hi @Tommie van Odido , 

Here are the screenshots 
 

 

L
Rank
Reputatie 6
Badge

@ChaosMonkey, could you run the tests with only the Zyxel? 

We do not have a lot of customers using Linux haha. Therefore we do not have a Linus manual. 

hi @ChaosMonkey : for Linux these test are not so dififcult  if you know how to use the command line.

Download the appropiate CLI client from https://www.speedtest.net/nl/apps/cli install it and run the test. I don’t know if they have a CLI client for non x86_64 hardware. When I run this client on my box I get something like:

[louis@lair ~]$ speedtest

   Speedtest by Ookla

      Server: ColoCenter bv - Zoetermeer (id: 3242)
         ISP: T-Mobile Thuis
Idle Latency:     4.72 ms   (jitter: 0.25ms, low: 4.46ms, high: 5.11ms)
    Download:   275.14 Mbps (data used: 311.8 MB)                                                   
                  4.93 ms   (jitter: 0.49ms, low: 3.92ms, high: 18.98ms)
      Upload:   389.91 Mbps (data used: 502.5 MB)                                                   
                  4.89 ms   (jitter: 7.02ms, low: 3.87ms, high: 222.81ms)
 Packet Loss:     0.6%
Re-running that test gives me better results (from another remote server)

I don’t feel however that this will give you much: your observation that there is a route flapping in your path indeed could be related. When the route (in the Odido network) flaps seems to be the point where packet loss occurs (the next hop after the first flapping router seems to show some packet loss when that happens. @Tommie van Odido: please ask the network guys to have a look at that. It may however be related to the second issue below when a DOS attack occurs?

The router going down when you are DOS’ed is another issue however.  The Zyxel should not be affected by it. You could try to disable the DOS protection under “beveiliging → firewall to see if that helps. It may be a case where the firewal is to pro-active and reporting on all threats (even on closed ports!) takes so much resources that the router hangs or reboots. @Tommie van Odido you may want to check with network people if this needs to be reported to Zyxel

The DOS attack may be triggered on the IP-address as soon as you get identified and you IP-address gets found out, so you cannot rule out that the attack is directed to you.

I may be wrong, but to me it all looks like being related to a DOS attack on you.

 

 

 

Ik ben ook maar een klant die wel eens andere klanten probeert te helpen.
Tommie van Odido
Rank
Reputatie 7
Badge +9

@ChaosMonkey, could you run the tests with only the Zyxel? 

We do not have a lot of customers using Linux haha. Therefore we do not have a Linus manual. 

Life is too short to drink bad wine!
C
Reputatie 1

Hey @ChaosMonkey, hmm could you run a couple of speedtests for me? Then I will forward this to our tech guys.

The instructions for this can be found on our website. 

Please follow all the steps carefully, please share the screenshots in the topic instead of to our e-mail. We cannot process an application with missing steps.

Would this still be behind the Zyxel or behind my mikrotik as the edge router?

Curious why you have no guide for linux? That would be my go to, to make sure nothing is running the background.

Reageer


ForumvoorwaardenCookie instellingen