On 11/5/02 11:23 AM, Ray Olszewski from <[EMAIL PROTECTED]> wrote: > OK. What you are asking for here is considerably simpler than what I > understood from your earlier message, and it is quite straightforward to do > at the ipchains level. I'm too out of date with Eigerstein to translate the > ipchains stuff to Charles' scripts, though, but perhaps someone else will be > able to step in with that part. I suspect, though, that you will have to add > them to the file that handles non-standard rules explicitly, since the > requirements are a bit specialized.
I am glad my revision to my original post made things clearer. Reading the troubleshooting guide helped. > > At 05:48 AM 5/11/02 -0400, Enchufa2.com wrote: > [...] >> What I would like to do is prevent users from changing the browser proxy >> configuration at their workstations and then bypass the proxy/cache and also >> to prevent unauthorized users to change their e-mail app configuration and >> become able to send/receive external e-mail using external e-mail servers. >> >> Ideally, unathorized users would only be able to use the local mail servers >> and authorized users would be able to use both internal and external >> servers. > > To prevent ALL users from bypassing the Squid proxy server, create ipchains > rules that block all traffic destined for port 80 (and maybe 443, 20, and > 21, depending on what services you have Squid handling) from any internal IP > address other than the one for the host running the Squid proxy. > > To prevent ALL users from bypassing the internal mail server, create > ipchains rules that block all traffic destined for port 25 from any IP > address other than the one for the host running SMTP server. Also block all > traffic destined for ports 110 and the IMAP port (unless there is a reason > why the SMTP server needs to connect to offsite servers on these ports; then > do the same as port 25.) > > Preventing only "unauthorized" users from doing these things depends on how > you identify them. You seem to have in mind authorizing *hosts* rather than > users, since you write: > >> I was thinking of using DHCP to associate "authorized machines" with an >> specific IP addresses or range via IP leases based on MAC addresses. For Proxy and SMTP usage, the users are already required to authenticate themselves, but I would like to have another layer of security by restricting access to HTTP and SMTP/IMAP/POP traffic based on IP addresses. > Doing this is a natural extension of the process of authorizing the servers > to use these ports. You'd do it (at the ipchains level) by inserting, at an > appropriate location, input-chain rules that ... > > FIRST, explicitly ACCEPT traffic to (for example) port 25 > from the "authorized machines" > > SECOND, explicitly DENY (or REJECT) traffic to those same > ports from all other LAN addresses > > BTW, your original message seemed to want to do more than block ... you > seemed to be looking for a way to redirect at least some of this traffic > back to the LAN hosts. This, or at least some of this, may be doable by way > of a custom chain in ipchains; I haven't tried it so am not sure. I'm more > confident that the iptables system in kernel 2.4.x could manage this by way > of its PREROUTING table (though once again I haven't actually done it), > albeit at some price in extra LAN traffic. I haven�t looked at more recent versions or distros of LRP/LEAF heritage (Oxygen, Dachstein) but it may be that I upgrade to a LRP/LEAF derivative based on a 2.4 kernel and iptables filtering. Thanks again, Omar _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
