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.
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.
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.
--
------------------------------------"Never tell me the odds!"---
Ray Olszewski -- Han Solo
Palo Alto, CA [EMAIL PROTECTED]
----------------------------------------------------------------
_______________________________________________________________
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
