Just to clarify.... In the rule:
# Add SMTP Block
/sbin/iptables -A CUSTOMFORWARD -p tcp -s ! ip.ad.re.ss --
destination-port 25 -i eth0 -j LOG --log-prefix "PORT25_REFUSED"
/sbin/iptables -A CUSTOMFORWARD -p tcp -s ! ip.ad.re.ss --
destination-port 25 -i eth0 -j DROP
How would it be possible to be written in case of two internal mail servers?
Or does the use of (!) will prohibit this and I will have to write a rule
for each server separately?
Thanks,
Stef
> ----- Original Message -----
> From: "Angus Scott-Fleming" <angussf@...>
> To: <Ipcop-user@...>
> Sent: Thursday, March 20, 2008 4:14 PM
> Subject: Re: [IPCop-user] IPCop stopping email going out
>
>
>> On 20 Mar 2008 at 8:33, Alex Schaft wrote:
>>
>>> On 2008/03/20 05:58, Chris Leahy wrote:
>>> > Hi All
>>> > I want to set IPCop to stop all email from the orange network going
>>> > out to the
>>> > big bad world and only allow 1 machine on the green network to send
>>> > email
>>> > out.
>>> > Any ideas?
>>> > Thanks to everyone ;-)
>>> >
>>> Best option would be the BlockoutTraffic addon
>>>
>>> http://www.blockouttraffic.de/
>>
>> I wanted to do something similar last year -- I needed to block outbound
>> SMTP
>> from every machine but the mail server. After playing with BOT I
>> realized it
>> was overkill and *_way_* too much work for what we needed, so I did a
>> little
>> searching of the Marc IPCop- user list archives as I was sure others had
>> needed
>> the same capabilities. You can block outbound SMTP with just a couple of
>> lines
>> in rc.firewall.local.
>>
>> For future reference, here's what I did. Although I was working just
>> with a
>> GREEN-RED network, something like this suitably modified with additional
>> lines
>> for ORANGE should work fine for you. I ended up adding the following
>> lines to
>> /etc/rc.d/rc.firewall.local:
>>
>> (in the "start" section)
>>
>> # Add SMTP Block
>> /sbin/iptables -A CUSTOMFORWARD -p tcp -s ! ip.ad.re.ss --
>> destination-port 25 -i eth0 -j LOG --log-prefix "PORT25_REFUSED"
>> /sbin/iptables -A CUSTOMFORWARD -p tcp -s ! ip.ad.re.ss --
>> destination-port 25 -i eth0 -j DROP
>>
>> (in the "stop" section)
>>
>> # Remove SMTP Block
>> /sbin/iptables -D CUSTOMFORWARD -p tcp -s ! ip.ad.re.ss --
>> destination-
>> port 25 -i eth0 -j LOG --log-prefix "PORT25_REFUSED"
>> /sbin/iptables -D CUSTOMFORWARD -p tcp -s ! ip.ad.re.ss --
>> destination-
>> port 25 -i eth0 -j DROP
>>
>> where "ip.ad.re.ss" is the IP address of the mail-server. Watch
>> word-wrap --
>> each of the above sections contains 3 lines, the first starts with "#"
>> and the
>> other two start with "/sbin/iptables". I then ran rc.firewall.local to
>> stop
>> and restart all the custom rules:
>>
>> root@...:~ # ./rc.firewall.local stop
>> root@...:~ # ./rc.firewall.local start
>>
>> The first time, of course, the new rules weren't active so it whined
>> about
>> missing rules, but after restarting we immediately found the IP address
>> of the
>> spamming machine by looking at the firewall logs.
>>
>> HTH
>>
>> Angus
>>
>> --
>> Angus Scott-Fleming
>> GeoApps, Tucson, Arizona
>> 1-520-290-5038
>> +-----------------------------------+
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> IPCop-user mailing list
>> IPCop-user@...
>> https://lists.sourceforge.net/lists/listinfo/ipcop-user
>
|