[prosody-users] How to block all XMPP file transfers (Prosody/Gajim)

[Ken Adams]

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
<http://jonathonstaff.com/blog/tackling-file-transfers-with-the-xmppframework/>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
<https://prosody.im/doc/modules/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]

I've been looking into mod_firewall
<https://modules.prosody.im/mod_firewall.html> 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

Post by Ken Adams
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
<http://jonathonstaff.com/blog/tackling-file-transfers-with-the-xmppframework/>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
<https://prosody.im/doc/modules/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

[Matthew Wild]

Hi Ken,

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: ***@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]

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.*

Post by Ken Adams
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
<http://jonathonstaff.com/blog/tackling-file-transfers-with-the-xmppframework/>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
<https://prosody.im/doc/modules/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

[Matthew Wild]

Post by Ken Adams
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]

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!

Post by Ken Adams

Post by Ken Adams
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

Post by Ken Adams
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

Post by Ken Adams
our machines down to only using Gajim plus this did the "trick". I'll

test

Post by Ken Adams
your rules out below as they definitely are better structured to address

the

Post by Ken Adams
alternative methods. I'll provide feedback on these but I'm not sure how

I

Post by Ken Adams
would go about testing each method as Gajim seems to be essentially

blocked

Post by Ken Adams
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]

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.

<!-- Out 11/10/2017 3:44:38 PM -->
<iq xmlns="jabber:client" to="***@mycompany.com/R1"
from="***@mycompany.com/R1" id="533ca1b1-9c4c-4380-9420-2d0dc42f0fc8"
type="set">
<jingle xmlns="urn:xmpp:jingle:1" action="session-initiate"
initiator="***@mycompany.com/R1"
sid="b17e86d3-160b-4b2a-a36f-ddc4d3a49cd3">
<content name="fileWYHPQSER3FJLNVOC" creator="initiator">
<security xmlns="urn:xmpp:jingle:security:xtls:0">
<fingerprint>E5:B5:5A:0A:E5:0F:D0:55:E3:E3:35:44:F3:1F:DE:38:0A:85:EF:9A:3F:15:91:70:AC:44:FA:D4:CF:81:5A:97</fingerprint>
<method name="x509" />
</security>
<description xmlns="urn:xmpp:jingle:apps:file-transfer:*3*">
<offer>
<file>
<name>npp.7.5.1.Installer.exe</name>
<date>2017-11-08T14:12:56</date>
<size>2885168</size>
<hash xmlns="urn:xmpp:hashes:1"
algo="sha-512">1b55db384377793ed76e619869f7edc05cc9e56f503728469944c9f4c18197da36b31fbc099011287c795f495e74f1c26a52450270a25b64d396a6cd2c4609ff</hash>
<desc />
</file>
</offer>
</description>
<transport xmlns="urn:xmpp:jingle:transports:s5b:1"
sid="4900a307-e513-4eb6-ad0f-8a2bd1f19e7a">
<candidate jid="***@mycompany.com/R1"
cid="9560f38f-a075-4c5f-968e-f5f6bdea0db5" priority="8257536"
host="10.70.8.90" type="direct" port="28011" />
<candidate jid="***@mycompany.com/R1"
cid="abba8e12-d92f-4ed9-9b4d-6b5f05226e6e" priority="8257536"
host="fe80::cd8f:d7ef:3b5:54a3%10" type="direct" port="28011" />
<candidate jid="***@mycompany.com/R1"
cid="fe19ec87-920d-401a-b153-345a93379334" priority="8257536"
host="fe80::292d:a5e5:dc71:19b9%14" type="direct" port="28011" />
<candidate jid="***@mycompany.com/R1"
cid="52c42697-e55a-42b2-9c14-44e85b7cfc34" priority="8257536"
host="fe80::285c:2e92:f5b9:f7a5%43" type="direct" port="28011" />
<candidate jid="***@mycompany.com/R1"
cid="e4cd1d96-b74f-40f0-ba59-46f34b7c1465" priority="8257536"
host="169.254.84.163" type="direct" port="28011" />
<candidate jid="***@mycompany.com/R1"
cid="f2e6a0ac-3461-4a9f-bdcc-5355588dc81f" priority="8257536"
host="2001:0:5ef5:79fb:285c:2e92:f5b9:f7a5" type="direct" port="28011" />
</transport>
</content>
</jingle>
</iq>

<!-- In 11/10/2017 3:44:38 PM -->
<iq id='533ca1b1-9c4c-4380-9420-2d0dc42f0fc8' type='result'

Post by Ken Adams
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
<http://jonathonstaff.com/blog/tackling-file-transfers-with-the-xmppframework/>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
<https://prosody.im/doc/modules/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

[Matthew Wild]

Post by Ken Adams
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}***@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