Re: [users@httpd] Apache permissions stabs new Linux user in face with icepick. Suggestions?

[Francis Roy]

On 16-03-09 09:47 PM, Kurtis Rader wrote:

On Wed, Mar 9, 2016 at 6:38 PM, Francis Roy > wrote:

Thank you that answers my question quite nicely. It's not a giant
flag waving at the internet, but if someone got a hold of my machine
directly, it could provide a small bit of information used in a
general strategy.


Just to be pedantic "they" don't have to get a hold of your machine
directly. If the attacker can install software of their choosing, say by
exploiting a vulnerability in your web server, then that software could
exploit the looser permissions on your home directory. But that is moot
given that you already had to grant the web server access to your home
directory in order to support your requirements. The concern now is
whether user accounts on your machine other than the one running the
apache web server can exploit those looser permissions.


It's my personal, sole-user development machine tucked away behind a 
NAT. I just wanted to be sure that I wasn't doing the equivalent of 
opening up common ports.


By the way, can you recommend a good, practical Linux security forum or 
list? New OS means I have to learn new specifics and tricks.


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache permissions stabs new Linux user in face with icepick. Suggestions?

[Wim Lewis]

On Mar 9, 2016, at 6:38 PM, Francis Roy  wrote:
> Thank you that answers my question quite nicely. It's not a giant flag waving 
> at the internet, but if someone got a hold of my machine directly, it could 
> provide a small bit of information used in a general strategy.

Right. It's not automatically unsafe to allow other users to see your mounted 
disks' contents[1], but the casual user's expectation is that user A can't tell 
what files user B has, so the default setup is to disallow that.

But if you *want* to expose some files to other users (in this case, to the 
"_www" user that Apache runs as) then it's reasonable to give them execute (aka 
search) and possibly read permission.




-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache permissions stabs new Linux user in face with icepick. Suggestions?

[Kurtis Rader]

On Wed, Mar 9, 2016 at 6:38 PM, Francis Roy 
wrote:
>
> Thank you that answers my question quite nicely. It's not a giant flag
> waving at the internet, but if someone got a hold of my machine directly,
> it could provide a small bit of information used in a general strategy.


Just to be pedantic "they" don't have to get a hold of your machine
directly. If the attacker can install software of their choosing, say by
exploiting a vulnerability in your web server, then that software could
exploit the looser permissions on your home directory. But that is moot
given that you already had to grant the web server access to your home
directory in order to support your requirements. The concern now is whether
user accounts on your machine other than the one running the apache web
server can exploit those looser permissions.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: [users@httpd] Apache permissions stabs new Linux user in face with icepick. Suggestions?

[Francis Roy]

On 16-03-09 09:29 PM, Kurtis Rader wrote:

On Wed, Mar 9, 2016 at 6:17 PM, Francis Roy 

Re: [users@httpd] Apache permissions stabs new Linux user in face with icepick. Suggestions?

[Kurtis Rader]

On Wed, Mar 9, 2016 at 6:17 PM, Francis Roy 
wrote:

> On 16-03-09 08:44 PM, Eric Covener wrote:
>
>> If you want to serve out of your home directory, it needs to be
>> executable by "other".
>>
>
> Thank you, Eric and Kurtis, both. That was the problem.
>
> I did the following:
>sudo chmod 755 /home/username
>
> If I may, a follow-up question: does this create a potential security
> vulnerability on my machine that I should find measures of protecting?


Probably not but it's not the sort of question anyone can answer without
spending a few days reviewing your situation. The reason most UNIX distros
create the home directory for a user with mode 750 (no public access) is to
make it impossible for other accounts on the machine, which aren't a member
of your primary group, to guess whether a file is present by exploiting the
search capability. In other words, if you've done "chmod 751" then even if
I'm not a member of the group that owns your home directory I can execute
"ls /media/username/$filename" commands (or equivalent) to probe whether
$filename exists. It's a potential information leak that could
theoretically be used to launch an attack. Whether that's a concern for you
depends on a lot of factors.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: [users@httpd] Apache permissions stabs new Linux user in face with icepick. Suggestions?

[Francis Roy]

On 16-03-09 08:44 PM, Eric Covener wrote:

If you want to serve out of your home directory, it needs to be
executable by "other".


Thank you, Eric and Kurtis, both. That was the problem.

I did the following:
   sudo chmod 755 /home/username


If I may, a follow-up question: does this create a potential security 
vulnerability on my machine that I should find measures of protecting?



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache permissions stabs new Linux user in face with icepick. Suggestions?

[Eric Covener]

On Wed, Mar 9, 2016 at 8:40 PM, Francis Roy  wrote:
>  drwxr-x--- username


If you want to serve out of your home directory, it needs to be
executable by "other".

-- 
Eric Covener
cove...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache permissions stabs new Linux user in face with icepick. Suggestions?

