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. 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. 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. 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. 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. 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. 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 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). 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 2) XMPP requires certain ports to be open, firewall open required ports for required protocols (application alignment with infrastructure) 3) XMPP does not perform DoS filtering, firewall filters connection rates 4) XMPP does not perform IP address anti-spoofing, firewall prevents/reduces anti-spoofing attempts. 5) XMPP SPIM protection??, if traffic is unencrypted the firewall (or IDS) can detect malformed traffic and known SPIM signatures. Note, I searched for an Anti-SPIM plugin for Openfire and could not find any. What flavour XMPP servers are you using? regards, Paddy. On Mon, Jun 14, 2010 at 5:43 PM, Paul Aurich <[email protected]> wrote: > On 2010-06-14 07:56, paddy joesoap wrote: >> Matthew, >> >>> Considering that for the majority of their lifetime most XMPP streams >>> are encrypted and often compressed, iptables probably wouldn't be that >>> much help at L7-filtering in XMPP. >> >> If the XMPP server ran a locally hosted iptables firewall perhaps then >> some additional traffic could be filtered. > > iptables would still be seeing encrypted packets, barring a decently > complex load-balancing environment; they would remain encrypted right up > until the userspace XMPP daemon decrypted them. > >> Federated Example: >> My understanding having looked briefly at the book entitled: "XMPP: >> The Definitive Guide", is that traffic from c2s is decrypted at the >> XMPP server, then encrypted again for s2s communication and then >> decrypted on the end XMPP server, before being encrypted once more >> from s2c. >> >> Perhaps some deep packet inspection can occur at times when the >> communication is passing through the XMPP servers. > > All that encryption and decryption is done in the userspace XMPP daemon; > a firewall still only sees the originating and resultant TCP packets, > which are encrypted. > >> I also learn't from the book that the XMPP server may act as a >> relay/proxy for media such as SIP, Video and file sharing. >> Clients may also use p2p communication for these types of media. >> >> Are these communications encrypted? > > No, and while I haven't kept abreast of the various technologies, > there's at least one proposal for how to do it. > http://xmpp.org/extensions/xep-0262.html > >> Perhaps, a company policy might be to prevent out-of-band XMPP >> communication to prevent the possible leakage for sensitive files via >> the XMPP relay service or p2p communication. Would a firewall be >> useful here? > > Perhaps, but this isn't at all specific to XMPP. In such an > environment, you'd want to be locking down desktops from accessing all > sorts of external resources. In such an environment, it would make more > sense to disable s2s or disallow s2s except from whitelisted > domains/JIDs or filter out specific stanzas (policies better implemented > in the XMPP server, IMHO). > >>> I'd say the main weak point in XMPP's defences (at the moment) is DNS. >>> Since few servers have certificates signed by a CA, and many servers >>> don't check anyway, XMPP is very dependent on DNS being correct. >> >> And DNSSEC is not implemented in practice either. >> >> Perhaps a set of firewall rules that ensures that clients and/or the >> XMPP server can only make DNS queries to a certain IP address of the >> internal DNS server, might be of use. > > If you can't trust your XMPP server to perform DNS queries against the > correct DNS server, you've already lost. > >> What I am trying to do is tease out the threats to XMPP servers (and >> clients) and how best firewalls can add value at the: >> (1) IP layer >> (2) TCP/UDP layer and the > > The same way they do for any other server(s). Nothing at these levels > is XMPP-specific, IMHO. > >> (3) Application XMPP layer. > > Little, because it's typically always encrypted. Even then, policies > are better implemented on the server (which is designed for parsing XML > and grokking the stanzas, as opposed to doing byte-matching in iptables, > which is, to say the least, a hack). > >> I guess (1) and (2) are common across all servers, for example >> packet/connection limiting, making sure only the required XMPP ports >> are open on the firewall and so forth. > > Right. > > ~Paul > >
