Hi Dave, On Tue, Jun 15, 2010 at 2:17 PM, Dave Cridland <[email protected]> wrote:
> Isode M-Link has some capability to check the IP address of connections from > certain domains, so you could, for example, configure it to only accept > jabber.org domains from hermes.jabber.org. Cheers, I now have the link to your Isode M-Link website. > >> > 2) XMPP requires certain ports to be open, firewall open required >> > ports for required protocols (application alignment with >> > infrastructure) > Note that for outbound S2S, XMPP can potentially use any port. We have seen > "issues" with corporate firewall folk not wishing to open up anything more > than 5269 outbound. That's interesting to know. One may need to consider outbound stateful firewall rules for the XMPP server such that only the required port is open either 5269 or some other port. > >> > 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. >> >> > I think he's referring to IP-level spoofing. XMPP being entirely TCP, this > is somewhat difficult to achieve in practise, and is largely down to the > OS's TCP security. That's correct I was talking about layer 3 only. > > That said, the moment you have any TLS at all in place (including > unauthenticated ADH, say) then my understanding is that IP spoofing is no > longer practical. Agreed. However, a firewall will typically implement generic spoofing rules in accordance with RFC1918 and RFC3330. > FWIW, Isode M-Link - which I develop and run - will strip out certain > sub-elements of stanzas, and require them, on a per-domain basis. This isn't > a firewall feature as such, it's intended more for dropping data that's not > needed or wanted, for information security or bandwidth reasons - for > example, you can strip out the <status/> from presence to avoid information > leakage, or require that any <message/> must have a <body/> to restrict > message traffic to simple IM. Thanks for this information.
