PolarProxy and Security Onion 2.2

[Jonathan]

Hi,

First let me say, security onion is kick ass. Thank you to everyone who has developed this piece of software.

Now, I’m trying to set up PolarProxy to add decrypted TLS data to the database. I’m using the standalone setup of Security Onion 2.2 and was wondering if anyone had any input on what might be different to set this up as opposed to using SO 16.04. This website has a detailed guide on how to set it up for 16.04 and I’m just wondering how relevant it is for 2.2 with changes to the way the firewall and routing is set up in the new version.

https://www.netresec.com/?page=Blog&month=2020-01&post=Sniffing-Decrypted-TLS-Traffic-with-Security-Onion

For example the guide mentions setting up a dummy interface and using tcpreplay to send the decrypted data to the interface, can I just have tcpreplay send data to my current interface that is sniffing network traffic?

SecurityOnion 16.04 uses ufw for firewall, what does 2.2 use to allow the proxy ports to be opened?

My last question is more specific to my own setup, as I use OPNsense, but if I want to configure my router/gateway I just need to enable port forwarding in the settings on my router and point all TLS traffic to the Security Onion server running PolarProxy? Will this interfere with my web access to the server?

[Wes Lambert]

Salt is managing firewall rules for the grid in 2.x.  Underneath it's still using iptables, however.

https://docs.securityonion.net/en/2.3/firewall.html

For the last question, you'll need to consult vendor documentation/the PolarProxy blog post.

Thanks,

Wes

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/5b7a6ab4-fc2e-473c-a3ab-6c2ba1abb35cn%40googlegroups.com.

--

https://twitter.com/therealwlambert

https://securityonion.net/

[Erik Hjelmvik]

Hi Jonathan,

Replaying packets decrypted by PolarProxy to the interface used to sniff "normal" traffic should work but can be dangerous, depending on your setup. Tcpreplay will cause the decrypted packets to be transmitted FROM your sniffer interface TO the network it is connected to. If it is connected to a network tap, then that shouldn't be a big deal though. My recommendation is therefore to always configure a separate interface for the decrypted TLS traffic.

Forwarding outgoing TCP 443 traffic from your OPNsense firewall to TCP 10443 on the Security Onion server should not affect your own access to the SO server. However, if you also redirect TCP 443 traffic locally on the SO machine to 10443 then you will lose access to the https web service on SO.

One last thing, you can also run PolarProxy in Docker if you wish:

https://netresec.com/?b=20Accbd

I'd be happy to answer any additional questions you might have about PolarProxy!

Best regards,

Erik

To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/CAHjBB6ES9VwBEe0H5-1%3DJ2ZfvNBpqExP-YhJ5Yo-3g0a1vBaAA%40mail.gmail.com.

[Jonathan]

Hi Erik,

Thanks for getting back to me. I got PolarProxy installed on SO 2.2, it's using a dummy interface like described in the PolarProxy tutorial, this seems to be working. Though now I am having trouble configuring OPNsense port forwarding to capture traffic. Once I figure this out I'll write up the process for anyone who wants to try the same.

My setup is using a tap between the gateway and LAN access point, the SO management interface is also connected to the LAN access point.

I tried adding this NAT Forward rule in OPNsense: 

Interface: LAN

TCP IPv4

source: LAN net with any port,

destination: any destination with port 443, 

redirect to polaryproxy IP(192.168.1.3) port 10443

nat reflection: use system default (enabled)

automatic rules generated for firewall: enabled

In the NAT settings there are options for

Reflection for port forwards, enabled

Automatic outbound NAT for Reflection, enabled

