Make Basic firewalling as Factory Default

Hello,
Why can’t we make some basic firewall rules as Factory default instead of configuring it separately, example ssh limit rate, Respond to ping on Internet ports Disabled ,Block TCP/UDP flood (allows all invalid TCP packets to be dropped as protection from a SYN flood attack) ,or WAN by default is block incoming connections.so users are protected at bare minimum?

It is a bad idea
If I have only one interface WAN

1 Like

Hi,
I think this is not done because VyOS is a kind of all purpose solution. Rate limiting SSH might be a good idea if this is not already implemented. But not all deployments have a concept of a WAN interface. Moreover, only my home deployment has a WAN interface. None of my Company deployments have this.
I think it might even give some false sense of security since on some deployments eth0 might be the WANbut on other eth1 or eth0 and eth1 for failover… lots of possibilities.
Sander

1 Like

What can and should be done is to expand with examples in the blueprint section of the manual:

https://docs.vyos.io/en/latest/configexamples/index.html

3 Likes

I think the quick start should be the most secure example and with explanations.
Currently I feel like ipv6 is missing in it for 1.4 and can probably be improved further.

https://docs.vyos.io/en/latest/quick-start.html

2 Likes

I tried a few IPv6 related questions in this forum about a week ago but still no replies :frowning:

The problem with this is that nobody can predict what the use case of every install might be. What works for you might be a breaking change for another.

For example, you mention blocking ping. Having ping is a requirement in many of my deployments for some external monitoring tools and general troubleshooting by multiple people. Blocking it doesn’t really benefit the security posture.

It’s best to put that configuration burden on the network administrator, security engineer, etc since only they can know their environment and requirements best.

3 Likes

However blocking ping is an easy way to make sure that your box wont participate as a relay in DDoS-attacks where pings are being used.

But the proper countermeasure is of course to allow ping but rate limit them to lets say max 1 ping/srcip/second or so. So a sane default regarding pings would be to have that ratelimit included in the example config.

2 Likes

Yes this is what i am talking about instead of ZERO rules have at least some universal firewall rules in factory default configuration

No router comes with default FW rules in place.
VyOS comes with underlying Linux and can also be configured via Ansible to setup your explicit setup on as many devices as you wish.
:slight_smile:
Cheers
Marcel

Pf sense ,openwrt,opnsense, sophos home,mikrotik,even consumer grade routers like tplink,linksys,netgear comes with default firewalls (with profiles like light ,moderate or strict )the rules are automatically generated based on interfaces allocation…

Cheers

Cisco, Juniper, Palo-Alto, Alcatel default without any firewall rule :wink:
Which rules do you want to see?
For example I deploy cloud instance and don’t know which services will be used. What do you think will be default firewall rules?
I’m really don’t need any firewall, any conntrack and any NAT by default until I configure services and the firewall rules explicitly.

SSH disabled by default for non cloud instances. Why do I need firewall rules which limit it?
To protect syn flood attacks the rules are more complex ⚓ T5217 Add firewall SYNPROXY. I believe there shouldn’t be them at all by default. For example Synproxy doesn’t work with asymmetric traffic and you are getting drops for real packets.

Allow ICMP response but drop other ICMP types bad idea. Due to blackholing PMTU discovery and loosing “fragmentation needed” messages.

It will be annoying to delete default firewall rules every time after any deploy.

I’m definitely against it. But want to see other opinions.

5 Likes

Not really, both for example Arista and PaloAlto Networks comes with default rulesets but you might not see them at first glance.

For Arista there are a larger set of CoPP (control plane policing) rules that exists by default to protect the mgmt-plane CPU from whatever arrives at the data-plane and wants to have a word with the CPU.

The switch defines one control plane policy map named copp-system-policy. The copp-system-policy policy map is always applied to the control plane and cannot be removed from the switch. Other control plane policy maps cannot be added. Copp-system-policy consists of preconfigured classes, each containing a static class map and traffic resolution commands. Preconfigured classes cannot be removed from copp-system-policy.

That is both as QoS policy but also as a firewall policy.

For PaloAlto Networks the hidden rules are so you dont done goof when it comes to blocking yourself from the firewall mgmt-wise. Also stuff like VRRP etc (once enabled) will be added as “hidden” ruleset.

Even more are added “hidden” when you configure your PAN devices through Panorama (central remote management) so you dont cut off the communication with Panorama (which would become a really bad day at work if there is some distance to reset your PAN boxes).

I have filed this feature request some time ago where it would be handy to have some option to let VyOS autocreate some needed rules for your setup:

https://vyos.dev/T5509

Something like (default would be disable as in you would to manually have to setup the needed rulesets in input/output/forward filters):

set firewall auto-ruleset bgp enable
set firewall auto-ruleset dhcp-client enable
set firewall auto-ruleset dhcp-server enable
set firewall auto-ruleset dns-client enable
set firewall auto-ruleset dns-server enable
set firewall auto-ruleset ntp-client enable
set firewall auto-ruleset ntp-server enable
set firewall auto-ruleset ssh-client enable
set firewall auto-ruleset ssh-server enable
set firewall auto-ruleset vrrp enable

along with (default would be none, “any” or “all” should exist as an option aswell):

