again packet filter rules

there is no need to define blocks..anything that is not specifically allowed is blocked by default.  Also what does rule #1 say?

[ QUOTE ]
there is no need to define blocks..anything that is not specifically allowed is blocked by default.  Also what does rule #1 say? 

[/ QUOTE ]

the problem is, the firewall acts as smtp relay.. so i want to block traffic
(all)  to the relay from some ips.. and how can i do this. my way is the one above..

...just edit/check  :

/Proxies/SMTP/Outgoing Mail/Allowed Networks  

greetz
 Claus

[ QUOTE ]
...just edit/check  :

/Proxies/SMTP/Outgoing Mail/Allowed Networks  

greetz
 Claus 

[/ QUOTE ]

in v 4 ?

no one with any hint ?

Hi Toto, 

if i understood your setup correctly, than you only want to have an outgoing smtp mail relay, no incoming smtp traffic, right?
And you are using ASL V4?

What you need to do is, remove all SMTP routes from the Incoming Mail section in WebAdmin > Proxies > SMTP.
This will remove the Any SMTP Any Allow rule for all incoming traffic.

Than you only need to add you 'Thrusted hosts'  to 'Allowed networks' in the 'Outgoing Mail' section.

Thats it, than all incoming connection are sent to the default behavior which is LOGDROP.

hope that helps
regards
Gert

hi gerd,

no . i wanna block some ips to the external interface it should be dropped
on the external interface...

lets say traffic from 123.0.0.0 comes to external interface, so i like
this ip to be dropped on extern interface of the firewall , no matter what kind of port or proxy is used...  lets say 123.0.0.0 is some hacker like to check for something so i like to drop BEFORE something other take care of the ip paket.

maybe for other thinks we could make it some diffrent.. like traffic comes from 123.0.0.0 but i only want to block smtp traffic.. so it should be blocked BEFORE the proxy take care of it. it make no sense fror me that the proxy takes traffic i dont want.. or that i am not able to block traffic on external interface because of pppoe interface(?).

so what can i do ?


if not clear enough we should change to german email, if you have some time for this...

In v4 if you have enabled SMTP relay, it will accept all connections, and you can do nothing in the packet filter to prevent it from accepting traffic.  The only way to limit who can use the relay is to specify the allowed networks.  

So, basically, if someone port scans your firewall they will see port 25 as open, but they cannot use it as a relay.  Unfortunately, there isn't a way to make it work how you want.  This only happens with the proxy ports.  All other ports will be dropped by the packet filter.

The proxy sits outside the iptables barrier; so iptables commands will not block access to it; but I believe somebody tweaked their Exim proxy to do such as you want. Do a Search and repost if you can't find it...

first of all thanx to all, for your answers ! (hope my englsh is not SO bad)

then, what sense makes this proxy on the firewall ? my internal mailserver
does not realy also.. but i like to use this proxy/firewall combo not to have this traffic in my internal network .. thats the job of the firewall and proxy in my opinion .. to keep traffic out of the internal network on a rule based config.

thats the point where i can "turn of the proxy"..  because the there is no advantage .. all the things the proxy can do, is some work in qmail , spamassasin etc. if you know what i mean... the firewall proxy should take the load from my internal box.. then i can still use my cisco pix and some config
work to qmail and co. and i also can not understand , why the packet filter grabs behind the proxy , maybe someone can explain that in detail...

The job of the firewall I agree is to keep unwanted traffic out of your local network, but thats not the main focus of the smtp proxy.

It is there to protect your internal server against attacks, filter spam (and viruses) etc, and having the proxy on the firewall does take a load from the internal box as it is doing spam filtering, DNSBL look-up's etc instead of the internal mail server.

Its true, that if you can achive the same setup with qmail/spamasssin/MailScanner etc but not in the same easy to manage way.

That aside, I understand your confusion, because i wanted to do a similar thing a while ago, and found that the proxy is not protected by the firewall packet filter rules. Perhaps the astaro team can comment as to why this is?

Lastly, your English isn't great, but its hundreds of times better than my German [:)]

One reason it's architected that way: by simply enabling proxies, all functionality needed by the proxy gets delivered. If the proxy's behavior was interrelated/dependent upon the rules being configured right, you would have an exponentially greater number of posts here.

Granted, if you were to architect it the other way, you could support more complex controls; but the design of the proxy should be focused on just its functionality, not iptables. Someday, maybe Astaro will take the trouble to add fields to the proxy's configuration page to accomplish this level of control; in the meantime, you can do it from CLI.

Another interesting thought would be to offer a choice at time of proxy configuration as to whether it sits behind the iptables. That's a whole new dimension of complexity to introduce under the hood, though. The proxy would need to sit in its own virtual DMZ running on the box, right? [If you were to confine the proxy to sit behind just one internal NIC, then you would lose the access control for that NIC's LAN; and that wouldn't be very intuitive -the proxy is on the box, not behind a NIC] So Astaro would have to synthesize network address spaces for each proxy they used. And all that might be a bit much for some people to get their heads around; it would be somewhat daunting for some to configure and troubleshoot.

I suspect Astaro chose to keep it simple, figuring that most proxy settings can deliver on the essentials of what you need, and the development time is better spent (at this point in time) improving the functionality of the proxies (and maybe adding even more proxies in the months and years to come? SIP?? UPNP??); although I for one would certainly welcome the introduction of such a virtual DMZ proxy architecture as an option to Astaro...

One reason it's architected that way: by simply enabling proxies, all functionality needed by the proxy gets delivered. If the proxy's behavior was interrelated/dependent upon the rules being configured right, you would have an exponentially greater number of posts here.

Granted, if you were to architect it the other way, you could support more complex controls; but the design of the proxy should be focused on just its functionality, not iptables. Someday, maybe Astaro will take the trouble to add fields to the proxy's configuration page to accomplish this level of control; in the meantime, you can do it from CLI.

Another interesting thought would be to offer a choice at time of proxy configuration as to whether it sits behind the iptables. That's a whole new dimension of complexity to introduce under the hood, though. The proxy would need to sit in its own virtual DMZ running on the box, right? [If you were to confine the proxy to sit behind just one internal NIC, then you would lose the access control for that NIC's LAN; and that wouldn't be very intuitive -the proxy is on the box, not behind a NIC] So Astaro would have to synthesize network address spaces for each proxy they used. And all that might be a bit much for some people to get their heads around; it would be somewhat daunting for some to configure and troubleshoot.

I suspect Astaro chose to keep it simple, figuring that most proxy settings can deliver on the essentials of what you need, and the development time is better spent (at this point in time) improving the functionality of the proxies (and maybe adding even more proxies in the months and years to come? SIP?? UPNP??); although I for one would certainly welcome the introduction of such a virtual DMZ proxy architecture as an option to Astaro...