ADMINISTRATION HANDS-ON

1. ADMINISTRATION HANDS-ON

2. About the Hands-On • This hands-on section is structured in a way, that it allows you to work independently, but still giving you the possibility to consult step-by-step instructions. • Each given task will be divided into two sections • Actual Task • Conditions, goals and short instructions • Allowing you to work independently • Detailed instructions (step-by-step walk through) • In case you can not come up with own solutions

3. Root Update Server F-SecureAVCS 6 F-SecurePMS / PMC Real Infrastructure • Environment • Policy Manager and Console on single computer • One managed host (AVCS 6)

4. dnssrv01 filesrv01 PMS/PMC wks03 wks04 dnssrv02 filesrv02 wksXX wks02 AVCS 6 Subsidiary Munich Headquarters Helsinki Imaginary Infrastructure • During this hands-on we will create an imaginary infrastructure • 2 offices (Helsinki and Munich) • 3 imaginary workstations (Helsinki: wks02 / Munich: wks03 and wks04) • 1 real workstation in Helsinki (wks01) • 1 file server in each office (Helsinki: filesrv01 / Munich: filesrv02) • 1 DNS server in each office (Helsinki: dnssrv01 / Munich: dnssrv02)

5. Task Overview • Task 1: Create a new security level • Task 2: Testing dynamic rules • Task 3: Managing Application Control • Task 4: Testing Network Quarantine

6. Task 1: Create your own Security Level • Create a new security level with the name ”CustomTest” • Activate it on sub-domain level ”Development/HEL” • Configure the ruleset described below • Allow rules • 1st Rule: Web access (HTTP and DNS over UDP, to all hosts) • 2nd Rule: Pingoutbound (to all hosts) • Deny rules • 3rd Rule: Pinginbound (from all hosts, with alerting, type: security alert) • 4rd Rule: Catch rule (deny all bi-directional, from/to all hosts) => Task continues on next page

