Is it possible to disable file and avatar transfers over server to server connections? Failing that is it possible to disable this functionality altogether?
One of the reasons for wantint to install our own server was to get some control over instant messaging and prevent the leakage of files from our corporate network out onto the internet, which was almost impossible to control with mainstream instant messaging services such as MSN / AIM.
Many thanks.
Jason
As I understand it, this is largely going to be a client issue no matter what IM network you’‘re using. You may or may not be able to stop file transfers from occurring, though if they have Internet access to any degree, you can’'t stop all of it.
My suggestion would be to either disable s2s entirely, or log absolutely every bit of traffic in and out of your Jabber stuffs so that you’‘d have a record of what people are talking about, sending, etc. Other than that, I don’‘t think there’'s anything else you can do short of disabling Internet access.
Thanks for the info.
I don’'t really buy it though. When a file transfer is initiated the following request gets sent to the server, goes down the S2S server connection and is relayed to the external client.
I don’‘t see why a server side content filer couldn’'t eat these messages and respond with an error message, avatars are also sent over the wire, given the windows WMF vulnerability it would be great to be able to stop virtually anything other than plain text from traversing the network boundary via IM.
Allowing controlled instant messaging access to the outside world is the primary reason I’'m deploying Wildfire, if controls are not available then the users may as well be using MSN or Yahoo.
I’‘ll go have a look at the plug-in structure, I’'m sure there is a means to tack on some control.
Thanks
Jason.
Never mind. I’'ve just noticed that there is a vote on to get these features included in the content filter plug-in.
Thanks
Jason.
Jason,
One place we’‘re looking to add controls is through Spark Manager. There’'s the obvious settings of enable/disable file transfer, but it seems like finer granularity control is more interesting. For example:
Force all file transfers to go through an anti-virus check.
Allow internal file transfer, but disable file transfer to those not in the company.
Only allow file transfer of certain file types.
Only allow file transfer for certain groups of users.
Are there other controls you would want? Which out of the ones I listed above would you find most compelling?
Regards,
Matt
Hi Matt,
Would the settings only be applicable to Spark clients or would this just be a convenient place to include the configuration settings server-wide? For the purposes of content filtering it’'s always better to filter at the server rather than rely on the client as clients other than your own or hacked derivatives would bypass the settings.
Would like to block pretty much all binary transfers between our server and other servers on the internet. The goal here is to make outside suppliers and some personal use of messaging safe. In some circumstances we may wish to “trust” some specific servers and enable this functionality.
-*Force all file transfers to go through an anti-virus check.
Always useful for any transfers, not sure how the mechanics would work.
-*Allow internal transfer, but disable file transfer to those not in the company.
Good, but perhaps in the domains whitelist for connections we could mark a particular server/domain as trusted for transfers.
-*Only allow file transfer of certain file types.
Unless the server acts as an intermediary for the file transfer and can use some unix “magic” style file identification techniques I doubt that this would be very reliable, it can’'t hurt but might give a false sense of security.
-*Only allow file transfer for certain groups of users.
Being able to whitelist certain users would make a great deal of sense, particularly those working on a helpdesk who are providing technical support for instance.
Thanks
Jason.
The problem that arrises is that the server can only account for known methods of file transfer. In other words there is the standard XMPP methods to transfer files but it is relativly trivial to hack your own client, as XMPP is an open standard, that would just change the namespace for the transfer method and voila I bypass the file transfer blocks. Perhaps the concern is only marginal but I think rather valid as XMPP becomes more prominent.
Alex
Valid point, however blocking standard means of transfers would be a worthwhile measure. Yes people can hack clients, but I’‘m not concerned with those users, anyone smart enough to do that could I’'m sure find easier ways to get files in and out of the network.
The more likely threat that bothers me is an internet worm traversing through the jabber network. For this worm to be able to propogate successfully it would have to use file transfer methods that are supported by the majority of clients.
One good thing going for the jabber network is the client diversification so the chances of a traditional worm being able to successfully spread throughout the network are pretty slim, as the worm would have to be able to retrieve and understand the configuration parameters and contacts list for each different client. However, if and when google open up google talk to 3rd party connections the risk to users on the jabber network will increase as a significant amount of users will all be using the same client.
When protecting our e-mail/web users from viruses, spyware, spam etc. I do not rely on any features within the mail client or on the desktop machine - of course desktop measures are also in place - Malicious content gets blocked at the border through e-mail scanners, web filtering, firewalls etc. this is the only sane way to protect a network from internet threats.
A module that spots anomolous messages such as users trying to bypass the filtering via the methods you suggested is also interesting, in this case it is not essential the messages are blocked, an administrator notification and turning up auditing for the conversation is all that is required in this scenario. A malicious employee can be dealt with through employment contracts, provided that appropriate evidence is collected.
The Wildfire server rewriting and brokering requests (turning peer 2 peer into client 2 server 2 client) in such a way that files can be virus scanned and sent through a content filtering mechanism would also be interesting.
I don’‘t have any expectations of any of these features making it into the product, they are ideas into the pot but in the meantime it is unlikely that I’'ll be able to permit communications between our internal server and the outside world.
Perhaps this feature set doesn’'t belong within wildfire and would instead make more sense as some sort of proxy that could sit between any jabber server and the outside world?
Cheers
Jason
(Administrator for a local government site)