set firewall auto-ruleset bgp interface 'eth0 eth1'
set firewall auto-ruleset dhcp-client interface 'eth0 eth1'
set firewall auto-ruleset dhcp-server interface 'eth0 eth1'
set firewall auto-ruleset dns-client interface 'eth2 eth3'
set firewall auto-ruleset dns-server interface 'eth2 eth3'
set firewall auto-ruleset ntp-client interface 'eth0 eth5'
set firewall auto-ruleset ntp-server interface 'eth0 eth5'
set firewall auto-ruleset ssh-client interface 'eth7 eth8'
set firewall auto-ruleset ssh-server interface 'eth7 eth8'
set firewall auto-ruleset vrrp enable interface 'eth9'
3 Likes

Opnsense has these rules automatically generated

Pfsense has these

The MikroTik RouterOS 6.46.8, 6.47.9 and 6.48.2 defaultfirewallrules are:

/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"
add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"
add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"

for IPv6 it also creates address-list bad_ipv6 before creating firewallrules

/ipv6 firewall address-list
add list=bad_ipv6 address=::/128 comment="defconf: unspecified address"
add list=bad_ipv6 address=::1 comment="defconf: lo"
add list=bad_ipv6 address=fec0::/10 comment="defconf: site-local"
add list=bad_ipv6 address=::ffff:0:0/96 comment="defconf: ipv4-mapped"
add list=bad_ipv6 address=::/96 comment="defconf: ipv4 compat"
add list=bad_ipv6 address=100::/64 comment="defconf: discard only "
add list=bad_ipv6 address=2001:db8::/32 comment="defconf: documentation"
add list=bad_ipv6 address=2001:10::/28 comment="defconf: ORCHID"
add list=bad_ipv6 address=3ffe::/16 comment="defconf: 6bone"
add list=bad_ipv6 address=::224.0.0.0/100 comment="defconf: other"
add list=bad_ipv6 address=::127.0.0.0/104 comment="defconf: other"
add list=bad_ipv6 address=::/104 comment="defconf: other"
add list=bad_ipv6 address=::255.0.0.0/104 comment="defconf: other"

/ipv6 firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=input action=accept protocol=icmpv6 comment="defconf: accept ICMPv6"
add chain=input action=accept protocol=udp port=33434-33534 comment="defconf: accept UDP traceroute"
add chain=input action=accept protocol=udp dst-port=546 src-address=fe80::/10 comment="defconf: accept DHCPv6-Client prefix delegation."
add chain=input action=accept protocol=udp dst-port=500,4500 comment="defconf: accept IKE"
add chain=input action=accept protocol=ipsec-ah comment="defconf: accept ipsec AH"
add chain=input action=accept protocol=ipsec-esp comment="defconf: accept ipsec ESP"
add chain=input action=accept ipsec-policy=in,ipsec comment="defconf: accept all that matches ipsec policy"
add chain=input action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"
add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=forward action=drop src-address-list=bad_ipv6 comment="defconf: drop packets with bad src ipv6"
add chain=forward action=drop dst-address-list=bad_ipv6 comment="defconf: drop packets with bad dst ipv6"
add chain=forward action=drop protocol=icmpv6 hop-limit=equal:1 comment="defconf: rfc4890 drop hop-limit=1"
add chain=forward action=accept protocol=icmpv6 comment="defconf: accept ICMPv6"
add chain=forward action=accept protocol=139 comment="defconf: accept HIP"
add chain=forward action=accept protocol=udp dst-port=500,4500 comment="defconf: accept IKE"
add chain=forward action=accept protocol=ipsec-ah comment="defconf: accept ipsec AH"
add chain=forward action=accept protocol=ipsec-esp comment="defconf: accept ipsec ESP"
add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept all that matches ipsec policy"
add chain=forward action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN

One could of course argue that VyOS is mainly a router (default allow) and not a firewall (default drop) but still…

3 Likes

I agree to that argument.
:slight_smile:
None of any professional router eqipment has neither preinstalled ACL or FW rules nor a GUI.

Cheers
Marcel

1 Like

*sense is primarily a firewall system, it is pretty bad at being a router.

ex. LAN and WAN ports are hardcoded and cannot be changed after install, you can’t have more than one lan port, and it is very easy to lock yourself out of management.

VyOS is primarily a router platform, you don’t have WAN and LAN just ports and networks.

ex: Any port can be assigned to a WAN uplink, and you can have multiple LANs on multiple ports.

But I’ve been thinking a basic setup wizard would make setup much easier for someone that isn’t used to the CLI.

2 Likes

I dont agree with that statement.

Both are based on an opensource operating system where various applications are used to perform firewalling, routing etc.

VyOS uses nftables which is part of the Linux kernel for firewalling while OPNsense uses pf which is part of the FreeBSD kernel for firewalling.

VyOS uses FRR for routing. OPNsense also uses FRR for routing.

VyOS uses KEA for DHCP. OPNsense also uses KEA for DHCP.

And so on…

The main difference (except for the OS itself) is that the userinterface for VyOS is mainly through CLI where we are all waiting for a proper webgui.

While the main userinterface for OPNsense is the webgui even if you can use CLI if you really want to (but not recommended).

Well firstly OPNsense doesn’t have a CLI, and secondly you completely ignored the whole hard coded interface thing.

Sure it do have a webgui, you can even see a screenshot of it at their startpage:

https://opnsense.org/

Also, interface groups have existed in OPNsense for ages:

https://docs.opnsense.org/manual/firewall_groups.html