One Bad Pixel
All your pixel are belong to us.
«
»

Part 4: Adding Stateful Firewall to Vyatta

Previous: Part 3: Vyatta Basuc Setup.

If you have been following along with the previous parts, you probably have a functional lab router (or possibly a home network of some type) up and running, but you likely are hoping to add some firewall rules to help protect your network. It is important to note that firewall rules are applied in sequential order until a match is made, at which point the action is applied and further rules are not processed. This is important as the majority of your rule issues are likely to be the result of improper sequencing.

The firewall rules are extremely powerful, however can be a source of frustration if certain care isn’t made to keep them organized. In this part, I will only cover IPv4 rules. IPv6 rules are nearly the same, with a couple very minor syntax differences. In a later part, we will setup an IPv6 tunnel to HE.net and get you your own IPv6 address space. Without spending too much time discussing, let’s get right to it.

Firewalls are applied multiple ways, depending on what we are trying to do. The basic types are “in”, “out”, and “local”. These refer to traffic going inbound through the router, outbound from the router, and locally to the router itself.

We need to choose names for our firewalls and assign them a default action. The default action determines what happens to traffic which does not match any rules. Most of the time, we want an implicit deny at the end, so we use a default-action of “drop”. If you were using this only to limit certain types of traffic, you could use a default action of “accept” and write rules to block specific traffic. In regards to naming, they can be anything, but I specifically pick names that are easy for me to remember what their purpose is, such as “TO-ROUTER-IPV4”, “TO-LAN-IPV4”, “TO-DMZ-IPV4”, “FROM-LAN-IPV4”, “FROM-DMZ-IPV4”, etc. IPv4 and IPv6 firewalls are applied seperately, so it is useful to label your firewalls accordingly.


set firewall name TO-LAN-IPV4 default-action drop
set firewall name TO-ROUTER-IPV4 default-action drop
#not using these
#set firewall name TO-DMZ-IPV4 default-action drop
#set firewall name FROM-LAN-IPV4 default-action drop
#set firewall name FROM-DMZ-IPV4 default-action drop
commit

Because we cant account for every piece of inbound traffic in our network, we need to make sure we allow traffic that is related to other things that are allows, and allow return traffic for established connections. We will put this rule at the beginning as most of our traffic will be of this type and should be allowed.


set firewall name TO-LAN-IPV4 default-action drop
set firewall name TO-LAN-IPV4 rule 10 action accept
set firewall name TO-LAN-IPV4 rule 10 description "Allow established and related"
set firewall name TO-LAN-IPV4 rule 10 log disable
set firewall name TO-LAN-IPV4 rule 10 state established enable
set firewall name TO-LAN-IPV4 rule 10 state related enable
commit
#do the same for the TO-ROUTER firewall
set firewall name TO-ROUTER-IPV4 default-action drop
set firewall name TO-ROUTER-IPV4 rule 10 action accept
set firewall name TO-ROUTER-IPV4 rule 10 description "Allow established and related traffic"
set firewall name TO-ROUTER-IPV4 rule 10 log disable
set firewall name TO-ROUTER-IPV4 rule 10 state established enable
set firewall name TO-ROUTER-IPV4 rule 10 state related enable
commit
exit
save

Now that we have allowed the established traffic, we can start securing the router to only allow the proper management traffic.


set firewall name TO-ROUTER-IPV4 default-action drop
commit
#here you can see how we use context edit mode to save us a bunch of typing
edit firewall name TO-ROUTER-IPV4
#rule 20 allows icmp
set rule 20 action accept
set rule 20 description "Allow ICMP from anywhere"
set rule 20 protocol icmp
#rule 30 allows ssh
set rule 30 action accept
set rule 30 description "Allow SSH from 8.8.8.8" 
set rule 30 destination port 22
set rule 30 protocol tcp
#we could also specify a source address in CIDR format, like 8.8.8.0/24
set rule 30 source address 8.8.8.8
#rule 40 allows openvpn
set rule 40 action accept
set rule 40 description "Allow OpenVPN to connect to this router"
set rule 40 destination port 1194
set rule 40 protocol udp
exit
commit
save
#protocols could be icmp, tcp, udp, or tcp_udp (for both)

Now that we have allowed some specific traffic to the router, we also want to allow some specific traffic in to our LAN. I am not going to do a lot of rules here, just a single sample rule for a DNS server that we have inside our network and a rule for a WEB server. There is some specific considerations when writing firewall rules and how they interact with NAT translation. Its important to understand when the firewall rules are applied related to when NAT translations are applied. I will go more into this in a later part when we discuss NAT translation.


#here you can see how we use context edit mode to save us a bunch of typing
edit firewall name TO-LAN-IPV4
set rule 100 action accept
set rule 100 description "Allow DNS to internal DNS server"
#172.16.0.5 is our internal DNS server (even though we didnt set this up in part 3 on our DHCP pool)
set rule 100 destination address 172.16.0.5
#this rule is optional, since anywhere is the default, but if you wanted to limit to a specific source network, you could
set rule 100 source address 0.0.0.0/0
#dns uses UDP, but can use TCP occasionally so we need to allow both
set rule 100 protocol tcp_udp

