Re: [Shorewall-users] Port knocking and DNAT

On Wed, Sep 6, 2017 at 7:45 PM, Tom Eastep wrote: I'll not spend much time on improved port knocking features, since I > consider that technique to be the ultimate in "security by obscurity". > You're right but it really comes handy more often than one could think,

Re: [Shorewall-users] Port knocking and DNAT

On Tue, Sep 5, 2017 at 5:58 PM, Tom Eastep wrote: > To sum up : I need the user to knock on port X which triggers the DNAT > > of port Y to the internal Windows RDP port. > > > > How can I achieve that? Thank you. > > > > PS: Using Shorewall 5.0.12 if that matters. > > Do

[Shorewall-users] Port knocking and DNAT

Hi, I'm currently using the port knocking feature on the firewall itself for the usual SSH service and it works perfectly. For one special user, always on the move thus no fixed IP address, I need to give him access to a Windows box behind the firewall using the RDP protocol. The old/deprecated

[Shorewall-users] NFTables on the roadmap?

Hi, You probably already know most of its contents but here's a nice introduction to NFTables: http://developers.redhat.com/blog/2016/10/28/what-comes-after-iptables-its-successor-of-course-nftables/ Is there any plan in the future to switch to it? I ask because it's now quite widely

Re: [Shorewall-users] [ENHANCEMENT] A way to support macros in "masq" file?

On Fri, Oct 14, 2016 at 1:14 PM, Simon Hobson wrote: > Ex 1: simple :) > > > > rules: > > NTP(ACCEPT) { source=lan dest=net:$NTP_HOST } > > > > masq: > > $IF_NET { source=$LAN adress=$GW_IP proto=udp port=ntp } > > > > Ok, no big deal really but would look nicer with a

[Shorewall-users] [ENHANCEMENT] A way to support macros in "masq" file?

Hi, The use of macros make the "rules" file really nice, tidy and clean! It would be nice if there was a way to support macros in the "masq" file. Unfortunately, I have to deal with lots of crappy software/appliances which all have specific sets of destination IP addresses and ports and often

Re: [Shorewall-users] Stricter "interfaces" check

On Thu, Oct 13, 2016 at 4:13 AM, Tom Eastep wrote: > Tom deserves to win a nobel prize for all his nice work on > > shorewall! > > > > Not at all. I just listen to users' reports and implement changes that > address their concerns. > I already said it some months ago but

Re: [Shorewall-users] Stricter "interfaces" check

On Tue, Oct 11, 2016 at 5:49 PM, Tom Eastep wrote: I believe that this particular class of user blunder is best guarded > against by setting IGNOREUNKNOWNVARIABLES=No in shorewall[6].conf, > Oh dear! Is there something you didn't thought about when designing Shorewall?

Re: [Shorewall-users] rules and zones interaction

On Tue, Oct 11, 2016 at 5:27 PM, Tom Eastep wrote: Your rule should be: > > Ping(ACCEPT) { source=all dest=all+ rate=100/sec } > > (Note the plus sign) > Argh... I hate missing stuff, especially when it's correctly documented!

[Shorewall-users] Stricter "interfaces" check

Hi, Just a small issue I've faced. I made a typo on the "interfaces" file, like this : bar ${IF_BAR} nets=(${NET_BAR}),nosmurfs,rpfilter,bridge dmz ${IF_F00} nets=(${NET_FOO}),nosmurfs,rpfilter,bridge notice: ${IF_FOO} is misspelled with 00 (zeros) instead of letter "O" which leads to an

[Shorewall-users] rules and zones interaction

