One Bad Pixel
Soylent Green is people!
«
»

Part 6: Vyatta Firewall Groups

If you have been following along with my series of Vyatta articles, you probably have a pretty decent set of firewalls built to support a couple web servers at this point. In Part 4, we setup a bunch of firewall rules, but since we will likely be adding a lot over time, it can become quite a job to manage them all.

In this article, I will be introducing you to firewall groups to make management tasks less of a burden to keep updated. Based on the state of our system at the end of Part 5, we have an internal DNS server and 2 WEB servers. The DNS server accepts incoming tcp and udp connections on port 53, and the WEB servers accept incoming tcp traffic on ports 80 and 443, as well as RDP (tcp port 3389) from certain locations.

Using groups, we can make some logical groupings of hosts, ports, and networks to reduce the number of firewall rules required to keep it all functioning. Lets start by creating a few groups, then we can go modify our firewalls to use the new groups.

Lets start by creating a group for our internal hosts that accept RDP. The groups can be named anything, but I found from experience it helps to name them in a way that you can remember what type of group they are, what interface they apply to, and what their purpose is.


#make a description for the group
set firewall group address-group AG-LAN-RDPHOSTS description "LAN Hosts that accept RDP"
#then add our webservers to the group
set firewall group address-group AG-LAN-RDPHOSTS address 172.16.0.10
set firewall group address-group AG-LAN-RDPHOSTS address 172.16.0.11

#lets make another for servers that accept web (HTTP, HTTPS) traffic
set firewall group address-group AG-LAN-WEBHOSTS description "LAN Hosts that accept HTTP/HTTPS"
set firewall group address-group AG-LAN-WEBHOSTS address 172.16.0.10
set firewall group address-group AG-LAN-WEBHOSTS address 172.16.0.11
commit
save

That wasn’t so hard now, was it? Lets create a few more groups. They should be pretty self explanatory what they are for.


#a group for our RDP and remote access ports, maybe we add VNC here also
set firewall group port-group PG-TCP-RDPPORTS description "TCP Ports for RDP Access"
set firewall group port-group PG-TCP-RDPPORTS port 3389

#and another group for our webserver ports
set firewall group port-group PG-TCP-WEBPORTS description "TCP Ports for WEB Access"
set firewall group port-group PG-TCP-WEBPORTS port 80
set firewall group port-group PG-TCP-WEBPORTS port 443
commit
save

Remember our rule (111 & 121) to allow RDP access that was restricted to only our remote office at 5.6.7.0/24? What if we had another remote office at 6.7.8.0/24 that also needed to be able to connect. Rather than creating a firewall rule for each one, we can create a group and combine both those rules into one. First, let’s make a network group.


set firewall group network-group NG-WAN-RDPNETWORKS description "WAN Networks allowed to connect to RDP"
set firewall group network-group NG-WAN-RDPNETWORKS network 5.6.7.0/24
set firewall group network-group NG-WAN-RDPNETWORKS network 6.7.8.0/24
commit
save

“But wait,” you say, “What do these groups do now?” Great question, now, we can fix up our firewall rules to use these new groups. Lets start by removing the extra firewall rules we created in Part 5, rules 120 and 121, then, we can modify rules 110 and 111 to meet the needs of our groups.


delete firewall name TO-LAN-IPV4 rule 120
delete firewall name TO-LAN-IPV4 rule 121

#now, lets modify rule 110 to use a group for the hosts and a group for the ports
delete firewall name TO-LAN-IPV4 rule 110 destination address
delete firewall name TO-LAN-IPV4 rule 110 destination port
set firewall name TO-LAN-IPV4 rule 110 destination group address-group AG-LAN-WEBHOSTS
set firewall name TO-LAN-IPV4 rule 110 destination group port-group PG-TCP-WEBPORTS
commit
save