With these rules going, I hit refresh on an https site, nothing loads, and PolarProxy shortly crashes right after... when I look at journalctl this is the output:

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:51359

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:60007

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:60136

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:9479

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:43495

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:18350

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:63989

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:54534

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:38743

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:45148

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:16869

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:57737

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:11496

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:39182

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:61013

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:44999

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:60132

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:13983

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:4090

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:60659

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:19147

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:11559

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: Unhandled Exception: System.AggregateException: One or more errors occurred. (Too many open files in system) ---> System.Net.Sockets.SocketException: Too many open files in system

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: at System.Net.Sockets.Socket.DoBeginAccept(Socket acceptSocket, Int32 receiveSize, AcceptOverlappedAsyncResult asyncResult)

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: at System.Net.Sockets.Socket.BeginAccept(Socket acceptSocket, Int32 receiveSize, AsyncCallback callback, Object state)

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: at System.Net.Sockets.Socket.BeginAccept(AsyncCallback callback, Object state)

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: at System.Net.Sockets.TcpListener.BeginAcceptTcpClient(AsyncCallback callback, Object state)

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: at System.Net.Sockets.TcpListener.<>c.<AcceptTcpClientAsync>b__28_0(AsyncCallback callback, Object state)

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: at System.Threading.Tasks.TaskFactory`1.FromAsyncImpl(Func`3 beginMethod, Func`2 endFunction, Action`1 endAction, Object state, TaskCreationOptions creationOptions)

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: at System.Net.Sockets.TcpListener.AcceptTcpClientAsync()

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [23B blob data]

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: --- End of inner exception stack trace ---

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: at System.Threading.Tasks.Task.WaitAllCore(Task[] tasks, Int32 millisecondsTimeout, CancellationToken cancellationToken)

Oct 11 23:42:44 h4x-1337 PolarProxy[30474]: [24B blob data]

Oct 11 23:42:45 h4x-1337 systemd[1]: PolarProxy.service: main process exited, code=dumped, status=6/ABRT

Oct 11 23:42:45 h4x-1337 systemd[1]: Unit PolarProxy.service entered failed state.

Oct 11 23:42:45 h4x-1337 systemd[1]: PolarProxy.service failed.

the list of connections logged from random ports is a few hundred to thousand long, then that sequence of errors and the PolarProxy crash, it looks like there are too many connections and PolarProxy can't handle it... but why is that happening?

Do you have any explanation on how I can fix this or what's going on?

Thanks,

Jonathan

[Jonathan]

I just had an idea,  since I have a tap on SO sniffing network data, is it possible to skip the gateway port forwarding and just forward the sniffed data as it is coming into SO?

 

For example, if PolarProxy is on the SO box and listening on port 10443 and my tap is on interface eno1, then I would put these rules on my SO machine:

 

sudo iptables -A INPUT -i eno1 -p tcp --dport 10443 -m state --state NEW -j ACCEPT

 

sudo iptables -t nat -A PREROUTING -i eno1 -p tcp --dport 443 -j REDIRECT --to 10443

 

Would this work? Are there any downsides to messing with the incoming data like that?

[Erik Hjelmvik]

Hi Jonathan,

About the "System.Net.Sockets.SocketException: Too many open files in system": We have not seen this happen before. Is there any chance you could send the full exception stack trace, including the 23 and 24B blob data, to info[at]netresec.com? We'd be happy to help figure out what might be going wrong there.

Can you please elaborate on the idea you mentioned ("skip the gateway port forwarding and just forward the sniffed data as it is coming into SO")? Do you mean that you want to forward the sniffed traffic from the network tap to PolarProxy? Unfortunately that will not work, because PolarProxy will need to be part of the communication chain in order to decrypt the TLS traffic. This decryption cannot be done passively.

Best regards,

Erik

To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/6fd7cf8c-4d54-4494-acdf-15f000c6436an%40googlegroups.com.

[Jonathan]

Erik,

I'm not sure how to retrieve stack trace information or 23/24B blob data, if you explain how I can try though. The error is reproducible if I turn on port forwarding to the SO/PP server, enable NAT reflection, and try to access an HTTPS. The server is getting flooded from the gateway with incoming requests and then that error occurs.

I suspect this has something to do with incorrect gateway settings (NAT reflection probably doesn't need to be enabled?) and SecurityOnion competing with PolarProxy for port 443 (HTTPS requests from my client are not reaching PolarProxy, instead they getting directed to the nginx server hosting the SO web GUI). For example if I try "curl --insecure --resolve www.netresec.com:443:192.168.1.3 https://www.netresec.com/", and 192.168.1.3 is my SO/PolarProxy server, I get an HTTP Error 302 from nginx server (which I'm assuming is the nginx server hosting SO 2.3 on port 443). 

However, if I modify the iptables and add: 

"-A PREROUTING -i enp0s20f0u4 -p tcp -m tcp --dport 4433 -j DNAT --to-destination 172.17.0.4:443" 

Then I can connect to SO 2.3 web GUI using port 4433, and then I have another rule for PolarProxy: 

"-A PREROUTING -i enp0s20f0u4 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 10443"

Then the curl command works from in my network.

