Les Mikesell wrote:
Craig White wrote:
We will work also with the Red Hat Security team and see if we can
isolate any issues that might be FIXABLE.
doesn't this almost beg for upstream to make denyhosts a base install
and automatically on, just as sshd is automatically on?
I've always
General note:
"loose" - pronounced "luce" (like Henry Luce, publisher of Time
magazine), rhymes with goose - means not tight, or insecure or, as a
verb, to let go of.
"lose" - pronounced "looz," rhymes with booze (I know you'll
understand that one! :-) - means to fail to hold on to or keep track
On Jan 28, 2008 9:19 PM, Michael A. Peters <[EMAIL PROTECTED]> wrote:
> Frank Cox wrote:
> > On Mon, 28 Jan 2008 22:36:03 -0500
> > Jim Perrin <[EMAIL PROTECTED]> wrote:
> >
> >> And above all, because I know many admins slack on this, and I'm
> >> guilty of it as well if it's not forced... ROTATE
David Thompson wrote:
"Michael A. Peters" wrote:
I have never understood this. If I have a good, strong password that nobody
knows, how is changing it to another one an improvement over what I already
have?
I agree with you.
For user accounts, changing one strong password for another gains y
Chris Mauritz wrote:
Milton Calnek wrote:
If you don't like the defaults, get anaconda to change them for you.
Or write a script that you run shortly after install to make the
changes for you.
That would be pretty amazing if at the end (or at the beginning) of the
install there was some chec
Milton Calnek wrote:
If you don't like the defaults, get anaconda to change them for you.
Or write a script that you run shortly after install to make the
changes for you.
That would be pretty amazing if at the end (or at the beginning) of the
install there was some checkbox that said somethi
Johnny Hughes wrote:
Jim Perrin wrote:
The real reason is that RHEL does not ship that way, so CentOS does not
either.
The bottom line for this and all other questions like it is this:
We clone the configuration of the upstream system on purpose so that
CentOS performs as much as possible
"Michael A. Peters" wrote:
>>
>> I have never understood this. If I have a good, strong password that nobody
>> knows, how is changing it to another one an improvement over what I already
>> have?
>
>I agree with you.
For user accounts, changing one strong password for another gains you nothing,
Chris Mauritz wrote:
Alfredo Perez wrote:
I will add to that list, change ssh port 22 to somthing else
Why? Most of the script kiddies now check all the higher ports for ssh
too. Moving ssh's port around solves nothing.
Actually, I have to disagree.
SOME of the script kiddies check highe
Jim Perrin wrote:
On Jan 29, 2008 5:52 AM, mouss <[EMAIL PROTECTED]> wrote:
Jim Perrin wrote:
Along the lines of staying safe, now is probably a good time to check
your password policies.
1. Don't allow root access to ssh. (modify /etc/ssh/sshd_config)
why isn't this the default?
Taking a
On Jan 29, 2008 8:01 AM, Alfredo Perez <[EMAIL PROTECTED]> wrote:
> Thinking about the above made me ask the following question:
>
> Is it possible to setup Centos to ask for a change of password
> every month?
Yep. Change the values in /etc/login.defs for PASS_* and use: chage -M
-m -W USER
Alfredo Perez wrote:
> I will add to that list, change ssh port 22 to somthing else
>
Why? Most of the script kiddies now check all the higher ports for ssh
too. Moving ssh's port around solves nothing.
Cheers,
___
CentOS mailing list
CentOS@centos.o
On Mon, Jan 28, 2008 at 10:36:03PM -0500, Jim Perrin wrote:
> Along the lines of staying safe, now is probably a good time to check
> your password policies.
>
> 1. Don't allow root access to ssh. (modify /etc/ssh/sshd_config)
> 2. restrict root logins to only the local machine. (modify /etc/secur
On Tue, Jan 29, 2008 at 04:43:16PM +1100, Les Bell wrote:
>
> Frank Cox <[EMAIL PROTECTED]> wrote:
>
> >>
> I have never understood this. If I have a good, strong password that
> nobody
> knows, how is changing it to another one an improvement over what I already
> have?
> <<
>
> Correct. Moder
On Jan 29, 2008 5:52 AM, mouss <[EMAIL PROTECTED]> wrote:
> Jim Perrin wrote:
> > Along the lines of staying safe, now is probably a good time to check
> > your password policies.
> >
> > 1. Don't allow root access to ssh. (modify /etc/ssh/sshd_config)
> >
> why isn't this the default?
>
Taking an
Jim Perrin wrote:
Along the lines of staying safe, now is probably a good time to check
your password policies.
1. Don't allow root access to ssh. (modify /etc/ssh/sshd_config)
why isn't this the default?
2. restrict root logins to only the local machine. (modify /etc/securetty)
3. Limit u
Frank Cox <[EMAIL PROTECTED]> wrote:
>>
I have never understood this. If I have a good, strong password that
nobody
knows, how is changing it to another one an improvement over what I already
have?
<<
Correct. Modern thinking is to teach people how to create a good, strong
password and then sti
Frank Cox wrote:
On Mon, 28 Jan 2008 22:36:03 -0500
Jim Perrin <[EMAIL PROTECTED]> wrote:
And above all, because I know many admins slack on this, and I'm
guilty of it as well if it's not forced... ROTATE your passwords
periodically
I have never understood this. If I have a good, strong pass
Jim Perrin wrote:
On Jan 28, 2008 10:14 PM, Les Mikesell <[EMAIL PROTECTED]> wrote:
Craig White wrote:
We will work also with the Red Hat Security team and see if we can
isolate any issues that might be FIXABLE.
doesn't this almost beg for upstream to make denyhosts a base install
and aut
>I have never understood this.
Exactly why you should be more proactive, if it matters in your environment.
>If I have a good, strong password that nobody
>knows
Do you know this?
CMIIW,
But an example from the windows world would be *if* someone sniffed the hash of
an admin login, then took it
On Mon, 28 Jan 2008 22:36:03 -0500
Jim Perrin <[EMAIL PROTECTED]> wrote:
> And above all, because I know many admins slack on this, and I'm
> guilty of it as well if it's not forced... ROTATE your passwords
> periodically
I have never understood this. If I have a good, strong password that nobod
On Mon, 2008-01-28 at 22:19 -0500, Jim Perrin wrote:
> On Jan 28, 2008 10:14 PM, Les Mikesell <[EMAIL PROTECTED]> wrote:
> > Craig White wrote:
> > >>
> > >> We will work also with the Red Hat Security team and see if we can
> > >> isolate any issues that might be FIXABLE.
> > >
> > > doesn't
Along the lines of staying safe, now is probably a good time to check
your password policies.
1. Don't allow root access to ssh. (modify /etc/ssh/sshd_config)
2. restrict root logins to only the local machine. (modify /etc/securetty)
3. Limit users with access to 'su' to the wheel group (use visud
On Jan 28, 2008 10:14 PM, Les Mikesell <[EMAIL PROTECTED]> wrote:
> Craig White wrote:
> >>
> >> We will work also with the Red Hat Security team and see if we can
> >> isolate any issues that might be FIXABLE.
> >
> > doesn't this almost beg for upstream to make denyhosts a base install
> > a
Craig White wrote:
We will work also with the Red Hat Security team and see if we can
isolate any issues that might be FIXABLE.
doesn't this almost beg for upstream to make denyhosts a base install
and automatically on, just as sshd is automatically on?
I've always wondered why a progra
On Mon, 2008-01-28 at 19:55 -0600, Johnny Hughes wrote:
> Johnny Hughes wrote:
> > Here is the applicable article:
> >
> > http://www.linux.com/feature/125548
> >
> > There are links in the above article that explain tests for the system
> > and what is currently known about the rootkit.
> >
>
Johnny Hughes wrote:
Here is the applicable article:
http://www.linux.com/feature/125548
There are links in the above article that explain tests for the system
and what is currently known about the rootkit.
Apparently initial access is NOT via any vulnerability but just guessed
root passwor
27 matches
Mail list logo
