francolmenar / offensive_technologies_ctf Goto Github PK

Extend your monitoring software so you can automatically get statistics on number of packets and bytes sent to the server in TCP data, TCP SYN, UDP and ICMP and Total categories so you can diagnose various DDoS attacks. Make sure the software monitors the correct interface.

Develop monitoring at the server that will let you automatically check the content of HTTP requests you are getting and who is sending them.

SlowLoris attack => keeps the server's resource pool busy by slowly submitting requests with headers and never finishing.

Script needs to be improved => maybe add multithreading ?? Possible defense: reqtimeout module

Extend your monitoring software so you can detect number of packets and bytes sent to the server by each client IP. Make sure the software monitors the correct interface.

Learn how you would write rules for iptables to filter traffic with some characteristics, e.g., by protocol, sender IP, length, TCP flags, etc.

You may need to write those rules manually during the exercise but make sure you have tried to write them while preparing for the exercise and that they work correctly.

You can check correctness by generating attack traffic with some signature (e.g., packet length, sender IP, protocol, etc.), writing a rule to filter it and checking that that traffic is dropped.

You can check for drops in two ways. First, you could run your monitoring software on the interface leading to the server. Second, you could use an option with iptables that lets you see counts of times a rule was matched.

It may be advisable to try both methods for measuring correctness as the first measures what goes to the server and the second shows you that the rule was activated by attack traffic

Traditional flooding tools like flooder or hping3 Possible defense: hashlimit on iptables or rate_limit in snort.

I think it would be useful if there could be a script to automatically create the passwords randomly at the DB setup - it is optional but it could be useful.

apache2-utils => stress test the server with ab -c 200 -n 5000 -r Possible defense: qos_module

Add more options to be displayed.

To check it, verify that it's not possible to deposit and withdraw from any user by specifying a random password.

It checks the correctness of the data stored at the DB.

It is optional but I think it would be useful.

Install qos_module and automate it to be run at the start.

GoldenEye => keeps the server's connections alive by using HTTP Keep Alive + No Cache as attack vector. Possible defense:

use hash limit in ip tables
use snort rules to block Keep-Alive and No Cache

Integrate setup/server_iptables_setup.sh, setup/setup.sh and server/set_up_server.sh into the same script.

Add flags options to be able to define if all the scripts are going to be run or just some of them.