Attacks

Introduction

There were some unsuccessful attacks on the services on the Home Lab server. The primary cause of the attack was that RDP access was made to Walnut.

Cause

The principal cause of the attacks was that a DNS name for Walnut was made on Cloudflare as DNS only. This would have exposed the actual IP address of the Home Lab, in itself that would not have been a problem except there was some reference to port 19000 being used for RDP to Walnut. Even that would not have been so much of a problem if Pfsense had been set to drop everything from outside the LAN. Unfortunately, TCP port 19000 was exposed to the Internet and when it was probed the attacker would have had a response from the RDP server on Walnut. At the same time the attackers would have been able to get the IP address of Walnut. So the attacker would now know that there is a server and RDP port, that is enough to start probing.

Impact

As soon as the IP address was known there was a constant stream of connection attempts on random ports directly at the IP address. At the same time the attackers were endeavouring to locate as many other sub domains that could be attacked so the wpad.seaoffate.net was probed every few hours to try and get a sitemap. The variations of a mail server were probed for a time and other similar DNS names were queried but as none of them actually existed there would have been no IP address returned from Cloudflare. So any bots that were querying non existent domains would have no real impact on my internet connection and would be fielded by Cloudflare.

As the attackers had discovered the IP address of my home network they let their bots randomly query the various ports but as most ports would have been blocked by default by Pfsense they would have simply timed out. Sadly, they got a response from the RDP server on port 19000 so they tried various different passwords to try to login because RDP is known to have server. Other ports were scanned in a random fashion at the same time.

As soon as it noticed that the network was under attack there was a full review of the rules in place on Pfsense and things like the port forward rule for 19000 to walnut were changed so that the only packets that would be accepted would come from the LAN and everything else would be dropped. To be sure there was not much that needed to be changed radically. One slight change was to have all webservers only accept incoming traffic if it came from one of Cloudflare's IP addresses. Personally, as Ip addresses can and frequently are spoofed there is limited value in adding rules concerning IP addresses that are on the WWW but it is the recommended best practice and it will do no harm and it could, maybe mitigate some future attack. All of the other rules were written properly and limited access to LAN only where appropriate and needed no change.

Even though the attacks were never going to do any good after the Pfsense rules review the bots continued to probe and scan and these continual probes made the ISP block most of the incoming traffic including the webservers and the legitimate traffic were blocked as well. The expression is to be black boxed. The Virgin Media IP address was black boxed for several weeks and only cleared the day before the ISP was changed. If the decision to change ISP had not already been made We would have had to have made the dynamic IP address change but as it was already known that it would be changed at a fixed point in time no action was taken.

Resolution

There was no absolute steps taken to resolve the attack but there were changes to Pfsense that would stop any penetration. Also the DNS only entries were removed in anticipation of the change in IP address. These DNS only entries existence had already, in part triggered the attack, were removed so that when the IP address changed there would not be an easy route for the attackers to get the new address and restart the cycle. While there was no direct action to combat the attack because the IP address was about to be changed, there would have been a few things to try to get the IP address to renew.

• Try switching off the router for an extended period ( days or preferably weeks) so that the ISP's DHCP server issues a new IP address.
• Try changing the router's MAC address if that is possible on the ISP's router.
• Change the router to "modem mode" and use the Pfsense firewall's MAC address to trigger a new DHCP issue. Not sure if this will actually work as the modem mode may still use the ISP router's MAC address.
• Contact the ISP's support and ask them to change the IP address.

The key point is to get a new IP address or wait until the attackers give up.

• ==Moving Forward==

As there is a new ISP and therefore a new IP address any attack on the old IP address is irrelevant. However, we do not want a new attack to start so we need to keep the IP address hidden and not have any DNS only entries on Cloudflare, at least not for some time. It does not matter that the attack did not penetrate Pfsense because the constant probes made the ISP black bo the IP address so it is in effect a DDOS attack. There will for a time be some changes to access to services such as

• Websites will continue to be proxied by Cloudflare.
• PFsense rule to only allow web traffic from Cloudflare IP addresses.
• RDP and NoMachine access will be over VPN or within the LAN
• Pfsense rules to drop any packets originating outside 192.168.1.0/24
• VPNs clients will be configured with the IP address rather than as a "DNS only" domain name. If the IP does change it can still be obtained from Cloudflare's control panel. I could add a Specific DNS name with DNS only set but not ever advertise it on these wiki pages because it will only ever be on the laptop or other client and be unchanging there would be no need to record it in notes and is unlikely to be guessed by any attacker, especially if it is someLongRandomString.seaoffate.net.
• Other services will need to be configured so as to not reveal an IP address
  • Cloudflare offer a service called Cloudflared. This is a VPN tunnel through Cloudflare to the clients inside the firewall. The Cloudflared client is added to the VM and API keyis added to it, the client initiates the connection to Cloudflare so there is no need to add any port forward rules to Pfsense or the edge firewall.
  • TCPshield for Minecraft server will forward data from TCPshield to my host and this service is configured to expect bot attacks. I believe the free tier allows for one GB per month
  • A cheap VPS that simply forwards the designated ports but drops everything else. So that if there is an attack it will be on the VPS and even then it is likely to be only short lived because every port the attacking bot tries will be dropped including the most popular ones.