Atomicorp

I have a customer using FrontPage (yes, I know...).

After installing ASL he cannot do the FrontPage "publish" thing with the (default) http:// URL. But he CAN do it with ftp:// URL.

That seems reasonable to me - but it seems there is some long-standing bug with FrontPage when you use the ftp:// protocol (550 errors).

I Imagine ASL has disallowed the http:// method for FrontPage. I imagine that happens via mod-security. I've tried fiddling - but can't fix it!

Any ideas on how I can relax the rules for this guy's site? Thanks.

Does it log anything about it in the GUI?

Nope, nothing there under "security event".

I've found this post from 2005 though:
http://www.gotroot.com/tiki-index.php?p ... =frontpage

I wonder if that is the issue? But am I right that "SecFilterInheritance" does not exist in mod_security 2.5?

I have tried "SecRuleEngine Off" in modsecurity_crs_10_config.conf and restarting Apache, but that does not seem to fix it.

I don't think its mod_security then. That would turn it off completely.

The thing is though - this is definitely server-wide and not site specific. It affects all FP domains on this Plesk box. And it seems to have started after install of ASL (or is a big coincidence!).

Is there anything in ASL other than mod-security that can affect this (I guess something is blocking file transfers via http)?

Also, is "SecRuleEngine Off" the right way to completely disable mod_security, or should I do this via the GUI somehow? I say this 'cos I can see the green light for ModSecurity in the GUI even after setting "SecRuleEngine Off" (and restarting Apache). And if I select "Configuration" >> "config" it still says MOD_SEC = "yes". If I change that to "No", and hit "execute", then I get a GUI error, and the status remains unchanged.

Have you looked at any other logs? /var/log/messages or the output of dmesg?

No, nothing in messages or dmsg. Nor in httpd/audit_log or modsec_debug.log, or psa/var/log/xferlog. Can't figure it out...

RichardM, have you had any luck getting frontpage to work?

SecFilterInheritance has changed to SecRuleInheritance - this caused problems for me at first too, although I'm having further issues - plus this specific server didn't have frontpage working at all yet, still trying to get it to go first time - previous server was rhel4 w/out asl and fp worked fine.

I think my problem is within Plesk though.

On one domain in particular, Plesk does not create the necessary files in httpdocs. It only creates httpdocs/_vti_pvt with a file fplck... inside - have tried disabling fp, deleting *vti* enabling fp, but no dice. Also have tried re-installing fp altogether with patched rpms for centos5, but same issue.

Plesk will create all the proper folders for other domains on the server, but httpdocs/_vti_bin/_vti_adm/*.exe don't exist as the server reports... permissions all seem ok... but couldn't find anything in those folders on old server, so must be using files from /usr/local/frontpage/version5.0?

Any ideas? ... Scott?

Anyway, hope the Sec..Inheritance bit helps I'll post back here if I find a solution to my own probs.

PS - also not seeing anything in any access, error, debug, dmesg or audit logs (aside from 404s)

jeremiah wrote:RichardM, have you had any luck getting frontpage to work? SecFilterInheritance has changed to SecRuleInheritance

No, I could not get FP to work. In fact, whatever the problem is (in my case), I don't think it is ModSecurity as switching that off entirely doesn't help.

I have had FP on Plesk for years without any significant problems. Then the moment I installed ASL all FP sites on the machine could not do FrontPage-style FTP (really "http").

Having said that, FP is awful and is no longer promoted by Microsoft. So I have persuaded my FP customers that they have to abandon the beast!

Yeah, I'm trying to find an alternative so I can move on as well. I had this customer try Contribute but they seemed to have difficulty finding their way around - probably just need some training.

Did you find an alternative to fp that brought instant happiness and satisfaction? Some sort of golden chalice for blissful content editing?

I use Dreamweaver (but I'm not sure that's going anywhere good under Adobe!). If DW is a bit complex to recommend to a customer then I think the best alternative is probably Netobjects Fusion. It suits those who would otherwise like FrontPage with easy-to-use templates and themes.

But mostly I try to get those folks to use a professional web designer! If they feel they need regular page updates, then (a) it's usually never as often as they think it'll be, and (b) it's still probably best to get a good arrangement with a pro to do the work at a reasonable cost.

There doesn't seem to be a good open source + linux DW alternative (NVU - http://www.nvu.com/ - seems to have spluttered to a stop).

thanks for the pointers. i try to stay away from DW, FP, etc. although their standards compliance does seem to be improving greatly. i haven't tried netobjects before. i believe adobe will be scrapping golive in favor of dw so it should get much better.

i had this customer try the new expressions web and it seems that might actually work as when he tried to use the frontpage server extensions option i got an alert:

kernel: grsec: denied untrusted exec of /usr/local/frontpage/version5.0/exes/_vti_bin/shtml.exe by /usr/local/frontpage/version5.0/apache-fp/_vti_bin/fpexe[fpexe:2076] uid/euid:10001/10001 gid/egid:2523/2523, parent /usr/sbin/httpd[httpd:19160] uid/euid:0/0 gid/egid:0/0

so it seems that the older frontpage client couldn't handle the patched fpse centos 5 rpms for some reason?

i'm not sure how to fix this though as searching returns advise about tweaking/disabling TPE - but...

[root@host ~]# sysctl -a | grep tpe
error: permission denied on key 'kernel.sched_nr_migrate'
[root@host ~]#

any thoughts?

also, is that permission denied error normal, or is there a way to fix that?

a denied untrusted exec error means that an untrusted user (apache) is attempting to execute a file that is not owned by root. So the fix would be to make sure every file and directory on that path is owned, and only writable, by root.

thank you, that looks like it will work.

i need to read the grsecurity docs, but can you tell me quickly how trusted/untrusted users are defined?

are there any security implications with files in /usr/local/frontpage/version5.0 being owned by root?

it seems the sysctl permission error has been noticed by others too http://www.opensubscriber.com/message/f ... 36538.html

thanks again