7. Task 1: Create your own Security Level • Test your rules • Check the DNS resolution (use nslookup) • Define application control access types for prompted applications • Make sure the same application are not prompted at next launch! • Open Internet Explorer. Does the web access work? • Apply same access types as above • Check your rules with the local web interface (http://localhost:58581) • Ping your host from the console. Does the ping work? • Also monitor your policy domain (both console and host). Anything unusual? => After you finished the testing, and everything works, continue on page 28

8. Creating a new Security LevelWalk Through • Creating a new security level • Open Firewall Security Settings • Click ”Add” (name it ”Custom Test”)

9. Creating a new Security LevelWalk Through • Make ”CustomTest” the active level for the ”Development/HEL” sub-domain • Lock the setting

10. Creating a new Security LevelWalk Through • Create the first new rule • Select the policy root domain (F-Secure) • Open Firewall Rules, there are no rules in the new rule set • Create a rule

11. Creating a new Security LevelWalk Through • The first rule will be an allow rule

12. Creating a new Security LevelWalk Through • The rule will be applied to connections created to any remote host

13. Creating a new Security LevelWalk Through • Specify outbound DNS and HTTP • Use the predefined “HTTP” and “DNS” service (DNS over UDP!)

14. Creating a new Security LevelWalk Through • No flags or alerts needed for this rule • Click “Next” • Name the rule “Web Access” and click “Finish”

15. Creating a new Security LevelWalk Through • Create a catch rule as the last security level rule (on root level!) • Deny all traffic in both directions (inbound and outbound) • Distribute policies

16. Creating a new Security LevelWalk Through • Check that the policy has arrived on your host • Active security level should be ”CustomTest” and it should be locked

17. Creating a new Security LevelWalk Through • Check that DNS works • Open command prompt nslookup www.f-secure.com

18. Creating a new Security LevelWalk Through • You are running nslookup for the first time. Application Control has intercepted the server listen connection (UDP) • Choose “Do not show this dialogue for this program again” and click “Allow”

19. Creating a new Security LevelWalk Through • Open the web interface • Open Internet Explorer (allow the outbound connection) • WebUI URL: http://127.0.0.1:58581/

20. Creating a new Security LevelWalk Through • Use the web interface to check the rules you created with the PMC

21. Creating a new Security LevelWalk Through • Ping test • First try to ping your PMC computer from the your managed host and then the other way around • Neither ping should work, as your current rules do not allow this

22. Creating a new Security LevelWalk Through • Create a rule allowing outbound ping • Apply the rule to the sub-domain “Finland” • Use the pre-configured service “Ping” • No alerting needed (accept default) • Name the rule “Ping outbound”

23. Creating a new Security LevelWalk Through • Create a rule denying inbound ping • Apply the rule to the sub-domain “Finland” • Use the pre-configured service “Ping” • Activate alerting • Alert type: “Security Alert” • Alert trap: “Network Event: Inbound Service Denied” • Name the rule “Ping inbound”

24. Creating a new Security LevelWalk Through • Check the new rules • Select the sub-domain “Finland” • “Web Access” and “Deny rest” rule should be grayed out (inherited from the root domain!) • Distribute policies

25. Creating a new Security LevelWalk Through • Ping your host from the Policy Manager computer • Ping still shouldn’t go through

26. Creating a new Security LevelWalk Through • The echo request has created a security alert • Check alerts from Policy Manger Console

27. Creating a new Security LevelWalk Through • A pop-up alert should be visible on the workstation • Click “Show All” for an alert summary

28. Creating a new Security LevelTask Summary • You have now created your own security level, and added firewall rules which allow the host to • Connect to the internet (using HTTP only) • Resolve DNS names (using DNS over UDP) • Generate outbound ping requests

29. Task 2: Testing Dynamic Rules • Understanding dynamic application control rules is very important • Dynamic rules are located before the last catch rule (deny all rule) • Remember that rules are read top to bottom • Static firewall rules are applied first • If there is no static rule match, the traffic might be allowed by one of the dynamic rules (e.g. inbound SMB, TCP 445) • Remember, that even though you have a bi-directional deny rule as a last rule, dynamic rules might allow traffic, before the deny rule can take effect! => Task continues on next page

30. Task 2: Testing Dynamic Rules • A good example to show the function of dynamic rules is, to enable remote access to the host’s local web interface • Change the current policy in a way, that remote connections from both local host and remote hosts are accepted • No static firewall rule is needed • Search the policy setting in the MIB tree (Advanced Mode) ? => Task continues on next page

31. Task 2: Testing Dynamic Rules • As next step, allow connections to the local host’s web interface only from the Policy Manager Console • Change the current ruleset so, that unauthorized hosts connecting to the web interface generate a security alert • Distribute policies • Try to connect to your host’s web interface (from the console) • The connection should work! • Now, ask your neighbour to establish a connection to your host • The connection should be refused! • You should get a security alert, both on your host and on the console => After you finished the whole task, continue on page 46

32. Testing Dynamic RulesWalk Through • Activate remote access to the local web user interface • Setting only available in Advanced more (View/Advanced Mode) • F-Secure Internet Shield/Settings/Firewall Service/HTTP • Mode = For Both Local and Remote Hosts • Distribute policies!

33. Testing Dynamic RulesWalk Through • Connect to your client’s local web interface (from the console) • Open Internet Explorer, http://<wks ip address>:58581/

34. Testing Dynamic RulesWalk Through • Create a new service • Open Firewall Services and click “Add”

35. Testing Dynamic RulesWalk Through • Name the service “HTTP58581” • Use a comment field for a short description

36. Testing Dynamic RulesWalk Through • Set the IP-Protocol as TCP

37. Testing Dynamic RulesWalk Through • Set the Initiator Ports as >1023

38. Testing Dynamic RulesWalk Through • Set the Responder Port as 58581

39. Testing Dynamic RulesWalk Through • Set the classification number • Choose “Other well-known TCP services (6000)”

40. Testing Dynamic RulesWalk Through • No need to enable extra filtering

41. Testing Dynamic RulesWalk Through • Review the service summary • Click “Finish”

42. Testing Dynamic RulesWalk Through • Create a rule, using the created service (HTTP58581) • Select sub-domain “Development/HEL” • Define an inbound rule, allowing web interface remote access only from the console.

43. Testing Dynamic RulesWalk Through • Create a second rule, using the same service • Select sub-domain “Development/HEL” • Define an inbound deny rule, restricting connections to the local web interface from all remote hosts • Enable alerting (type: security alert) • Name the rule “Restrict access to WebUI (inbound)” • Important: This rule has to be placed after the rule created on the previous page!

44. Testing Dynamic RulesWalk Through • Open Internet Explorer on your console • Connect to http://<wks ip address>:58581/ • Why does it work? • Ask your neighbour to establish a connection to the host’s web interface • Monitor the console and host alerts • Anything unusual? • Disable the “Restrict access to WebUI (inbound)” rule (distribute policies) • Ask your neighbour to connect again. Why does it work now?

45. Testing Dynamic RulesWalk Through • Static rules are enabled, only connections from the console are allowed. Why? • Static rules are applied before dynamic rules • The 3rd static rule blocks all remote web interface connections from hosts other than the console • With disabled static rules, the connection works from everywhere! Why? • The firewall daemon (fsdfwd.exe) is listening by default to port 58581 1 2

46. Task 3: Managing Application Control • Goal: Configure a safe Application Control environment • Select sub-domain ”Development/HEL” • Create rules for the following applications • Internet Explorer (allow establishing of outbound connections only!) • Nslookup (allow inbound connection listen only!) • Restrict all new (unknown) applications from establishing connections • Both client and server applications • Create a custom message, applied when unknown applications try to establish connections. => After you completed this task, continue on page 54

47. Managing Application ControlWalk Through • Create an Application Control list • Select the root policy domain (F-Secure) • Start your list with the Internet Explorer (IEXPLORE.EXE) • Click “Create Rule(s)”

48. Managing Application ControlWalk Through • Choose the application control rule type • Allow IEXPLORE.EXE acting as client (outbound) • Deny IEXPLORE.EXE acting as server (inbound)

49. Managing Application ControlWalk Through • Choose “No message” • Click “Next”

50. Managing Application ControlWalk Through • Apply this rule to the whole policy domain • Choose “F-Secure” and click “Finish”