ASL 3.2.8 Firewall changes (alpha)

scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Re: ASL 3.2.8 Firewall changes (alpha)

Unread post by scott »

We'll post the next iteration of changes here. And you're right, it is a really simple way to manage the list-based rules. Thats why I really liked this non-object based approach.

I used to work with extensively fwbuilder.org as a rule manager years. So the other day I went back to revisit it for inspiration. Not having used it for 7 or 8 years I assumed that great leaps and strides would have been made in usability. Not so. The entire object approach is so ingrained in "commercial" firewall tools that there has been zero innovation. Aside from supporting some new devices its basically the identical process as before.

So thats one thing... we're not going object. You'd have to take a class, or go to school to use something this mundane. People shouldnt spend so much time agonizing over something that is just barely a security tool.

ipset's (in ASL since 2.6.30.60) have potential. Being able to use match flags against giant lists deeply simplifies things like Geo or RBL's. (Example: .cn rules go from 30k entries to 1 that just says '.cn'). It could allow for port/ip tuples like the acl approach were playing with.

Other than that I like what I see in firewalld from fedora, the zone approach is especially innovative. The DBUS parts are powerful, but they scare me (exploitable? maybe) and the ability to not drop state on established connections has extreme utility in HA environments.
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Re: ASL 3.2.8 Firewall changes (alpha)

Unread post by scott »

And an addendum here to a really good point you brought up, which is that crafting rules should be possible from a shell. The web interface is OK for more high level logic (like a wizard, or maybe visualizing how rules apply in the stack), the shell is the only way you'll be configuring things in a distributed environment like ASE.
prupert
Forum Regular
Forum Regular
Posts: 573
Joined: Tue Aug 01, 2006 2:45 pm
Location: Netherlands

Re: ASL 3.2.8 Firewall changes (alpha)

Unread post by prupert »

scott wrote:And an addendum here to a really good point you brought up, which is that crafting rules should be possible from a shell. The web interface is OK for more high level logic (like a wizard, or maybe visualizing how rules apply in the stack), the shell is the only way you'll be configuring things in a distributed environment like ASE.
Exactly! And not only if you are working with an ASE setup, but also (in our case) when managing a heterogenous set of servers for various ASL customers. We'd like to work on the command-line with elegance and prefer not to have to dive into a web interface at all. As the ASL firewall is offering great protection, we've opted to replace our existing firewall strategy with yours. Features like the one we're discussing here are of tremendous value to us. They enable us to administer all these different servers without too much hassle.

Do you want me to open a feature request for this in the portal, or have you already created one?
Lemonbit Internet Dedicated Server Management
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Re: ASL 3.2.8 Firewall changes (alpha)

Unread post by scott »

We've got several related to this already, and some overarching ones related to distributed management. So far we're tracking:

* firewalld (https://fedoraproject.org/wiki/FirewallD)
* Augeas (http://augeas.net/) - This is more of a manipulation library or configurations, sort of like GET/SET in snmp. It covers a vast number of services and applications, not just firewalls
* saltstack (http://saltstack.com/community.html), another abstraction layer, but for distributed management over networks.
* ipsets, (http://ipset.netfilter.org/) this has some real potential for a direct replacement of the acl system. Another interesting use case is that ipsets can automatically populate other rulesets. For example this:

# Create new ipset
ipset -N portscan iphash

# Detector rules for microsoft netbios, and mssql
iptables -A INPUT -p tcp --dport 137 -j SET --add-set portscan src
iptables -A INPUT -p tcp --dport 1433 -j SET --add-set portscan src

# Action to drop packets
iptables -A INPUT -m set --set portscan src -j DROP

So now any IP that hits ports 137, or 1433 will automatically be blacklisted from every port. You could also invert that logic to use the same thing to create portknocking rules
Post Reply