How to Block File Transfer in Wildfire!

Hi all,

I have a special request in my job, now my Boss wants to block the service the File Transfer. How can I block File Transfer in the wildfire?

Thanks in advanced

Hi,

You can enable/disable file transfer from Wildfire admin console; specifically from the “File Transfer Setttings” link on the sidebar of “Server” tab.

Hi absabby28,

To expand slightly on aznidin suggestion, disabling the File Transfer proxy service will only allow you to block file transfers that are done through Wildfire. However, some clients don’‘t use the proxy service when transferring files so disabling it won’‘t necessarily accomplish what exactly what you’'re looking for. However, Wildfire Enterprise does have the ability to completely block all file transfers, as well as a number of other cool features. You can try it out by downloading it from the list of available plugins in the Wildfire Admin Console.

Hope that helps,

Ryan

Hi all

What does it mean? I must buy Wildfire Enterprise!!!

We use Wildfire OpenSource, and I only want to block file transfer

Hi absabby28,

No, you don’‘t have to buy Enterprise, but that is one option. You might also try Jeff’'s suggestion of blocking the port(s) that the clients use to transfer files.

Hope that helps,

Ryan

ryang wrote:

However, Wildfire Enterprise does have the ability to completely block all file transfers, as well as a number of other cool features. You can try it out by downloading it from the list of available plugins in the Wildfire Admin Console.

Note that this feature actually is “security through obscurity”. AFAIK this feature just blocks the XML traffic that handles file transfer initiation. So, it would be fearly easy to modify a Jabber client to change the file transfer protocol a little, so that the XML traffic isn’‘t blocked anymore. The problem is that these clients do support an unstandard protocol which creates a friction in the Jabber community. At the same time, the blocking feature doesn’‘t help anymore. Hence, the blocking feature is evil IMO: it decreases security because people feel safe while this isn’'t true, and it hurts the Jabber community. That is also the reason why I hate this feature and why I hope this will never be included in the open-source version of Wildfire and it also would be nice against the Jabber community and the customer to drop this {non|marketing-only}-feature in the Enterprise version. A big warning claiming that this feature is “security through obscurity”, that people should use it at there own risk, and that it can hurt the Jabber front by using it, also can help.

PS: I think even DRM might be a better solution to prevent file transfers.

DRM!!! aghhhh! now thats how to hurt open source… imho

Hi Sander,

sending files via IM or email is evil if you are working in a company. This will produce n copies - and maybe one will make n backups instead just one - of a file and no one is able to track changes or locate the current version of a document.

Some users do really need assistance, so I really like this option.

There are some WebDAV enabled storage and versioning systems available so one should really use them.

For public or internet usage no one - except the madmen - will buy an enterprise version.

LG

Hi sanderd,

You bring up some valid points but I don?t agree that the file blocking feature is evil. You?re right that the feature isn?t going to stop a user who has the skills and determination to write their own client just so they can transfer a file, but how many users in a corporate environment, that as LG pointed out is the most likely place to deploy Wildfire Enterprise, meet that sort of criteria? Is it ?security through obscurity?, maybe so, but is that an entirely bad thing in this case? Maybe it?s enough to slow people down from sharing files which they?ll find a way to do if not by email attachments or IM but by thumb drives, CDs, iPods or those square shaped floppy things that we all used to have stacks of on our desks.

Regards,

Ryan

it2000 wrote:

sending files via IM or email is evil if you are working in a company.

I know that this can be a problem.

You?re right that the feature isn?t going to stop a user who has the skills and determination to write their own client just so they can transfer a file, but how many users in a corporate environment, that as LG pointed out is the most likely place to deploy Wildfire Enterprise, meet that sort of criteria?

How many people are able to misuse a leak in Internet Explorer? And how many script kiddies when there is an exploit available?

btw: I heard that there already is an exploit for the client limiting feature in the Enterprise edition (which is also a bad thing IMO, see web browser world with it’'s browser specific web sites; using certificates would be much better): the Jabber client JAJC can pretend it is another Jabber client.

Is it ?security through obscurity?, maybe so, but is that an entirely bad thing in this case?

IMO, yes (see arguments in my first post).

Sander,

Another way of performing file transfer in IM clients would be to manually send one message at a time with either a 0 or 1 to indicate the next bit in the file. If that can’‘t be blocked, that must mean that disabling file transfers is “not secure”? No client or server can ever meet your definition of security. Plus, we’‘re not even talking about a security issue, we’'re talking about a feature to help enforce company policy. Security would come through a combination of other things such as forcing anti-virus scans on all files, controlling which apps can be installed on a desktop, firewalls, etc.

Regards,

Matt

Lol Matt,

as one can send messages with an unlimited size (or can one limit the size somewhere?) it may be more easy to escape the special XML characters in a binary and send it within one message.

LG

matt wrote:

Sander,

Another way of performing file transfer in IM clients would be to manually send one message at a time with either a 0 or 1 to indicate the next bit in the file. If that can’‘t be blocked, that must mean that disabling file transfers is “not secure”? No client or server can ever meet your definition of security. Plus, we’‘re not even talking about a security issue, we’'re talking about a feature to help enforce company policy. Security would come through a combination of other things such as forcing anti-virus scans on all files, controlling which apps can be installed on a desktop, firewalls, etc.

Yes, that’'s true, but why is the feature then marketed as a Security feature on http://www.jivesoftware.com/products/wildfire/features/security.jsp while, in fact, it should be as “stupid company policies” with a big warning that the feature can create a false feeling of security so that the company will become less secure overall. Plus, it would be good add a side note saying that it can hurt the unity of the XMPP community; there are already too much file transfers protocols, “features” like this can cause the creation of even more (unofficial!) file transfer protocols.

Blocking transfers via the server in a big company would work imho, for 2 reasons…

  1. Large companies do not usually give users admin rights to install new / different clients (or any other software).

  2. Most large companies do not usually allow end users to write there own software and use it on the network.

I know from my experiance that it was instant dismissal if 1 or 2 above was broken and hence a fairly decent deterrrent. If admin then blocked transfer on the server there is nothing the user can do about it.

If a user has enough technical knowhow to rewite the code from a reverse enginnered exe on the machine in the first place then sacking them for breaking the companies IT policy would deter them, I would have thought.

OK, I know this wouldn’‘t work at a software devel company, but how many large companies > couple hundred people are there anyhow? Probably count them on one hand. If your a small outfit then if you can’'t trust your employees then you aint going very far.

I.

p.s. Secuity taken a step too far? Probably. But thats what big corporates do.

ibradshaw wrote:

Blocking transfers via the server in a big company would work imho, for 2 reasons…

  1. Large companies do not usually give users admin rights to install new / different clients (or any other software).
  1. Most large companies do not usually allow end users to write there own software and use it on the network.

Do not forget about web-based Jabber clients (Java, Flash or Ajax)…