ABOUT
Posts Tagged ‘Zorp’
netfilter.org says thanks
You may not know, but I used to contribute to the Linux packet filtering subsystem called Netfilter: I primarily worked on transparent proxying, the technology needed for our proxy based firewall/gateway product, Zorp. If I remember correctly, we completely revamped that thing about 3 times, until it got integrated into the kernel.
Because of my Netfilter work and my affiliation with BalaBit, BalaBit has been a sponsor of Netfilter Workshop, the annual gathering for Netfilter developers. This is a very enjoyable occassion, at least I do enjoy meeting with guys like Patrick McHardy, David Miller, Harald Welte and the others. I’ve learned a lot from them.
I was told that because of our past support BalaBit got included into the “Thanks” section of netfilter.org, I’m proud of being mentioned there, being a (small) part of something that is deployed on the Internet in such great numbers is a good feeling.
Netfilter Workshop 2010
Among others I’m somewhat involved into Linux Netfilter development because of our Zorp proxy based product. It is that time of the year again that Netfilter developers converge, this time to Seville, thanks to our generous host Pablo Neira. So I may not be that responsive this week, but I’ll definitely check emails and possibly even respond to them if you care to post a feedback on the last syslog-ng release.
Read on the Netfilter Workshop at Eric’s blog at: http://nfws.edenwall.com/en.
Introducing Zorp
You may not know but in addition to my work on syslog-ng I fulfill a couple of roles in BalaBit. Among others I’m the product manager of Zorp Gateway an application layer firewall. The reason of my silence on this front basically was that there’s a long ongoing project inside the company walls to produce the next major version and I don’t like talking about something where you don’t have anything tangible. This however is changing, Zorp4 (or the way we sometimes call it Zorp-NG 
is coming around: a first, internal preview release was made available a month ago and development towards the first customer release is progressing at full speed.
Those readers who don’t know Zorp, let me introduce it: it is a proxy based, transparent firewall product, capable of processing more than 20 application layer protocols. In addition to merely mediating traffic between peers, it also allows advanced transformation and actions on the traffic going through. It was the first product which decrypted SSL streams back in 2000 and made it possible to scan for viruses in SSL encrypted protocols like POP3S. Although the advanced functions Zorp had from the very beginning are very useful and are unique today, the current User Interface for Zorp 3 is difficult for most users to handle. Therefore we started to create a new user interface from scratch and this is going to be Zorp4.
Zorp is different from a lot of other firewall products in various ways, I’ll try to summarize those differences in upcoming blog posts.
The actuality of this post is however the release of two maintenance releases, one for each of the two currently supported branches: 3.3 and 3.3fr1. Right now we create maintenance releases three times a year.
Some of the interesting changes/corrected bugs:
- The Commtouch content filtering engine performing SPAM filtering has been updated to version 6.02.0034.
- Generating the ‘Service report in CSV’ report is now significantly faster: generating the report for configurations having thousands of zones and services takes now minutes instead of several hours.
- Some network interface drivers were updated in the kernel to support newer hardware.
- Zone matching in packet filter rules work for any IPv4 transport protocols (not just for TCP/UDP).
- In certain cases, when creating a dispatcher, ZMC reported a false collision. This has been corrected.
- In certain cases, the configuration generated for road warrior IPSec connections was incorrect. This has been corrected.
- We added support for Windows 7 in the The Zorp Authentication Agent.
For detailed information see the changelog by following this link: http://www.balabit.com/files/zorp-pro/3.3R7/changelog-en.txt or for FR1 http://www.balabit.com/downloads/files/zorp-pro/3.3fr1R2/changelog-en.txt
SFTP proxy
I installed Google analytics on this blog, and as it seems a number of people come here looking for “SFTP proxy”, because of an old article I posted last July. Those interested primarily in my syslog-ng related articles may skip this post as this contains completely unrelated information, others please read on.
For those who don’t know: SFTP is a file-system sharing protocol running on top of SSH. It is not yet an IETF standard, however more and more enterprises replaces the aging FTP protocol for SFTP. The reasons are numerous:
- FTP uses plain text passwords,
- FTP uses multiple TCP connections for file transfer,
- FTP has inherent problems like bounce attacks,
- FTP does not encrypt traffic,
- FTP only supports filesystem metadata (last modification time, etc.) via extensions
- and others.
All-in-all SFTP is newer, shinier and designed better. There’s one problem though: SFTP uses SSH and SSH is encrypted. But wait, I said this is a drawback for FTP. Right, using encryption is good and bad at the same time. Good, because it prevents eavesdropping, bad because it cannot be controlled by security devices at the network perimeter.
Sometimes is it quite useful to see what’s going on in a traffic crossing the network borders: you can restrict the usage of SFTP to a set of trustworthy clients, not for everyone. And even them can be controlled by enabling a full transaction log.
If your enterprise allows FTP traffic, there are tools to log FTP transfers, and in extreme cases to log actual data. For SFTP this is not so simple, once you permit outgoing port 22 (used for SSH), complete file system sharing can cross your firewall without you noticing. Scary, eh?
There are currently two solutions for this problem:
- Disable SSH and use FTP instead. This has the drawback that passwords travel in unencrypted form, and the traffic itself is easily sniffable.
- Use something like our Shell Control Box product, it is based on Zorp, with a complete SSH man-in-the-middle implementation, controls various SSH channels, limits what can get through, can log transaction data, and furthermore: at the end of the day the transmitted data is still encrypted on untrusted networks.
SCB is not using any of the OpenSSH code, it is a complete reimplementation of the SSH protocol stack, and because of Zorp all of it can run transparently (even in bridge mode) working in concert with your other firewalls/security devices.
So if you need to install proper SFTP controls, be sure to check it out.
Some kernel hacking
After some time I needed to do some kernel coding again. To seamlessly support dynamically created interfaces in Zorp, we need something I called “interface groups”.
Each interface might belong to a single group that basically describes how the interface was created. For instance there’s an interface group for each PPP profile, but an interface group can encapsulate interfaces created by PPTPD.
It is quite difficult to match dynamic interfaces by their nature: iptables sports wildcard interface name matching with the ‘+’ character but it only works if interface names have some kind of prefix _AND_ if you don’t want to differentiate between two groups.
If you have two sets of PPP devices (like in the example I described above), then you have no way to create a separate ruleset, unless you reload iptables everytime a new interface is added to the system.
Adding to the burden, in Zorp we want to be able to bind a service to these dynamically created interfaces, of course without listing the actual IP address in the configuration file.
The idea is simple, I added an “interface group ID” to the net_device struct, and an option to the “ip link” command to set/query this ID. Once an interface is created by some kind of program (for instance pppd), a script is executed in its /etc/ppp/ip-up.d directory and userspace can assign a group ID based on the PPP profile name. Then Zorp gets notified about the change through NETLINK and can react by binding to the IP address of the new interface. The configuration remains static, no reloading needs to be done when such a change happens, and you can create firewall policies for something like: please allow this set of services for everyone using this PPP profile, without entering one specific IP address to the configuration. Neat, eh?
I posted my work on netdev and netfilter-devel, I’m curious what the kernel maintainers will think about it.
SSH publickey authentication implemented
I have hacked on our SSH gateway today to add publickey authentication support. By the way I may not have explained this before, so a short introduction is due: Zorp is an application layer gateway with support for 21 protocols, among them an SSH gateway capable of looking into the encrypted SSH stream and restricting the protocol to a subset that you really want to allow to your users. (e.g. you can forbid TCP port forwarding while still allowing terminal access).
The problem with publickey authentication is that the signature covers the so called SSH session_id which is a unique value derived during key exchange. My proxy implements a man-in-the-middle, so the clientproxy and proxyserver connections have a different session id, thus simply replaying the authentication packets of the client will not work since the SSH session ids do not match.
The solution is that we are going to replace user keys transparently when crossing the firewall, which means that private keys need to be stored there. This is both a feature and a drawback: a feature since you can control which keys you are allowing to leave your perimeter and a drawback as this requires additional management tasks. It would have been so much nicer if we could do this transparently, but I am afraid this is not possible unless we modify all clients out there or alternatively we manage to find a way to crack the Diffie-Hellmann key exchange algorithm.
On the syslog-ng side I have committed a fix to make files over 2GB work again. It should be available in the next snapshot shortly. I’m also thinking about preparing 1.9.10 with the fixes accumulated so far.
Spending time in gdb…
I have spent the last three days debugging an ugly crash in the upcoming Zorp 3.1. First I had some problems with the core files produced with Linux 2.6.12, as the register values proved to be invalid, thus the backtrace was even more unusable than it is usual with heap corruptions.
I could get access to the original register values as Zorp dumps part of its stack when a fatal signal is encountered. Using that information I could locate the stack frame of the signal handler and luckily Linux passes a “struct sigcontext” to each signal handler as parameter which contains register information. But nevertheless it made analyzing the core files difficult.
After a post to the gdb mailing list it turned out to be a kernel problem rather than a gdb problem and with the help of my collegue Krisztián Kovács (of Netfilter ct_sync fame) we could solve the problem by backporting a fix from 2.6.15, so core files are now ok.
The problem however seems to be difficult, I have already studied the libc malloc implementation, disassembled and annotated the _int_malloc and _int_free functions, I’m now able to read hexdumps of heap areas fluently but I still don’t have a fix for the problem. Lucky us Zorp restarts itself in this situation and the scenario where this problem occurs is not frequently used.
My suspicion is that the SSL error state for threads are the cause of the problem as I have evidence that the freed heap block is overwritten by ERR_clear_state(), which destroys the next and prev pointers in the freed memory block, thus resulting in the crash. The error states are supposedly thread-specific variables, but the way the allocation is done is suspicious.
I hope I can finally find this problem tomorrow.