Re: How we handle attacks?

2013-10-07 Thread inode0
On Mon, Oct 7, 2013 at 10:37 AM, Toshio Kuratomi wrote: > Objection. > > + Use denyhosts as this is what we're using on the rest of infra. > > + we should talk a bit about whether we want denyhosts on for all cloud > boxes or just specific ones. I lean towards enabling it for security but we > di

Re: How we handle attacks?

2013-10-07 Thread Toshio Kuratomi
Objection. + Use denyhosts as this is what we're using on the rest of infra. + we should talk a bit about whether we want denyhosts on for all cloud boxes or just specific ones. I lean towards enabling it for security but we did envision the cloud hosts being more forgiving than the rest of infr

Re: How we handle attacks?

2013-10-07 Thread Miroslav Suchý
On 10/07/2013 05:23 AM, Anshu Prateek wrote: Most of these logins are automated bot attempts. On my personal servers, one easy way I have found is changing the default port to something else and that cuts down my lastb by almost 99%! Yes, I do that for my personal servers as well (and it works

Re: How we handle attacks?

2013-10-06 Thread Christopher Meng
Do we need some honeypots? ;) ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: How we handle attacks?

2013-10-06 Thread Anshu Prateek
I guess you are talking about ssh access? Most of these logins are automated bot attempts. On my personal servers, one easy way I have found is changing the default port to something else and that cuts down my lastb by almost 99%! On Thu, Oct 3, 2013 at 5:50 PM, Miroslav Suchý wrote: > I see i

Re: How we handle attacks?

2013-10-03 Thread Tristan Santore
On 03/10/13 16:34, Matthew Miller wrote: On Thu, Oct 03, 2013 at 09:29:36AM -0600, Kevin Fenzi wrote: We might want to look at all the options in this space again at some point however. I think denyhosts isn't maintained much upstream anymore and thus is not porting to journald, so with newer re

Re: How we handle attacks?

2013-10-03 Thread Matthew Miller
On Thu, Oct 03, 2013 at 09:29:36AM -0600, Kevin Fenzi wrote: > We might want to look at all the options in this space again at some > point however. I think denyhosts isn't maintained much upstream anymore > and thus is not porting to journald, so with newer releases it's likely > to stop working.

Re: How we handle attacks?

2013-10-03 Thread Kevin Fenzi
On Thu, 3 Oct 2013 07:40:10 -0700 Toshio Kuratomi wrote: > On Thu, Oct 03, 2013 at 03:10:13PM +0200, Miroslav Suchý wrote: > > On 10/03/2013 02:55 PM, Jhoanir Torres wrote: > > >Is highly recommended use 'Fail2Ban' in victim servers. > > > > And do we already use it? Because git grep in ansible.

Re: How we handle attacks?

2013-10-03 Thread Toshio Kuratomi
On Thu, Oct 03, 2013 at 03:10:13PM +0200, Miroslav Suchý wrote: > On 10/03/2013 02:55 PM, Jhoanir Torres wrote: > >Is highly recommended use 'Fail2Ban' in victim servers. > > And do we already use it? Because git grep in ansible.git returns zero to me. > We use denyhosts which serves a similar pu

Re: How we handle attacks?

2013-10-03 Thread Miroslav Suchý
On 10/03/2013 02:55 PM, Jhoanir Torres wrote: Is highly recommended use 'Fail2Ban' in victim servers. And do we already use it? Because git grep in ansible.git returns zero to me. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys __

Re: How we handle attacks?

2013-10-03 Thread Jhoanir Torres
Is highly recommended use 'Fail2Ban' in victim servers. -- Jhoanir Torres El oct 3, 2013 7:20 AM, "Miroslav Suchý" escribió: > I see in log file of copr-fe-dev a lot of attempts to login as > root/postgres/nagios/oracl/**test user. Well it is ~4000 attempts. So it > depend on your definition of

How we handle attacks?

2013-10-03 Thread Miroslav Suchý
I see in log file of copr-fe-dev a lot of attempts to login as root/postgres/nagios/oracl/test user. Well it is ~4000 attempts. So it depend on your definition of "lot of". But it caught my attention. Do we have some standard procedure how to handle it? Add that IPs to blacklist? Move ssh port t