Click RED packets to block · Let GREEN ones through
Select Difficulty
Click red attack packets before they reach the firewall · Green = legitimate traffic, don't block!
Available for opportunities
AkthamAl-Arabi
// Network & Cloud Security Engineer · CCNA
Network and systems security engineer with hands-on experience in enterprise networking, SOC operations, cloud infrastructure, and ITSM. Building secure, well-configured networks — one interface at a time.
Background, skills, and a quick overview of my focus areas.
Experience
Internships, certifications, volunteering, and training.
Projects
GNS3, Packet Tracer, and real-world security lab projects.
Contact
Reach out via email or connect on platforms I use most.
Certifications
CCNA, Azure, Security+, BTL-1 with topics breakdown.
Skills & Tools
Technical skill bars and full tools & technologies arsenal.
About
Background & Expertise
I'm a network and systems security engineer based in Amman, Jordan. I graduated with a BSc in Electrical Engineering (Network & Systems Security) from Al-Balqa Applied University in February 2026 with a GPA of 3.24/4.00.
My focus spans enterprise network design and security, cloud infrastructure on Microsoft Azure, SIEM-based threat detection with Splunk, and ITSM platform implementation. I build and test configurations in GNS3 and Cisco Packet Tracer — everything from basic switching to full IPSec VPN deployments.
Currently working as an ITSM Consultant at DIMA Solutions implementing OpenText SMAX aligned with ITIL practices, while volunteering with the IEEE Computer Society's Member Development team.
Network EngineeringCloud InfrastructureNetwork SecuritySIEM & SOCITSM / ITILPython & API
Network Engineering
Policy-based routing, LAN/WAN design, redundancy and failover across enterprise-scale topologies
Cloud Infrastructure
Azure AZ-104/500 certified. Virtual networks, IAM, NSG, Security Center, and hybrid cloud deployments.
Network Security
Threat detection, perimeter hardening, zero-trust access controls, and defence-in-depth across hybrid environments
ITSM Services
OpenText SMAX implementation and IT Service Manager configuration aligned with ITIL service management practices.
Engineered a defensive SIEM infrastructure using Splunk Enterprise and Sysmon to detect advanced threats and C2 traffic, with custom SPL detection rules.
Conducted authorized Black Box penetration tests — breached targets via VPN hash cracking (IKEv1) and privilege escalation.
Utilized Tenable Nessus for vulnerability management; identified critical flaws in legacy systems and authored remediation plans.
Developed custom Python scripts to automate threat intelligence gathering via the VirusTotal API, significantly reducing manual analysis time.
Provided technical support and infrastructure management for large-scale government projects, including the Ministry of Education and the Public Security Directorate.
Executed enterprise-wide Windows OS imaging and deployments using Ventoy and Hiren's BootCD to ensure standardized software configurations across workstations.
Managed end-to-end hardware provisioning, diagnosed software and hardware malfunctions, and coordinated logistical handover of IT assets to site administrators.
Community
Volunteering — IEEE Computer Society
Member Development (MD) Team, Amman · Feb 2026 – Present. Rotated through multiple leadership roles to maximise community impact.
The Librarian
Knowledge Provider
Shared technical articles, PDFs, and summaries in the community's technical-news channel to maintain consistent learning resources for all members.
Engagement Leader
Community Activation
Organized games, Q&A sessions, and themed challenges. Built a Python Discord bot with slash commands, leaderboards, and admin controls for automated quiz delivery.
Tech Leader
Peer Education
Delivered technical workshops to help community members build skills through peer learning and hands-on sessions.
Data Keeper
Analytics & Tracking
Tracked workshop attendance, recorded sessions, monitored less active members, and provided engagement insights to support community growth.
Under Development
IEEE Project — Automated Ethical Hacker Platform
Building an automated ethical hacking platform that detects vulnerabilities in websites and applications — designed for startups, developers, and small businesses. Features automated scanning (SQL Injection, XSS, open ports), ownership verification, multi-level testing from basic to enterprise-level, and detailed reports with risk levels and recommended fixes.
Career Path
Certifications & Training
CCNA
Cisco Certified Network Associate
Cisco Systems · 3 courses completed · Certified May 2025
Exploring the Role of the Metaverse in Achieving SDG 3: A Bibliometric Analysis of its Impact on Teacher Mental Pollution and Well-being
S. Alabidi, K. Alarabi, O. A. Khurma, A. Alarabi, R. Taani · EMCEI, Sfax, Tunisia, 2025
Work
Selected Projects
GNS3, Cisco Packet Tracer, and real-world lab projects covering routing, switching, security, VPN, wireless, and more.
Capstone · AI + Security
001
Conversational Firewall Management
LangGraph-orchestrated chatbot that translates plain-English commands into OPNsense REST API calls. 40+ integrated endpoints covering firewall rules, DHCP, IDS/IPS, diagnostics, and routing — deployed on a GNS3 multi-router OSPF topology.
LangGraphFastAPIOPNsenseGNS3
View project details + topology →
Security · SIEM
002
Enterprise SIEM & Attack Detection Lab
Production Splunk SIEM with SPL rules for brute-force, DoS, Metasploit RCE, and PowerShell obfuscation. Full SOC dashboards.
SplunkSysmonMetasploitPython
Coming Soon
Full write-up, topology diagram, and demo screenshots are being prepared and will be published shortly.
Network · Performance
003
HAProxy Load Balancing Evaluation
Controlled performance analysis of Round Robin, Least Connections, and Source-IP under baseline and degraded conditions.
HAProxyUbuntuGNS3ApacheBench
Coming Soon
GNS3 topology, benchmark results, and detailed analysis coming soon.
IoT · Protocol Research
004
IoT Protocol Analysis: MQTT vs CoAP
Experimental comparison under constrained IoT conditions. MQTT reliable but 10× latency spike; CoAP lower latency but ~12% packet drop.
PythonMQTTCoAPGNS3Azure VM
Coming Soon
Test environment setup, protocol capture analysis, and findings writeup in progress.
20+ lab projects — not all shown here, more coming soon
GNS3 and Cisco Packet Tracer topologies covering routing, switching, security, VPN, wireless, and more. Detailed project pages being added progressively.
Connect
Reach Out
Open to full-time roles, freelance security and networking projects, research collaborations, and consulting across network engineering, cloud infrastructure, and ITSM.
A three-tier conversational management system for OPNsense Next-Generation Firewall, built as a university capstone by a 5-person team. A LangGraph-orchestrated AI agent interprets plain-English commands and translates them into precise REST API calls across 40+ OPNsense endpoints — covering firewall rules, DHCP, IDS/IPS, diagnostics, and static routing. The frontend (ReactJS + TypeScript) features a real-time SSE dashboard, topology viewer, and dual-panel chat UI. Deployed and validated inside a GNS3 multi-router OSPF topology with Cloudflare Dynamic DNS for stable external access.
Dedicated apiclient service account with API key/secret — full audit trail
All endpoints validated via Postman before integration into the abstraction layer
Suricata IDS/IPS with ET Open ruleset; alert querying via /api/ids/service/query_alerts
Key Design Decisions
Why LangGraph?
LangGraph's state machine paradigm was chosen to handle multi-step, cyclical reasoning: the Agent Node decides, a Conditional Router checks for tool calls, the Tool Node executes, a Tool Logging Node persists to PostgreSQL, then control loops back to the Agent to process results. This agentic loop handles complex chained commands that a simple prompt pipeline cannot.
Why OSPF?
OSPF was chosen over static routing so the firewall could dynamically learn all subnets. OPNsense participates in OSPF Area 0 via the FRR plugin, advertising its LAN/WAN prefixes and receiving routes from R1–R5. This means adding a new subnet only requires a router config change — the firewall adapts automatically within seconds of LSA flood convergence.
Why SSE?
WebSocket required a persistent bidirectional channel which added complexity for a read-heavy alert feed. SSE (Server-Sent Events) gave us a simple one-way push stream over plain HTTP — compatible with standard browsers, automatically reconnecting, and trivial to implement in FastAPI with EventSourceResponse. A periodic polling fallback handles SSE reconnection failures gracefully.
Why PostgreSQL?
PostgreSQL was selected for its mature relational model, seamless Python integration via psycopg2, and ability to store both application state (users, tokens, messages, tool_usages) and LangGraph checkpoints (checkpoint_writes, checkpoint_blobs tables) in the same database. LangGraph's PostgreSQL checkpointer provides persistent conversation state across sessions without any external cache layer.
Firewall-first
All traffic — including API calls from the management PC — passes through OPNsense before reaching any internal host. The firewall validates source IPs, applies stateful inspection, and runs Suricata signatures on every flow. Even if the API backend is compromised, no lateral movement is possible without the firewall permitting it.
Team Members
Aktham Al-Arabi
Network & Firewall Architect
Designed the full GNS3 multi-router OSPF topology and owned all OPNsense NGFW configuration — interface zones, NAT policies, IDS/IPS tuning, and the complete REST API surface mapping across 40+ endpoints validated via Postman.
Built the FastAPI service layer — async endpoints, the OPNsense abstraction client (httpx-based), Python scripting for all 40+ tool functions, and the middleware pipeline connecting the LangGraph agent output to live firewall commands.
Engineered the ReactJS + TypeScript SPA from the ground up — dual-panel chat interface with SSE streaming, the real-time CPU/memory/traffic monitoring dashboard, GNS3 topology iframe embed, and the dynamic LLM model switcher component.
Owned the authentication flow UI, collapsible sidebar navigation, and the role-based access control front-end enforcement. Also built the reports and documentation portal, ensuring SOC Analyst and Administrator views render the correct restricted controls.
— Animated dashes show live traffic flow direction
Subnet Map
10.0.0.0/24 — OPNsense WAN (em2), OSPF adjacency link to R1
192.168.1.0/24 — OPNsense LAN (em0, .250), egress / management network
192.168.2.0/24 — OPNsense OPT1 (em1, .1), Kea DHCP client zone
192.168.3.0/24 — Attacker segment (Linux VM 3 / Kali), routed via R5
Transit subnets (R1–R5) — Seven /24 OSPF backbone links forming the multi-router mesh; all participate in Area 0 and exchange LSAs to build full reachability
Security Zones & Key Devices
OPT1 Trust Zone — Terminals 1–3 and Linux VMs 1–2 receive addresses from Kea DHCP pool (.50–.200); all traffic inspected by Suricata
LAN Egress — 192.168.1.250 is the single NAT masquerade exit point; also hosts the Web Server VM (accessible externally via Cloudflare DDNS)
Attacker Zone — Linux VM 3 (Kali, 192.168.3.x) routed through R5 → R4; blocked by OPNsense default-deny WAN policy with Suricata alerts
ISP / Internet — Simulated cloud/ISP node connects the topology to the external access path
All inter-zone flows enforced by OPNsense; Suricata monitors WAN + OPT1 interfaces
Traffic Flow Analysis
01
PC2 sends a packet — e.g. HTTP GET to 55.55.55.10. The frame hits SW1 which does a MAC lookup and forwards it out the uplink toward OPNsense's LAN interface (192.168.2.1).
02
OPNsense stateful inspection — The firewall checks its ruleset. LAN → WAN HTTP is permitted by default policy. It creates a state table entry, applies NAT if needed, and passes the packet out the WAN interface toward R1.
03
R1 OSPF lookup — R1 has an OSPF-learned route to 55.55.55.0/24 via R2 (next-hop learned during OSPF adjacency). It forwards the packet toward R2 across the 12.0.0.0/24 transit link.
04
R2 delivers to LinuxA — R2 has LinuxA directly connected on 55.55.55.0/24 (e0 interface). The packet is ARP-resolved and delivered. Return traffic takes the symmetric path — R2 → R1 → OPNsense → SW1 → PC2, with OPNsense matching the existing state entry to allow the reply.
01
Admin opens the dashboard from PC on the LAN (192.168.2.x). The browser sends an HTTPS request to the FastAPI backend on port 8000. OPNsense has an explicit allow rule: source 192.168.2.0/24, destination FastAPI host, port 8000.
02
FastAPI validates JWT — The server checks the Bearer token, extracts the role claim, and determines whether the requested action is within the user's RBAC permissions. An Operator cannot write rules; an Admin can.
03
FastAPI calls OPNsense REST API — The backend makes a server-side HTTPS call to OPNsense's management API (127.0.0.1:443 from OPNsense's perspective, or internal LAN IP). The API accepts only pre-authorized API keys. The translated firewall rule is submitted as a JSON payload.
04
Rule applied + SSE streamed back — OPNsense applies the rule and returns a 200. FastAPI writes the action to the audit log, then pushes a confirmation event over the SSE channel. The admin's browser receives it in real time — no polling required.
Hello
OPNsense joins OSPF Area 0 — The firewall is configured with router ospf and advertises its LAN (192.168.2.0/24) and WAN (192.168.1.0/24) subnets. It sends multicast Hello packets (224.0.0.5) every 10 seconds to R1 across the 10.0.0.0/24 link.
DBD
Database exchange — After neighbors form a 2-Way adjacency, they exchange Database Description (DBD) packets listing their LSDB contents. OPNsense and R1 compare DBDs and request any missing LSAs.
LSA flood
LSA propagation — Each router floods its Router LSA to all neighbors. Within seconds, every router in Area 0 (R1–R5 and OPNsense) has an identical LSDB and runs SPF to compute the shortest path to every subnet — including OPNsense's LAN and all transit links.
Result
Full reachability — Any host behind SW1 can reach any host behind SW2 via dynamically computed OSPF paths. OPNsense enforces policies on all inter-zone flows. No static routes required anywhere — adding a new subnet auto-propagates to all routers within seconds.
Attempt
Kali (192.168.3.x) tries to SSH into R1 or a LAN host. The packet is routed normally by R5 → R4 and arrives at OPNsense's WAN interface. This is expected — routing works fine.
Rule check
OPNsense evaluates its ruleset top-down. The WAN interface has a default-deny policy. There is no rule permitting SSH (port 22) from 192.168.3.0/24 to any LAN host. The packet matches the implicit deny-all rule at the bottom.
Suricata
Suricata IDS fires a signature match — repeated TCP SYN to port 22 from an external source triggers the ET SCAN SSH BruteForce rule family. An alert is generated and queued to the SSE stream so the admin dashboard lights up in real time.
Block + RST
OPNsense drops the packet and sends a TCP RST to Kali. The internal LAN hosts are completely shielded — they never see the connection attempt. The FastAPI audit log records the block event with source IP, destination, port, timestamp, and the matching rule name.
Full Technology Stack
Network Infrastructure
GNS3
Network emulation platform. Runs Cisco IOS images and Linux VMs in a single unified topology.
OPNsense
FreeBSD-based NGFW. Stateful packet filtering, Hybrid Outbound NAT, OSPF via FRR plugin, REST API management (apiclient account).
Core
Suricata IDS/IPS
Inline IDS engine on OPNsense. ET Open community ruleset; alert querying, policy toggling, and ruleset updates all chatbot-accessible.
Cisco IOS (R1–R5)
5 routers running OSPF Area 0. Seven /24 transit subnets; provide full reachability between all segments including OPNsense zones.
OSPF (FRR plugin)
OPNsense participates via FRRouting daemon. LAN/OPT1 passive interfaces; NVRAM persistence; adjacency with R1 verified via show ip ospf.
Firewall Zones
LAN (192.168.2.0/24), WAN (10.0.0.0/24), OPT1 — separate security zones enforced by OPNsense interface rules.
Cloudflare DDNS
Custom Python script + NSSM Windows service keeps jrx7.com A record updated. ui.jrx7.com points to the React UI server.
Destination NAT
Port forwarding on edge device tunnels HTTPS (TCP/443) inbound traffic to OPNsense LAN interface for external API access.
Kea DHCP
OPNsense Kea DHCPv4 service on OPT1 (192.168.2.50–200). Pool, reservations, and subnets all manageable via chatbot.
Backend architecture, LangGraph agent orchestration, LLM tool-binding and model routing, FastAPI async service design, chatbot integration, and PostgreSQL checkpointing.