Have you considered using a reverse proxy solution like Pound in place of stunnel? It can add/modify the X-Forwarded-For header on incoming requests, then by tweaking Apache's CustomLog format, you can have the origin IP address in your Apache logs.
By the way - great post!
warming
· 3 months ago
If stunnel can handle X-Forwarded-For http header(s), maybe then mod_rpaf could help apache straighten out the logged ips. Ymmv.
cperciva
· 3 months ago
There are patches for stunnel to make it insert X-Forwarded-For headers; but to do that stunnel needs to do some basic parsing of HTTP connections, which adds significant complexity -- so I'd prefer to avoid that route. You're quite right that this is an option, though.
Jon
· 3 months ago
"which adds significant complexity" - and a larger attack surface...
cperciva
· 3 months ago
That too. :-)
Prakash S
· 3 months ago
192.168.0.44 is this a virtual IP? And is your authoritative nameserver primary or secondary authoritative? thanks!
cperciva
· 3 months ago
192.168.0.44 is a non-routable IP address which I created on a virtual interface. The nameserver is authoritative; I haven't set up AXFR.
A
· 3 months ago
I prefer not to allow outbound mail from a webserver. I allow only inbound web and SSH traffic (and the outbound half of those connections).
cperciva
· 3 months ago
Having outbound email from web servers is good -- otherwise you can't get email from your cron jobs.
pgib
· 3 months ago
Or, you know, like run hundreds of web applications whose functionality relies on or would be strongly crippled without sending email...
John
· 3 months ago
I'd reiterate the need to perform modification of X-Forwarded-For in many situations. In order to prevent session hijacking, many web apps will associate the request source IP with session identifiers. If a new IP makes a request using an existing cookie, the app can force re-authentication. By hiding the source IP address, you're significantly handicapping these types of checks. A strong understanding of your application is essential before implementing this type of security, as is proper testing of security functions afterward.
cperciva
· 3 months ago
Quite true. In my case I don't use source IP addresses for authentication purposes -- it's far too easy for that to break -- but it's certainly something people should be aware of.
madssj
· 3 months ago
Remind me to get you a tinfoil hat that says "Thank you".
Jonas
· 1 month ago
These sort of setups doesn't scale much beyond one or two admins who know the system intimately. It also pretty much requires you to roll your own security update processes.
What I would like to see instead is a privsep'd Apache (like OpenSSH does it), with sensitive processes separate and locked down by default.
Allan Jude
· 2 weeks ago
I've used nginx in front of apache, and nginx can do SSL and X-Real-IP or X-Forwarded-For
But what we use now is alot like what you already have. We use nginx in one jail, serving static content (images), and providing SSL, but it then passes CGI requests to a FastCGI running in a separate jail. This also makes it easy to load balance, by having more than one fastcgi jail, spread across a number of physical boxes.
All Comments
By the way - great post!
What I would like to see instead is a privsep'd Apache (like OpenSSH does it), with sensitive processes separate and locked down by default.
But what we use now is alot like what you already have. We use nginx in one jail, serving static content (images), and providing SSL, but it then passes CGI requests to a FastCGI running in a separate jail. This also makes it easy to load balance, by having more than one fastcgi jail, spread across a number of physical boxes.