[Kurtis Rader]

If we take the error message at face value this part of it, "because search
permissions are missing", is relevant. In the UNIX filesystem permission
model the "file" permissions mean the following when applied to a directory:

read: The process can read the contents of the directory; i.e., enumerate
all the file/directory names contained within it. The "ls" command, for
example, requires read access to list the contents of a directory.

write: The process can modify the contents of the directory; i.e., create
and remove files in the directory.

execute: The process can search the directory; i.e., if it knows the name
of a file or subdirectory it can access it.

What that error is telling you is that the user ID that Apache is running
as does not have the ability to "search" one of the directories in the path
to the file. This means that either the public execute bit is not set, or
the group execute but is not set or if set apache is not a member of that
group, or the user execute bit is not set or if set apache is not running
as that user.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: [users@httpd] Re: [Bulk] Re: [users@httpd] rewrite simple php under a sub url

[Sven Seeberg]

Am 10.03.2016 um 00:43 schrieb Sven Seeberg:
> Am 10.03.2016 um 00:40 schrieb lejeczek:
>>
>> On 09/03/16 23:29, Sven Seeberg wrote:
>>> Ah sorry, I think I missunderstood your question.
>> possibly
>>> mod_rewrite only changes the "appearance" of the URL for the Browser /
>>> user. This PHP programm still sees the original URL.
>>>
>>> Your problem does not seem related to Apache but to the file paths on
>>> your server. Maybe you could work around it with symlinks?
>> what I thought, what I hoped would be possible is for apache to do
>> some real-time, in-flight url mangling so the app (silly code which
>> seems fine only under root /), while being served from under - /phpapp
>> - would think it's all good and is under /
> You could possibly achieve the desired behaviour with mod_header. But
> maybe something like the following line would be an easier solution:
>
> $ ln -s /path/phpapp /path
Sorry, that suggestion is stupid. But you need to work on the file
system or php app parameters, not on the apache configuration.
>
>>> Am 10.03.2016 um 00:17 schrieb lejeczek:
 On 09/03/16 22:12, Sven Seeberg wrote:
> Hi there,
>
> you can either just move the DocumentRoot to a directory which
> contains
> the folder phpapp with all the PHP files in it.
>
> Or create an .htaccess file / edit your VirtualHost and add the
> following line:
> RewriteRule ^phpapp/(.*)$ $1
 nope, having looked at some error logs I see (with above rewrite) app
 still somewhere uses /phpapp subdir.

 Warning: include(path/phpapp/index-full.php): failed to open stream:
 No such file or directory in /var/www/devs/phpapp/templates/full.php
 on line 3
 thanks for suggested search query.
