reverse proxy
in [Postfix]
|
From: Glenn English on 1 Apr 2010 17:52 On Apr 1, 2010, at 1:48 PM, Victor Duchovni wrote: > What is the "it" that has to be done for "security reasons". Reverse proxy-ing servers on the firewall. The idea, as I understand it, is to keep badness from getting to the servers. I can kinda understand that for HTTP -- ACLs based on UR* and stuff like that might make apache's life easier -- but I don't really know what good an SMTP reverse proxy would do, aside from double checking protocol. > If you don't need proxy-mode for non-security reasons, you don't need > proxy mode. I didn't think so (I'm a long way from needing load balancing, and postfix seems to do a pretty good job of looking out for itself), but I'm looking into it. Thanks for the vote against. It occurs to me to move the spam filtering to the firewall, but I don't see a lot to be gained from that. Besides, I'm a refugee from "fixup protocol smtp." -- Glenn English ghe(a)slsware.com
From: Victor Duchovni on 1 Apr 2010 18:05 On Thu, Apr 01, 2010 at 03:52:46PM -0600, Glenn English wrote: > > On Apr 1, 2010, at 1:48 PM, Victor Duchovni wrote: > > > What is the "it" that has to be done for "security reasons". > > Reverse proxy-ing servers on the firewall. The idea, as I understand it, is to keep badness from getting to the servers. I can kinda understand that for HTTP -- ACLs based on UR* and stuff like that might make apache's life easier -- but I don't really know what good an SMTP reverse proxy would do, aside from double checking protocol. > > > If you don't need proxy-mode for non-security reasons, you don't need > > proxy mode. > > I didn't think so (I'm a long way from needing load balancing, and postfix seems to do a pretty good job of looking out for itself), but I'm looking into it. Thanks for the vote against. > > It occurs to me to move the spam filtering to the firewall, but I don't see a lot to be gained from that. Besides, I'm a refugee from "fixup protocol smtp." Were you asking about using Postfix as a proxy in front of internal SMTP servers, or using firewall reverse-proxy SMTP support to sit in front of Postfix. The latter is definitely a very bad idea. The former is sometimes appropriate, but fairly unusual, letting Postfix operate normally with a store and forward queue is much more typical and usually the right choice. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
From: Glenn English on 1 Apr 2010 18:42 On Apr 1, 2010, at 4:05 PM, Victor Duchovni wrote: > Were you asking about using Postfix as a proxy in front of internal SMTP > servers, or using firewall reverse-proxy SMTP support to sit in front of > Postfix? I was asking about Postfix running as a daemon on the firewall computer that handles routing and inspecting traffic between the WAN, the DMZ, and the LAN. This Postfix would intercept and inspect incoming SMTP connections (and drop some) before passing valid ones on to the real Postfix MTA running on a computer in the DMZ. A 3-hole PIX running Postfix, in other words. > The latter is definitely a very bad idea. Why? I can see how it'd be a duplication of effort, but I don't see how it would hurt. > The former is sometimes > appropriate, but fairly unusual, letting Postfix operate normally with > a store and forward queue is much more typical and usually the right choice. I know it's much more typical; I'd never heard of putting proxies on the firewall before (I'd never thought of the PIX stuff as a proxy, just a little content filtering (that was always getting me in trouble)). But popularity in itself doesn't make it the best way to do things. The argument is that a packet filter is easily made 'default deny' but a lot of cruft gets through because the packet headers may be OK, while the content is evil. An IDS/IPS is not effective because it's 'default allow' and is always chasing the latest exploit pattern. A reverse proxy, though, is an application level 'default deny'. Therefore, reverse proxy filtering can block content-based attacks that haven't been seen yet. (I know there's a lot more to Snort's rules than just the latest patterns, and that it's 'default allow' because that's the way the default ruleset is configured. I'm just repeating some of what they said, and I'm attracted to parts of the proxy argument.) -- Glenn English ghe(a)slsware.com
From: Wietse Venema on 1 Apr 2010 19:36 Glenn English: > > On Apr 1, 2010, at 4:05 PM, Victor Duchovni wrote: > > > Were you asking about using Postfix as a proxy in front of internal SMTP > > servers, or using firewall reverse-proxy SMTP support to sit in front of > > Postfix? > > I was asking about Postfix running as a daemon on the firewall computer th >-at handles routing and inspecting traffic between the WAN, the DMZ, and the >-LAN. This Postfix would intercept and inspect incoming SMTP connections (and >- drop some) before passing valid ones on to the real Postfix MTA running on >-a computer in the DMZ. A 3-hole PIX running Postfix, in other words. So why must this be a Postfix-as-proxy, instead of a complete Postfix-with-queue instance? Wietse
From: Stan Hoeppner on 1 Apr 2010 21:33 Glenn English put forth on 4/1/2010 5:42 PM: > I was asking about Postfix running as a daemon on the firewall computer that handles routing and inspecting traffic between the WAN, the DMZ, and the LAN. This Postfix would intercept and inspect incoming SMTP connections (and drop some) before passing valid ones on to the real Postfix MTA running on a computer in the DMZ. A 3-hole PIX running Postfix, in other words. If you want all the edge security managed by one device, I'd suggest you look here: http://www.astaro.com/ and prepare to open the corporate pocketbook relatively wide depending on the size of your user base and WAN bandwidth. If you actually know enough about what you're doing, just punch a TCP 25 pub/priv PAT hole through your current F/W to your Postfix server and beef up your AS/AV countermeasures. We've talked about a plethora of such methods both here and on spam-l that you've seen. Using an SMTP proxy/relay on the F/W box and sticking your Postfix server in the DNZ is a useless, fruitless, labor hogging effort, complicating your network architecture and introducing new troubleshooting headaches, for _zero_ security gain. Proxies and DMZs look neat on paper and in theory, but in the real world, for 95%+ or more of deployed applications, including SMTP mail, they create far more problems than they could ever hope to solve. Any seasoned sysop shuns unneeded complexity. The KISS principle applies to IT as it does to most things. -- Stan
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Sub-domains ignore transport relayhost Next: problems with permit_sasl and unknown_address |