Would utilizing a home lab environment to demonstrate the attack in real time be sufficient?
You don't need home lab to simulate an attack, all that you need is either another computer or VM, either on same subnet or separate subnet that will serve as attacker's machine from where you'll attempt to exploit your web server.
That attacker's machine should have Kali-Linux installed to simplify the process.
As a safety precaution while you do so your server should not be accessible over the internet to rule out someone taking advantage of it due you exploiting your server.
One approach is to use ready to use exploits, which one exactly you'd use depends on existing vulnerabilities on your web server, therefore first step is to learn known vulnerabilities (CVE's) on your server.
By "server" here I mean Apache server not your web site code.
Tools exist that help list CVE's, on Debian the tool is called
debsecan but since you're using Arch they might have their own tool.
If you can't find such tool then you'll need to browse CVE database somewhere online to list known CVE's for your currently running Apache version.
Once you know the holes next step is to boot up your attack machine and use metasploit framework which contains numerous exploits already written, it will take some time to learn how to use it effectively, but your job boils down to launching exploits vs vulnerabilities that you know they exist from what's said beforehand.
Further method if previous one proves to be ineffective (ex. no attack succeeded) is to write exploits yourself, I assume you won't know how to do this so I'll only share abstract concepts:
- Clone apache server source code
- Use various analysis tools to detect programmer mistakes in code (ex.
flawfinder, rats, splint, psscan etc.)
- Otherwise also use your own skills to study the code to spot programmer errors
- If an error or mistake is found write an exploit suitable to be used by metasploit framework to exploit that mistake
Further method is testing your own web server code...
I have no exact clues how this could be done but I assume you'd be looking for exploits that target server side code or libraries.
So the principle is likely the same except you'd be targeting server side site code instead of server itself.
If you're specifically interested in testing your own server side code, I'd also suggest to run static analysis tools on your code and fix any warnings reported. (which one depends on what server side code do you use on server)
Often such warnings point to your programming errors that could easily be exploited.
All this is only about your web server, if you however run other services on your home lab then those services need to be tested as well using the same principle, because an attacker may compromise whole system by exploiting only one service.
edit:
You might also want to simulate DDoS against your server:
Bash:
# Launch attack in one terminal
sudo hping3 --rawip --syn --ipproto 6 --flood 10.10.10.10 --destport 80
# Measure PPS in another terminal
vnstat -i eth0 -tr
The first command above is launched from your attacker's machine where
10.10.10.10 is your server address and
--destport is your server port.
The second command can be used on same machine whose only purpose is to measure how many packets are sent, this is usually limited by your link local bandwidth (which is likely larger than your ISP bandwidth).
If you local bandwidth is lower than your ISP bandwidth then the only limitation is that of how fast can
hping3 send packets.
According to my past tests that was:
Bash:
# hping3 statistics:
# TCP: 76,97 Mbit/s 178154 packets/s (2314 packets/1Mbit)
# UDP: 56,23 Mbit/s 167360 packets/s (2976 packets/1Mbit)
# ICMP: 58,82 Mbit/s 175058 packets/s (9276 packets/1Mbit)
But I don't recall whether limited by my hardware or hping3, so you might also want to set up multiple attack machines for the purpose.
While the attack is running you'll normally want to attempt to visit your server from your phone so that it's over the internet and not over LAN which is now hopefully under burden enough for server to fail to serve.
To prevent DDoS you'll want to play with
nftables although that's not the ultimate defense but it's better than none.
Note that with the help of
hping3 you can send malware to your server, therefore you can also simulate such scenario in combination with DDoS simulation.
Hackers sometimes launch DDoS not to deny service (as it is popular and false belief) but to exploit the machine during the attack by launching exploits in same time or sending their malware to server.
---
You'll also want use
nmap from attacker's machine to be able to determine what hackers can learn about your server, and then accordingly set up
nftables so that minimum information can be gathered.
This includes attempting and preventing port scanning in addition to OS and server name and version detection.