Hi, On a host with 1 physical interface (internet) and several internal bridges where LXC VMs (veth) are attached to different subnets. Everything runs fine, nothing to complain about. My policy file looks like this : $FW { dest=all policy=ACCEPT } dmz1,dmz2 { dest=dmz1,dmz2+ policy=REJECT

Re: [Shorewall-users] mtr and ICMP type 11 (Time exceeded)

On Thu, Sep 29, 2016 at 9:32 PM, Simon Hobson wrote: And traceroute. > It occurs to me, you might not know how traceroute works - it's fairly > simple and obvious once yo see it. > First of all, thank you very much for this detailed and very nice explanation. This should

Re: [Shorewall-users] mtr and ICMP type 11 (Time exceeded)

On Thu, Sep 29, 2016 at 3:03 PM, Simon Hobson wrote: >From the network traffic PoV, MTR is not "normal" - the traffic it > generates is far from normal. > "Normal" traffic will rarely generate TTL Exceeded responses. With it's > default settings, MTR will generate one TTL

Re: [Shorewall-users] mtr and ICMP type 11 (Time exceeded)

On Wed, Sep 28, 2016 at 4:50 AM, Tom Eastep wrote: You are logging related ACCEPT decisions -- do you expect those > connections to not be accepted??? > I use RELATED_LOG_LEVEL=info to get informed when "something goes wrong" or "something unexpected happens". I get

[Shorewall-users] mtr and ICMP type 11 (Time exceeded)

Hi, When I use mtr-tiny (text mode version) to check on a destination, the firewall logs get flooded a lot! No matter if I mtr from an inside host (ie: desktop) or the firewall itself. ex: on the firewall itself, "mtr 1.2.3.4" and suppose there are 6 hops to reach it from A.A.A.A to F.F.F.F I

Re: [Shorewall-users] Allow multiple destination zones in "policy".

On Sat, Sep 10, 2016 at 6:04 PM, Tom Eastep wrote: >> zoneA { dest=zoneA,zoneB,zoneC policy=REJECT loglevel=info } > >> zoneB { dest=zoneB,zoneC,zoneA policy=REJECT loglevel=info } > >> zoneC { dest=zoneC,zoneA,zoneB policy=REJECT loglevel=info } > > > > Fewer lines

Re: [Shorewall-users] Allow multiple destination zones in "policy".

On Sat, Sep 10, 2016 at 2:35 PM, Robert K Coffman Jr. -Info From Data Corp. wrote: > zoneA { dest=zoneA,zoneB,zoneC policy=REJECT loglevel=info } > > zoneB { dest=zoneB,zoneC,zoneA policy=REJECT loglevel=info } > > zoneC { dest=zoneC,zoneA,zoneB policy=REJECT

[Shorewall-users] Allow multiple destination zones in "policy".

Hi, Just as a convenience, would it be possible to allow multiple destination zones in policy file? Rationale: I use Shorewall on every server I manage, be it the gateway fire or an internal server. On a server with heavy LXC usage, I have a bridge interface or even multiple bridges to separate

Re: [Shorewall-users] Minor suggestion

On Wed, Jul 20, 2016 at 12:34 AM, Tom Eastep wrote: Will be in 5.0.11. > This is just amazing! Thank you! Really! If only 1% of the companies I dealt with in my career, claiming to provide "enterprise class" and/or "professional" (most of the time paid) support could

[Shorewall-users] Minor suggestion

Hi, I exclusively use the "alternate specification of columns" because I find it way more clearer to read. >From time to time, I need to set a comment to a specific rule. It would be really nice to add a new keyword "comment" to the alternate spec. It would make the configuration a bit lighter

Re: [Shorewall-users] Shorewall 5.0.10 Beta 1

On Wed, Jun 15, 2016 at 12:29 AM, Tom Eastep wrote: Shorewall 5.0.10 Beta 1 is now available for testing. > >[...] > New Features: > > 1) The 'allow' command can now remove entries from the ipset-based > dynamic blacklists. > > allow ... > Tom, you're a

Re: [Shorewall-users] Blacklist from command line

On Mon, Jun 6, 2016 at 9:42 PM, Tom Eastep wrote: > Yes -- All variables need to be in shorewall.conf but you don't need > > to specify a value after the equals sign(not specified = if a value > > is not specified, then the default value of ... is assumed). > > > >

Re: [Shorewall-users] Blacklist from command line

On Sun, Jun 5, 2016 at 4:04 PM, Tom Eastep wrote: You are missing a great many settings in shorewall.conf - in this case, > DYNAMIC_BLACKLIST=ipset will allow dynamic blacklisting (as is > documented in shorewall(8)). > Ok I'll look into that. Thanks > If the above is

[Shorewall-users] Blacklist from command line

Hi, I wonder if I'm doing something wrong because I really can't figure out the reason preventing Shorewall from being able to blacklist from the command line Shell# shorewall blacklist 1.2.3.4 ERROR: The blacklist command is not supported in the current Shorewall configuration If I repeat

Re: [Shorewall-users] ?INFO / ?WARNING

On Sat, Apr 30, 2016 at 5:16 PM, Tom Eastep wrote: Will be in 5.0.9 Beta 2 > Thank you VERY MUCH! Shorewall is really a delight to use, thanks for your hard work on this project. -- ObNox --

[Shorewall-users] ?INFO / ?WARNING

Hi, I'm using "?INFO" in "rules" within conditional code but I find it to be a bit too verbos such as the following example: Shell# foobar=1 shorewall check Checking using Shorewall 5.0.8... Resetting INFO: Added support for Foobar - /etc/shorewall/rules (line 138) Shorewall configuration

Re: [Shorewall-users] SMB from "net" zone

On Fri, Feb 19, 2016 at 5:42 AM, James Andrewartha < jandrewar...@ccgs.wa.edu.au> wrote: Many ISPs drop port 445 (and others) to customers. See for example > https://iihelp.iinet.net.au/Port_Blocking_at_iiNet Interesting! Indeed that was the problem after dealing with "action.Drop" and

[Shorewall-users] SMB from "net" zone

Hi, For a special use case, I need to give access to a CIFS service (445/tcp) from the WAN. I'm struggling quite hard to sort this out. After finding that Samba wasn't the culprit and tshark showed no traffic on the interface related to TCP port 445, I got back to basics :-) I tried the simplest

