Snort QUIC detection
-
Snort is completely oblivious? That's not good for tunneling issues and detection.
I brought this up because I keep thinking about how that will ripple into the firewall market very soon. I understand the post is for the update issues with Cisco's Snort subscriber rules. I just keep thinking about the content accelerators, transparent proxies, the firewall and snort everything that requires new software because of major protocol changes. Lots of new code and long hours are needed to understand it. It's not going away it's going to be used more and more. Thanks for all you do cheers.
-
@jonathanlee said in Snort Update error 422:
Snort is completely oblivious? That's not good for tunneling issues and detection.
You do know that no IDS can inspect encrypted traffic unless you run a MITM setup on the firewall? HTTPS/3 is encrypted, thus the IDS (Snort or Suricata) can see nothing inside the data payload. All it can see is what little piece of the header remains in the clear. And for now it can see the initial exchanges about SSL certs. That's how OpenAppID can work. But it obviously can't see the actual keys exchanged and is therefore unable to decrypt the traffic.
I have mentioned in several threads over the last couple of years that the exponential growth of encryption is effectively neutralizing all IDS/IPS on edge devices such as firewalls. Your best location for IDS/IPS now is on the endpoint client where the traffic is eventually decrypted and available in the clear. The only way to utilize Snort or Suricata on a firewall and scan everything is to implement a man-in-the-middle solution that breaks the certificate chain of trust. And that is not a good solution.
Here is some of the traffic that is today routinely encrypted, while a few years ago it was all in the clear.
- SMTP/POP3 email
- DNS
- HTTP
- FTP
- Telnet
Today that is usually the following instead:
- SMTPS/POP3S/IMAPS
- DoT or DoH
- HTTPS
- SFTP
- SSH
And then there is the whole VPN traffic model. So the days of IDS/IPS on firewalls is limited in my view.
-
@bmeeks Palo Alto Firewalls can decrypt at the proxy. The proxy intercepts the traffic and decrypts in the proxy with SSL certificates and inspects traffic for issues. It can be done we did it in a lab in college a couple weeks ago. We had the certificates intercepted and decoded. Again this is a very large enterprise class firewall.
From Palo Alto knowledge base:
"PAN-OS can decrypt and inspect inbound and outbound SSL connections going through a Palo Alto Networks firewall. SSL decryption can occur on interfaces in virtual wire, Layer 2, or Layer 3 mode by using the SSL rule base to configure which traffic to decrypt. In particular, decryption can be based upon URL categories, source users, and source/destination IP addresses. Once traffic is decrypted, tunneled applications can be detected and controlled, and the decrypted data can be inspected for threats. . ."Make sure to upvote
-
@jonathanlee that would be App-ID classification use. IDS/IPS one can say is not limited just needs a good upgrade with lots of coffee. The http get requests are what confuses me with the new https3 the get requests hold so much data that can be tracked if it is out of the norm.
-
@jonathanlee but it all will require a content accelerator or transparent proxy and use of SSL certificates. Snort + Squid = Epic IPS
-
@jonathanlee said in Snort Update error 422:
@bmeeks Palo Alto Firewalls can decrypt at the proxy. The proxy intercepts the traffic and decrypts in the proxy with SSL certificates and inspects traffic for issues. It can be done we did it in a lab in college a couple weeks ago. We had the certificates intercepted and decoded. Again this is a very large enterprise class firewall.
From Palo Alto knowledge base:
"PAN-OS can decrypt and inspect inbound and outbound SSL connections going through a Palo Alto Networks firewall. SSL decryption can occur on interfaces in virtual wire, Layer 2, or Layer 3 mode by using the SSL rule base to configure which traffic to decrypt. In particular, decryption can be based upon URL categories, source users, and source/destination IP addresses. Once traffic is decrypted, tunneled applications can be detected and controlled, and the decrypted data can be inspected for threats. . ."This is what I meant by "man-in-the-middle", or MITM. That is what proxies and trusted certs are about on the firewall. But doing this breaks the chain of trust, and really only works in a large corporate environment where the company has total control of end-user devices and can force install the needed cert chain on them, or else force use of the proxy and its cert chain. The garden variety BYOD (bring your own device) folks are usually restricted to just Internet access only in that scenario.
You can't reasonably do MITM for things like WiFi cafes, hotels, or even smaller businesses without a larger, dedicated, and highly skilled IT staff to look after such setups. I did not say in my original post that it could not be done. I instead said it was difficult due to the need for MITM, and then I stated MITM breaks the chain of trust and presents an ethical issue in and of itself. For example, you would be able as the firewall admin to peer into the personal banking transactions of employees if they accessed their bank account over the company network. Is that really ethical?
A company that can afford Palo Alto is likely not going to permit an open-source product into their house. I worked at such a large corporation before I retired. Open-source anything was actually forbidden by official policy. The closest thing allowed was RedHat Linux, but we had to use the paid-support channel. No CentOS was allowed, although they are basically the same thing.
-
@bmeeks thank for the reply.
Palo Alto will not ever allow you to peer into anything with decryption such as banking information transactions. All it does is decrypt and match what app is in use for a specific tunnel when it is decrypted and parses the data to remove the built in spyware and malware. Remember on Senate hearing for Data mining with Facebook, Palo Alto blocks such use of that built in spyware software and nothing else. On the admin side you just see Facebook-Base and the lists of spyware blocked or Google-Base and list of spyware blocked. The tunnels that come with SSL is what is stopped and inspected for illegal use with signature matching. No one wants Facebook or Google sending personal information or Banking Transactions overseas with a tunnel or harvesting data like that. It is not ethical to do that on their side with Privacy Laws.
Make sure to upvote
-
This is a great conversation. I wanted to share with you a small part of of our class lab that shows what the firewall admin really sees, it is nothing but the signatures that decode the issues. Just much like modern antivirus software. It matches the issues and blocks then with decryption, nothing more. I cant see anything like Bank information just "Spyware."
The images are when Google-base use was decoded. Look at all the bugs they had hidden in the SSL encryption. There is so many, to many for Data protections. I wonder what Facebook's looked like before the Senate hearing. You can still see some, imagine someone looking at Facebook at work, wouldn't you want this blocked at the Bank so the spyware cant run, or at a hospital.
(Image: Logs showing nothing that relates to anything but file signatures that would show issues much like antivirus software)
(Image: You can also block web search anonymizers that normally would be allowed without use of such a tool.)
(Image: Testing block of this signature)
(Image: logs show nothing that is related to private information)
Use of this never reveals much beyond what threats are seen with the matching signatures.
-
@jonathanlee All of that has to send some type of http get request out when its used. With HTTPS3 I wonder what kind of HTTPS3 get request is used.
-
@jonathanlee said in Snort Update error 422:
@bmeeks thank for the reply.
Palo Alto will not ever allow you to peer into anything with decryption such as banking information transactions. All it does is decrypt and match what app is in use for a specific tunnel when it is decrypted and parses the data to remove the built in spyware and malware. Remember on Senate hearing for Data mining with Facebook, Palo Alto blocks such use of that built in spyware software and nothing else. On the admin side you just see Facebook-Base and the lists of spyware blocked or Google-Base and list of spyware blocked. The tunnels that come with SSL is what is stopped and inspected for illegal use with signature matching. No one wants Facebook or Google sending personal information or Banking Transactions overseas with a tunnel or harvesting data like that. It is not ethical to do that on their side with Privacy Laws.
Sorry, but you are missing my point entirely. It has nothing at all to do with what Palo Alto might or might not allow you to see within their applications. The point is that once an SSL session is intercepted and decrypted, everything in that session is visible to the person controlling the interception and decryption. The only thing that protects you then is the integrity of the person with the keys. A not-so-ethical firewall admin most certainly could use the broken decryption chain as a means to gather confidential details such as login credentials to external sites.
But this conversation has pretty much totally hijacked the original thread and is not related at all to the original problem.
-
Yes one can say the same about Google and Facebook once pure encrypted non firewalled traffic is let go on a private network, what is to stop them from data mining? Yes I understand this is gone a different path then the post. However we have seen what occurred on the Untied States Senate Hearing about data mining already once. This was never to be about law and ethics on what is allowed or should or should not be done on this post. Protocol changes and the approval of their use is a different topic all together. "The preemption doctrine refers to the idea that a higher authority of law will displace the law of a lower authority of law when the two authorities come into conflict." Yes "Facebook" has no authority over rules on Network comminutions. Protocol changes need approval. That is why I can block 443UDP. Have a good one great conversation. Palo Alto also as of a couple days ago can use App-ID with QUIC HTTPS3, so it is safe from abuse again. SSL decryption software inside of non-open source software is not normally seen by others without approval. Years ago they use to use RSA keys for so many items even parts look up for equipment for service techs.
-
@bmeeks Don't get me wrong I love to talk shop it is its own language talking about firewalls with other people. Thank you for all you do. Have a great day. On Palo Alto's side you have to install certificates on the devices so it is encrypted again as it leaves the firewall to the lan side. Maybe the proxy is encrypted also.
-
F fireodo referenced this topic on
