Re: Shared drives through a firewall

mcclenbw@xxxxxxxxxxx wrote:
True SSH and WebDAV are better options, but that's changing the topic.
I'm guess since it's an "untrusted server" that someone else is
administering it. So using a different protocol probably isn't an

Maybe.. sometimes the best solution to an awkward problem is to rewrite the problem. The OP did ask for "ammunition", too - an easy, securer alternative way of transferring files certainly seems like anti-SMB-over-the-internet ammunition to me! :)

I've had success in rewriting the problem such that I could deploy webdav on a number of occasions in the past where SMB or FTP were being considered for file transfer.

It sells quite well in this respect based on the fact that it has great client support (better than SCP/SFTP) and in both the linux and windows worlds very rarely requires any extra software for anyone who already has any web infrastructure in place. At worst, the extra software is an apache module..

As far as being less likely to draw attention from attackers than
opening up SMB ports, the key here is to only open SMB ports to allow
communication between the server and client. Don't just open SMB ports
to the world because you need to communicate with one IP address on the
other side of your firewall. That's as silly as opening all ports on a
server, just because you need one open.

Agreed - but in most scenarios, opening up SMB, even to quasi-trusted partners or clients over a WAN isn't ideal either way; too many holes that go too deep for my liking, and they're holes that (unlike HTTP(s)/Webdav) generally can't be partially mitigated with application-layer filtering.

The addition of IP / IP Range filtering makes this scenario less awful, but not unawful, imo. :)

- James.

James (njan) Eaton-Lee | UIN: 10807960 |

"The universe is run by the complex interweaving of three
elements: Energy, matter, and enlightened self-interest." - G'Kar | ca:

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature