Objectives
The simulator ticks each one as soon as the network meets it.
Vulnerability profile STRICT: action block, minimum severity high. Attach it to rule PUB-WEB.
URL filtering profile NO-SOCIAL: block social. Attach it to rule OUT.
Commit. From LAP1: traffic tcp 203.0.113.10 80 payload "GET /../../etc/passwd" is now blocked, and the normal request still arrives.
From PC1: traffic tcp 198.51.100.1 80 payload "GET / Host: facebook.com" is blocked, and www.example.org arrives. The Threat Log has both.
Before you start
Alert only logs, so you can see what a profile would catch before you block it. A profile on a deny rule would do nothing, because the traffic is already gone. show threats and show url-categories list what this model knows: RouteBuddy’s own short teaching lists. The profile lines are shortened too: a real URL Filtering profile sets an action per category, and a real Vulnerability Protection profile holds rules per severity.
Concept
Profiles read what an allow rule lets through
A rule allowing web browsing allows an attack inside web browsing, and any site. A security profile reads the traffic of an allow rule. A vulnerability profile looks for known attacks, and a URL filtering profile looks at where a request is going. A profile does nothing until a rule uses it.
Concept
A rule can name an application, not a port
App-ID reads a packet to name its application, so a rule can allow web browsing rather than port 80. Service application-default adds a second check: the application must be on its usual port. Service any drops that check.
