How to block all XMPP file transfers (Prosody/Gajim)

Ken Adams

unread,

Nov 8, 2017, 5:18:47 PM11/8/17

to Prosody IM Users

I've spent hours scouring the internet for some clues or pointers to BLOCK FILE TRANSFERS on my company's internal XMPP server running prosody on the server side and Gajim on the windows client side. Note: Seeking to control this on the server side if possible.

From everything I'm reading on basic XMPP file transfers it appears to have numerous methods that can be used.

This blog does a nice job laying out all of the potential methods. It seems like every internet search I come across dealing with file transfers in XMPP in general are seeking the opposite - "How to get transfers to work or how to optimize them, how to use a proxy etc." I have yet to come across any specifically dealing with blocking the use of it completely.

One method I myself attempt was to configure mod_proxy65 but specify a bogus proxy server/IP in the prosody config to break it. I haven't had much luck with that approach but I'm not sure if my initial testing with it is even the correct way to configure it. Further research on file transfers then gave me the impression that all these numerous methods that can be used are auto negotiated in some way for the clients to determine the best method to use when initiating a file transfer between each other. This in a way if true put this first attempted method above on the back burner, as it seems even if I did get this bogus proxy method to work, it would lead to clients just using a different method in that list.

QUESTION - Do XMPP file transfers in general function over a specific port outside the main tcp 5222 client to server port? If it did I could block this at the network firewall for machines on different subnets and/or on our eset endpoint security suite installed on the client machine at the eset firewall level.

I'm hoping someone else out there has gone down this path I currently am and has some insight on all of this. Any tips, tricks, methods, or pointers would be GREATLY appreciated!

Thanks - Ken

Ken Adams

unread,

Nov 13, 2017, 10:03:58 AM11/13/17

to Prosody IM Users

I've been looking into mod_firewall as a possible option to get this done but not 100% sure yet on how to craft up firewall rules file to key in on the proper XML portion of the communication to block/deny and send a reply to the user stating it's not allowed.

I'll continue testing this feature but if anyone out there has any background on the use of mod_firewall, I would greatly appreciate any tips or pointers!

If other methods outside this module are options for this, I'm open for any solution that solves this as well.

Thanks
- Ken

Matthew Wild

unread,

Nov 15, 2017, 7:34:39 AM11/15/17

to Prosody IM Users Group

Hi Ken,

On 13 November 2017 at 15:03, Ken Adams <kenad...@gmail.com> wrote:
> I've been looking into mod_firewall as a possible option to get this done
> but not 100% sure yet on how to craft up firewall rules file to key in on
> the proper XML portion of the communication to block/deny and send a reply
> to the user stating it's not allowed.

We spoke briefly in the chatroom about this last week. Sorry for the
delay responding here... had a busy couple of weeks and I'm behind
with email.

The main problem with "blocking file transfers" is that it's a very
broad requirement. Hence asking exactly what you were aiming for.

There are a number of different (standardized) ways to transfer files
in XMPP. And any given client is able to invent its own non-standard
file transfer mechanism, for example. And then of course someone could
just copy and paste the contents of a file into a message. So really
consider exactly what your requirements are, and what you are aiming
for.

