XMPP Service Operators - 2026-03-29

Does anybody run an xmpp-server on a non-standard port? I'm going to be implementing some new firewall rules and this would be good to know. If yes, why?

tom: multiple servers on the same IP, for example

Yes I do, because I only have one IPv4 per place I live at, and have more than one XMPP server.

If you have IPv6 that should be fine for this usecase though.

MattJ what about you? Do you have IPv6?

Sometimes

Do you have any ipv6 xmpp servers on a non-standard port?

or ipv4-only

Yes, almost certainly

what alternate ports are in use?

The ones listed in SRV records

It feels like you're researching with the intent of implementing outbound port filtering. If this is true, I'm going to be more direct and suggest you reconsider.

I am. I'm setting up egress filtering on my server networks.

Even if I gave you a list of all the port numbers servers I run on are using today, that's besides the point. Port filtering is fragile.

Maybe only allow XMPP connections to V6 addresses ending with :5269 /s

I'm just curious if what is actually being used in the wild is sequentially numbered ports or totally random.

I don't usually choose totally random

Usually X222, X269, etc

But I have done sequential too

I see. And these servers don't have any ipv6 at all?

I don't know, I run lots of servers and I can't remember off the top head which have V6 and don't. I expect most of them do these days.

Do you have any suggestions for what I should do, if I can't do egress filtering based on dport for the xmpp server? My goal is to limit the value and usability of my servers to exploitation. Also to put a stop to data exfiltration

What exactly is the attack that you would be protecting against? I don't really see how port numbers factor into much at all these days

It's just a number. Even the <1024 rule has been eroded these days, and conversely you can find practically anything on 443

Especially with saying that IPv6 is a way around it

Many times when and if a server gets exploited, malware is uploaded which then is used to carry out cybercrime on other remote hosts. Either connect to a C2C server or to use the server to send spam, proxy through etc. Also when a vulnerability is found in software a usual exploit requirement is to try to leverage arbitrary code execution in order to connect back out to some host.

I'm just defining what expected behavior is in the firewall, whitelisting that and forbidding everything else.

Nothing stops a C2 server being run on port 5269 (whether it is XMPP-based or not)

For a webserver this is straightforward. I only need to accept TCP/443, 80 in. My server doesn't need to be connecting out to other others. Maybe I whitelist the submission port for a mailserver if a webapp needs to send email. For XMPP this is a bit more complicated due to the federation aspect.

> Nothing stops a C2 server being run on port 5269 (whether it is XMPP-based or not)

sure, but when I start getting alerts for a host trying to reach ports I've never allowed and it's never tried to before it's an indicator of suspicious activity.

Whenever you see outgoing connections from your xmpp server to anything, probe that address for srv and warn you if has no matching srv record if that's your fear

You got a Snort or Suricata rule for that?

No, I didn't even know snort doesn't mean snot until now

I don't do these kind of things

The xmpp standard allows all ports and doesn't really know default ports. So you can restrict it if you want but you can't expect a server be on any special port

There a limit for a normal port range an xmpp server to be on? Above 1024?

tom, no, anything goes.

i run mine on 443 and 5269+70 fwiw

folks, did you notice the mod_s2s_vmesh prosody module? it is amazing. i like it so much i have generalized it, and wrote a dns server: gemini://bbs.geminispace.org/s/Yggdrasil/40667

web links https://modules.prosody.im/mod_s2s_v6mesh.html

https://hg.prosody.im/prosody-modules/file/771944f2a7c7/mod_s2s_v6mesh/README.md

my dns server https://github.com/norayr/rn