Re: [Shorewall-users] I'll be off of the list for several days

On Tue, Nov 17, 2015 at 5:11 PM, Tom Eastep wrote: I have a health issue that I will be dealing with. Hope to be back next > REJECT pain, DROP whatever is affecting you and ACCEPT our thoughts to help you be again in good SHAPE :-) -- ObNox

Re: [Shorewall-users] May the pumpkin pie (with whipped cream!) never end

On Thu, Nov 26, 2015 at 2:52 PM, TN Patriot wrote: Just want to give a Happy Thanksgiving wish to Tom Eastep and all the > Shorewall > team. They work hard at a demanding and oftentimes unthankful job, > making a > program for us that works well, is free and open-source.

Re: [Shorewall-users] Skip logging FAQ21 type entries

On Sat, Oct 10, 2015 at 8:26 PM, Tom Eastep wrote: > Swall:+lan-net:ACCEPT:IN=eth1 OUT=eth0 SRC=192.168.0.1 DST=zz.zz.zz.zz > > PROTO=ICMP TYPE=3 CODE=3 [SRC=zz.zz.zz.zz DST=192.168.0.1 PROTO=UDP > > SPT=10760 DPT=25565 ] > > > > zz.zz.zz.zz is a random public internet IP.

[Shorewall-users] INCLUDE directive

Hi, Playing a bit with the INCLUDE (and ?INCLUDE) directive I don't get exactly what I wish and from what I see, I think this is not yet possible. I would like to make Shorewall configuration highly modular for the "rules" part by being able to disable/enable parts of it. For example, I have

Re: [Shorewall-users] INCLUDE directive

On Sun, Oct 11, 2015 at 11:26 PM, Tom Eastep wrote: I would rather you used ?if...?else...?endif to conditionally include/exclude features. That's already supported. > That's not exactly the same in this case because I don't want/need to rely on a condition for some

Re: [Shorewall-users] INCLUDE directive

On Mon, Oct 12, 2015 at 5:52 AM, Ob Noxious <obn...@gmail.com> wrote: I fail to see how ?IF.. ?ELSE..?ENDIF statements would help in my case as > there's no special usable pattern to trigger these configs with. > It stoke me few minutes later :-) A simple variable in "params&

Re: [Shorewall-users] Interesting case : GlusterFS

On Sat, Sep 19, 2015 at 8:21 PM, Tom Eastep wrote: Attached is an inlineable action that accepts two parameters: > > - The number of bricks in the cluster :Default is 2 > - Enable Infiniband port 24008 (0 or 1) :Default is 0 (Don't open 24008) > > Add > > GlusterFS

Re: [Shorewall-users] Interesting case : GlusterFS

On Sat, Sep 19, 2015 at 8:21 PM, Tom Eastep wrote: Attached is an inlineable action that accepts two parameters: > [...] > This will be a standard Shorewall action in 5.0.0 Beta 2. > One word : Wow :-) Thank you! -- ObNox

[Shorewall-users] Interesting case : GlusterFS

Hi, I'm playing a bit with GlusterFS - https://www.gluster.org/ - and of course, I want it to work flawlessly with Shorewall. GlusterFS needs some TCP ports for the control channel (the easy part: 24007/tcp) but it also need some dynamically opened ports. In a nutshell : If you create a

[Shorewall-users] Shorewall 4.6.13.1

