Re: Firewall Best Practice regarding XMPP traffic?

[paddy joesoap <paddyjoesoap () gmail com>]

Hi Kevin and all,

I have taken on board the XMPP administrators views that TLS should
always be used and thus eliminates (or at least minimises) the ability
to perform layer-7 filtering. However, from reading the various XMPP
RFC's called XEP's, I think the there are situations that allow for
DPI and defense in-depth situations using a firewall. Its not just as
simple as opening XMPP service ports and leaving the XMPP server
handle security on its own.

The following discussion is very centric to XMPP and the possible
firewall role beyond port openings. I will try to refrain from asking
such specific protocol questions (in this case XMPP) in the future
that are not core to this forums objectives. However, if anyone has,
like Kevin, experience with configuring both XMPP servers and building
firewall configurations that support their protection, I'd like to
hear your comments regarding below.

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 possibilities. In practice, it would be much
better to have a locally hosted Snort IDS perform content filtering
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 they 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? I'd
imagine firewalls are the best option here.

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.
regards,
Paddy.

On Thu, Jun 17, 2010 at 7:44 AM, K K <kkadow () gmail com> wrote:
> In my experience, yes -- XMPP servers are generally deployed in the
> DMZ with TLS enabled (required) for all connections.
>
> Theoretically you could load a copy of your XMPP server's private key
> onto a content inspection device, granting it visibility inside the
> encrypted session.  I've never known anybody to do this in practice.
>
> What I have seen done for a corporate XMPP deployment is to have the
> clients connect to an edge device using the legacy SSL-only port
> (TCP/5223), and then use a generic SSL appliance pass-through to
> decrypt the traffic at the edge, so it enters the DMZ in the clear,
> where the TCP stream can be inspected as needed

Cool, so layer-7 is still possible and practical in a corporate
setting (depending on the business-level security policy!).

> This still leaves
> any server-to-server traffic non-inspectable,

I wonder as I have discussed above, if Dialback is used particularly
with legacy systems, if traffic can be inspected s2s?

I am not hung up about layer-7 filtering. Rather, I am trying to
understand all possible scenario's that a firewall may be used,
regardless of it being to practical. For example, an IDS may be more
suitable for l-7 filtering. But by asking about how a firewall can
protect XMPP servers other than port openings and source IP addresses,
provides me at least with a deeper understanding of XMPP server access
control and more importantly firewall access control ;-)

Thanks Kevin for your comments.

> but ensures all traffic
> to/from directly connected clients is available for IPS scanning and
> L-7 inspection/filtering.
>
>
> Speaking of firewalls, I'm still disappointed that none of the "Chat
> aware" content filtering products are offering support for XMPP.
> Blue Coat, Websense, Vontu, etc all go to great lengths to attempt to
> see inside AIM and Yahoo chat, but totally ignore the one fully open
> protocol in the inspection engines.
>
>
> Kevin Kadow
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards