Attacks - Revision history

Wikisailor: /* Moving Forward */

2026-01-24T17:14:21Z

Moving Forward

← Older revision		Revision as of 17:14, 24 January 2026
Line 31:		Line 31:
	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.		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		There will for a time be some changes to access to services such as
			* With the new ISP router the config will only forward the ports that are actually needed. I should have done the same with the old router but its config was a bit limited.
	* Websites will continue to be proxied by Cloudflare.		* Websites will continue to be proxied by Cloudflare.
	* PFsense rule to only allow web traffic from Cloudflare IP addresses.		* PFsense rule to only allow web traffic from Cloudflare IP addresses.

Wikisailor: /* Impact */

2026-01-24T17:11:42Z

Impact

← Older revision		Revision as of 17:11, 24 January 2026
Line 9:		Line 9:
	==Impact==		==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 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 for example 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 the attackers had discovered the public IP address of my home network they let their bots randomly query the various ports but most ports would have been dropped by default by the Pfsense and 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.		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.

Wikisailor: /* Cause */

2026-01-24T17:08:16Z

Cause

← Older revision		Revision as of 17:08, 24 January 2026
Line 5:		Line 5:
	==Cause==		==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.		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 in these wiki notes. 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 public 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==		==Impact==

Wikisailor: /* Introduction */

2026-01-24T17:06:44Z

Introduction

← Older revision		Revision as of 17:06, 24 January 2026
Line 1:		Line 1:
	==Introduction==		==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.~~		There were some unsuccessful attacks on the services on the '''[[Home Lab]]''' server. The primary cause of the attack was that there was a DNS only entry on Cloudflare and a port forward on ISP router & Pfsense and it was documented in the wiki notes. all of these thing had to happen to get some bot to attack

	==Cause==		==Cause==

Wikisailor: /* Introduction */

2026-01-24T17:03:23Z

Introduction

← Older revision		Revision as of 17:03, 24 January 2026
Line 1:		Line 1:
	==Introduction==		==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.		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==		==Cause==

Wikisailor: /* Resolution */

2026-01-24T17:01:43Z

Resolution

← Older revision		Revision as of 17:01, 24 January 2026
Line 27:		Line 27:
	The key point is to get a new IP address or wait until the attackers give up.		The key point is to get a new IP address or wait until the attackers give up.

	*==Moving Forward==		==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.		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.

Wikisailor: /* Moving Forward */

2026-01-24T17:01:23Z

Moving Forward

← Older revision		Revision as of 17:01, 24 January 2026
Line 27:		Line 27:
	The key point is to get a new IP address or wait until the attackers give up.		The key point is to get a new IP address or wait until the attackers give up.

	==Moving Forward==		*==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.		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.
Line 35:		Line 35:
	* RDP and NoMachine access will be over VPN or within the LAN		* 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		* 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.		* 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 to ~~use the~~ Cloudflared ~~service where possible so that they are only accessed by their~~ VPN tunnel.		* Other services will need to be configured so as to not reveal an IP address
	* If Cloudflared ~~or proxy~~ is ~~not possible either use some other type of proxy~~ or ~~VPN tunnel such as~~ TCPshield for Minecraft server.		** 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.
	** ~~of a~~ cheap VPS that simply forwards		** 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.
	~~Any new services~~

Wikisailor: /* Moving Forward */

2026-01-24T16:40:58Z

Moving Forward

← Older revision		Revision as of 16:40, 24 January 2026
Line 32:		Line 32:
	There will for a time be some changes to access to services such as		There will for a time be some changes to access to services such as
	* Websites will continue to be proxied by Cloudflare.		* Websites will continue to be proxied by Cloudflare.
	* RDP and NoMachine access will be over VPN or within the LAN ~~with~~ Pfsense rules to drop any packets originating outside 192.168.1.0/24		* PFsense rule to only allow web traffic from Cloudflare IP addresses.
	* 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.		* 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.
			* Other services to use the Cloudflared service where possible so that they are only accessed by their VPN tunnel.
			* If Cloudflared or proxy is not possible either use some other type of proxy or VPN tunnel such as TCPshield for Minecraft server.
			** of a cheap VPS that simply forwards

			Any new services

Wikisailor: /* Moving Forward */

2025-07-22T12:13:54Z

Moving Forward

← Older revision		Revision as of 12:13, 22 July 2025
Line 28:		Line 28:

	==Moving Forward==		==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.
			* RDP and NoMachine access will be over VPN or within the LAN with 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.

Wikisailor: /* Resolution */

2025-07-22T10:59:10Z

Resolution

← Older revision		Revision as of 10:59, 22 July 2025
Line 19:		Line 19:
	==Resolution==		==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 ~~current~~ attack ~~were~~		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==		==Moving Forward==