Asus RT-AC68U - System Log Information, Is someone accessing my network?

[Netbug]

Hi,

I keep getting information in my log and want to understand what it means as am bit worried incase someones accessing my router/home network.

I get them randomly but just checked and got the below:

Apr 21 10:13:23 kernel: ACCEPT IN=eth0 OUT= MAC=e0:**:**:**:**:**:28:8a:1c:ec:74:52:08:00 SRC=31.192.198.17 DST=8*.***.**.*** LEN=40 TOS=0x00 PREC=0x00 TTL=47 ID=2808 PROTO=ICMP TYPE=13 CODE=0
Apr 21 10:13:23 kernel: ACCEPT IN=eth0 OUT= MAC=e0:**:**:**:**:**:28:8a:1c:ec:74:52:08:00 SRC=31.192.198.17 DST=8*.***.**.*** LEN=40 TOS=0x00 PREC=0x00 TTL=44 ID=43432 PROTO=ICMP TYPE=13 CODE=0
Apr 21 11:19:13 kernel: ACCEPT IN=eth0 OUT= MAC=e0:**:**:**:**:**:28:8a:1c:ec:74:52:08:00 SRC=90.110.47.24 DST=8*.***.**.*** LEN=40 TOS=0x00 PREC=0x00 TTL=35 ID=60720 PROTO=ICMP TYPE=13 CODE=0
Apr 21 11:19:14 kernel: ACCEPT IN=eth0 OUT= MAC=e0:**:**:**:**:**:28:8a:1c:ec:74:52:08:00 SRC=90.110.47.24 DST=8*.***.**.*** LEN=40 TOS=0x00 PREC=0x00 TTL=25 ID=15226 PROTO=ICMP TYPE=13 CODE=0
Apr 21 11:50:55 kernel: ACCEPT IN=eth0 OUT= MAC=e0:**:**:**:**:**:28:8a:1c:ec:74:52:08:00 SRC=107.147.149.125 DST=8*.***.**.*** LEN=40 TOS=0x00 PREC=0x00 TTL=31 ID=49851 PROTO=ICMP TYPE=13 CODE=0

I have a Asus Router RT-AC68U connected to a BT OR Modem and randomly get these in my log, i have it so it logs accepted connections etc and want to ensure there's nothing to worry about.

I replaced DST=IP with ** as that is my ip address, the first part of the MAC code (also replaced with **) in log above is my LAN MAC address (as stated in router network map). Any help in understanding this would be appreciated as just want to ensure nobody is on my network or trying to hack my router etc. the SRC=IP (this is sometimes same IP and different IPs).

My firewall is enabled so is DoS protection and Respond Ping Request from WAN is disabled.

thanks for any help.

 

[RMerlin]

Those are ICMP type 13 (Timestamp) packets. They are sent to your router, and it probably replies back with an ICMP 14 packet.

While odd, this should not pose any security threat. ICMP packets are generally accept by default, PINGs being the most notable exception.

 

[Netbug]

Thanks for the reply RMerlin.

I did check via a google search a few times previously but don't really quite get it at the moment to be honest, will try and read further about it if i can find anything as would like to understand the log better. I been getting them a few months now, i'm using the latest Asus beta firmware but was getting them for past two/three firmwares prior to the latest beta. It's what concerned me as never got them before then they appeared out of the blue.

Thanks for the reply although i'm still confused atm why i get them regulary in system log. The SRC=IP addresses are all from foreign countries. I sometimes get's loads all together with SRC=IP being different but it quietened down for about past two weeks.

I did a full router reset etc using asus restoration utility when the beta was released and cleared/reset Nvram via ssh although i don't think that would have made any difference but did it anyway.

I do have a VM and connect to my vpn provider via the VM, but again don't think that has anything to do with it either plus the vpn is done via supplied vpn software not via the router.

 

[Smacs]

I noticed a couple of such lines in my AC66U's log lately as well. Source IP somewhere in Indonesia... There's no log entry for the reply TYPE=14 though, or should it not even be there even if it was sent?

Jul 25 05:55:05 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=xxx <1>SRC=101.255.x.x DST=x.x.x.x <1>LEN=40 TOS=0x00 PREC=0x00 TTL=34 ID=9700 PROTO=ICMP TYPE=13 CODE=0
Jul 25 05:55:05 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=xxx <1>SRC=101.255.x.x DST=x.x.x.x <1>LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=18081 PROTO=ICMP TYPE=13 CODE=0

Anyhow, my question. How could it (ICMP timestamp) be blocked? It seems the default options in GUI won't block it?

 

[RMerlin]

I noticed a couple of such lines in my AC66U's log lately as well. Source IP somewhere in Indonesia... There's no log entry for the reply TYPE=14 though, or should it not even be there even if it was sent?

