Overriding http server confs, Disabling non-ssl connections to the admin interface

[falter]

Now, I understand the idea behind adding configuration parameters to my vhost apache configurations ( httpd.include ) via vhost.conf or vhost_ssl.conf. However, I have found little documentation on what the capabilities of these override files are.

Specifically, say that there is something inside httpd.include that I would like to just comment out. I see no means to issue subtractive config options in vhost.conf or vhost_ssl.conf.

A more particular example is the Plesk admin interface Apache configuration (httpsd.conf found in /usr/local/psa/admin/conf). I only want to be able to access it via SSL on port 8443, and would love to disable non-ssl access that is on port 8880. I have found that if I block access to port 8880 via the firewall, I can still log into the admin interface on 8443, but I am presented with the following error:
"Service Unavailable
Service is not available now, probably your Plesk is misconfigured.
Contact Your provider for details."

That smacks of insanity. If my SSL-encrypted session is dependant on access to a non-encrypted version of the interface, then what is the point of having an encrypted version of the interface?

Anyway, back to the whole overrides thing. According to /usr/local/psa/admin/conf/httpsd.conf, I can ONLY override configuration options with /usr/local/psa/admin/conf/httpsd.custom.include .. I could easilly just comment out the "Listen 8880" statement in httpsd.conf, but if plesk gets upgraded, I could lose the change. What do I do in httpsd.custom.include to disable access to port 8880?

 

[Amin Taheri]

I did that as well, I just commented out the Listen 8880 directive and restarted psa.

if I ever upgrade psa I have a list of things to redo - and since I upgrade so few times, I have a procedure and testing and deployment regiment to go through anyways, I just add one more thing to the list.

 

[falter]

I suppose my problem is that, since I'm new to Plesk, I don't know the conditions under which the config files will be overwritten.

I'm a bit confused about the error I get simply by firewalling 8880 off. When I don't have it firewalled, I never noticed any spurious connection attempts from my system to port 8880 when I was hitting 8443... It must be a local connection that I'm not seeing.

I really hate having to get all hack-fu with stuff that I'd rather let the system run, update itself, and me only worry about things when I get security alerts from Osiris or something else. The way this works, it makes me feel like I'm running a flippin' windows box.

 

[Amin Taheri]

If you dont like "hack-fu" then linux is not for you. the entire os and daily process is like that.

 

[atomicturtle]

You could just block it with a firewall rule:

iptables -A INPUT -p tcp --dport 8880 -j DROP


I actually never noticed that was even on since my firewall policy was default DENY.

 

[falter]

Understandably, however I have been working with Linux professionally for the last 10 years. Plesk is supposed to make my life easier. In some ways it has, however, in this case, it's made a simple matter complicated because of a feature-incomplete implementation of an override file that I cannot find documentation for. The thing that I use to bounce it is a binary, so I don't know what it is doing. Lacking documentation, I'd look at the source code, but I don't know if that is available. Sure, I could do the work-around as you suggest (and I probably will), but I don't really feel like touching boxes in my free time, as I'm jumping around on dozens of different platforms every day at work.

atomicturtle, I have tried adding a drop rule for 8880, but Plesk becomes non-functional with the error that I mention in my original post. There's some requirement for Port 8880 to be open (or perhaps a verification of the httpsd config) that I haven't isolated. Unless, perhaps, other people are able to firewall it, and something is just screwy with my vps setup (CentOS 4.5).

Maybe I'll just firewall it all, and poke a hole for plesk as needed.

 

[atomicturtle]

Im not on a VPS in this case which is probably why Im not running into a problem .

You may want to try this, if you havent already:

iptables -I INPUT -p tcp --dport 8880 -j DROP

That is an insert, as opposed to an add. Meaning it goes in at the top of the rulset rather than the bottom. Its distantly (remotely... just barely) possible that there is some state tracking rule in the mix that would cause your 8443 connection to fail if 8880 was not available.


I agree with you completely, it shouldn't even be there, let alone something you can't turn off. I will definitely add the ability into ASL to turn that off.

 

[falter]

It's odd, and I'll have to troubleshoot it later.

My INPUT chain's policy is set to DROP.
So, I am currently explicitly allowing access to certain ports. I'd think that, if I were to have any funny problems, it would be in trying to *get* access to port 8880, rather than deny access. That is, everything works peachy keen if I have a rule allowing for new connections to port 8880 and 8443. However, if I remove the rule allowing port 8880, Plesk on port 8443 gets goofy.

I'm using CSF (http://www.configserver.com/cp/csf.html) to generate my ruleset... given that I don't see any port 8880 attempts while I'm working on port 8443, something else must be going on. I suspect that perhaps plesk will check to see if the port is available, and if it is not, then it will complain? Technically, the drop policy would apply to adapter IPs and localhost, as well.

Originally posted by atomicturtle
Im not on a VPS in this case which is probably why Im not running into a problem .

You may want to try this, if you havent already:

iptables -I INPUT -p tcp --dport 8880 -j DROP

That is an insert, as opposed to an add. Meaning it goes in at the top of the rulset rather than the bottom. Its distantly (remotely... just barely) possible that there is some state tracking rule in the mix that would cause your 8443 connection to fail if 8880 was not available.


I agree with you completely, it shouldn't even be there, let alone something you can't turn off. I will definitely add the ability into ASL to turn that off.

 

[Amin Taheri]

how does CSF measure up against apf for example, or any of the other firewalls out there?

I remember (chirpy I think his name was) the cpanel forum guy from many many years ago when I was a cpanel host and he was pretty sharp so its not that I dont trust his work, but with a product that was deisgned for cpanel integration how well does it work with plesk?

 

[falter]

I had originally had CPanel for about a two days, and decided that it was a total piece of garbage. I was horrified at the inconsistency of the interface. That, and within that time I had managed to screw it up, just by clicking around.

I had tried CSF with cpanel, and I thought it was neat that it told me all sorts of security things that were wrong with the system, but, really, I'd rather run Bastille Linux (http://bastille-linux.sourceforge.net/) to get a hardened system.

You can install and run CSF without having cpanel installed. I use it because it has both a firewall ruleset generator, in addition to a log monitoring and response daemon (called lfd). LFD will monitor login attempts across various services (POP3, SMTP AUTH, IMAP, SSH) in addition to various services or directories. Since I don't serve email on any of my system (daemons disabled, and firewalled off), I only care about SSH login attempts. Multiple failed login attempts will get you blocked by my firewall (I do have at least one host that could never get blocked, should I get goofy and block my own IP, somehow). The funny thing is that you can't get into SSH on my system without a proper key, so all of their login attempts are fruitless.

I've also disabled the process and directory monitoring, as I do not want it killing processes on my system. I use a file-integrity monitor called Osiris (http://osiris.shmoo.com/index.html) to monitor my files, directories, RPM database, listening ports, users, and groups. It's a pretty rad little FIM, and I highly recommend it.

Otherwise, I like CSF. It's worked fairly well, and upon review of the ruleset, I'm pretty happy. I haven't used APF so I can't say how it compares.

Originally posted by HostingGuy
how does CSF measure up against apf for example, or any of the other firewalls out there?

I remember (chirpy I think his name was) the cpanel forum guy from many many years ago when I was a cpanel host and he was pretty sharp so its not that I dont trust his work, but with a product that was deisgned for cpanel integration how well does it work with plesk?

 

[atomicturtle]

Could be something else in there, Im definitely not seeing any connections over that, or having any issues when I turn it off via the config, or block it with the firewall. Id try clearing all your rules first, then try a single explicit deny on that port. Just to rule out any other upstream problems in the ruleset.