Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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).
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)
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.
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.
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. 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.
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.
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!
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.
Last edited by peter_robb; 12-14-2002 at 04:40 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.