Objective
Analyze the data from my T-Pot honeypot deployed on AWS EC2 and leverage the findings to create a Web Application Firewall (WAF) with custom rules. The WAF will be designed to reduce future attacks by blocking known attackers based on collected data.

T-Pot Insights
I've observed a variety of interesting insights gained from the honeypot over the last 10 days to include:

• Over 670,000 events recorded from over 6,400 unique IP addresses
• 88% of the source IP addresses have been identified as "known attackers"
• The top 5 countries associated with the attacking IP addresses are as follows: India (18%), Vietnam (14%), China (13%), USA (12%) and Russia (10%)
• Among the client software detected on the honeypot, 86% of them have been using ZGrab. ZGrab is a network scanning tool designed to collect data from various services and protocols such as HTTP, HTTPS, FTP, SMTP, IMAP, POP3, DNS, SSH, and more. It can gather specific information like SSL/TLS certificates, HTTP headers, email information, DNS data, etc.
• The most common port destinations targeted by the attackers are as follows: 445 (Typically File Sharing & Active Directory), 53 (DNS), 5900 (Virtual Network Computing, allowing remote access & control), 547 (DHCP) and 80 (Web Server/HTTP)

Introduction
10 days ago, I deployed a T-Pot honeypot on AWS EC2 to capture and analyze incoming attack traffic. Now I am utilizing the insights gained from analyzing the honeypot data to develop and implement a WAF for enhanced attack detection and prevention.

Tools & Technologies Used
AWS Web Application Firewall (WAF), Aplication Load Balancer (ALB), AWS EC2, Custom Inbound Rules, T-Pot (Honeypot)

Implementation
1. Create Application Load Balancer (ALB):
An ALB is created to distribute incoming traffic to multiple targets. In this case, the ALB acts as a connection point between the WAF and the honeypot deployed on EC2.

2. Create a WAF and Custom Rules:
Once the WAF is established, and custom rules are created based on the analysis of honeypot data. For testing purposes, three rules are implemented:
A. Blocking the top 10 IP addresses identified as "known attackers."
B. Blocking IP addresses originating from the top countries associated with attack traffic (excluding the United States).
C. Blocking any IP address that exceeds 500 requests within a 5-minute timeframe, deemed to be non-human behavior (potentially ZGrab or Nmap scans).

NOTE: Blocking entire countries may not be suitable in all real-world scenarios due to various factors such as VPN access requirements or the utilization of contractors in those countries. Considerations should be made based on individual company requirements.

3. Connect the WAF to the Load Balancer:
Under the "Associated AWS resources" section of the WAF, the ALB is added as the associated resource to enable traffic filtering.

4. Connect the Load Balancer to the EC2 Instance:
In the EC2 console, the security group for the EC2 instance is modified by adding a new inbound rule that permits traffic from the load balancer's security group ID.

5. Monitor and Test:
Almost immediately, new observations show that incoming requests originate primarily from allowed countries (e.g., the United States), while other types of requests cease. The total number of events significantly decreased, likely due to the automatic blocking of IP addresses making more than 500 requests within a 5-minute span.

Before the integration of the WAF and custom rules, the honeypot experienced an average of nearly 5,000 events per hour. However, with the implementation of the WAF and the enforcement of the custom rules, the event count has significantly reduced to an average of 50 events per hour. This represents a remarkable decrease of 99%.

Challenges & Lessons Learned
One challenge encountered during this process was understanding the purpose and functioning of an Application Load Balancer (ALB). However, after learning about ALBs and watching tutorial videos on setting up the connection between the ALB, WAF, and EC2 instances, the rest of the process proceeded smoothly.

Conclusion
The overall process of setting up the T-Pot honeypot, monitoring attacks, analyzing data, and creating rules for future attack mitigation on AWS was highly engaging. The ability to witness real-time changes in attack maps and dashboards, along with the reduction in attack events, provided rewarding insights.

Future refinement of this approach could involve detecting additional attack methods and continuously updating the list of known attackers to enhance the security measures. However, due to cost considerations related to the large number of Docker containers required (18 containers across t3.xlarge instances with 128GB RAM ouch!), the honeypot will be temporarily disabled. Nevertheless, this experiment served as a valuable learning experience in AWS and cybersecurity defensive measures.