On 15 June 2010 10:49, paddy joesoap <[email protected]> wrote: > Hi Paul, > > Thanks for responding. > > If I understand both Matthew and yourself correctly, XMPP servers and > client interactions are all TLS/SSL based (or should be) and thus deep > packet inspection would need to be handled either at the application > layer either by the XMPP server or perhaps some other form of XML > based inspection. >
Correct. > Have you any opinions on how such XMPP servers are deployed in > practice? What I mean is that, is TLS used all the time. I presume > there are legacy systems that don't benefit from the SASL options and > TLS, that if combined with a firewall would mimic such advanced > features. I see from the Openfire administration page that c2s can be > either encrypted or plain-text over port 5222. The s2s communication > is over port 5269. I am not sure if s2s MUST be encrypted. > It's not required to use it (yet?) but support for TLS is required. In fact most servers will probably let you turn it off entirely. However for the reasons of relying on DNS I mentioned earlier, that's the wrong direction you'd be going in. Personally I'd rather TLS with verified identity than no TLS and the ability to inspect packets before they reached the XMPP server. > Consider a enterprise scenario where remote communication to an XMPP > server either c2s or s2s is over a VPN. In this case, one may not want > to consider a hardened XMPP server that uses TLS (but may use in > conjunction to the firewall a whitelist). In this case, a firewall > could inspect the XMPP stanza's. For example, find the string that > matches a certain JID or a known malware signature. > Sure, if there's no TLS this is possible. > Presumably if the solution is TLS end-to-end then one could argue that > a firewall is not required except to prevent DoS and protect other > services hosted on the XMPP server that cannot protect themselves. I think I'd argue that, yes. > However, I presume there is a management issue with handling the > TLS-based certificates each time you create a new XMPP service and/or > connect to another XMPP server. > Yes, which is probably one reason TLS with real certificates isn't as common as we want it to be. Discussions are often happening about how we can achieve security in spite of this, or how we can aid adoption. I suspect that simply once spam and rogue servers start appearing, a few services will start to require verified certificates before allowing an s2s connection with a peer. The situation for clients doesn't look so positive... requiring everyday users to get their own certificates would be asking for quite a lot :) > Also, what happens in the case of some malicious Web URL that is doing > the rounds that may be contained within IM messages. While a firewall > can act as a single chokepoint and thus a single point of management, > I presume that each XMPP service would require individual management > to filter the malicious URL from XMPP stanza's. > Afraid so. > There is also the situation where some enterprise environments want to > be able to filter all packets on its local subnet at least, either by > firewall, IDS, network-based anti-virus and so forth. In these > situations, would XMPP still operate over TLS pipes? What happens in > your experience in practice? > I've yet to know of anyone who rathered external filtering than TLS, but it's early days perhaps. As an example Google are probably (one of?) the largest XMPP deployments... they use TLS for clients quite happily (require it in fact if I recall). They used to use TLS for s2s as well, but don't at the moment (I don't think for reasons of filtering) but I believe they are working on bringing it back. > I notice when I look at the Openfire administration GUI that there is > an option for file transfer proxy over port 7777. I presume such > traffic is unencrypted. My understanding is this proxy is used as a > sort of relay/router between two clients, because the XMPP stanz'a are > intended for small payloads. A firewall could inspect traffic over > port 7777 to ensure no sensitive data is being leaked. Again, this > out-of-band communication is not specific to XMPP (but does use the > XMPP server in this case). > Yes, that's correct. The proxy can be used to set up a (bidirectional in fact) pipe between two XMPP entities. Usually this is for transferring files, and there is no standard on encrypting file transfers (though there is nothing to stop clients doing this). > Regardless of encrypted layer-7, there are some synergies between XMPP > and iptables firewall when providing security in-depth. > 1) XMPP IP address whilelist, firewall source IP address filtering I'd be surprised if there aren't any XMPP servers that can already do this, but yet I'd agree it's a job best done by the firewall. > 2) XMPP requires certain ports to be open, firewall open required > ports for required protocols (application alignment with > infrastructure) Yes, external firewall. > 3) XMPP does not perform DoS filtering, firewall filters connection rates XMPP servers actually do allow for these kind of things. For example: http://xmpp.org/extensions/xep-0205.html > 4) XMPP does not perform IP address anti-spoofing, firewall > prevents/reduces anti-spoofing attempts. For s2s connections (clients already authenticate with credentials, so it's not as much of an issue) XMPP uses dialback to prevent spoofing: http://xmpp.org/extensions/xep-0220.html Obviously as I noted before, this is dependent on DNS being correct. Anything you can deploy externally would help make the dialback checks more secure. > 5) XMPP SPIM protection??, if traffic is unencrypted the firewall (or > IDS) can detect malformed traffic and known SPIM signatures. > SPIM isn't really a problem at the moment, but we know the day will come. In fact there are a couple of specifications on suggested ways to help tackle it: http://xmpp.org/extensions/xep-0268.html and http://xmpp.org/extensions/xep-0275.html Both are wanting implementations and experience so they can be developed further and out of experimental stage. > Note, I searched for an Anti-SPIM plugin for Openfire and could not > find any. What flavour XMPP servers are you using? > I use (and develop) Prosody. I should probably mention that I've been working on something the past few weeks that might interest you - it's essentially a Prosody module that handles most of what we've been discussing. The best way to describe it is probably "iptables for XMPP", as it lets you define custom rules for handling/routing stanzas, based on their header, contents, origin and other things. I'm away this week, but was planning to release it next week when I get back. Matthew