Though this has it's own issue. Namely, I've noticed that Kibana and Playbook have internal url generation on their pages that don't pick up the 4433 switch and try to link to 443, making those pages unavailable. There may be other issues making this modification causes that I'm unaware of. I posted another conversation in this group regarding the ability to switch default 443 to and different port, maybe there is a solution there.

As far as the skipping the gateway idea, yeah... as soon as I posted that I realized it didn't make sense in terms of how TLS works. There's no undo post, haha.

Thanks,

Jonathan

[Jonathan]

Hey Erik,

I think I may have been going about this the wrong way, hence all the errors. 

What if I were to create a separate IP to forward traffic to, and for PolarProxy to listen on (using a virtual interface or another NIC)? That way there's no conflict and I don't have to mess around with (and likely break) the routing to my Security Onion setup. There wasn't really a need to have both services on the same IP and port.

Does PolarProxy have a configuration to listen on a specific interface or IP?

If not, then I realized I didn't quite understand how docker containers works until just now, and your earlier suggestion on setting up a docker is probably the way to go with this.

From what I'm reading, if I set up PolarProxy in docker, then I can use iptables to forward traffic going to the separate IP to the container via the docker IP... is that correct?

Looks like I'm learning as I'm going along here, so I appreciate the help.

Thanks,

J

[Erik Hjelmvik]

Hi Jonathan,

Yes, it can sometimes be a good idea to set up a separate nic + IP for PolarProxy depending on what else you're running on the PC. The "-p" argument in PolarProxy can be used to specify the IP and port like this:

 -p [LISTEN-IP,]LISTEN-PORT,DECRYPTED-PORT[,EXTERNAL-PORT]

For example: "-p 192.168.3.3,10443,80,443"

You can run "./PolarProxy --help" for more details.

However, if you run PolarProxy in Docker then there is no need to specify the IP address with "-p". As you mention, you'll instead use firewall rules to forward the incoming traffic to the internal IP of the Docker container running PolarProxy.

/erik

To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/ee7a3469-1cb5-4129-aee2-a594e55727fen%40googlegroups.com.

[Jonathan]

So the separate NIC was proving to be more a hassle than anything. I went with changing the PolarProxy 443 port. Now, I've got PolarProxy set up in Docker alongside Security Onion and I can connect to get the cert. I've changed the port that PolarProxy listens on by changing all mentions of 443 to 444 in your Docker tutorial, that way Security Onion web UI doesn't conflict. 

Now I'm having trouble with my gateway iptables... I think I have to set a return path for the traffic, since HTTPS is now locally on 444 instead of 443, but I'm not sure how.

Here's what I've got so far:

Separate gateway config with Proxy on same subnet as local network, basically from your website:

iptables -A FORWARD -i br-lan -d 192.168.1.3 -p tcp --dport 10443 -m conntrack --ctstate NEW -j ACCEPT

iptables -t nat -A PREROUTING -i br-lan ! -s 192.168.1.3 -p tcp --dport 443 -j DNAT --to 192.168.1.3:10443

iptables -t nat -A POSTROUTING -o br-lan -d 192.168.1.3 -p tcp --dport 10443 -j MASQUERADE

FYI I learned if you want PolarProxy ports to be open you have to put this in after SO is finished launching:

iptables -I DOCKER-USER -p tcp --dport 10080 -j ACCEPT

iptables -I DOCKER-USER -p tcp --dport 10443 -j ACCEPT

iptables -I DOCKER-USER -p tcp --dport 444 -j ACCEPT

and similar rules in firewalld

So yeah I think I"m missing the return path but not sure what the command is.

Right now I'm getting  a lot of this on my log output:

<3>[10443] 192.168.1.1 -> www.netresec.com Failed to connect to www.netresec.com

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:49064

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:29120

<3>[10443] 192.168.1.1 -> api.trakt.tv Failed to connect to api.trakt.tv

<3>[10443] 192.168.1.1 -> www.netresec.com Failed to connect to www.netresec.com

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:29123

<3>[10443] 192.168.1.1 -> www.netresec.com Failed to connect to www.netresec.com

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:29128

<3>[10443] 192.168.1.1 -> www.netresec.com Failed to connect to www.netresec.com

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:29131

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:64765

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:64766

<3>[10443] 192.168.1.1 -> www.netresec.com Failed to connect to www.netresec.com