Jul 25 05:55:05 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=xxx <1>SRC=101.255.x.x DST=x.x.x.x <1>LEN=40 TOS=0x00 PREC=0x00 TTL=34 ID=9700 PROTO=ICMP TYPE=13 CODE=0
Jul 25 05:55:05 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=xxx <1>SRC=101.255.x.x DST=x.x.x.x <1>LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=18081 PROTO=ICMP TYPE=13 CODE=0

Anyhow, my question. How could it (ICMP timestamp) be blocked? It seems the default options in GUI won't block it?

The webui option only handles ICMP echo (pings), not other ICMP types. If you want to block other ICMP types for some reason, you will have to manually configure iptables yourself, with a third party firmware.

 

[Smacs]

Thanks for the reply, I assume your firmware should make iptables configuration possible?
I'm running 380.59.

 

[RMerlin]

Thanks for the reply, I assume your firmware should make iptables configuration possible?
I'm running 380.59.

Through custom shell scripts, yes.

 

[Smacs]

OK, sounds good.
I haven't had to deal with iptables too much in the past, so I will need to dig into it a bit before making any actual changes.
One thing caught my attention though when I looked at the existing conf - the default policy on the INPUT chain currently is ACCEPT. Shouldn't that be DROP?

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      420 31635 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0           
2     3661  707K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194
3      186  8370 DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 8
4     2190  148K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
5     250K   24M logaccept  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
6     1427  226K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           state NEW
7     186K   25M ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
8        0     0 logaccept  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68
9        2    80 logaccept  icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp !type 8
10   33295 2644K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

(There is an OpenVPN server running)

 

[ColinTaylor]

One thing caught my attention though when I looked at the existing conf - the default policy on the INPUT chain currently is ACCEPT. Shouldn't that be DROP?

No, this has been discussed elsewhere. It's a design choice, rather than have the policy as DROP the last rule of the chain is DROP everything. There's no right or wrong way. I'd guess it's done this way to make coding all the possible firewall configurations easier.

 

[Smacs]

True, the last drop rule should catch traffic that doesn't match any of the above rules.

I'm just wondering, if the firewall rules would have been done the other way (default DROP and followed by only allow rules), would it have made any difference with the ICMP getting through? Which of the current rules actually allowed it through?

E: I'm lacking a couple of cups of coffee today to see the answer to my question within the rules

 

[sfx2000]

I keep getting information in my log and want to understand what it means as am bit worried incase someones accessing my router/home network.

Don't worry about it - it's just ping packets...

 

[ColinTaylor]

Don't worry about it - it's just ping packets...

Ah, but that's the point. They're not ping (Echo) packets.

As Merlin pointed out, they are Timestamp packets.

 

[sfx2000]

Ah, but that's the point. They're not ping (Echo) packets.

As Merlin pointed out, they are Timestamp packets.

That's a ping packet... probably either someone doing a quick scan on your ISP's network, or the ISP itself...

Apr 21 10:13:23 kernel: ACCEPT IN=eth0 OUT= MAC=e0:**:**:**:**:**:28:8a:1c:ec:74:52:08:00 SRC=31.192.198.17 DST=8*.***.**.*** LEN=40 TOS=0x00 PREC=0x00 TTL=47 ID=2808 PROTO=ICMP TYPE=13 CODE=0

If you see a TCP/UDP connection request/accept, then it's time to worry - ICMP is stopped at the edge with IPv4 and a NAT'ed router/AP.

Like I said earlier - don't worry about it...

 

[ColinTaylor]

That's a ping packet... probably either someone doing a quick scan on your ISP's network, or the ISP itself...

Apr 21 10:13:23 kernel: ACCEPT IN=eth0 OUT= MAC=e0:**:**:**:**:**:28:8a:1c:ec:74:52:08:00 SRC=31.192.198.17 DST=8*.***.**.*** LEN=40 TOS=0x00 PREC=0x00 TTL=47 ID=2808 PROTO=ICMP TYPE=13 CODE=0

Sorry sfx2000, you've confused me there. Are you classifying all ICMP packets as "pings"?

This is a type 13 packet (Timestamp), whereas I would classify only a type 8 packet (Echo request) as a ping. https://en.wikipedia.org/wiki/Ping_(networking_utility)#Echo_request

But yes, don't worry about it.

 

[sfx2000]

Sorry sfx200, you've confused me there. Are you classifying all ICMP packets as "pings"?

Pretty much - there's a lot of options that one can do with ICMP packets, to get different information on a network, but since this is from your WAN side, NAT and the SPI firewall stops it.

Bigger things in the world to worry about - AsusWRT is just documenting that it got the packet on the WAN side, and wrote it into the syslog... no big deal.

 

[ColinTaylor]

Hmm, I see your point, but personally I'll stick with the pedantic definition of "ping" being an echo request.

BTW It wasn't me that asked the original question

 

[sfx2000]

Hmm, I see your point, but personally I'll stick with the pedantic definition of "ping" being an echo request.

BTW It wasn't me that asked the original question

Response was not targeted towards a specific OP, so sorry there - it's for the community benefit.. we see this asked from time to time..