On Wednesday, December 07, 2011 10:44:10 AM Michael Simpson wrote:
> SELinux is great but didn't save Russell Coker from having his play
> machine owned with the vmsplice exploit.
> http://etbe.coker.com.au/2008/04/03/trust-and-play-machine/
> http://www.coker.com.au/selinux/play.html
In this par
On Wednesday, December 07, 2011 12:30:27 PM Rui Miguel Silva Seabra wrote:
> The fact that they immediately (first thing, actually) did was to
> upgrade OpenSSH does suggest that there is a Zero Day bug around.
While at first blush that would appear to be so, it may be that the openssh was
upgrad
On 12/07/2011 06:59 PM, John R Pierce wrote:
>
> anyways, this is getting very far afield for a centos specific list, and
> should instead be discussed on a security list or forum somewhere.
I've said this in the past as well - we have some super talent on this
list when it comes to admin / mana
On 12/07/11 8:12 AM, Ljubomir Ljubojevic wrote:
> Better yet. sshd could be upgraded to have dummy daemon on port 22. He
> will accept connections, ask for password but will not be able to
> resolve any usernames. Now THAT would be something.
heh. connect port 22 to a honeypot running in a VM that
Vreme: 12/07/2011 06:29 PM, Craig White piše:
>
> On Dec 7, 2011, at 4:49 AM, Johnny Hughes wrote:
>
>>> There is also use of denyhosts and fail2ban. They allow only few
>>> attempts from one IP, and all users can share attacking IP's (default is
>>> every 30 min) so you are automatically protected
On Tue, 06 Dec 2011 15:45:04 -0600
Johnny Hughes wrote:
> On 12/06/2011 02:36 PM, Les Mikesell wrote:
> > On Tue, Dec 6, 2011 at 2:18 PM, Karanbir Singh
> > wrote:
> >> On 12/06/2011 08:09 PM, Les Mikesell wrote:
> >>> Any luck on the specific attack path yet? The linked article
> >>> suggests
On Dec 7, 2011, at 4:49 AM, Johnny Hughes wrote:
>> There is also use of denyhosts and fail2ban. They allow only few
>> attempts from one IP, and all users can share attacking IP's (default is
>> every 30 min) so you are automatically protected from known attacking
>> IP's. Any downside on thi
On Wed, Dec 7, 2011 at 10:12 AM, Ljubomir Ljubojevic wrote:
>
> Better yet. sshd could be upgraded to have dummy daemon on port 22. He
> will accept connections, ask for password but will not be able to
> resolve any usernames. Now THAT would be something.
Or, it could simply rate-limit failures
Vreme: 12/07/2011 03:37 PM, Bowie Bailey piše:
> On 12/7/2011 7:07 AM, Lamar Owen wrote:
>> On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
>>> [Changing the port #] is completely and utterly retarded. You have done
>>> *NOTHING* to secure SSH by doing this. You have instead ma
On 7 December 2011 12:46, Lamar Owen wrote:
> On Wednesday, December 07, 2011 05:32:00 AM Ljubomir Ljubojevic wrote:
>> There is also use of denyhosts and fail2ban. They allow only few
>> attempts from one IP, and all users can share attacking IP's (default is
>> every 30 min) so you are automatic
On 12/07/2011 08:17 AM, Stephen Harris wrote:
> On Wed, Dec 07, 2011 at 07:07:33AM -0500, Lamar Owen wrote:
>> On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
>>> [Changing the port #] is completely and utterly retarded. You have
>> done *NOTHING* to secure SSH by doing this. Yo
On 12/7/2011 7:07 AM, Lamar Owen wrote:
> On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
>> [Changing the port #] is completely and utterly retarded. You have done
>> *NOTHING* to secure SSH by doing this. You have instead made it only
>> slightly, and I mean ever so slightly
On Wed, Dec 07, 2011 at 07:07:33AM -0500, Lamar Owen wrote:
> On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
> > [Changing the port #] is completely and utterly retarded. You have
> done *NOTHING* to secure SSH by doing this. You have instead made it
> only slightly, and I mean
On Wednesday, December 07, 2011 07:37:34 AM Always Learning wrote:
...
> The essential aspect of this suggestion is such a web site must be Linux
> non-denominational. Centos fans working with Ubuntu fans working with
> other flavours too including Red Hat et al. A genuine community
> Enterprise be
On Wednesday, December 07, 2011 05:32:00 AM Ljubomir Ljubojevic wrote:
> There is also use of denyhosts and fail2ban. They allow only few
> attempts from one IP, and all users can share attacking IP's (default is
> every 30 min) so you are automatically protected from known attacking
> IP's. Any
On Wed, 2011-12-07 at 07:07 -0500, Lamar Owen wrote:
> On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
> > A basic qualification to operate a computer would also be nice. Sad
> > thing is, there is no such thing.
> Microsoft has proposed such... of course, the prerequisites
On Wednesday, December 07, 2011 04:59:52 AM Nicolas Thierry-Mieg wrote:
> alphanumeric only isn't so secure-seeming is it? Is this for admins who
> log in with a cell phone instead of a real keyboard? ;-)
> seriously: I thought the consensus was that a secure password should
> contain at least on
On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
> [Changing the port #] is completely and utterly retarded. You have done
> *NOTHING* to secure SSH by doing this. You have instead made it only
> slightly, and I mean ever so slightly, more secure. A simple port scan of
> your
On Wed, 2011-12-07 at 12:59 +0100, Ljubomir Ljubojevic wrote:
> Vreme: 12/07/2011 12:53 PM, Always Learning piše:
> >
> > On 12/07/2011 04:32 AM, Ljubomir Ljubojevic wrote:
> >
> >> There is also use of denyhosts and fail2ban. They allow only few
> >> attempts from one IP, and all users can share
Vreme: 12/07/2011 12:53 PM, Always Learning piše:
>
> On 12/07/2011 04:32 AM, Ljubomir Ljubojevic wrote:
>
>> There is also use of denyhosts and fail2ban. They allow only few
>> attempts from one IP, and all users can share attacking IP's (default
>> is every 30 min) so you are automatically protec
On Wednesday, December 07, 2011 05:48:24 AM Adam Tauno Williams wrote:
> *DISABLE* password authentication on public-facing [and preferably all]
> servers. Isn't that securing a server rule#1?
Interestingly enough, there are vulnerability scanning tools out there that
will flag the lack of a pas
On 12/07/2011 04:32 AM, Ljubomir Ljubojevic wrote:
> There is also use of denyhosts and fail2ban. They allow only few
> attempts from one IP, and all users can share attacking IP's (default
> is every 30 min) so you are automatically protected from known
> attacking IP's. Any downside on this pr
On 12/07/2011 04:32 AM, Ljubomir Ljubojevic wrote:
> Vreme: 12/07/2011 11:12 AM, Johnny Hughes piše:
>> On 12/07/2011 03:59 AM, Nicolas Thierry-Mieg wrote:
>>> Lamar Owen wrote:
On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:
> I happen to have a copy of an older brute-forcer d
On Tue, 2011-12-06 at 16:58 -0500, Lamar Owen wrote:
> On Tuesday, December 06, 2011 04:45:04 PM Johnny Hughes wrote:
> 1.) Keep up to date as much as possible (and a 24 hour window is quite short,
> honestly, compared to the timeframes this attack appears to have occupied);
> 2.) Keep up with you
On Wed, 2011-11-30 at 13:05 -0500, m.r...@5-cent.us wrote:
> There's an article on slashdot about the Duqu team wiping all their
> intermediary c&c servers on 20 Oct. Interestingly, the report says that
> they were all (?) not only linux, but CentOS. There's a suggestion of a
> zero-day exploit in
Vreme: 12/07/2011 11:12 AM, Johnny Hughes piše:
> On 12/07/2011 03:59 AM, Nicolas Thierry-Mieg wrote:
>> Lamar Owen wrote:
>>> On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:
I happen to have a copy of an older brute-forcer dictionary here
(somewhere) and it's very large and
On 12/07/2011 03:59 AM, Nicolas Thierry-Mieg wrote:
> Lamar Owen wrote:
>> On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:
>>> I happen to have a copy of an older brute-forcer dictionary here
>>> (somewhere) and it's very large and has lots of very secure-seeming
>>> passwords in it.
Lamar Owen wrote:
> On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:
>> I happen to have a copy of an older brute-forcer dictionary here (somewhere)
>> and it's very large and has lots of very secure-seeming passwords in it.
>
> I ran down the copy I have; here's an excerpt of one of th
Vreme: 12/07/2011 03:49 AM, Always Learning piše:
>
> Op Woensdag, 7 december 03:45 +0100, Ljubomir Ljubojevic wrote:
>
>> Vreme: 12/07/2011 01:45 AM, Always Learning piše:
>>> The first thing I did was to make a 20-odd character password for Root
>>> with lowercase, uppercase and digits (using my
Op Woensdag, 7 december 03:45 +0100, Ljubomir Ljubojevic wrote:
> Vreme: 12/07/2011 01:45 AM, Always Learning piše:
> > The first thing I did was to make a 20-odd character password for Root
> > with lowercase, uppercase and digits (using my former address in
> > Germany).
>
> I like using seria
Vreme: 12/07/2011 01:45 AM, Always Learning piše:
> The first thing I did was to make a 20-odd character password for Root
> with lowercase, uppercase and digits (using my former address in
> Germany).
I like using serial numbers from Motherboards and other hardware. It's
more random.
--
Ljubo
On 12/6/2011 7:12 PM, Les Mikesell wrote:
> 2011/12/6 Fajar Priyanto:
> I happen to have a copy of an older brute-forcer dictionary here
> (somewhere) and it's very large and has lots of very secure-seeming
> passwords in it.
Why not don't allow root login from ssh? That's basic
On Tue, 2011-12-06 at 17:06 -0800, James A. Peltier wrote:
> | The first thing I did was to make a 20-odd character password for Root
> | with lowercase, uppercase and digits (using my former address in
> | Germany).
>
> Great! I'll do a little Google'ing and see if I can find out what that
>
On Tue, Dec 6, 2011 at 7:06 PM, James A. Peltier wrote:
> >
> Admins are not the incompetent ones. The users are! Any decent admin is
> going to ensure that there are the most layers and defensive systems in place
> to ensure a level of security that doesn't require the *USERS* to be rocket
>
- Original Message -
| On Tue, 2011-12-06 at 18:12 -0600, Les Mikesell wrote:
|
| > I'd expect it to be at least typical to firewall direct ssh access
| > from the internet.
|
| A Linux newcomer, untrained and a self-learner, I made an abrupt
| immersion into Linux on 1 June 2010. It was
On Tue, 2011-12-06 at 18:12 -0600, Les Mikesell wrote:
> I'd expect it to be at least typical to firewall direct ssh access
> from the internet.
A Linux newcomer, untrained and a self-learner, I made an abrupt
immersion into Linux on 1 June 2010. It was a steep learning-curve.
The first thing I
2011/12/6 Fajar Priyanto :
>
I happen to have a copy of an older brute-forcer dictionary here
(somewhere) and it's very large and has lots of very secure-seeming
passwords in it.
>>
>>> Why not don't allow root login from ssh? That's basic yet effective.
>>
>> This particular brute
Dec 7, 2011 7:05 AM Lamar Owen 작성:
> On Tuesday, December 06, 2011 05:31:58 PM Fajar Priyanto wrote:
>> Dec 7, 2011 5:58 AM Lamar Owen 작성:
>>> I happen to have a copy of an older brute-forcer dictionary here
>>> (somewhere) and it's very large and has lots of very secure-seeming
>>> password
On Tuesday, December 06, 2011 05:31:58 PM Fajar Priyanto wrote:
> Dec 7, 2011 5:58 AM Lamar Owen 작성:
> >I happen to have a copy of an older brute-forcer dictionary here (somewhere)
> >and it's very large and has lots of very secure-seeming passwords in it.
> Why not don't allow root login from s
On Tue, Dec 6, 2011 at 3:45 PM, Johnny Hughes wrote:
>
Any luck on the specific attack path yet? The linked article
suggests Centos up to 5.5 was vulnerable.
>>>
>>> We dont have access to the actual machines that were broken into - so
>>> pretty much everything is second hand info.
>
On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:
> I happen to have a copy of an older brute-forcer dictionary here (somewhere)
> and it's very large and has lots of very secure-seeming passwords in it.
I ran down the copy I have; here's an excerpt of one of the dictionaries:
Dec 7, 2011 5:58 AM Lamar Owen 작성:
> On Tuesday, December 06, 2011 04:45:04 PM Johnny Hughes wrote:
>> If I had to guess, I would say that the attackers probably developed
>> their code on CentOS, so they were looking for a CentOS machine to
>> deploy their code on in the wild. That would be w
On Tuesday, December 06, 2011 04:45:04 PM Johnny Hughes wrote:
> If I had to guess, I would say that the attackers probably developed
> their code on CentOS, so they were looking for a CentOS machine to
> deploy their code on in the wild. That would be why I would say CentOS
> was the OS used.
I
On 12/06/2011 02:36 PM, Les Mikesell wrote:
> On Tue, Dec 6, 2011 at 2:18 PM, Karanbir Singh wrote:
>> On 12/06/2011 08:09 PM, Les Mikesell wrote:
>>> Any luck on the specific attack path yet? The linked article
>>> suggests Centos up to 5.5 was vulnerable.
>>
>> We dont have access to the actu
On Tue, Dec 6, 2011 at 2:40 PM, wrote:
> >>
>>> But based on what we know and what we have been told and what we have
>>> worked out ourselves as well, its almost certainly bruteforced ssh
>>> passwords.
>>
>> So, coincidence that they were CentOS, and pre-5.6? Did they have
>> admins in common
Les Mikesell wrote:
> On Tue, Dec 6, 2011 at 2:18 PM, Karanbir Singh
> wrote:
>> On 12/06/2011 08:09 PM, Les Mikesell wrote:
>>> Any luck on the specific attack path yet? The linked article
>>> suggests Centos up to 5.5 was vulnerable.
>>
>> We dont have access to the actual machines that were
On Tue, Dec 6, 2011 at 2:18 PM, Karanbir Singh wrote:
> On 12/06/2011 08:09 PM, Les Mikesell wrote:
>> Any luck on the specific attack path yet? The linked article
>> suggests Centos up to 5.5 was vulnerable.
>
> We dont have access to the actual machines that were broken into - so
> pretty muc
On 12/06/2011 08:09 PM, Les Mikesell wrote:
> Any luck on the specific attack path yet? The linked article
> suggests Centos up to 5.5 was vulnerable.
We dont have access to the actual machines that were broken into - so
pretty much everything is second hand info.
But based on what we know and
On Wed, Nov 30, 2011 at 12:40 PM, Johnny Hughes wrote:
> On 11/30/2011 12:05 PM, m.r...@5-cent.us wrote:
>> There's an article on slashdot about the Duqu team wiping all their
>> intermediary c&c servers on 20 Oct. Interestingly, the report says that
>> they were all (?) not only linux, but CentOS
On Wed, 30 Nov 2011 14:01:36 -0500
John Hinton wrote:
> On 11/30/2011 1:55 PM, Benjamin Donnachie wrote:
> > On 30 Nov 2011, at 18:51, Les Mikesell
> > wrote:
> >
> >> Ssh is mostly about being able to log in.
> > I've always adopted the policy of disabling root logins, making
> > admins use a se
Benjamin Donnachie wrote:
On 30 Nov 2011, at 18:51, Les Mikesell wrote:
Ssh is mostly about being able to log in.
I've always adopted the policy of disabling root logins, making admins
use a separate account with public/private key authentication and then
requiring them to use su to
On 30-11-11 20:01, John Hinton wrote:
> On 11/30/2011 1:55 PM, Benjamin Donnachie wrote:
>> On 30 Nov 2011, at 18:51, Les Mikesell wrote:
>>
>>> Ssh is mostly about being able to log in.
>> I've always adopted the policy of disabling root logins, making admins
>> use a separate account with publi
On Wed, Nov 30, 2011 at 1:01 PM, John Hinton wrote:
>
On 11/30/2011 1:55 PM, Benjamin Donnachie wrote:
>
>>> Ssh is mostly about being able to log in.
>> I've always adopted the policy of disabling root logins, making admins
>> use a separate account with public/private key authentication and the
On Wed, Nov 30, 2011 at 1:01 PM, John Hinton wrote:
>
> How would you automate daily logins from another server to do something
> like rsync the entire /etc directory to a backup system?
>
Key restrictions in authorized_keys
from="10.10.10.10" command="rsync -azv blah/blah/." ssh-key-info-here
On 11/30/2011 1:55 PM, Benjamin Donnachie wrote:
> On 30 Nov 2011, at 18:51, Les Mikesell wrote:
>
>> Ssh is mostly about being able to log in.
> I've always adopted the policy of disabling root logins, making admins
> use a separate account with public/private key authentication and then
> requir
On 30 Nov 2011, at 18:51, Les Mikesell wrote:
> Ssh is mostly about being able to log in.
I've always adopted the policy of disabling root logins, making admins
use a separate account with public/private key authentication and then
requiring them to use su to elevate privileges.
Has the advanta
On Wed, Nov 30, 2011 at 12:42 PM, Rob Kampen wrote:
>
>> I've always wondered why something as complex as sshd doesn't do
>> anything to protect you from the simplest form of attack - like
>> rate-limiting failed attempts.
>>
>>
>
> Passwords?? Why?
Because they are there and enabled by default..
Les Mikesell wrote:
On Wed, Nov 30, 2011 at 12:05 PM, wrote:
Are your root passwords strong?
I've always wondered why something as complex as sshd doesn't do
anything to protect you from the simplest form of attack - like
rate-limiting failed attempts.
Passwords?? Why?
Remote ro
Les Mikesell wrote:
> On Wed, Nov 30, 2011 at 12:05 PM, wrote:
>>
>> Are your root passwords strong?
>
> I've always wondered why something as complex as sshd doesn't do
> anything to protect you from the simplest form of attack - like
> rate-limiting failed attempts.
Well, it does take time to
On 11/30/2011 12:05 PM, m.r...@5-cent.us wrote:
> There's an article on slashdot about the Duqu team wiping all their
> intermediary c&c servers on 20 Oct. Interestingly, the report says that
> they were all (?) not only linux, but CentOS. There's a suggestion of a
> zero-day exploit in openssh-4.3
On Wed, Nov 30, 2011 at 12:05 PM, wrote:
>
> Are your root passwords strong?
I've always wondered why something as complex as sshd doesn't do
anything to protect you from the simplest form of attack - like
rate-limiting failed attempts.
--
Les Mikesell
lesmikes...@gmail.com
___
There's an article on slashdot about the Duqu team wiping all their
intermediary c&c servers on 20 Oct. Interestingly, the report says that
they were all (?) not only linux, but CentOS. There's a suggestion of a
zero-day exploit in openssh-4.3, but both the original article, and
Kaspersky labs (who
62 matches
Mail list logo