<3>[10443] 192.168.1.1 -> gs-loc.apple.com Failed to connect to gs-loc.apple.com

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:64767

<3>[10443] 192.168.1.1 -> gs-loc.apple.com Failed to connect to gs-loc.apple.com

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:64768

<3>[10443] 192.168.1.1 -> gs-loc.apple.com Failed to connect to gs-loc.apple.com

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:64769

Thanks.

[Erik Hjelmvik]

You're almost there Jonathan. I hope we can figure out what is going wrong.

I'm not sure what you mean by "return path". It looks as if the connections are coming from 192.168.1.1, which I assume is your gateway router. This is expected if you're using what I call "Routing Option #2" in the PolarProxy documentation. It also means that the MASQUERADE rule seems to be working.

I noticed some entries like these ones in your PolarProxy output:

<3>[10443] 192.168.1.1 -> api.trakt.tv Failed to connect to api.trakt.tv

<3>[10443] 192.168.1.1 -> www.netresec.com Failed to connect to www.netresec.com

It looks as if PolarProxy cannot establish an outgoing connection to the real server. Is there some firewall rule in place that is blocking or preventing the PolarProxy machine from accessing external IPs on TCP port 443? Can you curl to those sites from the PolarProxy PC?

If you cannot use TCP 443, because it is already taken by another service, then my recommendation would be to ONLY listen on the 10443 port. Adding port forwarding from ports other than 443 will just add unnecessary complexity.

Best regards,

Erik

To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/93786611-88f9-4ea4-b69d-e255152e0a7an%40googlegroups.com.

[Jonathan]

Hi Erik,

Yes! Almost there! I am using "Routing Option #2" with MASQUERADE, because the proxy/SO box is separate from my gateway router and on the same subnet. 

I couldn't figure out what the "Failed to connect" issue was, though now that you explained it to me, an issue with the outgoing connection makes more sense. I was thinking the subsequent reply was being blocked or dropped somehow. So by "return path" I meant the reply to my connection attempt, going from the internet server to my computer, or in other words the route the packets take from the internet back to my client.

As per your suggestion I dropped any localhost forwarding from 443 or 443 to 10443...

docker create -p 10443:10443 -p 10080:10080 --name polarproxy polarproxy-image

Running this worked for about 10 minutes, pretty exciting! Then for some reason it stopped... using nmap from another computer showed ports 10443 and 10080 going from open (when it was working) to filtered (when it stopped working). I suspect it has something to do with either docker or SO refreshing their rules in IPtables, so I tried this: 

docker create -p 10443:10443 -p 10080:10080 --net=host --name polarproxy polarproxy-image

Thinking if i make a direct network connection to the host interface it will bypass any of those rules, and it seems to be working!!

I set up nc and tcpreplay without issue, so it should be playing to the "decrypted" dummy interface... though I'm not sure how to look for that interface in kibana or hunt, I will have to dig around and figure it out.

This is a sample of the PolarProxy log output. It looks like a lot of the sessions are not successful. Is this normal behavior?

<4>[10443] 192.168.1.1 -> chat-pa.clients6.google.com System.IO.IOException : Authentication failed because the remote party has closed the transport stream.

<4>[10443] 192.168.1.1 -> chat-pa.clients6.google.com Internal and/or external SSL session did not authenticate successfully

<6>[10443] 192.168.1.1 -> chat-pa.clients6.google.com Connection request for: chat-pa.clients6.google.com from 192.168.1.1:1432

<6>[10443] 192.168.1.1 -> people-pa.clients6.google.com Connection request for: people-pa.clients6.google.com from 192.168.1.1:1431

<6>Using cached certificate for chat-pa.clients6.google.com : 2210082BE23749EED38F016C38E932AF77E67853

<6>Using cached certificate for people-pa.clients6.google.com : 2210082BE23749EED38F016C38E932AF77E67853

<4>[10443] 192.168.1.1 -> chat-pa.clients6.google.com System.IO.IOException : Authentication failed because the remote party has closed the transport stream.

<4>[10443] 192.168.1.1 -> chat-pa.clients6.google.com Internal and/or external SSL session did not authenticate successfully

<4>[10443] 192.168.1.1 -> people-pa.clients6.google.com System.IO.IOException : Authentication failed because the remote party has closed the transport stream.

<4>[10443] 192.168.1.1 -> people-pa.clients6.google.com Internal and/or external SSL session did not authenticate successfully

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:1438

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:1439

