Mailing List Archive: DAViCal: General

protect web interface

Index | Next | Previous | View Threaded

peljasz at yahoo

May 18, 2012, 6:16 AM

Post #1 of 6 (312 views)
Permalink

protect web interface

dear all

one quick question - can on protect the web management interface
I'm thinking something like simple means of Allow/Deny in
apache's directive,
is it possible?

regards

fabian at wenks

May 18, 2012, 7:22 AM

Post #2 of 6 (313 views)
Permalink

Re: protect web interface [In reply to]

Hello

On 18.05.2012 15:16, lejeczek wrote:
> one quick question - can on protect the web management interface
> I'm thinking something like simple means of Allow/Deny in
> apache's directive,
> is it possible?

As all the access (including CalDAV / CardDAV) is going through
the same web hosting, it is probably not possible to use
Allow/Deny rule only for the web management part.

But you could protect the whole DAViCal Server (http or https)
from brute force logins with fail2ban [1].

[1] http://www.fail2ban.org/

I have attached my filter for fail2ban (davical.local). Add it to
your existing fail2ban installation and configure it in the
jail.local with your desired options and with pointing the
"logpath" to the Apache error.log of your DAViCal webhosting. For
blocking use TCP port 443 (or 80 if you do not use https).

bye
Fabian

Attachments:

davical.local (0.44 KB)

sebastian.gauss at hosteurope

May 18, 2012, 7:36 AM

Post #3 of 6 (308 views)
Permalink

Re: protect web interface [In reply to]

Hi,

my solution to this problem is using rewriting of the root url and the
index.php if not accessed from "my" ip-range:

RewriteCond %{REQUEST_URI} ^/index.php
RewriteCond %{REMOTE_ADDR} !^192\.168\.0\.
RewriteRule ^(.*)$ http://www.xxx.de$1 [R]

RewriteCond %{REQUEST_URI} ^/$
RewriteCond %{REMOTE_ADDR} !^192\.168\.0\.
RewriteRule ^(.*)$ http://www.xxx.de$1 [R,L]

Regards,
Sebastian

On 18.05.2012 16:22, Fabian Wenk wrote:
> Hello
>
> On 18.05.2012 15:16, lejeczek wrote:
>> one quick question - can on protect the web management interface
>> I'm thinking something like simple means of Allow/Deny in
>> apache's directive,
>> is it possible?
>
> As all the access (including CalDAV / CardDAV) is going through the same
> web hosting, it is probably not possible to use Allow/Deny rule only for
> the web management part.
>
> But you could protect the whole DAViCal Server (http or https) from
> brute force logins with fail2ban [1].
>
> [1] http://www.fail2ban.org/
>
> I have attached my filter for fail2ban (davical.local). Add it to your
> existing fail2ban installation and configure it in the jail.local with
> your desired options and with pointing the "logpath" to the Apache
> error.log of your DAViCal webhosting. For blocking use TCP port 443 (or
> 80 if you do not use https).
>
>
> bye
> Fabian
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Davical-general mailing list
> Davical-general [at] lists
> https://lists.sourceforge.net/lists/listinfo/davical-general

Attachments:

signature.asc (0.25 KB)

chris at netcar24

May 18, 2012, 8:22 AM

Post #4 of 6 (312 views)
Permalink

Re: protect web interface [In reply to]

hi,

i don't do that but a location entry should do the same

e.g.
<Location /index.php>
AuthType Basic
Auth...
...
</Location>

which enables you to log in to the interface from other IP's, too...
should be safe enough if it's an ssl-enabled domain.

cheers,
chris

ps: i'm just not clear about if this matches when the server is called just
without index.php. but because the index.php should be DirectoryIndex of
the Vhost it should end in a GET-request to index.php and therefor should
match the location... but better check that...

--On Freitag, Mai 18, 2012 16:36:30 +0200 Sebastian Gauß
<sebastian.gauss [at] hosteurope> wrote:

> Hi,
>
> my solution to this problem is using rewriting of the root url and the
> index.php if not accessed from "my" ip-range:
>
> RewriteCond %{REQUEST_URI} ^/index.php
> RewriteCond %{REMOTE_ADDR} !^192\.168\.0\.
> RewriteRule ^(.*)$ http://www.xxx.de$1 [R]
>
> RewriteCond %{REQUEST_URI} ^/$
> RewriteCond %{REMOTE_ADDR} !^192\.168\.0\.
> RewriteRule ^(.*)$ http://www.xxx.de$1 [R,L]
>
> Regards,
> Sebastian
>
> On 18.05.2012 16:22, Fabian Wenk wrote:
>> Hello
>>
>> On 18.05.2012 15:16, lejeczek wrote:
>>> one quick question - can on protect the web management interface
>>> I'm thinking something like simple means of Allow/Deny in
>>> apache's directive,
>>> is it possible?
>>
>> As all the access (including CalDAV / CardDAV) is going through the same
>> web hosting, it is probably not possible to use Allow/Deny rule only for
>> the web management part.
>>
>> But you could protect the whole DAViCal Server (http or https) from
>> brute force logins with fail2ban [1].
>>
>> [1] http://www.fail2ban.org/
>>
>> I have attached my filter for fail2ban (davical.local). Add it to your
>> existing fail2ban installation and configure it in the jail.local with
>> your desired options and with pointing the "logpath" to the Apache
>> error.log of your DAViCal webhosting. For blocking use TCP port 443 (or
>> 80 if you do not use https).
>>
>>
>> bye
>> Fabian
>>
>>
>> ------------------------------------------------------------------------
>> ------ Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions will include endpoint security, mobile security and the
>> latest in malware threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>
>>
>>
>> _______________________________________________
>> Davical-general mailing list
>> Davical-general [at] lists
>> https://lists.sourceforge.net/lists/listinfo/davical-general
>

