Re: [Shorewall-users] ProFtpd Shorewall DROP net-fw TLS connection from client ftp

[Davide Marchi]

[..]


To handle a protocol like FTP, Netfilter must inspect each packet of 
the

control connection in order to be able to automatically open data
connections. When the control connection is encrypted, it can't do 
that
and hence data connections are rejected. To work around this, you 
will
need to specify a range of passive ports in the ProFtpd 
configuration,

then open that port range in Shorewall. To handle active mode
connections, you would also need to open outbound connections whose
source port is 20 (that is the default, anyway).


Well, I confirm that the problem was "only" the enabling of the ProFtpd 
passive ports and the relative shorewall ports:


ProFtpd (sftp.conf-> that could be now tls.conf or ftps.conf) :

PassivePorts49152 65534

Shorewall (rules):

ACCEPT  net $FW tcp 
49152:65534 #PROSFTP PASSIVE PORT




SFTP is the preferred way to do Secure file transfer, as it is 
SSH-based
and does not use separate control and data connections. With SFTP, 
you

simply open the incoming connection in your Shorewall configuration.

-Tom


I opted for FTPS because I preferred to use the Letsencrypt 
certificates instead of self signed. I was wrong? :-)



Thanks Tom for your very appreciated help!

Davide




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] shorewall reload / restart

[Vieri Di Paola via Shorewall-users]

Hi,

I read the shorewall man page regarding the "reload" and "restart" commands. 
From a practical point of view and with default shorewall.conf settings in 5.1, 
if I change/add/delete entries in the "rules" file, and issue the "reload" 
command then I should expect the following:

- existing connections will not be affected
- the "new rules" will be processed and applied

Same thing should happen when changing entries in snat, mangle, routes, 
rtrules. The params file should also be re-read.

Correct?

So, with shorewall >=5.0.15, when would it be useful to issue the "restart" 
command? The only scenario I can think of is if I wanted to interrupt active 
connections (or at least preserve only those in "stoppedrules").

Regards,

Vieri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] ProFtpd Shorewall DROP net-fw TLS connection from client ftp

[Davide Marchi]

Hi friends,

On Debian Jessie,
I've configured ProFtpd to connect by tls (SSLv3 TLSv1 -> Letsencypt 
certificate) on port  but with Shorewall up, it DROP the connection:



Aug  8 18:50:10 server kernel: [16438563.572121] 
Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=00:50:56:3c:a8:50:00:08:e3:ff:fd:90:08:00 SRC=132.142.22.10 
DST=44.320.032.111 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=63283 DF 
PROTO=TCP SPT=33175 DPT=55298 WINDOW=29200 RES=0x00 SYN URGP=0



My rules.conf:

PORTPORT(S) 
DESTLIMIT   GROUP
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

Invalid(DROP)  net  $FW tcp

Ping(DROP)  net $FW

ACCEPT  $FW net icmp

Web(ACCEPT) net $FW
ACCEPT  net $FW tcp 443   
#HTTPS

ACCEPT  net $FW tcp 60319 #SSH
ACCEPT  net $FW tcp 587   
#SUBMISSION SERVICE DOVECOT
ACCEPT  net $FW tcp 995   
#SUBMISSION SERVICE DOVECOT SSL/TSL
ACCEPT  net $FW tcp 993   
#SUBMISSION SERVICE DOVECOT SSL/TSL
ACCEPT  net $FW tcp 110   
#SUBMISSION SERVICE DOVECOT STARTTLS
ACCEPT  net $FW tcp 143   
#DOVECOT POSTFIX
ACCEPT  net $FW tcp 25
#POSTFIX
ACCEPT  net $FW tcp 21
#PROFTP
ACCEPT  net $FW tcp 22
#PROSFTP

SSH(ACCEPT) net $FW tcp   #PROSFTP



Now I wondering where is the problem,

I've Fail2ban installed too and I've already clarified in its ML that 
this is not a problem that concerns F2B



A thanks to all those who want to help me better understand this issue!

Davide
Italy

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] traffic issues through firewall router

[Vieri Di Paola via Shorewall-users]

I can see the light at the end of the tunnel, but I'm not quite there yet.

A reminder of my current network:

Internet providers --- gw1 --- fw2 --- lan, dmz, caib, ibs

I replaced the old fw1 with the new fw2 this morning, and everything seemed to 
work until I found that some lan hosts could not access hosts in the caib and 
ibs zones. They could however access hosts in the wan zone, as well as fw2 
itself.

The strange thing is that two hosts with apparently the same access rules do 
not behave the same way. One can ping, the other can't.

Let's just take one example:

- ping dest IP address 10.215.134.196 in "ibs" zone from "lan" host with IP 
address 10.215.144.48 is OK 
- ping dest IP address 10.215.134.196 in "ibs" zone from "lan" host with IP 
address 10.215.246.47 FAILS 

Same thing happens with dest IP address 10.215.9.172 in "caib" zone.

Please note that host at 10.215.246.47 can ping fw2 and 8.8.8.8 in "wan" zone 
just fine.


This is the "rule" that should match:
ACCEPTlan:10.215.246.0/23caib:10.215.0.0-10.215.143.255all
ACCEPTlan:10.215.246.0/23ibs:10.215.0.0-10.215.143.255all


While performing the first test, I see this on fw2:

# tcpdump -nni enp10s0 host 10.215.246.47
07:41:23.433865 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 
46
07:41:28.933987 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 
46
07:41:34.434102 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 
46
07:41:39.934164 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 
46

My current "interfaces" file on fw2 is as follows:

lan $IF_LAN routeback,arp_filter=1
wan $IF_WAN routeback,arp_filter=1
caib$IF_CAIBarp_filter=1
ibs $IF_IBS arp_filter=1
dmz $IF_DMZ routeback,dhcp
-   lo  -

I unsuccessfully tried adding proxyarp=1 to IF_IBS, but not IF_LAN.

Here's the link to the shorewall dump while doing this test (I added logging to 
the lan-ibs and lan-caib policies):

https://drive.google.com/file/d/0B-tpkY1LkI67LXBXSTlaV1FOeEE/view?usp=sharing

(More) help appreciated.

Vieri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Shorewall 5.1.6 Beta 2

[Tom Eastep]

Shorewall 5.1.6 Beta 2 is now available for testing.

Problems Corrected since Beta 1:

1)  http://www.shorewall.net/shorewall_extension_scripts.htm states
that $SHAREDIR and $CONFDIR can be used in extension scripts, that
has not been true for some time. Beginning with this release, those
variables are once again available in the generated script.

2)  Under very rare circumstances, when OPTIMIZE level 8 was used,
messages such as the following could be issued during compilation:

Use of uninitialized value in hash element at
   /usr/share/shorewall/Shorewall/Rules.pm line 818.
Use of uninitialized value in concatenation (.) or string at
   /usr/share/shorewall/Shorewall/Rules.pm line 823.

That has been corrected.

New Features since Beta 1:

1)  The two new run-time extensions scripts (enabled and disabled) have
been enhanced

Like all run-time extension scripts, the contents of each script
are placed in a function body. In the case of these new scripts,
the function is passed arguments:

$1 = the physical name of the interface
$2 = the logical name of the interface
$3 = the name of the Provider, if any, associated with the
 interface.

Thank you for testing,

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] shorewall reload / restart

[Tom Eastep]

On 08/09/2017 12:56 AM, Vieri Di Paola via Shorewall-users wrote:
> Hi,
> 
> I read the shorewall man page regarding the "reload" and "restart" commands. 
> From a practical point of view and with default shorewall.conf settings in 
> 5.1, if I change/add/delete entries in the "rules" file, and issue the 
> "reload" command then I should expect the following:
> 
> - existing connections will not be affected
> - the "new rules" will be processed and applied
> 
> Same thing should happen when changing entries in snat, mangle, routes, 
> rtrules. The params file should also be re-read.
> 
> Correct?
> 
> So, with shorewall >=5.0.15, when would it be useful to issue the "restart" 
> command? The only scenario I can think of is if I wanted to interrupt active 
> connections (or at least preserve only those in "stoppedrules").
> 

With ADMINISABSENTMINDED=Yes, active connections are not interrupted
during restart. New connections not allowed by stoppedrules are denied
during the time that the firewall is stopped.

With RESTART=restart, doing a 'restart' allows the 'stop' and 'stopped'
extension scripts to be executed whereas 'reload' does not. So if you
have something in those scripts that you want done, then 'restart' is
appropriate.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] ProFtpd Shorewall DROP net-fw TLS connection from client ftp

[Tom Eastep]

On 08/09/2017 01:28 AM, Davide Marchi wrote:
> Hi friends,
> 
> On Debian Jessie,
> I've configured ProFtpd to connect by tls (SSLv3 TLSv1 -> Letsencypt
> certificate) on port  but with Shorewall up, it DROP the connection:
> 
> 
> Aug  8 18:50:10 server kernel: [16438563.572121]
> Shorewall:net-fw:DROP:IN=eth0 OUT=
> MAC=00:50:56:3c:a8:50:00:08:e3:ff:fd:90:08:00 SRC=132.142.22.10
> DST=44.320.032.111 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=63283 DF
> PROTO=TCP SPT=33175 DPT=55298 WINDOW=29200 RES=0x00 SYN URGP=0
> 
> 
> My rules.conf:
> 
> PORTPORT(S)DEST   
> LIMITGROUP
> ?SECTION ALL
> ?SECTION ESTABLISHED
> ?SECTION RELATED
> ?SECTION INVALID
> ?SECTION UNTRACKED
> ?SECTION NEW
> 
> Invalid(DROP)  net$FWtcp
> 
> Ping(DROP)net$FW
> 
> ACCEPT$FWneticmp
> 
> Web(ACCEPT) net $FW
> ACCEPT  net $FW tcp 443  
> #HTTPS
> ACCEPT net $FWtcp60319 #SSH
> ACCEPT  net $FW tcp 587  
> #SUBMISSION SERVICE DOVECOT
> ACCEPT  net $FW tcp 995  
> #SUBMISSION SERVICE DOVECOT SSL/TSL
> ACCEPT  net $FW tcp 993  
> #SUBMISSION SERVICE DOVECOT SSL/TSL
> ACCEPT  net $FW tcp 110  
> #SUBMISSION SERVICE DOVECOT STARTTLS
> ACCEPT  net $FW tcp 143  
> #DOVECOT POSTFIX
> ACCEPT  net $FW tcp 25   
> #POSTFIX
> ACCEPT  net $FW tcp 21   
> #PROFTP
> ACCEPT  net $FW tcp 22   
> #PROSFTP
> SSH(ACCEPT)net$FWtcp  #PROSFTP
> 
> 
> 
> Now I wondering where is the problem,
> 
> I've Fail2ban installed too and I've already clarified in its ML that
> this is not a problem that concerns F2B
> 
> 
> A thanks to all those who want to help me better understand this issue!

To handle a protocol like FTP, Netfilter must inspect each packet of the
control connection in order to be able to automatically open data
connections. When the control connection is encrypted, it can't do that
and hence data connections are rejected. To work around this, you will
need to specify a range of passive ports in the ProFtpd configuration,
then open that port range in Shorewall. To handle active mode
connections, you would also need to open outbound connections whose
source port is 20 (that is the default, anyway).

SFTP is the preferred way to do Secure file transfer, as it is SSH-based
and does not use separate control and data connections. With SFTP, you
simply open the incoming connection in your Shorewall configuration.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Documentation error?

[Vieri Di Paola via Shorewall-users]

From: Philip Le Riche 

>
> I presume "Corresponding..." down to the end of the quote is an unintentional
> duplicate.

It is.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Documentation error?

[Tom Eastep]

On 08/09/2017 03:03 PM, Philip Le Riche wrote:
> Trying to set up a transparent proxy I'm slightly confused by the
> following towards the end of
> http://shorewall.net/Shorewall_Squid_Usage.html :
> 
> |/etc/shorewall/mangle| (assume loc interface is eth1 and net interface
> is eth0):
> 
> #ACTION SOURCE  DESTPROTO  DPORT   SPORT
> DIVERT  eth00.0.0.0/0   tcp-   80
> TPROXY(3129)eth10.0.0.0/0   tcp80
> 
> Corresponding |/etc/shorewall/mangle| are:
> 
> #MARK   SOURCE  DESTPROTO  DPORT   SPORT
> DIVERT  eth00.0.0.0/0   tcp-   80
> TPROXY(3129)eth10.0.0.0/0   tcp80
> 
> I presume "Corresponding..." down to the end of the quote is an unintentional
> duplicate. If not, I'm even more confused as mangle doesn't have a MARK 
> column.
> 
>

That should read:

Corrseponding /etc/shorewall/tcrules are:


The tcrules file DID have a MARK column.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Documentation error?

[Philip Le Riche]

Trying to set up a transparent proxy I'm slightly confused by the
following towards the end of
http://shorewall.net/Shorewall_Squid_Usage.html :

|/etc/shorewall/mangle| (assume loc interface is eth1 and net interface
is eth0):

#ACTION SOURCE  DESTPROTO  DPORT   SPORT
DIVERT  eth00.0.0.0/0   tcp-   80
TPROXY(3129)eth10.0.0.0/0   tcp80

Corresponding |/etc/shorewall/mangle| are:

#MARK   SOURCE  DESTPROTO  DPORT   SPORT
DIVERT  eth00.0.0.0/0   tcp-   80
TPROXY(3129)eth10.0.0.0/0   tcp80

I presume "Corresponding..." down to the end of the quote is an unintentional
duplicate. If not, I'm even more confused as mangle doesn't have a MARK column.

Regards - Philip


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DOCKER issue

[Tom Eastep]

On 08/08/2017 08:42 PM, Roland Schmid wrote:
> Hi Tom, 
> 
> Thanks for the response, sadly didn't work.
> Please find the 2 requested shorewall dumps attached
> 

Docker isn't installing any meaningful rules. From the first dump:

In the filter table, both the DOCKER and DOCKER-ISOLATION chains are empty.

Chain DOCKER (0 references)
 pkts bytes target prot opt in out source
destination

Chain DOCKER-ISOLATION (0 references)
 pkts bytes target prot opt in out source
destination

In the nat table:

Chain PREROUTING (policy ACCEPT 49 packets, 2913 bytes)
 pkts bytes target prot opt in out source
destination
  105  6506 DOCKER all  --  *  *   0.0.0.0/0
0.0.0.0/0ADDRTYPE match dst-type LOCAL

That sends all incoming connection requests that have a LOCAL
destination (address on the firewall) to the DOCKER chain.

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL
0 0 DOCKER all  --  *  *   0.0.0.0/0
!127.0.0.0/8  ADDRTYPE match dst-type LOCAL

Same for outgoing connection to a local destination other than the
loopback network. For some unknown reason, that rule is repeated 12 times.

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination
0 0 MASQUERADE  all  --  *  !docker0  172.17.0.0/16
0.0.0.0/0

After routing, all connection requests from 172.17.0.0/16 whose
destination is not the docker0 bridge, are masqueraded.

Chain DOCKER (13 references)
 pkts bytes target prot opt in out source
destination
0 0 RETURN all  --  docker0 *   0.0.0.0/0
0.0.0.0/0

The DOCKER chain does nothing but return for connections originating in
a container.

All of that nonsense is preserved when Shorewall starts, which is what
Shorewall attempts to do when DOCKER=Yes. In addition, Shorewall creates
many rules in the DOCKER-ISOLATION chain, but since Docker isn't
generating any jumps to that chain, those rules are ignored.

This is totally unlike anything I've seen from Docker. I've changed the
Subject in this response in the hope that someone who knows more about
Docker than I do can help.

In the meantime, I suspect that this will work if you add DNAT rules for
the traffic that you wish to forward from the wan zone to the dock zone.
I normally see those rules generated by Docker itself.

-Tom
-- 
Tom Eastep\   Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \   understand
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users