> (http://lmgtfy.com/?q=mod_rewrite+subdirectory+to+root)
>
> Cheers
>
> Am 09.03.2016 um 23:05 schrieb lejeczek:
>> hi everybody
>> ough... this might sound silly what I'm hoping to achieve, well..
>> I have a php app that I don't know the code of but the app seems to
>> only work under top url, eg: www.theapp.net but it has to be served
>> from www.theapp.net/phpapp
>> I fiddling with rewrites but not being an expert I thought I'd ask if
>> it's even possible?
>>
>> many thanks
>> L.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
 -
 To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
 For additional commands, e-mail: users-h...@httpd.apache.org

>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
>
>





signature.asc
Description: OpenPGP digital signature

Re: [users@httpd] mod_substitute / mod_sed with Apache 2.4.7 (Ubuntu 14.04)

[Sven Seeberg]

mod_deflate still running on the backend server (I thought I had
disabled it) and a missing AddOutputFilterByType were responsible.
Problem solved.

Am 09.03.2016 um 18:10 schrieb Sven Seeberg:
> Hi everybody,
>
> I'm having a problem with mod_substitute or mod_sed while using one
> apache2 (Ubuntu 14.04) as a proxy and load balancer.
>
> The connection between proxy and backend is not encrypted, therefore the
> backend delivers only non-https links with the backend FQDN. Those have
> to be replaced by the corresponding proxy FQDN.
>
> On the documentation page
> (https://httpd.apache.org/docs/2.4/mod/mod_substitute.htm) is an example
> for this specific use case. However it does not work for me and I cannot
> find the reason. mod_deflate is not enabled.
>
> For testing purposes I created an index.html with the content "asdf" in
> the DocumentRoot. The content is also not replaced. Can anyone give me a
> hint on how to further debug this problem? Could this problem be
> specific for the Ubuntu package / dependent on a compiling parameter?
>
> ### site config ###
>
> 
> ServerName www.somedomain.tld
> DocumentRoot /var/www/redirect
>
> SSLEngine On
> SSLCertificateFile /etc/letsencrypt/live/somedomain.tld/cert.pem
> SSLCertificateChainFile
> /etc/letsencrypt/live/somedomain.tld/chain.pem
> SSLCertificateKeyFile
> /etc/letsencrypt/live/somedomain.tld/privkey.pem
>
> ProxyPass /wordpress_test/
> http://backend.somedomain.tld/wordpress_test/
> ProxyPassReverse /wordpress_test/
> http://backend.somedomain.tld/wordpress_test/
>
> 
> Substitute
> "s|http://backend.somedomain.tld/|https://www.somedomain.tld/|i"
> Substitute "s|asdf|jkl|i"
> Substitute
> "s|http://backend.somedomain.tld/|https://www.somedomain.tld/|"
> 
>
> 
>
> ### end site config ###
>
> Cheers
> Sven
>
>





signature.asc
Description: OpenPGP digital signature

Re: [users@httpd] Re: [Bulk] Re: [users@httpd] rewrite simple php under a sub url

[Sven Seeberg]

Am 10.03.2016 um 00:40 schrieb lejeczek:
>
>
> On 09/03/16 23:29, Sven Seeberg wrote:
>> Ah sorry, I think I missunderstood your question.
> possibly
>>
>> mod_rewrite only changes the "appearance" of the URL for the Browser /
>> user. This PHP programm still sees the original URL.
>>
>> Your problem does not seem related to Apache but to the file paths on
>> your server. Maybe you could work around it with symlinks?
> what I thought, what I hoped would be possible is for apache to do
> some real-time, in-flight url mangling so the app (silly code which
> seems fine only under root /), while being served from under - /phpapp
> - would think it's all good and is under /

You could possibly achieve the desired behaviour with mod_header. But
maybe something like the following line would be an easier solution:

$ ln -s /path/phpapp /path

>>
>> Am 10.03.2016 um 00:17 schrieb lejeczek:
>>>
>>> On 09/03/16 22:12, Sven Seeberg wrote:
 Hi there,

 you can either just move the DocumentRoot to a directory which
 contains
 the folder phpapp with all the PHP files in it.

 Or create an .htaccess file / edit your VirtualHost and add the
 following line:
 RewriteRule ^phpapp/(.*)$ $1
>>> nope, having looked at some error logs I see (with above rewrite) app
>>> still somewhere uses /phpapp subdir.
>>>
>>> Warning: include(path/phpapp/index-full.php): failed to open stream:
>>> No such file or directory in /var/www/devs/phpapp/templates/full.php
>>> on line 3
>>> thanks for suggested search query.
 (http://lmgtfy.com/?q=mod_rewrite+subdirectory+to+root)

 Cheers

 Am 09.03.2016 um 23:05 schrieb lejeczek:
> hi everybody
> ough... this might sound silly what I'm hoping to achieve, well..
> I have a php app that I don't know the code of but the app seems to
> only work under top url, eg: www.theapp.net but it has to be served
> from www.theapp.net/phpapp
> I fiddling with rewrites but not being an expert I thought I'd ask if
> it's even possible?
>
> many thanks
> L.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>

>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>>> For additional commands, e-mail: users-h...@httpd.apache.org
>>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>





signature.asc
Description: OpenPGP digital signature

[users@httpd] Re: [Bulk] Re: [users@httpd] rewrite simple php under a sub url

[lejeczek]

On 09/03/16 23:29, Sven Seeberg wrote:

Ah sorry, I think I missunderstood your question.

possibly


mod_rewrite only changes the "appearance" of the URL for the Browser /
user. This PHP programm still sees the original URL.

Your problem does not seem related to Apache but to the file paths on
your server. Maybe you could work around it with symlinks?
what I thought, what I hoped would be possible is for apache 
to do some real-time, in-flight url mangling so the app 
(silly code which seems fine only under root /), while being 
served from under - /phpapp - would think it's all good and 
is under /


Am 10.03.2016 um 00:17 schrieb lejeczek:


On 09/03/16 22:12, Sven Seeberg wrote:

Hi there,

you can either just move the DocumentRoot to a directory which contains
the folder phpapp with all the PHP files in it.

Or create an .htaccess file / edit your VirtualHost and add the
following line:
RewriteRule ^phpapp/(.*)$ $1

nope, having looked at some error logs I see (with above rewrite) app
still somewhere uses /phpapp subdir.

Warning: include(path/phpapp/index-full.php): failed to open stream:
No such file or directory in /var/www/devs/phpapp/templates/full.php
on line 3
thanks for suggested search query.

(http://lmgtfy.com/?q=mod_rewrite+subdirectory+to+root)

Cheers

Am 09.03.2016 um 23:05 schrieb lejeczek:

hi everybody
ough... this might sound silly what I'm hoping to achieve, well..
I have a php app that I don't know the code of but the app seems to
only work under top url, eg: www.theapp.net but it has to be served
from www.theapp.net/phpapp
I fiddling with rewrites but not being an expert I thought I'd ask if
it's even possible?

many thanks
L.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] rewrite simple php under a sub url

[Sven Seeberg]

Ah sorry, I think I missunderstood your question.

mod_rewrite only changes the "appearance" of the URL for the Browser /
user. This PHP programm still sees the original URL.

Your problem does not seem related to Apache but to the file paths on
your server. Maybe you could work around it with symlinks?

Am 10.03.2016 um 00:17 schrieb lejeczek:
>
>
> On 09/03/16 22:12, Sven Seeberg wrote:
>> Hi there,
>>
>> you can either just move the DocumentRoot to a directory which contains
>> the folder phpapp with all the PHP files in it.
>>
>> Or create an .htaccess file / edit your VirtualHost and add the
>> following line:
>> RewriteRule ^phpapp/(.*)$ $1
> nope, having looked at some error logs I see (with above rewrite) app
> still somewhere uses /phpapp subdir.
>
> Warning: include(path/phpapp/index-full.php): failed to open stream:
> No such file or directory in /var/www/devs/phpapp/templates/full.php
> on line 3
> thanks for suggested search query.
>>
>> (http://lmgtfy.com/?q=mod_rewrite+subdirectory+to+root)
>>
>> Cheers
>>
>> Am 09.03.2016 um 23:05 schrieb lejeczek:
>>> hi everybody
>>> ough... this might sound silly what I'm hoping to achieve, well..
>>> I have a php app that I don't know the code of but the app seems to
>>> only work under top url, eg: www.theapp.net but it has to be served
>>> from www.theapp.net/phpapp
>>> I fiddling with rewrites but not being an expert I thought I'd ask if
>>> it's even possible?
>>>
>>> many thanks
>>> L.
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>>> For additional commands, e-mail: users-h...@httpd.apache.org
>>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>





signature.asc
Description: OpenPGP digital signature

Re: [users@httpd] rewrite simple php under a sub url

[lejeczek]

On 09/03/16 22:12, Sven Seeberg wrote:

Hi there,

you can either just move the DocumentRoot to a directory which contains
the folder phpapp with all the PHP files in it.

Or create an .htaccess file / edit your VirtualHost and add the
following line:
RewriteRule ^phpapp/(.*)$ $1
nope, having looked at some error logs I see (with above 
rewrite) app still somewhere uses /phpapp subdir.


Warning: include(path/phpapp/index-full.php): failed to open 
stream: No such file or directory in 
/var/www/devs/phpapp/templates/full.php on line 3

thanks for suggested search query.


(http://lmgtfy.com/?q=mod_rewrite+subdirectory+to+root)

Cheers

Am 09.03.2016 um 23:05 schrieb lejeczek:

hi everybody
ough... this might sound silly what I'm hoping to achieve, well..
I have a php app that I don't know the code of but the app seems to
only work under top url, eg: www.theapp.net but it has to be served
from www.theapp.net/phpapp
I fiddling with rewrites but not being an expert I thought I'd ask if
it's even possible?

many thanks
L.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] rewrite simple php under a sub url

[Sven Seeberg]

Hi there,

you can either just move the DocumentRoot to a directory which contains
the folder phpapp with all the PHP files in it.

Or create an .htaccess file / edit your VirtualHost and add the
following line:
RewriteRule ^phpapp/(.*)$ $1

(http://lmgtfy.com/?q=mod_rewrite+subdirectory+to+root)

Cheers

Am 09.03.2016 um 23:05 schrieb lejeczek:
> hi everybody
> ough... this might sound silly what I'm hoping to achieve, well..
> I have a php app that I don't know the code of but the app seems to
> only work under top url, eg: www.theapp.net but it has to be served
> from www.theapp.net/phpapp
> I fiddling with rewrites but not being an expert I thought I'd ask if
> it's even possible?
>
> many thanks
> L.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>





signature.asc
Description: OpenPGP digital signature

[users@httpd] rewrite simple php under a sub url

[lejeczek]

hi everybody
ough... this might sound silly what I'm hoping to achieve, 
well..
I have a php app that I don't know the code of but the app 
seems to only work under top url, eg: www.theapp.net but it 
has to be served from www.theapp.net/phpapp
I fiddling with rewrites but not being an expert I thought 
I'd ask if it's even possible?


many thanks
L.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache virus scanning

[Wei-min Lee]

Using ICAP is a good way to go so that the person uploading files can be
notified of upload fails due to the virus scan.  Relying on filesystem
virus scans lacks visibility of quarantined/rejected files.

On Wed, Mar 9, 2016 at 12:18 PM, Wei-min Lee  wrote:

> You could use clamav via ICAP with squid transparently in front of apache.
>
> http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
> http://squidclamav.darold.net/config.html
>
> http://louwrentius.com/setting-up-a-squid-proxy-with-clamav-anti-virus-using-c-icap.html
>
> On Wed, Mar 9, 2016 at 8:12 AM, Aurélien Terrestris  > wrote:
>
>> On a large scale prod (200 000 users/day), I was using proxies working
>> with antivirus through ICAP protocol (RFC 3507). The results were pretty
>> good.
>> I am not sure we could use this technology with Apache, and ICAP seems a
>> bit old now.
>>
>> 2016-03-09 16:45 GMT+01:00 Christopher Schultz <
>> ch...@christopherschultz.net>:
>>
>>> John,
>>>
>>> On 3/9/16 10:21 AM, Rose, John B wrote:
>>> > What about if your web sites allow for uploading files? Would you not
>>> want
>>> > to scan those on upload before they got on your filesystem?
>>>
>>> Sure, it would be nice to have the file scanned during upload, but I'm
>>> guessing that the AV can't give an opinion on a file until it's been
>>> completely-uploaded. In that case, do you really want to buffer the
>>> whole file in memory to scan it?
>>>
>>> I think the file is going to make it -- at least in part -- to the disk
>>> either way, unless you have other controls in place such as upload-size
>>> limits where you can make a good bet that in-memory scanning can be done
>>> without bringing-down your server.
>>>
>>> Anyhow, I don't have any particular experience with mod_clamav or
>>> anything like that. Certainly I wouldn't rely upon it solely, since
>>> there are other ways files can make it onto your server(s). But it
>>> probably couldn't hurt.
>>>
>>> Things I'd be worried about are which requests will be scanned by the
>>> AV? Will every single GET/POST/etc. be scanned? That might cause a
>>> significant impact on your response times. Also, the aforementioned
>>> buffering -- does the file have to remain in memory to be scanned, or
>>> will it be streamed to a disk somewhere first? You don't want AV-scans
>>> to bust your memory cap.
>>>
>>> -chris
>>>
>>> > On 3/9/16 9:49 AM, "Christopher Schultz" >> >
>>> > wrote:
>>> >
>>> >> John,
>>> >>
>>> >> On 3/8/16 6:02 PM, Rose, John B wrote:
>>> >>> I am interested in both
>>> >>>
>>> >>> Thanks
>>> >>>
>>> >>> Sent from my iPad
>>> >>>
>>>  On Mar 8, 2016, at 3:27 PM, Christopher Schultz
>>>   wrote:
>>> 
>>> >>> John
>>> >>>
>>> >> On 3/8/16 2:43 PM, Rose, John B wrote:
>>> >> Looking for comments on mod_clamav, and any other alternative
>>> >> antivirus software for Apache on linux
>>> >>>
>>> >>> Are you trying to protect your clients or your servers?
>>> >>
>>> >> I would imagine that running any AV software that monitors the
>>> >> filesystem for changes would be sufficient. Why do you think you need
>>> an
>>> >> httpd module for this?
>>> >>
>>> >> -chris
>>> >>
>>> >> -
>>> >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>>> >> For additional commands, e-mail: users-h...@httpd.apache.org
>>> >>
>>> >
>>> >
>>> > -
>>> > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>>> > For additional commands, e-mail: users-h...@httpd.apache.org
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>>> For additional commands, e-mail: users-h...@httpd.apache.org
>>>
>>>
>>
>
>
> --
> *~Wei-min Lee~*
>



-- 
*~Wei-min Lee~*

Re: [users@httpd] Apache virus scanning

[Wei-min Lee]

You could use clamav via ICAP with squid transparently in front of apache.

http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
http://squidclamav.darold.net/config.html
http://louwrentius.com/setting-up-a-squid-proxy-with-clamav-anti-virus-using-c-icap.html

On Wed, Mar 9, 2016 at 8:12 AM, Aurélien Terrestris 
wrote:

> On a large scale prod (200 000 users/day), I was using proxies working
> with antivirus through ICAP protocol (RFC 3507). The results were pretty
> good.
> I am not sure we could use this technology with Apache, and ICAP seems a
> bit old now.
>
> 2016-03-09 16:45 GMT+01:00 Christopher Schultz <
> ch...@christopherschultz.net>:
>
>> John,
>>
>> On 3/9/16 10:21 AM, Rose, John B wrote:
>> > What about if your web sites allow for uploading files? Would you not
>> want
>> > to scan those on upload before they got on your filesystem?
>>
>> Sure, it would be nice to have the file scanned during upload, but I'm
>> guessing that the AV can't give an opinion on a file until it's been
>> completely-uploaded. In that case, do you really want to buffer the
>> whole file in memory to scan it?
>>
>> I think the file is going to make it -- at least in part -- to the disk
>> either way, unless you have other controls in place such as upload-size
>> limits where you can make a good bet that in-memory scanning can be done
>> without bringing-down your server.
>>
>> Anyhow, I don't have any particular experience with mod_clamav or
>> anything like that. Certainly I wouldn't rely upon it solely, since
>> there are other ways files can make it onto your server(s). But it
>> probably couldn't hurt.
>>
>> Things I'd be worried about are which requests will be scanned by the
>> AV? Will every single GET/POST/etc. be scanned? That might cause a
>> significant impact on your response times. Also, the aforementioned
>> buffering -- does the file have to remain in memory to be scanned, or
>> will it be streamed to a disk somewhere first? You don't want AV-scans
>> to bust your memory cap.
>>
>> -chris
>>
>> > On 3/9/16 9:49 AM, "Christopher Schultz" 
>> > wrote:
>> >
>> >> John,
>> >>
>> >> On 3/8/16 6:02 PM, Rose, John B wrote:
>> >>> I am interested in both
>> >>>
>> >>> Thanks
>> >>>
>> >>> Sent from my iPad
>> >>>
>>  On Mar 8, 2016, at 3:27 PM, Christopher Schultz
>>   wrote:
>> 
>> >>> John
>> >>>
>> >> On 3/8/16 2:43 PM, Rose, John B wrote:
>> >> Looking for comments on mod_clamav, and any other alternative
>> >> antivirus software for Apache on linux
>> >>>
>> >>> Are you trying to protect your clients or your servers?
>> >>
>> >> I would imagine that running any AV software that monitors the
>> >> filesystem for changes would be sufficient. Why do you think you need
>> an
>> >> httpd module for this?
>> >>
>> >> -chris
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> >> For additional commands, e-mail: users-h...@httpd.apache.org
>> >>
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> > For additional commands, e-mail: users-h...@httpd.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
>>
>


-- 
*~Wei-min Lee~*

[users@httpd] mod_substitute / mod_sed with Apache 2.4.7 (Ubuntu 14.04)

[Sven Seeberg]

Hi everybody,

I'm having a problem with mod_substitute or mod_sed while using one
apache2 (Ubuntu 14.04) as a proxy and load balancer.

The connection between proxy and backend is not encrypted, therefore the
backend delivers only non-https links with the backend FQDN. Those have
to be replaced by the corresponding proxy FQDN.

On the documentation page
(https://httpd.apache.org/docs/2.4/mod/mod_substitute.htm) is an example
for this specific use case. However it does not work for me and I cannot
find the reason. mod_deflate is not enabled.

For testing purposes I created an index.html with the content "asdf" in
the DocumentRoot. The content is also not replaced. Can anyone give me a
hint on how to further debug this problem? Could this problem be
specific for the Ubuntu package / dependent on a compiling parameter?

### site config ###


ServerName www.somedomain.tld
DocumentRoot /var/www/redirect

SSLEngine On
SSLCertificateFile /etc/letsencrypt/live/somedomain.tld/cert.pem
SSLCertificateChainFile
/etc/letsencrypt/live/somedomain.tld/chain.pem
SSLCertificateKeyFile
/etc/letsencrypt/live/somedomain.tld/privkey.pem

ProxyPass /wordpress_test/
http://backend.somedomain.tld/wordpress_test/
ProxyPassReverse /wordpress_test/
http://backend.somedomain.tld/wordpress_test/


Substitute
"s|http://backend.somedomain.tld/|https://www.somedomain.tld/|i"
Substitute "s|asdf|jkl|i"
Substitute
"s|http://backend.somedomain.tld/|https://www.somedomain.tld/|"




### end site config ###

Cheers
Sven




signature.asc
Description: OpenPGP digital signature

Re: [users@httpd] Apache virus scanning

[Aurélien Terrestris]

On a large scale prod (200 000 users/day), I was using proxies working with
antivirus through ICAP protocol (RFC 3507). The results were pretty good.
I am not sure we could use this technology with Apache, and ICAP seems a
bit old now.

2016-03-09 16:45 GMT+01:00 Christopher Schultz :

> John,
>
> On 3/9/16 10:21 AM, Rose, John B wrote:
> > What about if your web sites allow for uploading files? Would you not
> want
> > to scan those on upload before they got on your filesystem?
>
> Sure, it would be nice to have the file scanned during upload, but I'm
> guessing that the AV can't give an opinion on a file until it's been
> completely-uploaded. In that case, do you really want to buffer the
> whole file in memory to scan it?
>
> I think the file is going to make it -- at least in part -- to the disk
> either way, unless you have other controls in place such as upload-size
> limits where you can make a good bet that in-memory scanning can be done
> without bringing-down your server.
>
> Anyhow, I don't have any particular experience with mod_clamav or
> anything like that. Certainly I wouldn't rely upon it solely, since
> there are other ways files can make it onto your server(s). But it
> probably couldn't hurt.
>
> Things I'd be worried about are which requests will be scanned by the
> AV? Will every single GET/POST/etc. be scanned? That might cause a
> significant impact on your response times. Also, the aforementioned
> buffering -- does the file have to remain in memory to be scanned, or
> will it be streamed to a disk somewhere first? You don't want AV-scans
> to bust your memory cap.
>
> -chris
>
> > On 3/9/16 9:49 AM, "Christopher Schultz" 
> > wrote:
> >
> >> John,
> >>
> >> On 3/8/16 6:02 PM, Rose, John B wrote:
> >>> I am interested in both
> >>>
> >>> Thanks
> >>>
> >>> Sent from my iPad
> >>>
>  On Mar 8, 2016, at 3:27 PM, Christopher Schultz
>   wrote:
> 
> >>> John
> >>>
> >> On 3/8/16 2:43 PM, Rose, John B wrote:
> >> Looking for comments on mod_clamav, and any other alternative
> >> antivirus software for Apache on linux
> >>>
> >>> Are you trying to protect your clients or your servers?
> >>
> >> I would imagine that running any AV software that monitors the
> >> filesystem for changes would be sufficient. Why do you think you need an
> >> httpd module for this?
> >>
> >> -chris
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> >> For additional commands, e-mail: users-h...@httpd.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> > For additional commands, e-mail: users-h...@httpd.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

Re: [users@httpd] Apache virus scanning

[Christopher Schultz]

John,

On 3/9/16 10:21 AM, Rose, John B wrote:
> What about if your web sites allow for uploading files? Would you not want
> to scan those on upload before they got on your filesystem?

Sure, it would be nice to have the file scanned during upload, but I'm
guessing that the AV can't give an opinion on a file until it's been
completely-uploaded. In that case, do you really want to buffer the
whole file in memory to scan it?

I think the file is going to make it -- at least in part -- to the disk
either way, unless you have other controls in place such as upload-size
limits where you can make a good bet that in-memory scanning can be done
without bringing-down your server.

Anyhow, I don't have any particular experience with mod_clamav or
anything like that. Certainly I wouldn't rely upon it solely, since
there are other ways files can make it onto your server(s). But it
probably couldn't hurt.

Things I'd be worried about are which requests will be scanned by the
AV? Will every single GET/POST/etc. be scanned? That might cause a
significant impact on your response times. Also, the aforementioned
buffering -- does the file have to remain in memory to be scanned, or
will it be streamed to a disk somewhere first? You don't want AV-scans
to bust your memory cap.

-chris

> On 3/9/16 9:49 AM, "Christopher Schultz" 
> wrote:
> 
>> John,
>>
>> On 3/8/16 6:02 PM, Rose, John B wrote:
>>> I am interested in both
>>>
>>> Thanks
>>>
>>> Sent from my iPad
>>>
 On Mar 8, 2016, at 3:27 PM, Christopher Schultz
  wrote:

>>> John
>>>
>> On 3/8/16 2:43 PM, Rose, John B wrote:
>> Looking for comments on mod_clamav, and any other alternative
>> antivirus software for Apache on linux
>>>
>>> Are you trying to protect your clients or your servers?
>>
>> I would imagine that running any AV software that monitors the
>> filesystem for changes would be sufficient. Why do you think you need an
>> httpd module for this?
>>
>> -chris
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache virus scanning

[David Copeland]

Hi John,

For that I use a php script that handles the upload. It runs clamscan on
the uploaded file.

For example:

$outputlines = array();
$last = exec ( "clamscan --quiet
".$_FILES['uploadedfile']['tmp_name'], $outputlines, $rc );
   # then check $rc . 1 => a virus was found.

Dave.

On 03/09/2016 10:21 AM, Rose, John B wrote:
> What about if your web sites allow for uploading files? Would you not want
> to scan those on upload before they got on your filesystem?
>
> On 3/9/16 9:49 AM, "Christopher Schultz" 
> wrote:
>
>> John,
>>
>> On 3/8/16 6:02 PM, Rose, John B wrote:
>>> I am interested in both
>>>
>>> Thanks
>>>
>>> Sent from my iPad
>>>
 On Mar 8, 2016, at 3:27 PM, Christopher Schultz
  wrote:

>>> John
>>>
>> On 3/8/16 2:43 PM, Rose, John B wrote:
>> Looking for comments on mod_clamav, and any other alternative
>> antivirus software for Apache on linux
>>> Are you trying to protect your clients or your servers?
>> I would imagine that running any AV software that monitors the
>> filesystem for changes would be sufficient. Why do you think you need an
>> httpd module for this?
>>
>> -chris
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>


-- 
David Copeland
JSI Data Systems Limited
613-727-9353
www.jsidata.ca


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache virus scanning

[Rose, John B]

What about if your web sites allow for uploading files? Would you not want
to scan those on upload before they got on your filesystem?

On 3/9/16 9:49 AM, "Christopher Schultz" 
wrote:

>John,
>
>On 3/8/16 6:02 PM, Rose, John B wrote:
>> I am interested in both
>> 
>> Thanks
>> 
>> Sent from my iPad
>> 
>>> On Mar 8, 2016, at 3:27 PM, Christopher Schultz
>>> wrote:
>>>
>> John
>> 
> On 3/8/16 2:43 PM, Rose, John B wrote:
> Looking for comments on mod_clamav, and any other alternative
> antivirus software for Apache on linux
>> 
>> Are you trying to protect your clients or your servers?
>
>I would imagine that running any AV software that monitors the
>filesystem for changes would be sufficient. Why do you think you need an
>httpd module for this?
>
>-chris
>
>-
>To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>For additional commands, e-mail: users-h...@httpd.apache.org
>


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Apache virus scanning

[Christopher Schultz]

John,

On 3/8/16 6:02 PM, Rose, John B wrote:
> I am interested in both
> 
> Thanks
> 
> Sent from my iPad
> 
>> On Mar 8, 2016, at 3:27 PM, Christopher Schultz 
>>  wrote:
>>
> John
> 
 On 3/8/16 2:43 PM, Rose, John B wrote:
 Looking for comments on mod_clamav, and any other alternative
 antivirus software for Apache on linux
> 
> Are you trying to protect your clients or your servers?

I would imagine that running any AV software that monitors the
filesystem for changes would be sufficient. Why do you think you need an
httpd module for this?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Lots of messages "[ssl:warn] Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock"

[Yann Ylavic]

Hi,

On Wed, Mar 9, 2016 at 2:18 PM, Hiwot Wonago
 wrote:
> hello everyone,

please don't hijack threads, just open a new one.

Regards,
Yann.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Lots of messages "[ssl:warn] Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock"

[Hiwot Wonago]

hello everyone,
I downloaded Apache24, i was trying to install it as a service. i run it on
cmd, its looks fine on the command prompt. The problem is its not working
on browser. its Bringd Forbidden, error 403What should i do?
plus if i start Apache monitor service, it doesnt work on cmd, if i stop it
it works. And also it runs on cmd if Apache monitor is not started. Is that
normal?


On Wed, Mar 9, 2016 at 8:12 AM, Hildegard Meier  wrote:

> We have also this messages with severity "emergency":
>
> grep emerg /var/log/apache2/error.log
> [Wed Mar 09 07:09:31.099331 2016] [mpm_worker:emerg] [pid 26526:tid
> 139668485949184] (35)Resource deadlock avoided: AH00273:
> apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
> [Wed Mar 09 09:49:31.931429 2016] [mpm_worker:emerg] [pid 20322:tid
> 139668485949184] (35)Resource deadlock avoided: AH00273:
> apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
> [Wed Mar 09 11:00:09.663350 2016] [mpm_worker:emerg] [pid 3062:tid
> 139668485949184] (35)Resource deadlock avoided: AH00273:
> apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
> [Wed Mar 09 11:33:02.20 2016] [mpm_worker:emerg] [pid 5608:tid
> 139668485949184] (35)Resource deadlock avoided: AH00273:
> apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
> [Wed Mar 09 11:33:24.130957 2016] [mpm_worker:emerg] [pid 9516:tid
> 139668485949184] (35)Resource deadlock avoided: AH00273:
> apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
> [Wed Mar 09 11:36:08.238661 2016] [mpm_worker:emerg] [pid 10392:tid
> 139668485949184] (35)Resource deadlock avoided: AH00272:
> apr_proc_mutex_lock failed before this child process served any requests.
> [Wed Mar 09 12:54:09.526485 2016] [mpm_worker:emerg] [pid 22783:tid
> 139668485949184] (35)Resource deadlock avoided: AH00273:
> apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
> [Wed Mar 09 13:11:18.312498 2016] [mpm_worker:emerg] [pid 26526:tid
> 139668485949184] (35)Resource deadlock avoided: AH00273:
> apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

Aw: [users@httpd] Lots of messages "[ssl:warn] Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock"

[Hildegard Meier]

We have also this messages with severity "emergency":

grep emerg /var/log/apache2/error.log
[Wed Mar 09 07:09:31.099331 2016] [mpm_worker:emerg] [pid 26526:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 09:49:31.931429 2016] [mpm_worker:emerg] [pid 20322:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 11:00:09.663350 2016] [mpm_worker:emerg] [pid 3062:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 11:33:02.20 2016] [mpm_worker:emerg] [pid 5608:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 11:33:24.130957 2016] [mpm_worker:emerg] [pid 9516:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 11:36:08.238661 2016] [mpm_worker:emerg] [pid 10392:tid 
139668485949184] (35)Resource deadlock avoided: AH00272: apr_proc_mutex_lock 
failed before this child process served any requests.
[Wed Mar 09 12:54:09.526485 2016] [mpm_worker:emerg] [pid 22783:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 13:11:18.312498 2016] [mpm_worker:emerg] [pid 26526:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org