Samba in the DMZ

Bomber · 01-20-2002, 05:41 PM

Hey,

Currently I have a linux webserver set-up and I've put it in the DMZ (so it is on a different subnet to the rest of the network), I've got my firewall routing correctly to the webserver, but I want to allow the windows clients on the LAN be able to access samba shares on the webserver.

What dmz-pinholes would I need to create on the firewall to enable samba on the webserver to correctly work with the LAN computers and would this pose much security risk (cause I know the point of the DMZ is to not allow it access the internal network)....?

Any advice or suggestions would be much appriciated.

Thanks.

cliffyman · 12-11-2002, 01:44 PM

I have the exact same question as the person above - does anyone have any suggestions?

-Cliff

ubien · 12-11-2002, 02:04 PM

well in smb.conf you could set:
hosts allow = 192.168.1.0/255.255.255.0
this should only allow IPs coming from 192.168.1.0 to access samba shares. I have no idea how secure / easily beaten this is though.

cliffyman · 12-11-2002, 03:27 PM

I tried setting that and it actually prevented me from accessing SWAT at my workstation. FYI, a little quick info:

1. Each server in the DMZ uses its world IP
2. The subnet mask is 255.255.255.240

Within the LAN...

1. 192.168.28.x
2. Subnet mask 255.255.255.0

The LAN has access rights to everything (LAN, WAN and DMZ) and right now I have the server (designated by its world IP) able to hit one PC on my network (192.168.28.13) - and it can ping it just fine. Without this firewall rule in place, the server can't ping the PC so I've concluded it must be working.

Any other suggestions? I even tried leaving "hosts allow" and "hosts deny" blank in SWAT and I still can't see the workgroup of the server or the server itself (naturally).

Thanks!

-Cliff

cliffyman · 12-11-2002, 03:29 PM

Oh, one more thing... with the firewall rule in place I can use smbclient on the server to successfully connect to the PC and browse its shares. I just can't get the PC to see the server in "network places" (although it can ping the server fine - like I said, the LAN has global access everywhere so this must be a Samba problem and not a firewall problem)

-Cliff

jdc2048 · 12-11-2002, 11:58 PM

What name resolution is in use? If the samba server has no NETBIOS name and/or no resolution mechanism (from the PC perspective) then you won't see it in the "network places" on the PC.

Also you need to have bi-directional netbios traffic allowed (DMZ <->LAN) in order for the traffic to go through. Talk about a security nightmare!

Personnally, I would just tell those who need to get to it to type the name or IP into the address bar.

cliffyman · 12-12-2002, 03:46 AM

Yeah, I definitely don't want to compromise security considering we just spent some big bucks on the new network hardware.

What other means could you suggest besides using Samba / SMB? I was considering setting up an FTP server on the server and limiting access to it (using the FTP config files and our firewall) to our LAN only.

Any other ideas?

jdc2048 · 12-12-2002, 05:05 AM

ftp would definetely have less headaches than samba in a DMZ, but the passwords are sent in the clear. Anyone with a sniffer could get the passwords.

my suggestion would be to use ssh/scp for moving files to maximize security.

cliffyman · 12-12-2002, 01:36 PM

Good call. Although, since the traffic would be limited to LAN <-> DMZ I'm assuming no one could be sniffing our network from the WAN. I appreciate your help and advice on the matter.

plonker · 12-12-2002, 04:22 PM

That's correct. Just as long as you don't allow FTP in from your external port to either your DMZ or LAN you should be fine. I have a setup similar to this ( I have Checkpoint FW-1) between my LAN and DMZ and it works a treat. The only thing I don't allow is anonymous FTP access, so I can track usage.

Cheers
Craig

jdc2048 · 12-13-2002, 05:59 PM

Quote:

Originally posted by cliffyman
Good call. Although, since the traffic would be limited to LAN <-> DMZ I'm
assuming no one could be sniffing our network from the WAN. I
appreciate your help and advice on the matter.

That's correct, however, not all attacks come from outside your network. A
good deal of them begin inside with the company's employees. Anyone that
has permission to install programs on their work PC has the potential
to install a sniffer and use it.

Other factors:
If you are using a switched network, then a sniffer has less chance of
capturing the packets.

If you do use the ftp solution, then definitely ensure that your firewall
blocks all unnecessary traffic from the WAN into the DMZ.

cliffyman · 12-14-2002, 03:54 PM

Done and done. We'll shortly be configuring only our developer / administrator PCs on the LAN to have FTP access to the server in the DMZ, and everything besides SSH and HTTP are blocked coming into the DMZ by default.

Thanks again for everyone's advice. I guess SAMBA in the DMZ is just a bad idea!

-Cliff

peter_robb · 12-14-2002, 04:36 PM

Don't write it off just yet...
A DMZ's purpose is to avoid a compromised server from allowing free access back into the local "safe" lan.
By default, you should have free access LAN to DMZ, but not DMZ to LAN, hence pinholes.
Netbios uses broadcast packets to announce names and services..destination 255.255.255.255.
It is quite easy to forward these directly to/from the samba server using a DNAT rule between the samba server's broadcast address & the LAN broadcast address eg
-A PREROUTING -p udp -s 255.255.255.255 -i LAN_eth~ -j DNAT --to-destination 192.168.2.255 (example DMZ broadcast address) &
-A PREROUTING -p udp -s 192.168.2.255 -i DMZ_eth~ -j DNAT --to-destination 192.168.1.255 (example LAN broadcast address)

Fine tune it later with --dport 137:139 numbers
and -p tcp --dport 139 if you need to.