Now, you mentioned Gajim in the subject. So if we are limiting to
that, blocking just standard protocols should be enough (Gajim
supports plugins, but let's ignore that for now).

Here's an example mod_firewall script that should cover everything:

#####
::deliver

## File transfer protocols

# Block XEP-0096 SI File Transfer
KIND: iq
TYPE: set
PAYLOAD: http://jabber.org/protocol/si
JUMP CHAIN=user/reject-file-transfer

# Block XEP-0234 Jingle File Transfer
KIND: iq
TYPE: set
PAYLOAD: urn:xmpp:jingle:1
INSPECT: jingle@action=session-initiate
INSPECT: jingle/content/{urn:xmpp:jingle:apps:file-transfer:5}description
JUMP CHAIN=user/reject-file-transfer

# Block XEP-0363 HTTP File Upload
KIND: iq
TYPE: set
PAYLOAD: urn:xmpp:http:upload:0

## Underlying transports

# Block XEP-0047 In-band Bytestreams
KIND: iq
PAYLOAD: http://jabber.org/protocol/ibb
JUMP CHAIN=user/reject-file-transfer

# Block XEP-0065 SOCKS5 Bytestreams
KIND: iq
PAYLOAD: http://jabber.org/protocol/bytestreams
JUMP CHAIN=user/reject-file-transfer

::user/reject-file-transfer
BOUNCE=policy-violation (File transfers are not allowed)
#####

Disclaimer: it's not even tested, no guarantees that it blocks
everything (or that it doesn't block legitimate things). It's just
something that may help. Feedback welcome.

Good luck!

Regards,
Matthew

Ken Adams

unread,

Nov 16, 2017, 11:26:13 AM11/16/17

to Prosody IM Users

Matthew,

Thanks for your initial pointers in the chat room to get the ball rolling in this direction for me and thanks for this follow up reply with more info. I did manage to use Gajim's built in XML Console window to see what communication looked like behind the scenes during a file transfer between 2 clients. I noticed Jingle was being used in this case so I experimented with different structuring in the firewall file and ultimately just went with this basic one below.

KIND: iq

TYPE: set

PAYLOAD: urn:xmpp:jingle:1

INSPECT: {urn:xmpp:jingle:1}

BOUNCE=not-allowed (Company Restricts the use of File Transfers)

This appears to be blocking the initial request with jingle before it's even determined to be a file transfer. I know jingle has other uses with voice chat etc but that wasnt an issue for us as we're only seeking to use this as basic instant messaging .

However, I'm also aware of the many other routes that are taken for file transfers which you nicely outlined below THANKS! I'm not sure how or what determined the method used but noticed once I blocked jingle, gajim in particular doesn't negotiate or use any other method so I figured locking our machines down to only using Gajim plus this did the "trick". I'll test your rules out below as they definitely are better structured to address the alternative methods. I'll provide feedback on these but I'm not sure how I would go about testing each method as Gajim seems to be essentially blocked with just jingle rule?

QUESTION: What determines which method is used first, 2nd, 3rd, etc.

On Wednesday, November 8, 2017 at 5:18:47 PM UTC-5, Ken Adams wrote:

Matthew Wild

unread,

Nov 16, 2017, 11:29:31 AM11/16/17

to Prosody IM Users Group

On 16 November 2017 at 16:26, Ken Adams <kenad...@gmail.com> wrote:
> However, I'm also aware of the many other routes that are taken for file
> transfers which you nicely outlined below THANKS! I'm not sure how or what
> determined the method used but noticed once I blocked jingle, gajim in
> particular doesn't negotiate or use any other method so I figured locking
> our machines down to only using Gajim plus this did the "trick". I'll test
> your rules out below as they definitely are better structured to address the
> alternative methods. I'll provide feedback on these but I'm not sure how I
> would go about testing each method as Gajim seems to be essentially blocked
> with just jingle rule?
>
> QUESTION: What determines which method is used first, 2nd, 3rd, etc.

Gajim will look at what the recipient supports, and factor that into
its decision. If Jingle fails, it's up to Gajim whether it tries the
other methods (based on what you are saying, it would seem that it
doesn't).

Regards,
Matthew

Ken Adams

unread,

Nov 16, 2017, 1:12:31 PM11/16/17

to Prosody IM Users

Sounds about right. I'll definitely get the others included for safe measures. I do get your points on copy/paste of text into a chat session as a way to "leak/expose" content but blocking this is still valuable in our eyes to address other scenarios. Transferring non text based files between users that can not be copy/pasted, close a possible attack vector used to spread virus/malware or other nasty things if a machine was compromised and had this freely open to use. Exporting of non text based files that are part of our company's proprietary software etc. It also cuts down on unnecessary bandwidth usage on our network if users were allowed to use it.

Thanks a ton for your help on this!

Ken Adams

unread,

Nov 17, 2017, 8:57:58 AM11/17/17

to Prosody IM Users

So I did a little testing using your template fw rules you provided. In my case with Gajim knowing it focuses on jingle, I tested your format for that section but it didn't prompt back with the bounce message. I also compared it to captured XML output of a legit communication/file transfer and noticed one key difference highlighted yellow.

This one here is a basic file transfer, followed by select a file and thats it. The yellow highlight has a :3 at the end while your example had a :5. Not really sure what this number represents but either way 5 doesn't work and changing to 3 in my case also does not work.

</security>

<offer>

<file>

<name>npp.7.5.1.Installer.exe</name>

</file>

</offer>

</description>

</transport>

</content>

</jingle>

</iq>

On Wednesday, November 8, 2017 at 5:18:47 PM UTC-5, Ken Adams wrote:

Matthew Wild

unread,

Nov 17, 2017, 4:16:45 PM11/17/17

to Prosody IM Users Group

On 17 November 2017 at 13:57, Ken Adams <kenad...@gmail.com> wrote:
> So I did a little testing using your template fw rules you provided. In my
> case with Gajim knowing it focuses on jingle, I tested your format for that
> section but it didn't prompt back with the bounce message. I also compared
> it to captured XML output of a legit communication/file transfer and noticed
> one key difference highlighted yellow.

Thanks for testing. The change reflects that Gajim is using a
different version of Jingle to the latest version published at
xmpp.org. I didn't check what it implemented when I sent you those
rules, I just used the latest version on xmpp.org. A comprehensive
solution would have to block all versions. I don't currently see a
"nice" way of doing this in mod_firewall without just duplicating the
rule lots of times. It's very hard to keep the balance between keeping
mod_firewall's syntax simple but expressive...

Anyhow, the reason it still didn't work is because the 'INSPECT' line
wanted the fully-qualified tag name, including the namespace, so here
is the final rule that should work:

# Block XEP-0234 Jingle File Transfer

KIND: iq
TYPE: set
PAYLOAD: urn:xmpp:jingle:1

INSPECT: {urn:xmpp:jingle:1}jingle@action=session-initiate
INSPECT: {urn:xmpp:jingle:1}jingle/content/{urn:xmpp:jingle:apps:file-transfer:3}description
JUMP CHAIN=user/reject-file-transfer

But again, a warning that this will only block this version of Jingle
with a payload that matches this version of Jingle File Transfer. At
some point Gajim may update to a newer version, and other clients may
support other versions.

Hope this helps!

Regards,
Matthew

Reply all

Reply to author

Forward