How Many Home Network Attacks / Day is Too Many? I've got 2k.

[ChetFT]

In mid-December I decided to retire my Asus RT-N66U with stock firmware in favor of an Asus AC68U. I liked the idea of having my own VPN and better ability to segment my wireless network for my IOT and entertainment devices, also the AI protection sounded interesting. I put all of the security settings to conservative values, but did plug in a USB drive into the router. I checked the AI protection every day and saw a number of attacks. On the third day my 18 digit admin pw no longer gave me access to the router.

After resetting and re-flashing and unplugging the USB drive, I ordered a RATtrap hardware firewall. It is averaging 2k blocked attacks per day for the last two weeks. Is this a normal number of attacks, or am I being singled out for special attention, possibly by the botnet that recently owned my router? Do I need to contact my ISP and get a new IP adr?

It's been interesting learning a bit about networking, and also very surprising. I'm led to believe that a large proportion of home networks may be currently hacked. Anyhow, thanks for reading. I've already read quite a bit and have followed much of the simple advice on the web, but please do feel free to make suggestions on improved security. I've currently banished all IOT devices, but may flash the old N66U with 3rd party firmware and use it for the IOT stuff.

 

[EWBtCiaST]

How are you defining “attacks”?


Sent from my iPhone using Tapatalk

 

[ChetFT]

How are you defining “attacks”?


Sent from my iPhone using Tapatalk

Probably I should have called them blocked packets instead of attacks. Attack is an assumption on my part. Here is a representative list that the security appliance blocked:

Date In/out IP Dest Port City Country
1/9/18 19:37 Incoming 89.248.168.64 5444 Netherlands
1/9/18 19:36 Incoming 183.99.158.160 23 Seoul Republic of Korea
1/9/18 19:36 Incoming 89.248.168.64 5866 Netherlands
1/9/18 19:36 Incoming 89.248.168.64 2749 Netherlands
1/9/18 19:35 Incoming 202.71.50.118 23 Saitama Japan
1/9/18 19:35 Incoming 89.248.168.64 1997 Netherlands
1/9/18 19:35 Incoming 89.248.168.64 5986 Netherlands
1/9/18 19:34 Incoming 89.248.168.64 1751 Netherlands
1/9/18 19:34 Incoming 89.248.168.64 4168 Netherlands
1/9/18 19:34 Incoming 89.248.168.64 1191 Netherlands
1/9/18 19:33 Incoming 89.248.168.64 2142 Netherlands
1/9/18 19:33 Incoming 31.13.69.228 59931 United States
1/9/18 19:33 Incoming 89.248.167.131 82 Netherlands
1/9/18 19:32 Incoming 89.248.168.64 3776 Netherlands
1/9/18 19:32 Incoming 89.248.168.64 4252 Netherlands

It's pretty steady and amounts to about 2k blocks per day with IPs all over the world. I've looked at the logs from my AC68U, and get about 300 or so drops per day. It's a pretty steady rate for both logs, day or night, all my network clients on or off. I got a lot more in the AC68U log before I connected the RATtrap. Here's a representative log listing from the AC68U after installing the RATtrap:

Jan 9 18:18:36 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=50.116.17.183 DST=xx.xx.xxx.xx LEN=34 TOS=0x00 PREC=0x00 TTL=55 ID=22115 PROTO=ICMP TYPE=8 CODE=0 ID=22115 SEQ=0

Jan 9 18:36:25 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=47.74.157.9 DST=xx.xx.xxx.xx LEN=46 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=33920 DPT=123 LEN=26

Jan 9 18:48:16 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=173.249.21.178 DST=xx.xx.xxx.xx LEN=431 TOS=0x00 PREC=0x00 TTL=55 ID=64181 DF PROTO=UDP SPT=5164 DPT=5067 LEN=411

Jan 9 18:48:19 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=159.203.16.75 DST=xx.xx.xxx.xx LEN=80 TOS=0x00 PREC=0x00 TTL=53 ID=42751 DF PROTO=UDP SPT=40372 DPT=389 LEN=60

Jan 9 19:09:55 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=74.82.47.6 DST=xx.xx.xxx.xx LEN=70 TOS=0x00 PREC=0x00 TTL=52 ID=54889 DF PROTO=UDP SPT=12675 DPT=53 LEN=50

Jan 9 19:33:46 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=13.85.85.174 DST=xx.xx.xxx.xx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=52546 DF PROTO=TCP SPT=443 DPT=59942 SEQ=1290066212 ACK=884838776 WINDOW=235 RES=0x00 ACK URGP=0 OPT (0101080A08213040486813CD)

Jan 9 19:34:15 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=13.85.85.174 DST=xx.xx.xxx.xx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=52547 DF PROTO=TCP SPT=443 DPT=59942 SEQ=1290066212 ACK=884838776 WINDOW=235 RES=0x00 ACK URGP=0 OPT (0101080A08214C50486813CD)

Jan 9 19:37:42 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=145.239.141.201 DST=xx.xx.xxx.xx LEN=485 TOS=0x00 PREC=0x00 TTL=111 ID=5616 PROTO=UDP SPT=18576 DPT=5060 LEN=465

Sorry about the mess, it looked better in the spreadsheet.

 

[degrub]

Welcome to the Internet of Probes from every script kiddie in th world.
Just make sure you are dropping unsolicited packets.

 

[Eric]

I used to see multiple probes per second on my network. The most obvious ones are the connections to the servers using ssh to try to guess a password.

I saw on one server one day that out of 1.2 million attempts to guess passwords on ssh during the previous two months, more than half were from one /24 block in China, 116.31.116/24. So I decided to do something about it.

At the firewall, I now download the IPv4 and IPv6 zone files from www.ipdeny.com for the US. For each routable IP address on my network, there are now three options:

1) Allow incoming probes and attempts to connect from anywhere in the world.
2) Allow incoming probes and attempts to connect from the US and disallow all probes and attempts to connect from outside the US.
3) Allow only incoming probes and attempts to connect from our local addresses.

Nearly all addresses are on local access only and only two or three allow probes and connections from anywhere in the world.

There are days now when I don't even see one connection to a server with ssh by someone trying to guess passwords.

 

[RMerlin]

That's why personally, I prefer to move WAN-exposed SSH to a non-standard port. Prevents almost 100% of brute force attacks from hitting it. Otherwise, it gets a ridiculous amount of connection attempts, sometimes so heavy that the server's CPU load explodes under the flood of password attempts.

 

[WiFiNemesis]

I checked the AI protection every day and saw a number of attacks. On the third day my 18 digit admin pw no longer gave me access to the router.

Should we conclude from this that the "commercial grade" performance of AiProtection/TrendMicro is an inadequate security solution?

I've been looking for a comprehensive, easy-to-understand and practical guide to WAN-facing security for awhile now (on the order of SNB's reports). Still looking: anyone have a recommendation?

 

[sfx2000]

That's why personally, I prefer to move WAN-exposed SSH to a non-standard port. Prevents almost 100% of brute force attacks from hitting it. Otherwise, it gets a ridiculous amount of connection attempts, sometimes so heavy that the server's CPU load explodes under the flood of password attempts.

Moving the port can help - two schools of thought there, and both sides have sound reasons.

