Hi All, Having had time to digest the positive feedback and trying to get a handle of XMPP in general, I fully take on board that c2s and s2s is typically conducted over TLS tunnels and hence firewall content filtering is non-existent in this scenario.
However, I think there maybe a use for firewalls other than typical port openings for c2s and s2s and I'd like to hear to opinions on it. Serverless IM: In this scenario we have c2c interactions. My understanding of XEP-0174 is that communication is unencrypted. Consider a laptop user (in this case running iptbales on a Linux OS) that wants to interact with some other client on the local LAN ( i understand it can also apply to WAN, but not used in practice). The user may have identified the threat of Web URL phishing and have configured the firewall to filter our certain URLS or even certain keywords. In this case, the firewall would help protect the user from other p2p clients from receiving packets with malicious URL's. This is only a simple example, but one that demonstrates possiblities. In practice, it would be much better to have a locally hosted Snort IDS perform content filtering and then dynamically create iptables rules to prevent certain kinds of traffic. Server-2-Server Federation: >From reading the XEP-0220, I understand that certificate based TLS interaction and SASL authentication using the same certificate is not currently widespread. Thus, the less secure Dialback protocol is used. Leaving aside the threat of DNS poisoning, am I write in saying that communications between two servers that do not support TLS are unencrypted? If this is the case and is fairly common in the wild then perhaps a firewall in conjunction with an XMPP content filter plugin could provide a defense in-depth strategy (NIST, PCI-DSS compliance) to filter out malicious traffic such as SPIM, accidental information disclosure and so forth. Note, I have seen on the Openfire GUI that Dialback can be done over TLS. I am not sure why, one would do dialback over TLS as if teh support TLS then perhaps one would best opt for TLS and SASL External. External Components: My understanding is that these components are similar to plugins except they provide services that interact with the XMPP server over a TCP communication channel, over port 5275 in the case of Openfire. My understanding is that currently such external components communicate over the Jabber Component Protocol defined by XEP-0114. This protocol as I understand it sends messages in the clear. Consider a locally hosted firewall on the XMPP server. The firewall, in conjunction with various XMPP-based filters, could be used to inspect traffic at the application layer to ensure that malicious traffic is not forwarded to the external component and/or received on the XMPP server from the external component. BOSH over HTTP: My understanding is that communication can be over HTTP and does not have to be encrypted. I presume then that a firewall, Web proxies such as SQUID and IDS could play a role in adding extra protection. Also, if a client is embeded with a browser they would require the http-bind protocol and like BOSH, traffic can be unencrypted. SASL ANONYMOUS: I see from XEP-0175 that anonymous SASL provides interaction with unregistered clients. I see that authentication happens but is the communication channel afterwards encrypted? If not, a firewall (and/or IDS) could be used to filter various messages being sent to and from the XMPP server. This would help compliance with the XEP-0175 best practice requirement: "Because an anonymous user is unknown to the server, the server SHOULD appropriately restrict the user's access ...". The above discussion has been focused on filtering at Layer-7 in cases were TLS is not used. DoS: The XEP-0205 DoS standard requires that traffic connections be controlled. From the standard, it appears that a firewall is the best option here regarding IP addresses. Firewalls can filter based on the number of simultaneous connections and connection attempts within a given time frame. I haven't seen this kind of functionality at least in Openfire anyhow. Would XMPP servers take this role in practice? Whitelist/Blacklist IP addresses: XMPP servers and firewalls can work together to provide defense in-depth in this scenario. In my opinion this is useful. Consider a XMPP server that is hosted on a machine that also hosts other servers. It maybe possible that that machine becomes compromised by a Trojan that modifies the XMPP server's IP address whitelist. The network firewall (provided it is not also compromised) would then ensure that certain IP addresses can and cannot reach the XMPP server. Thus, defense in-depth is borne out. Looking forwards to your comments and corrections to any misconceptions I have discussed. regards, Paddy.