<6>[10443] 192.168.1.1 -> signaler-pa.clients6.google.com Connection request for: signaler-pa.clients6.google.com from 192.168.1.1:1438

<6>[10443] 192.168.1.1 -> signaler-pa.clients6.google.com Connection request for: signaler-pa.clients6.google.com from 192.168.1.1:1439

<6>Using cached certificate for signaler-pa.clients6.google.com : 2210082BE23749EED38F016C38E932AF77E67853

<6>Using cached certificate for signaler-pa.clients6.google.com : 2210082BE23749EED38F016C38E932AF77E67853

<6>[10443] 192.168.1.1 -> signaler-pa.clients6.google.com Action: DECRYPT

<6>[10443] 192.168.1.1 -> signaler-pa.clients6.google.com Action: DECRYPT

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:1450

<6>[10443] 192.168.1.1 -> update.googleapis.com Connection request for: update.googleapis.com from 192.168.1.1:1450

<6>Using cached certificate for update.googleapis.com : 65A848C463D51405B6023DDF195DFF90F67144E6

<6>[10443] 192.168.1.1 -> update.googleapis.com Action: DECRYPT

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:1452

<6>[10443] 192.168.1.1 -> activity.windows.com Connection request for: activity.windows.com from 192.168.1.1:1452

<6>[10443] 192.168.1.1 -> activity.windows.com Action: DECRYPT

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:1454

<6>[10443] 192.168.1.1 -> substrate.office.com Connection request for: substrate.office.com from 192.168.1.1:1454

<4>[10443] 192.168.1.1 -> substrate.office.com System.IO.IOException : Authentication failed because the remote party has closed the transport stream.

<4>[10443] 192.168.1.1 -> substrate.office.com Internal and/or external SSL session did not authenticate successfully

<6>[10443] 192.168.1.1 -> N/A Connection from: 192.168.1.1:1458

Thanks so much for the help, this has been a good learning experience. I hope other people find this useful in their own setups.

[Erik Hjelmvik]

Great work! Looks like you got PolarProxy running successfully using Docker in SO 2.2!

Is your dummy NIC configured as a Sniffing/Monitoring NIC in Security Onion? If not then you'll need to do that to get the decrypted traffic into Kibana / Hunt etc.

PolarProxy log entries saying "System.IO.IOException : Authentication failed because the remote party has closed the transport stream." might be caused by clients that don't trust the PolarProxy root CA.

Google products (like Chrome) typically use certificate pinning when connecting to Google services. Thus trusting the PolarProxy root CA will not be enough, they will reject the certificate anyway. I'm not sure if it is possible to disable certificate pinning in Chrome. I find that Firefox is much better suited for this.

There are also a few applications/services on Windows that won't accept the PolarProxy certificate even if you tell the OS to trust the certificate. I'm not sure if it's due to certificate pinning or if these applications don't rely on the computer's central "Trusted Root Certification Authorities" storage.

You can use the "--bypass <file>" argument in PolarProxy to tell it which domains you'd like it NOT to decrypt. PolarProxy will then simply let those TLS sessions pass right through without decrypting them. The "<file>" argument should be a text file with regex representations of domains to bypass. Here's an example:

^www\.netresec\.com$

.*\.google\.com$

This config will match the domain www.netresec.com and any subdomains of google.com. Since you're using Docker, make sure to put the config file in the volume for "/home/polarproxy/" so that you can update it more easily.

/erik

To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/1dd95a99-2f9d-4481-b7c6-8dfa8f757365n%40googlegroups.com.

[Jonathan]

Thanks Erik!

I had configured the dummy "decrypted" NIC as a monitoring NIC during SO setup, but it seems like SO is not picking up the traffic that is being forwarded to the interface using nc and tcpreplay... I'm not sure if SO disabled/ignored the "decrypted" interface during setup even though I chose it as a secondary monitoring interface... i'm guessing this being using nmcli post SO install shows my main sniffing interface (eno1) as green, active, and bonded to bond0, while decrypted is grey and unmanaged. I will have to try tcpreplay on eno1 or bond0 to see if that works, then i know it's the dummy interface.  In the meantime I have just had it writing to a file and been inspecting the file in Wireshark, extracting the files and looking at the data. Getting it to play in tcpreplay into SO is the next step.

Interesting point on pinning, I wasn't aware of that till you mentioned it, got me looking at all different ways SSL certificates are handled.