Lab 4.1 Network Firewalls 1 - AinsleyPlayer/SEC-350 GitHub Wiki
In this lab we are going to shut down and then manage traffic between the LAN, DMZ,WAN and MGMT Networks.
The initial configuration of fw01 will be illustrated in detail, but you will need to use that information to configure fw-mgmt.
Prerequisites
Make sure you can do the following before progressing in the lab (this step is extremely important for the success of your lab). rw01 can ping web01 via its static route, rw01 can browse to web01 wks01 can browse web01 wks01 can browse wazuh web01 can ping wazuh
Task 1: Configuring fw01
Create and link firewall zones to interfaces (eth0, eth1, eth2)
set zone-policy zone WAN interface eth0
set zone-policy zone DMZ interface eth1
set zone-policy zone LAN interface eth2
commit
save
Creating default drop and log rules across fw01
Step 1: WAN and DMZ firewalls
Observe and repeat the following commands. In the illustration below, we have created firewalls for WAN to DMZ and DMZ to WAN, we are going to lock them down with a default drop directive, and we will log violations of the firewall rules. We have also assigned firewalls to the respective direction of communication between zones.
Firewalls for WAN and DMZ
set firewall name WAN-to-DMZ default-action drop
set firewall name DMZ-to-WAN default-action drop
set firewall name WAN-to-DMZ enable-default-log
set firewall name DMZ-to-WAN enable-default-log
Assigning Firewalls to Zones
set zone-policy zone WAN from DMZ firewall name DMZ-to-WAN
set zone-policy zone DMZ from WAN firewall name WAN-to-DMZ
commit
save
Attempt to connect to web01 via rw01, it should fail
On fw01, monitor your firewall logs with the following command: tail -f /var/log/messages | grep WAN
Try your failed connection test again, You should observe a failed message
Deliverable 1:
Provide a screenshot showing a [WAN-TO-DMZ-default-D] log entry similar to the one above.
Step 2: Allow http inbound
Allow http traffic from the WAN to the DMZ based web01 using the following syntax, remember you use your IP address for web01.
Using what you know about VyOS Syntax, figure out how to append rule 10 to the WAN-to-DMZ firewall
Try to connect via http, the connection should still fail.
This time the failure is due to another firewall. The communication was stopped on the way back out, not on the way in. We need to explicitly tell the DMZ-TO-WAN firewall to allow established connections initiated from the WAN back out again. The following log shows the DMZ-TO-WAN default drop at work here.
The rule is DMZ-to-WAN or outbound traffic from the DMZ back to rw01 The source ip is web01 The source port is port 80/tcp (the web server response to the wget from rw01)
Step 3: Allowing established connections back out again.
The following screenshot shows an updated DMZ-to-WAN firewall rule that will allow connections that were let in the door, back out again.
We will reserve rule 1 for two conditions. The first is to allow established connections back out again, the second would be to have an open rule where all connections are allowed. Typically this would be the only rule in such a firewall.
Deliverable 2:
Take a screenshot similar to the one below that shows a failed wget or curl (1) followed by a successful connection to your web server. Make sure you've deleted the default welcome.conf file, you've restarted httpd and have added a simple index.html banner as shown in (2).
Step 4: DMZ and LAN Traffic Firewalls
We are going to continue our firewalling by creating default firewalls for LAN and DMZ and link them to zone policies. The completed DMZ and LAN zones should look like this. Firewalls
Zones
Whenever you set something you should commit it. If you want that setting to survive a reboot, you better save it too.
Step 5: Wassup with Wazuh?
Right now we have firewalls whose only rules are to drop everything (except port 80 to web01 from the WAN). We are now going to use debugging techniques shown earlier to find out why our wazuh traffic doesn’t work between DMZ and LAN (actually MGMT, but fw01 does not know about the MGMT network, just the LAN).
The Wazuh server expects clients to connect to it via tcp/1514 and tcp/1515, this is a good connection to start with. We will examine or logs to see if there are any drop messages for these ports.
DMZ-to-LAN
Step 6: Allow Wazuh agent communications
Deliverable 3:
Provide a screenshot similar to the one above of /var/log/messages on fw01 that shows a drop message like the one below, make sure you select the message that indicated PROTO=TCP and DPT=1514 or 1515
Step 7: Allowing established wazuh traffic back
Try finding LAN-to-DMZ traffic that has been dropped that has a SPT=1514,1515. This is a tcp connection, so we need to allow established back through the related firewall (LAN-to-DMZ)
Deliverable 4.
Provide a screenshot of your new LAN-to-DMZ rule 1 that allows established connections back through the LAN-to-DMZ firewall.
Step 8: Configure LAN-TO-WAN Firewall
We are receiving complaints from our Burlington-based employees because they cannot surf the internet or listen to Spotify. It is also likely that CRD is no longer working. We need to allow clients to initiate any connections to the WAN. This one requirement can be the Achilles Heel of network security. Clients in this zone typically need to initiate connections in a very permissive manner to do their jobs. We may need to look at supplementary host based controls and restrictive web proxies later.
Create a default LAN to WAN firewall and associate it with the appropriate zone policy. This firewall will have only one rule allowing LAN clients to initiate WAN connections.
The completed LAN-TO-WAN firewall looks like:
Step 9: Configure WAN-TO-LAN Firewall
Create the WAN-TO-LAN firewall, link it to the appropriate zones and allow established connections back from WAN to LAN
Deliverable 5:
Submit a screenshot showing a LAN-TO-WAN browsing session between wks01 and champlain.edu
Step 10: Configure LAN to DMZ Firewall
As communication between LAN and DMZ is currently broken, we need to create a firewall, assign to the appropriate zone policy and adjust it to only allow the traffic we want to go through. We want wks01 to be able to browse to web01 and we want mgmt01 to ssh into anything on the DMZ.
With that in mind, create firewall rules on LAN-TO-DMZ that allows 80/tcp from LAN to web01. 22/tcp from mgmt01 to the DMZ
Step 11: DMZ to LAN Firewall
Make sure to allow established traffic back through
Deliverable 6:
Screenshot showing web session between wks01 and web01.
Deliverable 7.
ssh into web01 from using the username testwazuhafterfirewall. Attempt this until the session is closed by web01. Provide a screenshot similar to the one below that shows a related security event in wazuh, after fw1 was configured.
Task 2: Configuring fw-mgmt
Now that you have the basics of zone and firewall configuration under your belt, you are going to use the techniques shown above in configuration of fw-mgmt. Create LAN and MGMT zones on fw-mgmt Create both zones and assign the correct interfaces and firewalls.
LAN-to-MGMT
Create a LAN-to-MGMT firewall that: Allows 1514,1515/tcp from LAN to wazuh Allows 443/tcp from mgmt01 on LAN to wazuh Allows 22/tcp from mgmt01 on LAN to wazuh Allows established traffic back through the related firewall
MGMT-to-LAN
Create a MGMT-TO-LAN firewall that: Allows MGMT to initiate any connection to the LAN Allows MGMT to initiate any connection to the DMZ Allows established traffic back again If you do this right, you should be able to connect from mgmt02 to the DMZ like so. wget to web01 ping to mgmt01 ping outside will fail because you didn't explicitly allow MGMT to go anywhere but LAN and DMZ.
Deliverable 8.
Provide a screenshot similar to the one below
Deliverable 9.
Provide the output of: show zone on fw-mgmt
Deliverable 10.
Provide the output of: show firewall name LAN-TO-MGMT
Deliverable 11.
Provide the output of: show firewall name MGMT-TO-LAN
Deliverable 12.
From mgmt01, Run an ssh test on web01 with a tag that indicates that this is a test of fw-mgmt. Take a screenshot of the resulting log within wazuh.