With OpenSSH, there are settings in the sshd_config that can really help out -- AllowUsers is very helpful, as that cuts down quite a bit on PAM checking (if using PAM) - if the user is not in that item, things don't go further - and RMerlin's build does have some brute force detection that rate limits connection attempts in the first place (similar to UFW's LIMIT setting for Ubuntu/Debian boxes) - and using certificates is preferred to user/pass authentication, again, limiting the load issues in verifying if the user is allowed or not.

Best thing though - really consider if there is a true and valid need to expose any services on the WAN side - esp. those on the router/gateway, as that box is the first line of defense in protecting your LAN - in most cases, it's more of a "want" because "it's there", but for each use case, there's usually a better approach than using the router itself.

 

[Eric]

Those are good points about various changes to the dhcpd_config file.

In my case, instead of AllowUsers, I create a group and make accounts that are permitted to sign in a part of that group. For example, "AllowGroups remoteuser". That way, if I need to add another username to the list, I just have to add it to the group and don't have to modify the sshd_config file at all to add the username to an AllowUsers.

I also use "Match Address" to have different settings for local addresses than from internet routable addresses. Password authentication is allowed only from local addresses and root logins are only permitted from 127/8.

In other words, it's locked down enough that it is doubtful that anyone from outside can get in with ssh unless they can get the RSA keys by other means. I'm not worried about people trying to guess passwords, but I do get tired of all the entries in the log files.

To me, the bigger concern is that if I'm seeing that many attempts to guess ssh passwords on my servers and devices, then there are going to be enormous numbers of attempts on customer equipment using a very wide variety of attacks.

There is always a slight possibility, though, that there might be a vulnerability in ssh itself that someone could exploit. Naturally, patches have to be kept up to date.

Regarding firewalls/routers, I often tell people that their routers/firewalls should only be considered secure if they are running the latest firmware. If they don't bother to update the firmware, then their firewalls and routers are not as secure as they think. There may be a 0-day exploit for which no patches have been issued, but the vast majority of break-ins are using exploits for which patches have been available for some time.

Patches that eliminate backdoors and other vulnerabilities only work if the patches have been applied. How many home users apply these patches? How many small or medium companies keep their firewalls up to date even if they contract it out to outside services?

 

[WiFiNemesis]

Should we conclude from this that the "commercial grade" performance of AiProtection/TrendMicro is an inadequate security solution?

Never mind. Of course it is.

COMPREHENSIVE FIRMWARE BINARY SCAN FINDS KRACK IS “TIP OF ICEBERG” FOR KNOWN WI-FI SECURITY VULNERABILITIES

 

[sfx2000]

In my case, instead of AllowUsers, I create a group and make accounts that are permitted to sign in a part of that group. For example, "AllowGroups remoteuser". That way, if I need to add another username to the list, I just have to add it to the group and don't have to modify the sshd_config file at all to add the username to an AllowUsers.

AllowGroups is always a good thing with good management practices...

I also use "Match Address" to have different settings for local addresses than from internet routable addresses. Password authentication is allowed only from local addresses and root logins are only permitted from 127/8.

Note here - over SSH on OpenSSH, never allow root to directly access - that's asking for trouble - go in as a 'trusted user' and then one can employ user account controls for sudo, and they can jump to root via su

In other words, it's locked down enough that it is doubtful that anyone from outside can get in with ssh unless they can get the RSA keys by other means. I'm not worried about people trying to guess passwords, but I do get tired of all the entries in the log files.

Keys are good - in an operational/production environment, one needs to stay on top of things if an employee checks out, but there, should be process in place.

To me, the bigger concern is that if I'm seeing that many attempts to guess ssh passwords on my servers and devices, then there are going to be enormous numbers of attempts on customer equipment using a very wide variety of attacks.

Whitelisting the ssh... The rest is just chatter in the logs...

There is always a slight possibility, though, that there might be a vulnerability in ssh itself that someone could exploit. Naturally, patches have to be kept up to date.

Depends on the host - embedded is likely going to be slower at a response, and they won't have whitelists for users...

Regarding firewalls/routers, I often tell people that their routers/firewalls should only be considered secure if they are running the latest firmware. If they don't bother to update the firmware, then their firewalls and routers are not as secure as they think. There may be a 0-day exploit for which no patches have been issued, but the vast majority of break-ins are using exploits for which patches have been available for some time.

Yep, agreed - see post above - ssh daemons like OpenSSH and DropBear are fairly secure if properly configured, all said, but again, and this is to the larger community, only expose services if needed, not wanted, but needed, and understand the risks of doing so.