ERDiagram
The ER Diagram (Entity Relationship Diagram) represents the relational database structure of the WISETrap Honeypot System based on the actual MySQL database schema.
The diagram illustrates how users, attacker activity, trap endpoints, attack logs, and alert notifications are connected through relational database design.
WISETrap is a deception-based web honeypot system designed to detect unauthorized access attempts through intentionally exposed trap resources such as:
/login.txt
The database architecture is divided into two major domains:
- User & Administration Management
- Honeypot Monitoring & Attack Logging
The ER Diagram defines all database entities, attributes, primary keys, foreign keys, and relationships used by the system.
Stores system user roles and permission groups.
- GroupId (PK)
- GroupName_En
- GroupName_Ar
- trap_endpoint_id (FK)
Defines user roles such as:
- Administrator
- Login Trap
The Login Trap group may optionally reference a trap endpoint.
Stores authentication and account information for system users.
- UserId (PK)
- Username
- Password
- PhoneNumber
- SubscriptionDate
- LastLogin
- GroupId (FK)
- Status
- FailedLogin
- created_at
- updated_at
Handles:
- Authentication
- User management
- Login tracking
- Group assignment
Stores extended profile information for each user.
- UserId (PK, FK)
- FirstName_En
- LastName_En
- Address_En
- FirstName_Ar
- LastName_Ar
- Address_Ar
- DOB
- Image
Separates profile information from authentication data for better database normalization.
Stores information about attackers or automated bots interacting with the honeypot system.
- attacker_id (PK)
- ip_address
- user_agent
- first_seen
- last_seen
- country
- is_bot
Tracks attacker identity and suspicious activity sources.
Stores honeypot trap resources monitored by the system.
- endpoint_id (PK)
- endpoint_name
- endpoint_url
- description
- is_active
- created_at
/login.txt
Defines exposed trap endpoints used for attacker detection.
Stores detailed records of suspicious requests and attacker interactions.
- log_id (PK)
- attacker_id (FK)
- endpoint_id (FK)
- requested_url
- timestamp
- http_method
- status_code
- request_data
- response_data
Captures:
- Attack attempts
- Request information
- HTTP activity
- Honeypot interaction logs
Stores alert notifications generated after suspicious activity is detected.
- alert_id (PK)
- log_id (FK)
- alert_type
- email_sent
- sent_at
- read_at
- status
- pending
- sent
- failed
- read
Tracks security notifications sent to administrators.
Relationship Type: One-to-Many (1:N)
Description: One group can contain multiple users.
Relationship Type: One-to-One (1:1)
Description: Each user has one profile record.
Relationship Type: One-to-Many (Optional)
Description: A trap endpoint may optionally be assigned to a user group.
Relationship Type: One-to-Many (1:N)
Description: One attacker may generate multiple attack logs.
Relationship Type: One-to-Many (1:N)
Description: One trap endpoint may appear in multiple attack logs.
Relationship Type: One-to-One (1:1)
Description: Each attack log may generate one alert notification.
- An attacker accesses a trap endpoint
- The honeypot system records request information
- Attack data is stored in AttackLogs
- Alert records are generated
- Administrators receive security notifications
The purpose of the ER Diagram is to define the relational database architecture used by the WISETrap Honeypot System and demonstrate how authentication, honeypot monitoring, attack logging, and alert management are connected through structured database relationships.
- The database uses MySQL with the InnoDB engine.
- Foreign keys enforce relational integrity.
- CASCADE and RESTRICT rules are used to maintain data consistency.
- The database design separates user management from honeypot monitoring logic.
- The architecture supports scalability and future feature expansion.