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
signature.asc
Description: OpenPGP digital signature