#lets fix up our RDP rule the same way
delete firewall name TO-LAN-IPV4 rule 111 destination address
delete firewall name TO-LAN-IPV4 rule 111 destination port
delete firewall name TO-LAN-IPV4 rule 111 source address
set firewall name TO-LAN-IPV4 rule 111 destination group address-group AG-LAN-RDPHOSTS
set firewall name TO-LAN-IPV4 rule 111 destination group port-group PG-TCP-RDPPORTS
set firewall name TO-LAN-IPV4 rule 111 source group network-group NG-WAN-RDPNETWORKS
commit
save

Now that we have the hang of this, lets create one last group to secure SSH access to our router, then modify rule 30 on the TO-ROUTER-IPV4 firewall to use the new group.


set firewall group address-group AG-WAN-ROUTERSSH description "WAN Hosts allowed to manage router via SSH"
set firewall group address-group AG-WAN-ROUTERSSH address 8.8.8.8

delete firewall name TO-ROUTER-IPV4 rule 30 source address
set firewall name TO-ROUTER-IPV4 rule 30 source group address-group AG-WAN-ROUTERSSH
commit
save

That’s all there is to it! If you want to see your current firewall setup, from config mode, issue the command “show firewall”. If you want to see your entire config, use “show”. You can show any part you want, the same way we set things.. Such as “show firewall name TO-LAN-IPV4 rule 110” will show you only that part.

Let’s make another group and a firewall rule to create a “blacklist” of addresses that you never want connecting to your LAN or Router.. This is useful if you have some troublesome hosts out there attacking your system.


set firewall group network-group NG-BLACKLISTNETS description "Networks blacklisted from any inbound connections"
#set firewall group network-group NG-BLACKLISTNETS network x.x.x.x/x
#to router
set firewall name TO-ROUTER-IPV4 rule 5 description "Blacklisted IPs, known hacking attempts"
set firewall name TO-ROUTER-IPV4 rule 5 action drop
set firewall name TO-ROUTER-IPV4 rule 5 source group network-group NG-BLACKLISTNETS
#to lan
set firewall name TO-LAN-IPV4 rule 5 description "Blacklisted IPs, known hacking attempts"
set firewall name TO-LAN-IPV4 rule 5 action drop
set firewall name TO-LAN-IPV4 rule 5 source group network-group NG-BLACKLISTNETS
commit
save


I find that this is normally a good idea, even if you don't immediately populate the blacklist group. Later, when we want to add a host to the blacklist, all we need to do is issue the following commands:


#replace x.x.x.x/x with the network/cidr of the offending host
#used to be able to set /32 here, but as of 6.6R1, can only make /30 as the smallest.
#if you need individual hosts, you need to add an address group and another rule
set firewall group network-group NG-BLACKLISTNETS network x.x.x.x/x
commit
save

While you are configuring, but before you have committed your changes, if you issue a show command, you will see that items to be added when you commit have "+" at the beginning of the line. Items to be removed will have "-" at the beginning of the line, and items that are going to change have ">" at the beginning of the line.

Next: Part 7: IPv6 enabling your Vyatta router (using a TunnelBroker)

 

5 Responses for “Part 6: Vyatta Firewall Groups”

  1. Part 5: NAT Translation in Vyatta | One Bad Pixel Says:

    […] Part 6: Vyatta Firewall Groups | One Bad Pixel on Part 4: Adding Stateful Firewall to Vyatta […]

  2. Jim Says:

    Found this site with related information http://www.fir3net.com/Vyatta/vyatta-how-to-configure-a-policy-based-vpn.html

  3. Part 7: IPv6 enabling your Vyatta router (using a TunnelBroker) | One Bad Pixel Says:

    […] Jim on Part 6: Vyatta Firewall Groups […]

  4. Kendra Says:

    The contents you mentioned in post is too good and can be very useful.

  5. max Says:

    Hey, this is great information you have posted! I’ve been trying to create a Cronjob based method of implementing blacklists, though it appears to be more complex then I first imagined it would be. if you’re interested try looking at: http://forum.vyos.net/showthread.php?tid=9811

Leave a comment!