Hi,
I'm testing Shorewall and it plays nice. I'm replacing my own home made
IPTables/NetFilter friendly wrapper I wrote more than a decade ago which
works perfectly well but lacks some features now like really ultra fine
grained special configurations support. I don't see the real need to
rewrite it given the tremendous amount of work done in Shorewall.
I have a test setup to play with in the usual shape (net + dmz) and using
Shorewall 4.6.11.2
Here are my findings and questions:
- Documentation says that SHOREWALL_SHELL defaults to "/bin/sh" in
/etc/shorewall/shorewall.conf but if it's not defined, the compiler
complains with a warning:
Use of uninitialized value $Shorewall::Compiler::config{"SHOREWALL_SHELL"}
in concatenation (.) or string at
/usr/share/shorewall/Shorewall/Compiler.pm line 95.
- There is the highly convenient [ACTION]:loglevel:tag,disposition but it's
very hard to find it in the documentation. I remember seeing it once but
when I was searching for it again, I had to use my memory to reproduce it
as there was no way to find it again.
- I tried to "Ping Flood" protect testhost to see how it would react. My
first approach was in "rules" files :
?SECTION NEW
Ping(ACCEPT) { source=all dest=all rate=1/sec }
Then from another host : ping -i 0.2 testhost (or "ping -f testhost" as
root) but it did work, all packets passed through, 0% packet loss. New try
with
?SECTION NEW
Ping(ACCEPT) { source=all dest=all rate=1/sec }
Ping(DROP):info:,PingFlood { source=all dest=all }
Again, not working as expected, 0% packet loss on the pinging host side.
Examining the NetFilter chains (shorewall show) proved that INPUT -> net-fw
-> 3rd rule "ACCEPT cstate ESTABLISHED" drank all the packets. This
explains why Ping(ACCEPT) {...} was only reached once, hence not triggering
the rate limit!
Finally, I moved these two rules to "?SECTION ALL" and now it works as
expected.
Is this the right way to do it? Is there a more "elegant" way of performing
the same action like in one line only using another method?
- I submitted a bunch of TCP packets with invalid flags to be caught by the
"tcpflags" chains and some of them made it through like FIN,RST PSH,FIN. Is
there a special reason?
- About the "tcpflags" chain, why not put it in the PREROUTING raw or
mangle table which is reach first wherever the packet is destined to?
"tcpflags" filters unwanted traffic so it'll be beneficial for all zones by
dropping packets at early stage and would avoid duplication by referencing
it in so many chains.
- Any plans to support the SYNPROXY introduced recently? :-)
- Shorewall is meant to secure entire networks ranking from the small home
setup to quite large/complex setups. Yet, I don't see it managing
"sys/module/nf_conntrack/parameters/hashsize" and
"/proc/sys/net/netfilter/nf_conntrack_max" which are very important for
connection tracking with lots of hosts. Shouldn't Shorewall provide a
helper for that or at least mention it in the docs?
That's it for now :-)
--
ObNox
------------------------------------------------------------------------------
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