i have a prosody on my pinephone now, on yggdrasil ip. (: and it federates with my clearnet server, and not only with mine. (:

> Does anybody run an xmpp-server on a non-standard port? I'm going to be implementing some new firewall rules and this would be good to know. If yes, why? Mine do, I have startls on directtls port, long story why. XMPP SRV records solve all your issues, as long as you set these you have no issues not using the standard ports. ↺

tom, port filtering on federated networks do not work, do not do it, you will only break your server.

federated protocols require the ability for your server to connect to any feasible port which a remote server might be on. The only way to properly implement an egress filter would be to write a plugin for prosody which upon looking up the SRV records, adds a rule to the firewall to allow traffic to the IP address on the remote on that specific port (aka letting prosody punch through the firewall). If you use ejabberd, basically the same thing, you would need it to be supported, which neither do afaik.

also if prosody then would be required to run with root permissions, therefore brings up more security concerns.

in order to do this more securely, 1. you would want prosody containerised or virtualised on an independent host. 2. You would require two daemons, prosody doing its normal stuff, and then a firewall daemon which validates what prosody is giving it (in case prosody is compromised) and then that daemon modify the firewall. The idea would be the daemon would only listen locally (unix socket) and thus would be protected from remote attack, unlike prosody which can be attacked remotely. The daemon would also be written as small as possible to minimise its attack surface, therefore running very little as root. But in any case, all of this effort to somewhat make egress filtering viable.

even then the attacker could just connect to the c&c server and/or exfiltrate data directly over XMPP

moparisthebest, well in both cases prosody will be pwned, I am simply talking about collateral, your XMPP data is already f*cked in this scenario. If prosody is running as root to allow for egress filtering, an attacker has your entire system.

my point is the egress filtering and port alerting rules are useless regardless since it's trivial to c&c or exfiltrate over plain XMPP

you seem to be proposing letting the compromised service update the allowlist whenever it wants which sounds useless with more steps

moparisthebest, egress filtering isn't explicitly to protect XMPP. It is for more finite control over the entire server's connections. For protocols like HTTPS and SMTP this works just fine as they are hard coded ports. But more and more protocols support non-standard ports with SRV records (or just specifying the port) and an egress filter then gets in the way. I don't believe egress filtering provides much benefit, however some people do like the control it provides. I think what tom has ran into is that hes messed with egress filtering, and then realised it breaks XMPP, because XMPP can use any port and SRV records make this easy to do. So my solution above was how you would get prosody to work with egress filtering and how to limit the increased attack surface it would create by doing so. Keeping prosody as a non-root user is essential, and you can't simply drop permissions because once you do prosody wouldn't be able to modify the firewall, that is why a second elevated daemon is needed which would then need to validate what prosody is passing it to ensure it itself can't be used to modify the firewall for any purpose other than allowing S2S connections.

prosody as root or not aside (you seem to be forgetting it's most likely all services run in isolated VMs but that's beside the point) if you are trying to use egress rules to secure against a compromised daemon, your threat model assumes it's compromised, then giving it any way at all to modify egress rules defeats the entire purpose and so is useless

> prosody as root or not aside (you seem to be forgetting it's most likely all services run in isolated VMs but that's beside the point) > > if you are trying to use egress rules to secure against a compromised daemon, your threat model assumes it's compromised, then giving it any way at all to modify egress rules defeats the entire purpose and so is useless you would hope that separate services run in isolated environments, but knowing the average server, I severely doubt this :/ ↺

> folks, did you notice the mod_s2s_vmesh prosody module? it is amazing. i like it so much i have generalized it, and wrote a dns server: gemini://bbs.geminispace.org/s/Yggdrasil/40667 It's neat but I don't really get the point vs regular DNS? ↺

as for the second point, yes if you are assuming the daemon is compromised, and then it has access to the egress rules, it is pointless. However non-federated services or those on fixed ports work well with egress filtering. Like I said my thing above was just how you would get prosody to work with egress filtering. This would obviously mean that compromising prosody then compromises your firewall, so you are compromising on security.

we aren't talking about the average server we are talking about egress filtering

in fact OpenBSD when set to a securelevel of 3 makes the firewall immutable, to defend against such attacks.

but also then prevents egress filtering ;)

> we aren't talking about the average server we are talking about egress filtering well I think we all agree its pointless, I was just trying to answer the question of how you could do it, I am not saying its wise or good for security, when I believe the opposite. ↺

> but also then prevents egress filtering ;) a different machine from the one you assume compromised is used for the filtering ↺

> a different machine from the one you assume compromised is used for the filtering yes this is done on the router/firewall (depending if you have a separate firewall from router in your network) however this would still rely on a daemon which would adjust the firewall to let S2S connections out, which would still be compromised if prosody was compromised, so it still doesn't provide a security benefit. ↺