=====================================
Trying to remove information from
the Internet is like fishing piss
out of the swimming pool.
=====================================

++++++++++++++++++++++++++++++++++++++
+ pgp: http://s.rubbish.de/gpgCS +
++++++++++++++++++++++++++++++++++++++

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

andrew at morphoss

May 18, 2012, 3:21 PM

Post #5 of 6 (310 views)
Permalink

Re: protect web interface [In reply to]

Hi,

The best approach is probably some combination that uses one of these
settings:

http://wiki.davical.org/w/Configuration/settings/restrict_admin_domain
http://wiki.davical.org/w/Configuration/settings/restrict_admin_port

combined with standard Allow/Deny rules.

With either of the settings above, the index.php will just pass
everything through to caldav.php unless you are connecting to the admin
domain and/or port.

Cheers,
Andrew.

On Fri, 2012-05-18 at 16:36 +0200, Sebastian Gauß wrote:
> Hi,
>
> my solution to this problem is using rewriting of the root url and the
> index.php if not accessed from "my" ip-range:
>
> RewriteCond %{REQUEST_URI} ^/index.php
> RewriteCond %{REMOTE_ADDR} !^192\.168\.0\.
> RewriteRule ^(.*)$ http://www.xxx.de$1 [R]
>
> RewriteCond %{REQUEST_URI} ^/$
> RewriteCond %{REMOTE_ADDR} !^192\.168\.0\.
> RewriteRule ^(.*)$ http://www.xxx.de$1 [R,L]
>
> Regards,
> Sebastian
>
> On 18.05.2012 16:22, Fabian Wenk wrote:
> > Hello
> >
> > On 18.05.2012 15:16, lejeczek wrote:
> >> one quick question - can on protect the web management interface
> >> I'm thinking something like simple means of Allow/Deny in
> >> apache's directive,
> >> is it possible?
> >
> > As all the access (including CalDAV / CardDAV) is going through the same
> > web hosting, it is probably not possible to use Allow/Deny rule only for
> > the web management part.
> >
> > But you could protect the whole DAViCal Server (http or https) from
> > brute force logins with fail2ban [1].
> >
> > [1] http://www.fail2ban.org/
> >
> > I have attached my filter for fail2ban (davical.local). Add it to your
> > existing fail2ban installation and configure it in the jail.local with
> > your desired options and with pointing the "logpath" to the Apache
> > error.log of your DAViCal webhosting. For blocking use TCP port 443 (or
> > 80 if you do not use https).
> >
> >
> > bye
> > Fabian
> >
> >
> > ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >
> >
> >
> > _______________________________________________
> > Davical-general mailing list
> > Davical-general [at] lists
> > https://lists.sourceforge.net/lists/listinfo/davical-general
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________ Davical-general mailing list Davical-general [at] lists https://lists.sourceforge.net/lists/listinfo/davical-general

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
A list is only as strong as its weakest link.
-- Don Knuth

------------------------------------------------------------------------

Attachments:

signature.asc (0.82 KB)

peljasz at yahoo

Jul 27, 2012, 2:51 AM

Post #6 of 6 (204 views)
Permalink

Re: protect web interface [In reply to]

how would you combined your rewrites with recommended
rewrites for prettier urls, these here:

RewriteCond %{REQUEST_URI} !^/$
# Not if it's an existing file
RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
# Everything else gets rewritten to /caldav.php/...
RewriteRule ^(.*)$ /caldav.php/$1 [NC,L]

regards

On 18/05/12 15:36, Sebastian Gauß wrote:
> Hi,
>
> my solution to this problem is using rewriting of the root url and the
> index.php if not accessed from "my" ip-range:
>
> RewriteCond %{REQUEST_URI} ^/index.php
> RewriteCond %{REMOTE_ADDR} !^192\.168\.0\.
> RewriteRule ^(.*)$ http://www.xxx.de$1 [R]
>
> RewriteCond %{REQUEST_URI} ^/$
> RewriteCond %{REMOTE_ADDR} !^192\.168\.0\.
> RewriteRule ^(.*)$ http://www.xxx.de$1 [R,L]
>
> Regards,
> Sebastian
>
> On 18.05.2012 16:22, Fabian Wenk wrote:
>> Hello
>>
>> On 18.05.2012 15:16, lejeczek wrote:
>>> one quick question - can on protect the web management interface
>>> I'm thinking something like simple means of Allow/Deny in
>>> apache's directive,
>>> is it possible?
>> As all the access (including CalDAV / CardDAV) is going through the same
>> web hosting, it is probably not possible to use Allow/Deny rule only for
>> the web management part.
>>
>> But you could protect the whole DAViCal Server (http or https) from
>> brute force logins with fail2ban [1].
>>
>> [1] http://www.fail2ban.org/
>>
>> I have attached my filter for fail2ban (davical.local). Add it to your
>> existing fail2ban installation and configure it in the jail.local with
>> your desired options and with pointing the "logpath" to the Apache
>> error.log of your DAViCal webhosting. For blocking use TCP port 443 (or
>> 80 if you do not use https).
>>
>>
>> bye
>> Fabian
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>
>>
>>
>> _______________________________________________
>> Davical-general mailing list
>> Davical-general [at] lists
>> https://lists.sourceforge.net/lists/listinfo/davical-general
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Davical-general mailing list
> Davical-general [at] lists
> https://lists.sourceforge.net/lists/listinfo/davical-general

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads