[Shorewall-users] DROP and COUNT with PROTO=255

[Tom Eastep]

Hi,
My last Shorewall rule is DROP with logging options (:info:polbl).
It's a custom DROP action identical to the upstream version, except
it includes the SRC IP addr. in an ipset.
I usually get messages in the log such as Shorewall:polbl:DROP...
Jun 5 16:47:51 kernel: Shorewall:polbl:COUNT:IN=enp9s5 OUT=
MAC=00:0d:88:cd:7f:c5:00:13:f7:23:ef:b4:08:00 SRC=1.2.3.4
DST=192.168.100.2 LEN=60 TOS=0x00 PREC=0x00 TTL=124 ID=10689
PROTO=255 MARK=0x2

- From your most recent dump:

Chain DROPBL (24 references)
pkts bytes target prot opt in out source
destination
4 1667 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 LOG flags 0 level 6 prefix "Shorewall:polbl:COUNT:"
0 0 ~log640 icmp -- * * 0.0.0.0/0
0.0.0.0/0 [goto] icmptype 3 code 4 /* Needed ICMP types */

What is the reason for which the packet was DROPped? What does
COUNT mean exactly, especially with PROTO=255?

That rule doesn't indicate that the packet is being dropped -- it
simply means that it is being logged and counted.

- -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
\_______________________________________________

[Tom Eastep]

________________________________ From: Tom Eastep

Post by Tom Eastep
That rule doesn't indicate that the packet is being dropped -- it
simply means that it is being logged and counted.

I'm asking because I created a custom Action (DROPBL) as you
previously suggested in another thread so that I could Drop and
insert the src IP address in an ipset if a client tried to connect
to an "unpublished" port.
My custom DROP action simply contains the following instruction at
ADD(POL_BL:src)

But you are invoking the action with a log level. So every rule in the
action body is generating log messages when matched. Since the first
entry in the action body is simply

DROP - -

every packet that is passed to the action produces a message.

- -Yom

- --
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
\_______________________________________________

[Philip Le Riche]

A student at school is working on getting Alexa working on a Raspberry
Pi. I've done it on one of my Pis and it works at home, but not at
school, I think because of the school web proxy. There seems to be a
paucity of information about proxy settings for Alexa, and it doesn't
appear to respect the system proxy settings in /etc/environment.

The Pi network is behind a Shorewall firewall to protect the school
network. So in a flash of inspiration, I thought I could simply DNAT the
http requests hitting Shorewall as default gateway, so automatically
redirecting them to the school proxy. That works for http, but not for
https.

After a little bit of digging to find out how a proxy functions for
https it became obvious that a simplistic DNAT couldn't work. It seems
that a browser, knowing that it's going through a browser, first sends
an unencrypted http CONNECT command before negotiating the ssl tunnel.

But would it be possible to somehow configure Shorewall, on receipt of a
tcp:443 connection request, to inject the CONNECT command into the
stream before starting to relay the ssl dialogue, quoting the pre-DNAT
destination ip address? How (in outline) could you achieve that?

Regards - Philip

[Tom Eastep]

Post by Philip Le Riche
A student at school is working on getting Alexa working on a
Raspberry Pi. I've done it on one of my Pis and it works at home,
but not at school, I think because of the school web proxy. There
seems to be a paucity of information about proxy settings for
Alexa, and it doesn't appear to respect the system proxy settings
in /etc/environment.
The Pi network is behind a Shorewall firewall to protect the
school network. So in a flash of inspiration, I thought I could
simply DNAT the http requests hitting Shorewall as default gateway,
so automatically redirecting them to the school proxy. That works
for http, but not for https.
After a little bit of digging to find out how a proxy functions
for https it became obvious that a simplistic DNAT couldn't work.
It seems that a browser, knowing that it's going through a browser,
first sends an unencrypted http CONNECT command before negotiating
the ssl tunnel.
But would it be possible to somehow configure Shorewall, on receipt
of a tcp:443 connection request, to inject the CONNECT command into
the stream before starting to relay the ssl dialogue, quoting the
pre-DNAT destination ip address? How (in outline) could you achieve
that?

See
http://roberts.bplaced.net/index.php/linux-guides/centos-6-guides/proxy-server/squid-transparent-proxy-http-https

- -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
\_______________________________________________

[Philip Le Riche]

Thank you Tom. I'd seen that there were various guides around for using
Squid as an intercepting proxy, but I don't want to crack open the ssl,
and anyway, since I can't find how to make Alexa use a proxy, I'm not
sure it'd be any easier to find its certificate store in order to inject
a squid certificate.

All I want to do is get Shorewall (or something running on the Shorewall
server) to field 443 connections and insert an http CONNECT verb before
relaying all subsequent traffic to the school proxy. If Shorewall
doesn't itself offer such a function I presume I could use it to DNAT
https to localhost and set up a Perl script to listen on localhost:443
then open an onward connection to the school proxy, inserting the
CONNECT verb before the outgoing traffic. Unless I've totally
misunderstood how an https proxy works.

Simply injecting the CONNECT verb before starting the ssl negotiation
must be pretty much what a browser on the school network does since the
school proxy doesn't require the installation of a certificate and
doesn't intercept ssl traffic.

Regards - Philip

Post by Tom Eastep

Post by Philip Le Riche
A student at school is working on getting Alexa working on a
Raspberry Pi. I've done it on one of my Pis and it works at home,
but not at school, I think because of the school web proxy. There
seems to be a paucity of information about proxy settings for
Alexa, and it doesn't appear to respect the system proxy settings
in /etc/environment.
The Pi network is behind a Shorewall firewall to protect the
school network. So in a flash of inspiration, I thought I could
simply DNAT the http requests hitting Shorewall as default gateway,
so automatically redirecting them to the school proxy. That works
for http, but not for https.
After a little bit of digging to find out how a proxy functions
for https it became obvious that a simplistic DNAT couldn't work.
It seems that a browser, knowing that it's going through a browser,
first sends an unencrypted http CONNECT command before negotiating
the ssl tunnel.
But would it be possible to somehow configure Shorewall, on receipt
of a tcp:443 connection request, to inject the CONNECT command into
the stream before starting to relay the ssl dialogue, quoting the
pre-DNAT destination ip address? How (in outline) could you achieve
that?

See
http://roberts.bplaced.net/index.php/linux-guides/centos-6-guides/proxy-server/squid-transparent-proxy-http-https
-Tom

[Tom Eastep]

Post by Philip Le Riche
Thank you Tom. I'd seen that there were various guides around for
using Squid as an intercepting proxy, but I don't want to crack
open the ssl, and anyway, since I can't find how to make Alexa use
a proxy, I'm not sure it'd be any easier to find its certificate
store in order to inject a squid certificate.
All I want to do is get Shorewall (or something running on the
Shorewall server) to field 443 connections and insert an http
CONNECT verb before relaying all subsequent traffic to the school
proxy. If Shorewall doesn't itself offer such a function I presume
I could use it to DNAT https to localhost and set up a Perl script
to listen on localhost:443 then open an onward connection to the
school proxy, inserting the CONNECT verb before the outgoing
traffic. Unless I've totally misunderstood how an https proxy
works.

I know of no way to make iptables do that; hence, Shorewall doesn't
support it. The only way that I have done HTTPS proxying with is to
use WPAD via DNS.

- -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
\_______________________________________________

[Lennart Sorensen]

Post by Philip Le Riche
Thank you Tom. I'd seen that there were various guides around for using
Squid as an intercepting proxy, but I don't want to crack open the ssl,
and anyway, since I can't find how to make Alexa use a proxy, I'm not
sure it'd be any easier to find its certificate store in order to inject
a squid certificate.
All I want to do is get Shorewall (or something running on the Shorewall
server) to field 443 connections and insert an http CONNECT verb before
relaying all subsequent traffic to the school proxy. If Shorewall
doesn't itself offer such a function I presume I could use it to DNAT
https to localhost and set up a Perl script to listen on localhost:443
then open an onward connection to the school proxy, inserting the
CONNECT verb before the outgoing traffic. Unless I've totally
misunderstood how an https proxy works.

I don't think this can be done. If the client expects to make an https
connection directly to the server, it tries to connect to the IP of
the server. If you intercept it with the firewall to redirect it to
something, you need to then somehow track where the original destination
was, so that you can issue the CONNECT to that target when you receive
the intercepted connection. I suppose a program that listens to tcp
connections that you could forward to, and checks the connection tracking
information might actually be able to do it, but I have never seen such
a program, so you would probably have to write one yourself.

Post by Philip Le Riche
Simply injecting the CONNECT verb before starting the ssl negotiation
must be pretty much what a browser on the school network does since the
school proxy doesn't require the installation of a certificate and
doesn't intercept ssl traffic.

Well you might be able to run squid in transparent proxy mode, have
shorewall forward all outbound http/https connections to squid, and then
configure squid to forward connections to the other proxy.

Works great for http, but for https you do need certificate stuff on
the client and squid to make things work. https really only works OK
with proxies when the client is explicitly configured to use one.