Is this bad practice?
 

Hi Everyone,

On my network, I wish to install a file server (Samba) and a proxy server (Squid). Our firewall has 2 network interfaces (plus 1 WAN). Since the proxy will need direct port 80 outbound access, I wish to put the proxy server on the 2nd interface to prevent ip spoofing.

Now, since we have a limited budget, we only have 1 physical server, however the server has 2 network cards in it. It is ok to bind samba to one network card, and bind squid to the other?

I guess I could use iptables to lock it down a bit better..

Or is the above just a bad idea and defeats the purpose of the firewall?

Thanks

It might help to discuss what the flow of traffic is. Most installations would probably run a DMZ on one interface and the LAN on the other interface. Is the proxy for all web traffic? Are you doing transparent proxying? Either way, your firewall should be able to direct traffic to the proxy server. Also, proper network segmentation (e.g. VLANs) should make IP spoofing nearly impossible with correctly configured routers.

Is this conceptually what your setup looks like?

I'm also a little puzzled by the IP spoofing problem. Are you saying you've had clients on "your lan" spoof the proxy IP address, and then had web server replies magically routed back to their workstation?

Yes that diagram is pretty much correct except "new http proxy" is also a file server which is what serves the LAN subnet directly.

By IP spoofing, (please keep in mind that this network isn't set up yet), I'm just afraid that if the proxy server was on the LAN subnet, someone coule change their workstation IP to the proxy IP, then be able to get direct access to the internet. Could this not happen? Also, we only have a Layer 2 switch, so can't VLAN just yet...

Thanks
----------------

Someone on your network could spoof an IP (i.e. pretend to be the proxy) and possibly get a request out to the 'net. But they would not receive a reply back -- instead the reply would go to the proxy host itself, and likely be ignored.

On the other hand, your firewall has two different internal interfaces. You could prevent this spoofing from going anywhere by requiring outbound http/s traffic to come in only on the interface that's connected to the proxy host.

Thanks for your reply

Really? Why would it be ignored? Surely if the "malicious" PC replied to a "who-has" ARP request before the proxy did, then it could poison the firewall's ARP table and "win"? Of course, I could just enable static ARP tables in the firewall.

This is exactly what I'm trying to do, but use the same physical server for both interal LAN (File server) and DMZ (proxy) services by "binding" each daemon to the respective phy interface on the server. This is my question on whether or not it is bad to do this

Many Thanks

I see your point about ARP poisoning. If that's a concern, it may need to be dealt with separately - e.g. arpwatch is quite handy. Static ARP tables could be another (or additional) approach.

Nope, it's not bad. (To be fair, what you're really doing is binding the daemon to an IP address / port combination; the IP is assigned to an interface.)

Is this done a lot industry? Have you got any tips to make sure that the proxy squid can't "leak" over to the LAN interface, as well as the Samba server "leaking" over to the DMZ side?

Thanks

IMO, an intelligent tcp/udp-listening service deployment will always bind to only the addresses it really needs to be listening on. (There are some daemons that don't offer this feature, unfortunately - e.g. ntpd.)

What do you mean by "leaking"? If foo is listening on 10.80.0.101 (and nothing else), then that is the only address foo will accept requests to. There simply won't be an open port on other addresses.

Be sure to configure your daemon to bind to a specific IP, rather than a wildcard (0.0.0.0/0, *, or no IP). After starting the daemon, check/confirm where it's listening using netstat -ltn (for tcp services) or netstat -lun (for udp services).