Hi, I upgraded to the latest version and played a bit with it. Testing some functions I found a small bug : Shell# shorewall status -i [...snip...] cat: /var/lib/shorewall/*.status: No such file or directory Interface * is Unknown The problem is /usr/share/shorewall/lib.cli in function

Re: [Shorewall-users] Extension scripts

On Sat, Sep 19, 2015 at 4:44 AM, Ob Noxious <obn...@gmail.com> wrote: Further tests seem to indicate that "initdone" must be in Perl like > "compile" but the doc does not specify this so I'm not sure. Trying > something like "my $foo = 'bar';" in &quo

[Shorewall-users] Extension scripts

Hi, I want to tweak some settings with sysctl when Shorewall inits. Following the doc at http://shorewall.net/shorewall_extension_scripts.htm I tried the following without success : /etc/shorewall/lib.private setFWParams() { ... some stuff... } /etc/shorewall/initdone setFWParams And then

Re: [Shorewall-users] First experience (next)

On Mon, Sep 14, 2015 at 4:33 AM, Tom Eastep wrote: > Shell# ip link add name ${iface} ${macaddr} type bridge > > Shell# ip link set dev ${iface} up promisc on > > That's the problem > > > Shell# brctl setfd ${iface} 2 > Dear dear dear! I've solved the problem and it

Re: [Shorewall-users] First experience (next)

On Wed, Sep 16, 2015 at 7:51 PM, Tom Eastep wrote: I've been running containers for three years now and have never had to > place the bridge in promiscuous mode to give the containers full > internet access. > I would like that too but currently, I can't figure a way to

Re: [Shorewall-users] First experience (next)

On Tue, Sep 15, 2015 at 6:00 PM, Tom Eastep wrote: > Maybe I'm missing something but how can I expect the LXC containers to > > reach any OTHER host other than the one the containers are running on? > > > > Without the promiscous mode, containers can only see each other

Re: [Shorewall-users] First experience (next)

On Mon, Sep 14, 2015 at 4:33 AM, Tom Eastep wrote: > Shell# ip link add name ${iface} ${macaddr} type bridge > > Shell# ip link set dev ${iface} up promisc on > > That's the problem > Maybe I'm missing something but how can I expect the LXC containers to reach any

Re: [Shorewall-users] First experience (next)

On Sun, Sep 13, 2015 at 11:36 PM, Tom Eastep wrote: > If you need more information, don't hesitate to ask. Thank you very much > > for trying to help with the case. > > It looks to me as if either the bridge is mis-behaving or the traffic is > being sent with the broadcast

Re: [Shorewall-users] First experience (next)

On Tue, Sep 8, 2015 at 8:24 PM, Tom Eastep wrote: Please forward the output of 'shorewall dump' collected as described at > http://www.shorewall.org/support.htm#Guidelines. > Sorry for the late reply, I've been drowning with work lately. Please find the "shorewall dump"

Re: [Shorewall-users] First experience (next)

On Mon, Sep 7, 2015 at 7:51 PM, Tom Eastep wrote: > "interfaces" file: > > net eth0 nets=(!10.1.1.0/24 ),nosmurfs,rpfilter > > vdmz vbr nets=(10.1.1.0/24 ),nosmurfs,rpfilter > [...] > > Thanks for any clue on this matter. > >

Re: [Shorewall-users] First experience

On Sun, Sep 6, 2015 at 9:54 PM, Tom Eastep wrote: > >> - 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

Re: [Shorewall-users] First experience (next)

On Sun, Sep 6, 2015 at 8:38 PM, Tom Eastep wrote: > > I'm really enjoying Shorewall for now. It's a bit "complex" for the > > newcomer but highly configurable, to an impressive level I must say. > > > > Glad to hear that it is working for you. > I confirm that I'm

Re: [Shorewall-users] First experience (next)

On Sun, Sep 6, 2015 at 11:57 PM, Ob Noxious <obn...@gmail.com> wrote: "interfaces" file: > net eth0 nets=(!10.1.1.0/24),nosmurfs,rpfilter > vdmz vbr nets=(!10.1.1.0/24),nosmurfs,rpfilter > Shoot! Of course, the vdmz zone does NOT have the "!"

[Shorewall-users] First experience

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

[Shorewall-users] First experience (next)

Hi, Please disregard my previous comment about the invalid TCP flags FIN,RST and PSH,FIN passing through "tcpflags" chain. They indeed passthrough but are blocked later by the "?SECTION INVALID" of the "rules" file. They simply were silently dropped because INVALID_LOG_LEVEL was unset in