#lets also make a rule for our webserver at 172.16.0.10
set rule 110 action accept
set rule 110 description "Allow HTTP/HTTPS to internal WEB server"
set rule 110 destination address 172.16.0.10
set rule 110 destination port 80,443
set rule 110 protocol tcp

#we want to allow RDP to our webserver but only from our office at 5.6.7.0/24
set rule 111 action accept
set rule 111 description "Allow RDP to internal WEB server from 5.6.7.0/24"
set rule 111 destination address 172.16.0.10
set rule 111 destination port 3389
set rule 111 protocol tcp
set rule 111 source address 5.6.7.0/24
exit
commit
save

Julien had asked about creating a firewall rule that drops by default and allows only specified traffic. This is pretty easy by using the default action of drop, just like the “TO-ROUTER-IPV4” firewall… We normally want to drop everything to the router except the stuff we specifically allowed, we typically do the same thing to the LAN as well. I have updated my examples to *hopefully* more clearly demonstrate this.

Last, we need to apply our firewalls to our interfaces. Don’t worry here, if you are connected to your router via SSH and you manage to kill your connection, a reboot will revert your changes to the last time you actually saved your config. (in which we have not yet applied the firewalls to the interfaces). I want to take a quick moment to bring up an important point about the differences between setting config, committing, and saving. If you are coming from a Juniper background, this concept is probably pretty familiar to you, but for those of you that are new or coming from a Cisco background, this might be a bit foreign.

In Vyatta, we write config by issuing either “set” or “delete” statements, however these do not affect what the router is doing currently. Once we decide that what we configured should be placed into action, we issue “commit”. This makes the configuration changes become active, unlike Cisco where the config is active as soon as you put it into config mode. This is important because it allows you do do things that are otherwise very difficult, such as changing an interface address and the default route at the same time (which you might want to do if you are remotely working via SSH on that interface). To make your changes permanent, you issue “save”, or if you want to undo your changes “discard”.


#for inbound firewalls, we apply them to the ingress interface of the router ususally
set interfaces ethernet eth0 firewall in name TO-LAN-IPV4
set interfaces ethernet eth0 firewall local name TO-ROUTER-IPV4
commit
#the following save is commented in case you are 
#cutting and pasting. We dont want to do this unintentionally
# in case you locked yourself out with your firewall
#save  

Next: Part 5: NAT translations

 

11 Responses for “Part 4: Adding Stateful Firewall to Vyatta”

  1. Part 3: Vyatta Basic Setup | One Bad Pixel Says:

    […] 6.5R1Part 1: Introducing Vyatta | One Bad Pixel on Part 2: Installing Vyatta Community 6.5R1Part 4: Adding Stateful Firewall to Vyatta | One Bad Pixel on Part 3: Vyatta Basic SetupJim on Part 3: Vyatta Basic SetupPeter on Part 3: Vyatta Basic Setup […]

  2. daytonachuff Says:

    Thanks for the great tutorial.

  3. Julien Says:

    thank you for this, however i didnt get about the Firewall thing set rules?
    set rule 20 destination address 172.16.0.5

    do i need to create a rule ? Nat or Firewall?

  4. Jim Says:

    Julien,
    Im not sure exactly what you are asking here, but I do see some of the confusion. It appears that rule 20 that I have at the end of my article is entirely un-explained as to why its there, and is actually in conflict with the rule 20 already created.

    I do need to come back and make the next article for NAT translations, which I will try to do this week.

    Cheers!

  5. Julien Says:

    Dear Jim,
    thank you so much for this,
    i need to know two things, i hope you can help me
    i need to deny every thing and allow just the open ports i specify on the firewall for the internet
    i want to create a rule to deny al the traffic, and i want to create a rules to allow like internet, rdp ect…
    can you give me a short brief how to do this?
    much appreciate it !

  6. Part 5: NAT Translation | One Bad Pixel Says:

    […] Router VM on ESXi 5.1 | Itamar on Part 1: Introducing VyattaDavid on DNSStuff alternativeJulien on Part 4: Adding Stateful Firewall to VyattaJim on Part 4: Adding Stateful Firewall to Vyatta Newest […]

  7. Part 6: Vyatta Firewall Groups | One Bad Pixel Says:

    […] Part 4: Adding Stateful Firewall to Vyatta | One Bad Pixel on Part 5: NAT Translation in Vyatta […]

  8. Jim Says:

    Make sure to look at Part 6 (Firewall Groups) for a great way to setup a blacklist firewall rule to disallow specific hosts from entering your network.

  9. domain Says:

    Nice response in return of this issue with real
    arguments and explaining all concerning that.

  10. Ler Says:

    Do you have a typo at the bottom of your article?

    #for inbound firewalls, we apply them to the ingress interface of the router ususally
    set interfaces ethernet eth0 firewall in name TO-LAN-IPV4
    set interfaces ethernet eth0 firewall local name TO-LAN-IPV4

    Shouldn’t the local scope get TO-ROUTER-IPV4 . ?

  11. Jim Says:

    Good catch! I fixed it in the article.

Leave a comment!