Just wondering how to run 2 versions of Apache on the same server, listening on different IPs and both on port 80.
Does one give them, the httpd, different names and effectively duplicate most of the Apache set-up ?
I use Apache;s virtual hosts facility for normal purposes but this is for a different project.
Thank you.
Paul.
On Mon, Aug 29, 2011 at 05:01:13PM +0100, Always Learning wrote:
Just wondering how to run 2 versions of Apache on the same server, listening on different IPs and both on port 80.
Does one give them, the httpd, different names and effectively duplicate most of the Apache set-up ?
I use Apache;s virtual hosts facility for normal purposes but this is for a different project.
Thank you.
Paul.
First, this sounds like a messy way to do it... spinning up another OS instance with the appropriate version of Apache you are after sounds cleaner...
However...
As long as you keep your various Apache installs from stepping on each other (where the binaries, logs, configs live, etc), you just need to make sure they're binding to mutually exclusive IP/port pairs. The "Listen" directive is likely what you're after here.
Ray
On Mon, 2011-08-29 at 09:13 -0700, Ray Van Dolson wrote:
First, this sounds like a messy way to do it... spinning up another OS instance with the appropriate version of Apache you are after sounds cleaner...
I have a spare server but I want to use an under-utilised one.
As long as you keep your various Apache installs from stepping on each other (where the binaries, logs, configs live, etc), you just need to make sure they're binding to mutually exclusive IP/port pairs. The "Listen" directive is likely what you're after here.
That's what I am currently browsing Google for.
Can the 'Listen 1.2.3.4:80' statement be inside a Virtual Host section ?
Does the 'NameVirtualHost' statement affect every Virtual Host until the next encounter of it, IP that is ?
If I don't get an answer I'll probably experiment.
Paul.
On Mon, Aug 29, 2011 at 05:23:24PM +0100, Always Learning wrote:
On Mon, 2011-08-29 at 09:13 -0700, Ray Van Dolson wrote:
First, this sounds like a messy way to do it... spinning up another OS instance with the appropriate version of Apache you are after sounds cleaner...
I have a spare server but I want to use an under-utilised one.
I was thinking virtualization (Xen or an OpenVZ style might be appropriate).
As long as you keep your various Apache installs from stepping on each other (where the binaries, logs, configs live, etc), you just need to make sure they're binding to mutually exclusive IP/port pairs. The "Listen" directive is likely what you're after here.
That's what I am currently browsing Google for.
Can the 'Listen 1.2.3.4:80' statement be inside a Virtual Host section ?
Does the 'NameVirtualHost' statement affect every Virtual Host until the next encounter of it, IP that is ?
If I don't get an answer I'll probably experiment.
Listen should be used in the global configuration. So, for example your 2.2 configuration file listens on 1.2.3.4:80:
Listen 1.2.3.4:80 NameVirtualhost 1.2.3.4:80
And you have an Apache 2.3.x instance with a separate config file listening on either a different IP or a different port on the initial IP:
Listen 1.2.3.5:80 NameVirtualHost 1.2.3.5:80
<VirtualHost 1.2.3.5:80> ... </VirtualHost>
or
Listen 1.2.3.4:8080 NameVirtualHost 1.2.3.4:8080
<VirtualHost 1.2.3.4:8080> ... </VirtualHost>
Ray
On Mon, 2011-08-29 at 09:26 -0700, Ray Van Dolson wrote:
I was thinking virtualization (Xen or an OpenVZ style might be appropriate).
Perhaps when I start using Centos 6.1. KVM or XEN ?
Listen should be used in the global configuration. So, for example your 2.2 configuration file listens on 1.2.3.4:80:
The standard Listen statement is used globally for the benefit of non-virtual hosts, if any.
And you have an Apache 2.3.x instance with a separate config file listening on either a different IP or a different port on the initial IP:
Even sub-version numbers of Apache are stable, odd ones are less stable. That is why I use only 2.2.
<VirtualHost 1.2.3.5:80>
I never ever give a virtual host declaration an IP address. If moving the virtual host to another server, I don't have to change anything expect the DNS. Also virtual hosts are web sites with different domain names, so I use
<virtualhost anydomain.com:80 www.anydomain.com:80>
<virtualhost domain2.com:80 www.domain2.com:80>
instead.
I found some information on
http://httpd.apache.org/docs/2.2/vhosts/examples.html
http://httpd.apache.org/docs/2.2/mod/core.html#namevirtualhost
I think the solution for me is two NameVirtualHost statements:-
NameVirtualHost 11.22.33.44:80
NameVirtualHost 11.22.33.55:80
with normal virtual hosts on IP 11.22.33.44 and the special virtual host on 11.22.33.55
This will give me a separate IP address, for the special virtual host, which I can utilise in iptables.
Thank you for your suggestions.
Best regards,
Paul.
On Mon, Aug 29, 2011 at 1:19 PM, Always Learning centos@u61.u22.net wrote:
I was thinking virtualization (Xen or an OpenVZ style might be appropriate).
Perhaps when I start using Centos 6.1. KVM or XEN ?
For light use you could drop in VMware server or player or virtualbox without much effect on the current system. It shouldn't be necessary, though, unless you'd like to install otherwise conflicting rpm packages or give root access to someone on the virtual server only.
Listen should be used in the global configuration. So, for example your 2.2 configuration file listens on 1.2.3.4:80:
The standard Listen statement is used globally for the benefit of non-virtual hosts, if any.
And you have an Apache 2.3.x instance with a separate config file listening on either a different IP or a different port on the initial IP:
Even sub-version numbers of Apache are stable, odd ones are less stable. That is why I use only 2.2.
<VirtualHost 1.2.3.5:80>
I never ever give a virtual host declaration an IP address. If moving the virtual host to another server, I don't have to change anything expect the DNS. Also virtual hosts are web sites with different domain names, so I use
<virtualhost anydomain.com:80 www.anydomain.com:80>
<virtualhost domain2.com:80 www.domain2.com:80>
instead.
So why can't you do that for your new virtualhost instead of running on a different IP?
I found some information on
http://httpd.apache.org/docs/2.2/vhosts/examples.html
http://httpd.apache.org/docs/2.2/mod/core.html#namevirtualhost
I think the solution for me is two NameVirtualHost statements:-
NameVirtualHost 11.22.33.44:80
NameVirtualHost 11.22.33.55:80
with normal virtual hosts on IP 11.22.33.44 and the special virtual host on 11.22.33.55
This will give me a separate IP address, for the special virtual host, which I can utilise in iptables.
If you are just firewalling there, apache can permit/deny ip ranges on its own for a location or virtualhost.
On Mon, 2011-08-29 at 13:35 -0500, Les Mikesell wrote:
For light use you could drop in VMware server or player or virtualbox without much effect on the current system. It shouldn't be necessary, though, unless you'd like to install otherwise conflicting rpm packages or give root access to someone on the virtual server only.
I've use Virtual Box successfully for Windoze 98 to run Ami Pro 3.1.
So why can't you do that for your new virtualhost instead of running on a different IP?
A mentally deranged lunatic has sent 30,000+ wrong URLs to a tiny web site. Its started about 5 August but significantly escalated on 22 August.
My Apache routine can add the IPs to iptables and block them. Since 22 August the lunatic has used over 100 different IPs from around the world to send those wrong URLs which always seem to include one of these:-
forgotten_password.php
login.php
contact.php
Assigning a spare IP address to this small web site should make it easier for me to experiment with IP tables and examine TCP packets without disturbing the server's normal workings. For example no valid HTTP request sent to that IP address should contain 'pas' or 'log' or 'con' so if I detect these the packets can be dropped - that is the theory. With dropped packets I lose the ability to easily record IP address and host name. However my web page has over 100 entries of machines compromised in the current abuse, so loosing new details is worth the satisfaction of blocking the loony.
If you are just firewalling there, apache can permit/deny ip ranges on its own for a location or virtualhost.
I don't know which IP address to block until at least one 'hit'. For low level abuse, I use a routine to add 'Deny from' to the site's .htaccess file. An IP blocked with this method can still access HTTPD where it will receive a 403 rejection. Thus successful blocks still involve the web server.
By filtering in IP tables by IP and then port, I can try to identity those keywords: con, pas, log and, if successful, drop the packets. Packet length, used by this lunatic, with a very few exceptions, is 60 bytes, so I could potentially identify the required 3-byte fragments.
It is amazing so many machines can be broken-into or misused by one deranged lunatic. I wonder if those machines run on Windoze.
Paul.
Always Learning wrote:
On Mon, 2011-08-29 at 13:35 -0500, Les Mikesell wrote:
<snip>
So why can't you do that for your new virtualhost instead of running on a different IP?
A mentally deranged lunatic has sent 30,000+ wrong URLs to a tiny web site. Its started about 5 August but significantly escalated on 22 August.
Sorry, not a lunatic. Your website's name has been harvested, and added to some black-market commercial or script kiddie toolkit, and it's on infected servers around the world. Take it from me... (I'm a contractor for a US Federal Gov't agency*, and we get *tons*.
My Apache routine can add the IPs to iptables and block them. Since 22 August the lunatic has used over 100 different IPs from around the world to send those wrong URLs which always seem to include one of these:-
Check out fail2ban. It works very nicely. <snip> mark
On Mon, 2011-08-29 at 15:31 -0400, m.roth@5-cent.us wrote:
Sorry, not a lunatic. Your website's name has been harvested, and added to some black-market commercial or script kiddie toolkit, and it's on infected servers around the world. Take it from me... (I'm a contractor for a US Federal Gov't agency*, and we get *tons*.
It would be nice if Uncle Sam went after the pests.
The attacks are not automatic. The loony is currently having difficulty finding vulnerable IPs and concentrating his efforts on a Japanese company with very lax security (7 IPs at the same place so far).
Check out fail2ban. It works very nicely.
Mark,
it states:
Fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.
I would like, if possible, to identify the fragments in IP tables and instantly block the packets thus preventing them entering the remainder of the server. Fail2ban does not do this. My current blocking requirement is specialised.
Paul.
Always Learning wrote:
On Mon, 2011-08-29 at 15:31 -0400, m.roth@5-cent.us wrote:
Sorry, not a lunatic. Your website's name has been harvested, and added to some black-market commercial or script kiddie toolkit, and it's on infected servers around the world. Take it from me... (I'm a contractor for a US Federal Gov't agency*, and we get *tons*.
It would be nice if Uncle Sam went after the pests.
Please. We don't want "unintended consequences" (as in, you're running these servers open to the 'Net? Why, you should....)*
The attacks are not automatic. The loony is currently having difficulty finding vulnerable IPs and concentrating his efforts on a Japanese company with very lax security (7 IPs at the same place so far).
Sounds like that may be their attack vector. I'd expect it to spread.
Check out fail2ban. It works very nicely.
Mark,
it states:
Fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.
I would like, if possible, to identify the fragments in IP tables and instantly block the packets thus preventing them entering the remainder of the server. Fail2ban does not do this. My current blocking requirement is specialised.
You might want to try it, anyway. It takes care of a *lot* of other attacks, too.
mark
* Forgot this on the last post: ObDisclaimer: I do not speak for the US Federal Gov't, nor for my employer; I speak (and rant) only for myself.
On Mon, Aug 29, 2011 at 2:25 PM, Always Learning centos@u61.u22.net wrote:
For light use you could drop in VMware server or player or virtualbox without much effect on the current system. It shouldn't be necessary, though, unless you'd like to install otherwise conflicting rpm packages or give root access to someone on the virtual server only.
I've use Virtual Box successfully for Windoze 98 to run Ami Pro 3.1.
So why can't you do that for your new virtualhost instead of running on a different IP?
A mentally deranged lunatic has sent 30,000+ wrong URLs to a tiny web site. Its started about 5 August but significantly escalated on 22 August.
Ummm, 30,000 isn't a particularly big number of hits to an apache server, especially if all it has to do is respond with a 'file not found'. But you are probably wise to be defensive.
My Apache routine can add the IPs to iptables and block them. Since 22 August the lunatic has used over 100 different IPs from around the world to send those wrong URLs which always seem to include one of these:-
forgotten_password.php
login.php
contact.php
That probably means the intrusion is self-propagating. That is, if the target is running some vulnerable php version or application, it is able to install a copy of itself and start over.
Assigning a spare IP address to this small web site should make it easier for me to experiment with IP tables and examine TCP packets without disturbing the server's normal workings. For example no valid HTTP request sent to that IP address should contain 'pas' or 'log' or 'con' so if I detect these the packets can be dropped - that is the theory. With dropped packets I lose the ability to easily record IP address and host name. However my web page has over 100 entries of machines compromised in the current abuse, so loosing new details is worth the satisfaction of blocking the loony.
As long as you aren't vulnerable yourself, I don't see the point of wasting human hours to save machine microseconds. And this is a tiny bit of the viruses and automated intrusion attempts happening in the wild so unless you can generalize it into a fail2ban type of process your time would be better spent making sure your systems are up to date and inherently secure.
If you are just firewalling there, apache can permit/deny ip ranges on its own for a location or virtualhost.
It is amazing so many machines can be broken-into or misused by one deranged lunatic. I wonder if those machines run on Windoze.
If that is the first instance you've seen, you must have a low-profile site. And no, web applications have their own bugs and vulnerabilities on Linux too. And if you aren't fairly close to up-to-date on the base distribution, those exploits can get root access. The last one I bothered tracking down used a java/spring vulnerability to run something to trigger a local root exploit in glibc (that I think was fixed in the 5.4 or 5.5 update) but there are probably newer ones - and more we don't know about.
On Mon, 2011-08-29 at 14:49 -0500, Les Mikesell wrote:
Ummm, 30,000 isn't a particularly big number of hits to an apache server, especially if all it has to do is respond with a 'file not found'. But you are probably wise to be defensive.
If it was the usually 50 to 100 phpmyadmin attempts from a single IP address, that single IP address can be blocked in IPtables.
The current lunatic could continue his attacks for several months. That probably means several hundred IPs, perhaps thousands, blocked for that one small web site. By splitting the targeted web site from the others, everything I do in IPtables should have little adverse effect on the server's other activities which use different IP addresses. I am trying to isolate the problem and then experiment to devise a re-usable solution for future persistent attacks, if any.
That probably means the intrusion is self-propagating. That is, if the target is running some vulnerable php version or application, it is able to install a copy of itself and start over.
In this particular incident, I am reasonable certain the loony is using tools to find vulnerable IPs and then manually feeding the address into his scrip.
As long as you aren't vulnerable yourself, I don't see the point of wasting human hours to save machine microseconds. And this is a tiny bit of the viruses and automated intrusion attempts happening in the wild so unless you can generalize it into a fail2ban type of process your time would be better spent making sure your systems are up to date and inherently secure.
I spent several hours today examining firewalls, questioning the set-up and tightening-up.
If that is the first instance you've seen, you must have a low-profile site.
First instance that has continued for more than 24 hours; and first with 30,000+ hits. Never ever advertise but top in Google's listing for a few distinct items and in the top 5 for a few other items.
And no, web applications have their own bugs and vulnerabilities on Linux too. And if you aren't fairly close to up-to-date on the base distribution, those exploits can get root access.
Always keen to update to the latest releases. I've seen too many Windoze machines run by others hacked and infected.
The last one I bothered tracking down used a java/spring vulnerability to run something to trigger a local root exploit in glibc (that I think was fixed in the 5.4 or 5.5 update) but there are probably newer ones - and more we don't know about.
Our browsers never run Flash or Java - the potential risk is perceived as too great.
Paul.
On Mon, Aug 29, 2011 at 3:14 PM, Always Learning centos@u61.u22.net wrote:
That probably means the intrusion is self-propagating. That is, if the target is running some vulnerable php version or application, it is able to install a copy of itself and start over.
In this particular incident, I am reasonable certain the loony is using tools to find vulnerable IPs and then manually feeding the address into his scrip.
That means he's not very good at it yet. The ones you need to worry about will send quick exploit tests cycling through different destinations, that if they succeed will post to a central receiver. Then later, likely from a different location, it will send the one that attempts to escalate access to root and/or establish a connection back for central control. The point here being that an IP block probably won't help much against an exploit that works well enough to establish a distributed base.
On Mon, 2011-08-29 at 15:52 -0500, Les Mikesell wrote:
That means he's not very good at it yet. The ones you need to worry about will send quick exploit tests cycling through different destinations, that if they succeed will post to a central receiver. Then later, likely from a different location, it will send the one that attempts to escalate access to root and/or establish a connection back for central control. The point here being that an IP block probably won't help much against an exploit that works well enough to establish a distributed base.
Thank you for this.
If I can establish an effective block for wrong HTTP requests in IPtables for incoming port 80 traffic, back-upped by my Apache routine adding IPs to IPtables or .htacesss file and having screwed down access and egress for all other traffic, the only other enhancement I need is SELinux ?
Paul.
On Mon, Aug 29, 2011 at 4:17 PM, Always Learning centos@u61.u22.net wrote:
That means he's not very good at it yet. The ones you need to worry about will send quick exploit tests cycling through different destinations, that if they succeed will post to a central receiver. Then later, likely from a different location, it will send the one that attempts to escalate access to root and/or establish a connection back for central control. The point here being that an IP block probably won't help much against an exploit that works well enough to establish a distributed base.
Thank you for this.
If I can establish an effective block for wrong HTTP requests in IPtables for incoming port 80 traffic, back-upped by my Apache routine adding IPs to IPtables or .htacesss file and having screwed down access and egress for all other traffic, the only other enhancement I need is SELinux ?
It's always hard to guess what the next successful exploit might be. With web servers they tend to be URLs that can be misparsed (by apache or application level code) into arbitrary commands which may or may not be combined with writing files somewhere and then trying to execute them. You can avoid a lot of the problems by making sure that apache can't write anywhere that is mounted with execute capability.
You can avoid a lot of the problems by making sure that apache can't write anywhere that is mounted with execute capability.
Or install a security module to do that for you. One that I've written that is nearing the end of its beta:
https://github.com/cormander/tpe-lkm
In some cases, you can even tell it to let apache not exec anything at all, if you're not running cgi scripts or bytecode php deployments (zend, etc).
-- Corey
On Mon, Aug 29, 2011 at 4:57 PM, Corey Henderson corman@cormander.com wrote:
You can avoid a lot of the problems by making sure that apache can't write anywhere that is mounted with execute capability.
Or install a security module to do that for you. One that I've written that is nearing the end of its beta:
https://github.com/cormander/tpe-lkm
In some cases, you can even tell it to let apache not exec anything at all, if you're not running cgi scripts or bytecode php deployments (zend, etc).
Would it have blocked this widely known/used vulnerability? http://seclists.org/fulldisclosure/2010/Oct/257
On Mon, Aug 29, 2011 at 4:57 PM, Corey Henderson corman@cormander.com wrote:
You can avoid a lot of the problems by making sure that apache can't write anywhere that is mounted with execute capability.
Or install a security module to do that for you. One that I've written that is nearing the end of its beta:
https://github.com/cormander/tpe-lkm
In some cases, you can even tell it to let apache not exec anything at all, if you're not running cgi scripts or bytecode php deployments (zend, etc).
Would it have blocked this widely known/used vulnerability? http://seclists.org/fulldisclosure/2010/Oct/257
Yes, because you've created the file you're executing:
$ gcc -w -fPIC -shared -o /tmp/exploit payload.c $ ls -l /tmp/exploit -rwxrwx--- 1 taviso taviso 4.2K Oct 15 09:22 /tmp/exploit*
# Now force the link in /proc to load $ORIGIN via LD_AUDIT. $ LD_AUDIT="$ORIGIN" exec /proc/self/fd/3
The attempt fails as designed by tpe. I've specifically tested this one.
It also stops the trick of using ld-x.x.so to execute binaries, because mmap and mprotect are also checked in addition to execve.
Tested on both CentOS 5 & 6. Haven't bothered testing it on 4 since it's close to EOL.
-- Corey
On Mon, 2011-08-29 at 15:57 -0600, Corey Henderson wrote:
Or install a security module to do that for you. One that I've written that is nearing the end of its beta:
https://github.com/cormander/tpe-lkm
In some cases, you can even tell it to let apache not exec anything at all, if you're not running cgi scripts or bytecode php deployments (zend, etc).
Corey,
What do you mean by 'bytecode php deployments' ? Ordinary PHP scripts ?
Thanks,
Paul.
On 8/29/2011 3:25 PM, Always Learning wrote:
On Mon, 2011-08-29 at 13:35 -0500, Les Mikesell wrote:
For light use you could drop in VMware server or player or virtualbox without much effect on the current system. It shouldn't be necessary, though, unless you'd like to install otherwise conflicting rpm packages or give root access to someone on the virtual server only.
I've use Virtual Box successfully for Windoze 98 to run Ami Pro 3.1.
So why can't you do that for your new virtualhost instead of running on a different IP?
A mentally deranged lunatic has sent 30,000+ wrong URLs to a tiny web site. Its started about 5 August but significantly escalated on 22 August.
My Apache routine can add the IPs to iptables and block them. Since 22 August the lunatic has used over 100 different IPs from around the world to send those wrong URLs which always seem to include one of these:-
forgotten_password.php
login.php
contact.php
If you can get a good list of what is requested, such as the one started above, and 'if' none of those pages exist, you can use modrewrite to redirect them to 127.0.0.1. :) Effectively sending the request back to themselves. That irritates them. Can be done on a per domain basis or serverwide for those regular attempts into what might exist on any server. For instance, I regularly see phpmyadmin references. I don't run that on any servers, but they come looking.
John Hinton
On Mon, 2011-08-29 at 16:24 -0400, John Hinton wrote:
If you can get a good list of what is requested, such as the one started above, and 'if' none of those pages exist, you can use modrewrite to redirect them to 127.0.0.1. :) Effectively sending the request back to themselves. That irritates them. Can be done on a per domain basis or serverwide for those regular attempts into what might exist on any server. For instance, I regularly see phpmyadmin references. I don't run that on any servers, but they come looking.
Thank you.
I've done it server-wide which extends protection to the virtual hosts.
RedirectMatch 301 ^(.*)admin(.*)$ http://127.0.0.1/hacker-alert
Paul.
On 08/29/11 11:19 AM, Always Learning wrote:
<VirtualHost 1.2.3.5:80>
I never ever give a virtual host declaration an IP address. If moving the virtual host to another server, I don't have to change anything expect the DNS. Also virtual hosts are web sites with different domain names, so I,,,
Always Talking, Never Learning. you need a new 'handle'.
AT: "How do I do (poorly described vague idea) ?"
(8 threads later, when the actual requirement is finally extracted)
someone: "Like this...."
AT: "No, No, I always do THIS"
sigh...
-
Always Learning -
Corey Henderson -
John Hinton -
John R Pierce -
Les Mikesell -
m.roth＠5-cent.us -
Ray Van Dolson