Re: Proxies, opensource and the general market: what's wrong with us?

On Wed, Apr 27, 2011 at 05:20:17PM -0700, [email protected] wrote:
> >
> >At the moment I am trying to offload non protocol-related http checks to 
> >external
> >ICAP filters.. For XML, I have some raw prototype, but I do not like the 
> >fact it
> >is based on libxml2 and inherits all potential vulnerabilities (as it is a 
> >huge
> >piece of code) and still there is a lack of automated tool that can be 
> >used to
> >"formalize" "normal" xml flow to check for anomalies later. For several 
> >well-documented
> >protocols it is not needed, but aiming at SOA it is probably a must :-(
> 
> I'm happy to hear of this work, is the prototype available somewhere?

Not yet, it is more an ugly PoC atm :-( But I am going to polish at a bit and
include in main source tree.

> >>openfwtk hasn't hit this yet for me as the key thing that I use FWTK
> >>for is the authenticated proxies and the last I checked it doesn't have
> >>an authsrv equivalent (or the ability for it's proxies to tie in to an
> >>authentication source).
> >
> >You must be missing something, authsrv is the part that required several 
> >fixes, so it
> >is there for sure, a few years at least and it is really improved much. 
> >Multiple groups per user are allowed, authentication
> >sources may be checked against netperm-table (you may write rules that 
> >restrict authentication
> >to a given proxy, or a given host), unix local socket is supported as 
> >transport to avoid writing
> >complicated "loopback prevention" rules, etc etc.
> 
> yep, I did miss it. I'll have to take another look at it. does it use the 
> same over-the-wire protocol as the fwtk authsrv (so that I can use the 
> existing proxies?)

Sure. It does even support old futile DES "encryption" for backwards compatibility.
It is compatible both on TCP and API levels (second part means you may recompile
your proxy with the new library and auth_open() call will automatically work
with unix socket connection as well)

http://openfwtk.cvs.sourceforge.net/viewvc/openfwtk/fwtk/nlib/authio.c?revision=1.13&view=markup

I have to admit, though, it was not really tested well, as most people run OpenFWTK without 
authentication features, so it might be wise to play with it a bit before placing in production
environment. If any bugs appear, I hope I can fix it quick enough.
> 
> >I am thinking about adding radius and/or pam backends support, but still 
> >had no time to implement that.
> 
> there's a authsrv pam module floating around already for fwtk, 

Yes, and there is a slightly modified version of it included in the distribution.
The change is quite simple: the "comment" field from "authorize" command is no longer actually
a "comment", as native TIS proxies provided some useful information there like proxy name and
peer address, I decided to document that and make it a part of protocol specification.
Some third-party software that did not honor this informal convention got broken and required minor
patches.

> I have no problem saying that things like log analysers are out of scope, 
> but (at least when initially released) the documentation was saying that 
> things like ssh and http were out of scope (and with telnet and FTP being 
> so insecure, I was remembering that you didn't implement them, leaving 
> little that would use authentication, which is probably why I was thinking 
> that authsrv wasn't implemented)

http was there from the very beginning. ssh, yes, still somehow out, actually not much (well, nothing!)
was changed since my old ugly openssh hack to implement simple proxy functionality. It is time to revisit that 
as well. The part I get paid for at the moment is http/emstp/pop3 (and imap is planned) with SSL support,
but I hope I can get some free time.. SSH is definitely high priority task, but I am still unsure what the
architecture and technical requirements should be. Do you have any wishes, what is essential for you -- key
management functions, whatever?

> I actually don't have an objection to the firewall being a collection of 
> different tools gathered togeather (that's just good code re-use in the 
> best opensource tradition), it may require some tweaks to code, or some 
> scripts to create the appropriate config files for some of the tools, but 
> that is far better than having to completely re-write the tools.

That's why I was talking about "kickstart" -- a set of configuration templates that eases this task.