With the impending release of Shorewall 3.4, I have begun thinking about
where we go from here. The following are some thoughts about the current
state of Shorewall and possibilities for the future.
Activity on the mailing lists and IRC channel has been steadily declining
for the last couple of years. This signals to me that the rate at which
people are adopting Shorewall is waning (I grant that the documentation has
gotten better over the years which helps lower the noise level somewhat).
While I've never had any ambitions toward dominating the OSS firewall
market, Shorewall takes a lot of work so I would prefer to spend my effort
on something that people want to use. Maybe it is still Shorewall -- maybe
it is something else.
My list of the major Shorewall shortcomings:
1) No GUI (other than Webmin). That is something that I personally am
unlikely to change because I have no interest in spending my time
developing one. Besides, first attempts at GUI creation tend to have
disappointing results at best.
2) Performance and scaling issues. Shorewall is being used in larger and
more complex configurations and the time required to run the generated
script increases non-linearly with configuration complexity. This has
been a common theme on the mailing list recently. Performance of the
shell-based compiler is also awful when dealing with large complex
configurations.
3) No IPv6 Support. We've talked about this before.
4) Lack of an ability to make quick "on the fly" configuration changes (this
is closely related to the performance problem -- if "shorewall restart"
always took less that a second, I don't believe that this would be an
issue).
Resolving these issues will require considerable change to the current
shell-based product and I suspect that just adding IPv6 support would make
the performance problem even worse. My feeling is that the current
shell-based implementation has gone about as far as it can go and that
adding additional major function to it while trying to maintain even the
current mediocre level of performance will be difficult.
I have begun some experimentation with rewriting the compiler in Perl and
that is looking promising. Converting to Perl will unfortunately present
migration/compatibility issues with compile-time extension scripts although
I've been able to retain shorewall.conf and /etc/shorewall/params
functionality for the most part. A Perl-based compiler would of course mean
the end of the road for Shorewall Embedded System support (at least for the
full Shorewall product) since Perl is typically not available on those
systems. Embedded Systems could still support Shorewall Lite.
Here are a couple of possible approaches to the run-time performance problem.
a) Keep the current zone-policy-rule paradigm but have the
compiler generate 'iptables-restore' input.
This is clearly preferable to the current approach of running
iptables repeatedly in the compiled script. We would still be stuck
with the order (n**2) scaling issues inherent in that paradigm
(see http://www.shorewall.net/ScalabilityAndPerformance.html).
b) Consider other paradigms which do not suffer from the scaling issues
implicit in zone-policy-rule.
For example, I'm familiar with one organization that has created a
firewall configuration tool based on a service-policy-rule
paradigm which scales much better.
Both approaches present migration/compatibility issues. Approach a)
maintains compatibility with the tabular config files from earlier Shorewall
releases but would likely invalidate most runtime extension scripts. We
could probably continue to call the product "Shorewall" though as the
changes would be more evolutionary than revolutionary. Approach b) is
clearly a new product -- "Shorewall-ng" or something.
Approach a) is not as straight-forward as it might first appear. To
accommodate Shorewall Lite, the compiler cannot simply create a single
monolithic iptables-restore file because part of the contents of that file
cannot be determined until run-time (all uses of 'detect' for example). So
at run-time, the script still has to perform some configuration analysis
then glue together an iptables-restore file that is appropriate for the
current configuration.
So long as we are discussing what to add to Shorewall, it is also worth
asking what the next version of the product can leave behind. Given that
BRIDGING=Yes won't work with kernel version 2.6.20 and later, that feature
is a rather obvious choice for elimination. ECN is now widely deployed on
the Internet so /etc/shorewall/ecn might also be a candidate for extinction.
Are there others?
I welcome your input and look forward to further discussion.
Thanks,
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ [EMAIL PROTECTED]
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
