Re: Root login
Roger Bumgarner un jour écrivit: I just tested this behavior on my Lenny/Sid workstation and Etch server... frightening indeed! Lenny does spit out an error whereas Etch still gives a password prompt. Well, It is not that bad as It is usualy only exploitable localy. But still certainly not the best behavior. Also, It allows to guess if some application have been installed without loggin in, because some application creates a user in /etc/passwd however, since this happens at the login shell, I'd be more concerned about a user booting a liveCD. I assume SSH still behaves correctly? can someone verify? It is all configured in PAM, and ssh use a different config file so It is not affected. To restore the original behaviour, just modify the file /etc/pam.d/login by replacing the following line by the second: #auth requisite pam_securetty.so authrequiredpam_securetty.so or even better (on a single line): auth [success=ok new_authtok_reqd=ok ignore=ignore auth_err=die service_err=die default=ignore] pam_securetty.so You can look at man pam.d (5) and pam_securetty to understand what It changes. With the Lenny behaviour, someone who attempt by mistake to login as root when using a tty (or equivalent) that has not been marked as trusted in /etc/securetty will be prevented to enter the root password (actually just strongly discouraged). With the old behaviour, he/she would still have been able to type in his password using a potentially untrusted channel, before seeing his login attempt being denied anyway. My guess is what they really wanted to do was something like the following: auth [success=ok new_authtok_reqd=ok ignore=ignore auth_err=die service_err=die default=ignore] pam_securetty.so I only made some quick tests by disabling one tty in securetty, so you should check It before trusting that It works as intended. Simon Valiquette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Root login
I just tested this behavior on my Lenny/Sid workstation and Etch server... frightening indeed! Lenny does spit out an error whereas Etch still gives a password prompt. however, since this happens at the login shell, I'd be more concerned about a user booting a liveCD. I assume SSH still behaves correctly? can someone verify? Thanks, -rb On Sat, Sep 13, 2008 at 1:20 AM, François Cerbelle <[EMAIL PROTECTED]> wrote: > > Le Sam 13 septembre 2008 04:47, s. keeling a écrit : > [...] >>> Try to login on any Lenny box console with an invalid account. >>> You will get "Incorrect login" without being prompted for a >>> password at all. >> What? And you get a shell prompt?!? >> > > Even if you do not have a shell, you do have an important information : > the login you tried does not exist. So, you can do a first rapid scan > based on dictionnary to find the existing users on the server. Then, you > can focus your attack on these accounts. > > If the system would ask a password, even if the account does not exist, > you can not know if the account exist or not. The security probleme is > here, if I good understood the previous message. > > As I use Etch, I was not able to test it on lenny and I did not test it on > Etch. > > > Fanfan > -- > http://www.cerbelle.net - http://www.afdm-idf.org > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Root login
Le Sam 13 septembre 2008 04:47, s. keeling a écrit : [...] >> Try to login on any Lenny box console with an invalid account. >> You will get "Incorrect login" without being prompted for a >> password at all. > What? And you get a shell prompt?!? > Even if you do not have a shell, you do have an important information : the login you tried does not exist. So, you can do a first rapid scan based on dictionnary to find the existing users on the server. Then, you can focus your attack on these accounts. If the system would ask a password, even if the account does not exist, you can not know if the account exist or not. The security probleme is here, if I good understood the previous message. As I use Etch, I was not able to test it on lenny and I did not test it on Etch. Fanfan -- http://www.cerbelle.net - http://www.afdm-idf.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Root login
On Friday 12 September 2008 21:47:31 s. keeling wrote: > Vincent Deffontaines <[EMAIL PROTECTED]>: > > Marek Kubica a écrit : > > > On Thu, 4 Sep 2008 13:25:13 +0100 > > > > > > Pawe? Krzywicki <[EMAIL PROTECTED]> wrote: > > >>> the solution was as Cerbelle said. Login as a normal user and do > > >>> sudo ( or you can activate root login from the login menu; but i > > >>> personally consider it really dangerous!) > > >> > > >> I am wondering why this is dangerous? > > >> If your password is seen as "strong" "FaG34#fCFD12drtfdg" something > > >> like this for example why this is dangerous? > > > > > > The point is, that 1) not too many people use strong passwords 2) > > > having root access allowed makes it [easier] to break in, since the > > > username is known as it is always "root". User-accounts might be named > > > pawel, pawelk, krzywicki or be completely unknown for the attacker. > > > > Even though this principle is true, it seems to me it is not in > > application on every system. > > > > Try to login on any Lenny box console with an invalid account. > > You will get "Incorrect login" without being prompted for a > > password at all. > > What? And you get a shell prompt?!? > > > I tend to consider this as a quite bad bug, but it seems it has > > been so for a while in Lenny, and even in upstream PAM. > > reportbug, search bugs.debian.org, ask in [EMAIL PROTECTED], > ... > > The "What?!?" was meant seriously. The closest I've come to running > Testing is Sidux which is Sid based, so I can't easily verify this. I > find it's difficult to believe that Lenny really does this, but what > do I know? Can anyone confirm? > I was curious, so I tried this on a recent daily netinst iso. Using an incorrect username does bypass the prompting of a password, and goes back to the login prompt. You get five tries, before issue is reprinted and the loop starts over again. The interesting thing is that if you enter the correct username and password on the fifth try, it will still fail to login and claim max tries exceeded, and start the loop again. I never got a shell for an unsuccessful login, although I also didn't get a shell for a successful login on the last attempt. > > -- > Any technology distinguishable from magic is insufficiently advanced. > (*)http://blinkynet.net/comp/uip5.html Linux Counter #80292 > - -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me. -- Thanks: Joseph Rawson signature.asc Description: This is a digitally signed message part.
Re: Root login
Vincent Deffontaines <[EMAIL PROTECTED]>: > Marek Kubica a écrit : > > On Thu, 4 Sep 2008 13:25:13 +0100 > > Pawe? Krzywicki <[EMAIL PROTECTED]> wrote: > > > >>> the solution was as Cerbelle said. Login as a normal user and do > >>> sudo ( or you can activate root login from the login menu; but i > >>> personally consider it really dangerous!) > >> I am wondering why this is dangerous? > >> If your password is seen as "strong" "FaG34#fCFD12drtfdg" something > >> like this for example why this is dangerous? > > > > The point is, that 1) not too many people use strong passwords 2) > > having root access allowed makes it [easier] to break in, since the > > username is known as it is always "root". User-accounts might be named > > pawel, pawelk, krzywicki or be completely unknown for the attacker. > > Even though this principle is true, it seems to me it is not in > application on every system. > > Try to login on any Lenny box console with an invalid account. > You will get "Incorrect login" without being prompted for a > password at all. What? And you get a shell prompt?!? > I tend to consider this as a quite bad bug, but it seems it has > been so for a while in Lenny, and even in upstream PAM. reportbug, search bugs.debian.org, ask in [EMAIL PROTECTED], ... The "What?!?" was meant seriously. The closest I've come to running Testing is Sidux which is Sid based, so I can't easily verify this. I find it's difficult to believe that Lenny really does this, but what do I know? Can anyone confirm? -- Any technology distinguishable from magic is insufficiently advanced. (*)http://blinkynet.net/comp/uip5.html Linux Counter #80292 - -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Root login
Marek Kubica a écrit : On Thu, 4 Sep 2008 13:25:13 +0100 Paweł Krzywicki <[EMAIL PROTECTED]> wrote: the solution was as Cerbelle said. Login as a normal user and do sudo ( or you can activate root login from the login menu; but i personally consider it really dangerous!) I am wondering why this is dangerous? If your password is seen as "strong" "FaG34#fCFD12drtfdg" something like this for example why this is dangerous? The point is, that 1) not too many people use strong passwords 2) having root access allowed makes it harder to break in, since the username is known as it is always "root". User-accounts might be named pawel, pawelk, krzywicki or be completely unknown for the attacker. Greetings, Even though this principle is true, it seems to me it is not in application on every system. Try to login on any Lenny box console with an invalid account. You will get "Incorrect login" without being prompted for a password at all. I tend to consider this as a quite bad bug, but it seems it has been so for a while in Lenny, and even in upstream PAM. Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Root login
Le Jeu 4 septembre 2008 16:24, Maximilian Wilhelm a écrit : > sudo sh > rm /etc/passwd > kill -9 $$ cat >> /root/.bashrc << EOF shopt -s histappend PROMPT_COMMAND="history -a;$PROMPT_COMMAND" EOF ;-) > # grep Root /etc/ssh/sshd_config > PermitRootLogin without-password :''-( Fanfan -- http://www.cerbelle.net - http://www.afdm-idf.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Root login
Anno domini 2008 François Cerbelle scripsit: > Le Jeu 4 septembre 2008 14:25, PaweÅ Krzywicki a écrit : > > On czwartek, 4 wrzeÅnia 2008, [EMAIL PROTECTED] wrote: > >> i too noticed a similar thing when i installed on my new laptop etch. > >> the solution was as Cerbelle said. Login as a normal user and do sudo ( > >> or you can activate root login from the login menu; but i personally > >> consider it really dangerous!) > > I am wondering why this is dangerous? > > If your password is seen as "strong" "FaG34#fCFD12drtfdg" something like > > this for example why this is dangerous? > Just because you log in "anonymously". In fact, if several people need a > root access, there are two possibilities : > - everybody knows and use the same root account/password, but you will bot > be able to know who made what. You can only see from which IP the "root" > connection was made. > - "root" account is locked, without password. nobody can directly connect > to it. everybody first need to connect with their personal account and > password before executing something as root. Nobody knows another one's > password, there is no common account or password and you can always know > who ran this damn "rm /etc/passwd". sudo sh rm /etc/passwd kill -9 $$ > Furthermore, root is also ALWAYS the first account to be attacked by > script kiddies. If it is locked, you are sure they will not be able to > connect to this account. # grep Root /etc/ssh/sshd_config PermitRootLogin without-password Your point being? (This is *not* ment personaly, you have the luck to wrote the last and most complete mail :)) Ciao Max -- Follow the white penguin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Root login
I use an automated preseed install, but when did they add the option to lock out the root account in the installer, and where is it asked? I agree that a locked root account, user accounts with a secure password policy and rsa keys, proper configuration of sudo, and use of AllowUsers in sshd are the best way to go for remote access. François Cerbelle wrote: > Le Jeu 4 septembre 2008 14:25, PaweÅ‚ Krzywicki a écrit : >> On czwartek, 4 wrzeÅ›nia 2008, [EMAIL PROTECTED] wrote: >>> i too noticed a similar thing when i installed on my new laptop etch. >>> the solution was as Cerbelle said. Login as a normal user and do sudo ( >>> or you can activate root login from the login menu; but i personally >>> consider it really dangerous!) >> I am wondering why this is dangerous? >> If your password is seen as "strong" "FaG34#fCFD12drtfdg" something like >> this for example why this is dangerous? > > Just because you log in "anonymously". In fact, if several people need a > root access, there are two possibilities : > - everybody knows and use the same root account/password, but you will bot > be able to know who made what. You can only see from which IP the "root" > connection was made. > - "root" account is locked, without password. nobody can directly connect > to it. everybody first need to connect with their personal account and > password before executing something as root. Nobody knows another one's > password, there is no common account or password and you can always know > who ran this damn "rm /etc/passwd". > > Furthermore, root is also ALWAYS the first account to be attacked by > script kiddies. If it is locked, you are sure they will not be able to > connect to this account. > > > Francois Cerbelle Thank you, -- James Shupe HermeTek Network Solutions http//www.hermetek.com 1.866.325.6207 This Email is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is legally privileged. The information contained in this Email is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone 1.866.325.6207 and destroy the original message. begin:vcard fn:James Shupe n:Shupe;James org:HermeTek Network Solutions adr:;;304B Peachtree Ln;Big Sandy;Texas;75755;USA email;internet:[EMAIL PROTECTED] title:President tel;work:1.866.325.6207 tel;cell:1.903.746.8424 x-mozilla-html:FALSE url:http://www.hermetek.com version:2.1 end:vcard signature.asc Description: OpenPGP digital signature
Re: Root login
Le Jeu 4 septembre 2008 14:25, PaweÅ Krzywicki a écrit : > On czwartek, 4 wrzeÅnia 2008, [EMAIL PROTECTED] wrote: >> i too noticed a similar thing when i installed on my new laptop etch. >> the solution was as Cerbelle said. Login as a normal user and do sudo ( >> or you can activate root login from the login menu; but i personally >> consider it really dangerous!) > I am wondering why this is dangerous? > If your password is seen as "strong" "FaG34#fCFD12drtfdg" something like > this for example why this is dangerous? Just because you log in "anonymously". In fact, if several people need a root access, there are two possibilities : - everybody knows and use the same root account/password, but you will bot be able to know who made what. You can only see from which IP the "root" connection was made. - "root" account is locked, without password. nobody can directly connect to it. everybody first need to connect with their personal account and password before executing something as root. Nobody knows another one's password, there is no common account or password and you can always know who ran this damn "rm /etc/passwd". Furthermore, root is also ALWAYS the first account to be attacked by script kiddies. If it is locked, you are sure they will not be able to connect to this account. Francois Cerbelle -- http://www.cerbelle.net - http://www.afdm-idf.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Root login
On Thu, 4 Sep 2008 13:25:13 +0100 Paweł Krzywicki <[EMAIL PROTECTED]> wrote: > > the solution was as Cerbelle said. Login as a normal user and do > > sudo ( or you can activate root login from the login menu; but i > > personally consider it really dangerous!) > I am wondering why this is dangerous? > If your password is seen as "strong" "FaG34#fCFD12drtfdg" something > like this for example why this is dangerous? The point is, that 1) not too many people use strong passwords 2) having root access allowed makes it harder to break in, since the username is known as it is always "root". User-accounts might be named pawel, pawelk, krzywicki or be completely unknown for the attacker. regards, Marek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Root login
Paweł Krzywicki wrote: > On czwartek, 4 września 2008, [EMAIL PROTECTED] wrote: >> i too noticed a similar thing when i installed on my new laptop etch. >> >> the solution was as Cerbelle said. Login as a normal user and do sudo ( >> or you can activate root login from the login menu; but i personally >> consider it really dangerous!) > I am wondering why this is dangerous? > If your password is seen as "strong" "FaG34#fCFD12drtfdg" something like this > for example why this is dangerous? The strength of the password does not matter, many people think the root account is too important to be in actual use. They think it should be impossible to actually run a shell as the root account at all. That's why many people have root logins over SSH enabled, as well. Sjors Gielen >> Kishore Chalakkal > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Root login
On czwartek, 4 września 2008, [EMAIL PROTECTED] wrote: > i too noticed a similar thing when i installed on my new laptop etch. > > the solution was as Cerbelle said. Login as a normal user and do sudo ( > or you can activate root login from the login menu; but i personally > consider it really dangerous!) I am wondering why this is dangerous? If your password is seen as "strong" "FaG34#fCFD12drtfdg" something like this for example why this is dangerous? > > Kishore Chalakkal -- Regards Pawel Krzywicki Debian GNU/Linux User: Pawel"at"Wartan"dot"org kadu:3735326 Registered Linux User : 406139 |PLUG :1966491030 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Root login
i too noticed a similar thing when i installed on my new laptop etch. the solution was as Cerbelle said. Login as a normal user and do sudo ( or you can activate root login from the login menu; but i personally consider it really dangerous!) Kishore Chalakkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "root login denied". But by what?
On Fri, Jun 17, 2005 at 10:47:49PM +0200, Marcin Owsiany wrote: > On Fri, Jun 17, 2005 at 07:33:02PM +0100, David Ramsden wrote: > > Does anyone know what generated the above log entries? > > try: > > find /usr/sbin /sbin /usr/local/sbin \ > /usr/bin /usr/local/bin /bin /usr/lib /lib -type f | \ > while read f; do > if strings $f | egrep -q 'no ip\?!'; then >echo "it's $f !" > fi > done > Thanks for that Marcin. Worked well and found the program that caused this. It was scponly. I'm guessing a shell user ran it from an SSH session and it's generated the log entries. So nothing to worry about! Thanks once again! David. -- .''`. David Ramsden <[EMAIL PROTECTED]> : :' :http://david.hexstream.co.uk/ `. `'` PGP key ID: 507B379B on wwwkeys.pgp.net `- Debian - when my girlfriend's away and there's nothing better to do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "root login denied". But by what?
On Fri, Jun 17, 2005 at 07:33:02PM +0100, David Ramsden wrote: > Does anyone know what generated the above log entries? try: find /usr/sbin /sbin /usr/local/sbin \ /usr/bin /usr/local/bin /bin /usr/lib /lib -type f | \ while read f; do if strings $f | egrep -q 'no ip\?!'; then echo "it's $f !" fi done > And why is there "no ip"? I guess this is a bug.. Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"root login denied". But by what?
Hi, Logcheck has just given me three of the following: Jun 17 17:17:15 hexstream [877]: root login denied [username: (0), IP/port: no ip?!] Each one with a different PID. They appear in my /var/log/auth.log I've never seen this type of message before but I've recently upgraded to the latest release of stable. Does anyone know what generated the above log entries? And why is there "no ip"? Regards, David. -- .''`. David Ramsden <[EMAIL PROTECTED]> : :' :http://david.hexstream.co.uk/ `. `'` PGP key ID: 507B379B on wwwkeys.pgp.net `- Debian - when my girlfriend's away and there's nothing better to do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [sec] Re: failed root login attempts
Personaly, I prefere: "AllowGroups ssh" so that i have to give a user explicit ssh access by adding him/her to the ssh group. Offcourse, root is not in this group :p -Original Message- From: Rolf Kutz [mailto:[EMAIL PROTECTED] Sent: woensdag 29 september 2004 23:48 To: [EMAIL PROTECTED] Cc: Noah Meyerhans Subject: Re: [sec] Re: failed root login attempts * Quoting Phillip Hofmeister ([EMAIL PROTECTED]): > On Tue, 28 Sep 2004 at 09:18:51PM -0400, Noah Meyerhans wrote: > > That doesn't seem to be the case. The most common one uses > > root/test/guest, but there are more that seem to be based on the same > > code. They all disconnect by sending the string "Bye Bye", e.g.: > > sshd[13613]: Received disconnect from 64.246.26.19: 11: Bye Bye > > > > I've seen many more aggressive root login attempts, as well as 'admin' > > and a number of other users. > > > > The somewhat unsetting thing that I'm wondering about is whether these > > machines are all sharing some big central password dictionary and are > > logging their attempted passwords to some central database. It ends up > > being some massive distributed dictionary attack, which I doubt is going > > to work on my systems, but I'm 100% sure that there are systems out > > there with weak root passwords. > > Best practices suggest: > > PermitRootLogin no Why not: PasswordAuthentication no UsePAM no - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [sec] Re: failed root login attempts
* Quoting Phillip Hofmeister ([EMAIL PROTECTED]): > On Tue, 28 Sep 2004 at 09:18:51PM -0400, Noah Meyerhans wrote: > > That doesn't seem to be the case. The most common one uses > > root/test/guest, but there are more that seem to be based on the same > > code. They all disconnect by sending the string "Bye Bye", e.g.: > > sshd[13613]: Received disconnect from 64.246.26.19: 11: Bye Bye > > > > I've seen many more aggressive root login attempts, as well as 'admin' > > and a number of other users. > > > > The somewhat unsetting thing that I'm wondering about is whether these > > machines are all sharing some big central password dictionary and are > > logging their attempted passwords to some central database. It ends up > > being some massive distributed dictionary attack, which I doubt is going > > to work on my systems, but I'm 100% sure that there are systems out > > there with weak root passwords. > > Best practices suggest: > > PermitRootLogin no Why not: PasswordAuthentication no UsePAM no - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [sec] Re: failed root login attempts
On Tue, 28 Sep 2004 at 09:18:51PM -0400, Noah Meyerhans wrote: > That doesn't seem to be the case. The most common one uses > root/test/guest, but there are more that seem to be based on the same > code. They all disconnect by sending the string "Bye Bye", e.g.: > sshd[13613]: Received disconnect from 64.246.26.19: 11: Bye Bye > > I've seen many more aggressive root login attempts, as well as 'admin' > and a number of other users. > > The somewhat unsetting thing that I'm wondering about is whether these > machines are all sharing some big central password dictionary and are > logging their attempted passwords to some central database. It ends up > being some massive distributed dictionary attack, which I doubt is going > to work on my systems, but I'm 100% sure that there are systems out > there with weak root passwords. Best practices suggest: PermitRootLogin no Then again, the people who have weak root passwords are not ones to follow best practices. -- Phillip Hofmeister pgped9HHVcQPF.pgp Description: PGP signature
Re: [sec] Re: failed root login attempts
On Tue, Sep 28, 2004 at 08:23:49PM -0300, Peter Cordes wrote: > Not if the pattern you want to ignore is more than one line. egrep is > purely line-by-line. This worm (or script-kiddie zombie?) always tries > root, admin, then test, ... That doesn't seem to be the case. The most common one uses root/test/guest, but there are more that seem to be based on the same code. They all disconnect by sending the string "Bye Bye", e.g.: sshd[13613]: Received disconnect from 64.246.26.19: 11: Bye Bye I've seen many more aggressive root login attempts, as well as 'admin' and a number of other users. The somewhat unsetting thing that I'm wondering about is whether these machines are all sharing some big central password dictionary and are logging their attempted passwords to some central database. It ends up being some massive distributed dictionary attack, which I doubt is going to work on my systems, but I'm 100% sure that there are systems out there with weak root passwords. > > Has anyone logged the passwords these attacks try? ENOTIME It might set my mind at ease regarding my point above, though. noah pgpufWL8KOAYq.pgp Description: PGP signature
Re: [sec] Re: failed root login attempts
On Tue, Sep 21, 2004 at 01:45:46PM +0100, Steve Kemp wrote: > On Sun, 19 Sep 2004, martin f krafft wrote: > > > > If you ask me, logcheck should learn how to evaluate log messages in > > > their context... > > If you want to have instant alerts of problems then logcheck is > what you want. If you to ignore some things and still receive timely > alerts then you're looking at something which can read your mind! > > If you can define what it is you don't want to see then logcheck > can handle that via the pattern files in logchecks ignore.d/ hierarchy. Not if the pattern you want to ignore is more than one line. egrep is purely line-by-line. This worm (or script-kiddie zombie?) always tries root, admin, then test, ... If it ever starts trying account names that actually exist, and aren't blocked from logging in entirely, I might see if I can get something to use iptables to block that IP for 15minutes after seeing that sequence, since it's a perfect signal that it's a bogus attack, and that it will try a bunch of logins right away, then never come back. Has anyone logged the passwords these attacks try? -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: [sec] Re: failed root login attempts
On Sun, 19 Sep 2004, martin f krafft wrote: > > If you ask me, logcheck should learn how to evaluate log messages in > > their context... If you want to have instant alerts of problems then logcheck is what you want. If you to ignore some things and still receive timely alerts then you're looking at something which can read your mind! If you can define what it is you don't want to see then logcheck can handle that via the pattern files in logchecks ignore.d/ hierarchy. It almost sounds like you're wanting to use something different anyway, perhaps logwatch is the package you're looking for? (Not in stable unfortunately, but a backport is trivial). Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [sec] Re: failed root login attempts
On Sun, 19 Sep 2004, martin f krafft wrote: > also sprach Noah Meyerhans <[EMAIL PROTECTED]> [2004.09.19.2219 +0200]: > > As an additional point against these scripts, they are host based. > > If I'm going to bother blackholing the source of these login > > attempts, I'm going to do it at the border. Yes, I can write > > scripts to react to this kind of scanning and have it > > automatically manipulate access lists on the routers, I'm not sure > > I really like the idea. I'm sort of leaning in that direction, at > > this point, though, just to shut up logcheck without telling it to > > ignore all failed root login attempts. > > If you ask me, logcheck should learn how to evaluate log messages in > their context... hmm there are ideas for logcheck after sarge+1, please elaborate. ATM logcheck is a pretty dumb `egrep -v' wrapper of your logs. that symplicity of design has it's strength, but there are for example demands for trigger values. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts [SCANNED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Thurman wrote: | On 9/19/04 1:30 PM, "martin f krafft" wrote: | | |>Other than blacklisting the IPs (which is a race I am going to |>lose), what are people doing? Are there any distinctive marks in the |>SSH login attempt that one could filter on? | | | We are using our hosts.deny files to stop all ssh attempts from ALL IP's and | then add the allowed user IP's in hosts.allow. | | We are also using a script similar to portsentry and logcheck called | logcheckplus which seems to do well, it will immediately lock out the | offending IP and notify you. It works well for dictionary attacks, ftp | kiddies and more. Just change your sshd port and don't worry about it. :/ - -- Ryan Carter -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBTt9MidqUDin6C5IRAvwwAJ4qDXiVFlte4cy3ICo7oDaUBjfkVQCeOBp6 b634sp2ObvS/2lUFgyJxFJ8= =WZvf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
* Noah Meyerhans ([EMAIL PROTECTED]) wrote: > As an additional point against these scripts, they are host based. If > I'm going to bother blackholing the source of these login attempts, I'm > going to do it at the border. Yes, I can write scripts to react to this > kind of scanning and have it automatically manipulate access lists on > the routers, I'm not sure I really like the idea. I'm sort of leaning > in that direction, at this point, though, just to shut up logcheck > without telling it to ignore all failed root login attempts. This may or may not be an option for you, but... There's an iptables match called 'ipt_recent' which you can use to blackhole addresses for a period of time. Many of these types of scans will hit an unused address first, or first hit an address/port combination that's not allowed. With ipt_recent you can then blackhole the address for some period of time (say, 60 seconds) which is generally more than long enough for the rest of the scan of your segment to be blocked. Of course, there are potential problems with any kind of automated blacklisting, the main one being the 'DoS' problem. ipt_recent tries to handle this by having the option to also track the TTL which at least makes it a little more difficult to forge packets which will block legitimate hosts. iptables also allows stateful filtering and if you use that then at least outbound connections won't be affected, only inbound ones could be. Stephen signature.asc Description: Digital signature
Re: failed root login attempts [SCANNED]
On 9/19/04 1:30 PM, "martin f krafft" wrote: > Other than blacklisting the IPs (which is a race I am going to > lose), what are people doing? Are there any distinctive marks in the > SSH login attempt that one could filter on? We are using our hosts.deny files to stop all ssh attempts from ALL IP's and then add the allowed user IP's in hosts.allow. We are also using a script similar to portsentry and logcheck called logcheckplus which seems to do well, it will immediately lock out the offending IP and notify you. It works well for dictionary attacks, ftp kiddies and more. -- David Thurman The Web Presence Group http://www.the-presence.com Web Development/E-Commerce/CMS/Hosting/Dedicated Servers 800-399-6441/309-679-0774 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
also sprach Arthur de Jong <[EMAIL PROTECTED]> [2004.09.20.1201 +0200]: > sshd[21195]: debug1: no match: libssh-0.1 I wonder whether sshd could be somehow made to just ignore when the banner does not match. > I'm not particularly worries since I have PermitRootLogin > without-password in /etc/ssh/sshd_config, only allow a few users > to ssh in anyway (use AllowGroups) and use opie passwords for > logins without a public key. I am more worried that real problems get hidden in between the floods of log entries this crap causes. And you do know that brute force crackers basically give a flying food whether you have opie or normal passwords... the chances differ, but not by much. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: failed root login attempts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 19 Sep 2004, martin f krafft wrote: > Are there any distinctive marks in the SSH login attempt that one could > filter on? The volume in attempts isn't as high here as on your system bug this is what I got when I set loglevel to debug: sshd[21195]: Connection from 211.99.26.89 port 58144 sshd[21195]: debug1: Client protocol version 2.0; client software version libssh-0.1 sshd[21195]: debug1: no match: libssh-0.1 sshd[21195]: Enabling compatibility mode for protocol 2.0 sshd[21195]: debug1: Local version string SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 sshd[21195]: debug1: Starting up PAM with username "root" sshd[21195]: Could not reverse map address 211.99.26.89. sshd[21195]: debug1: PAM setting rhost to "211.99.26.89" sshd[21195]: Failed password for root from 211.99.26.89 port 58144 ssh2 sshd[21195]: debug1: Calling cleanup 0x8052b48(0x0) sshd[21195]: debug1: Calling cleanup 0x806be5c(0x0) (it tries a password immediatly, while normal ssh tries several other things first) A while ago I saw the same thing happen for another account (guest or test I think) but currently only login attempts as root are done I'm not particularly worries since I have PermitRootLogin without-password in /etc/ssh/sshd_config, only allow a few users to ssh in anyway (use AllowGroups) and use opie passwords for logins without a public key. - -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBTqpwVYan35+NCKcRAl2rAJ92UBcG1Ts/bgaHvKzV4wRiGgAOxACgjRXW w/KcIEv31lrIHZqd8wAiqIk= =gV1i -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
On Sun, Sep 19, 2004 at 04:16:39PM -0400, Noah Meyerhans wrote: interfere with any random login based password guessing. Especially since, from what I hear about this scanner that's responsible for all these login attempts, it's trying mind-numbingly simple passwords, like root/root, guest/guest, empty passwords, and things like that. There's more than one going around. There's one trying a limited number of simple combinations and there's something else trying to brute force things with a much more extensive algorithm. A suitably paranoid person would wonder if the first thing was just cover for the second. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
martin f krafft <[EMAIL PROTECTED]> writes: > Are there any distinctive marks in the SSH login attempt that one > could filter on? Yes, the SSH banner: my honeyd logs show that of all such attempts, 63% use the banner 'SSH-2.0-windrone2', 35% use the banner 'SSH-2.0-libssh-0.1'. -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
also sprach Noah Meyerhans <[EMAIL PROTECTED]> [2004.09.19.2219 +0200]: > As an additional point against these scripts, they are host based. > If I'm going to bother blackholing the source of these login > attempts, I'm going to do it at the border. Yes, I can write > scripts to react to this kind of scanning and have it > automatically manipulate access lists on the routers, I'm not sure > I really like the idea. I'm sort of leaning in that direction, at > this point, though, just to shut up logcheck without telling it to > ignore all failed root login attempts. If you ask me, logcheck should learn how to evaluate log messages in their context... -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: failed root login attempts
On Sun, Sep 19, 2004 at 10:09:12PM +0200, martin f krafft wrote: > These scripts already exist. However, they require you to look > continuously. That's not an option. And it has to keep the admin in > the loop (and thus not be an automated blocker) because otherwise > you are open for denial-of-service attacks. As an additional point against these scripts, they are host based. If I'm going to bother blackholing the source of these login attempts, I'm going to do it at the border. Yes, I can write scripts to react to this kind of scanning and have it automatically manipulate access lists on the routers, I'm not sure I really like the idea. I'm sort of leaning in that direction, at this point, though, just to shut up logcheck without telling it to ignore all failed root login attempts. noah pgphAykCqjpee.pgp Description: PGP signature
Re: failed root login attempts
On Sun, Sep 19, 2004 at 09:53:23PM +0200, Bernd Eckenfels wrote: > You can either move your ssh to another port, that will greatly reduce the > distributed brute force attacks, or you can put a filter with port knocking > in front of it. Another option is to turn off password authentication, > completely. Neither of these is an option at a large site with dozens or hundreds of ssh users. Maybe if the sysadmins are the only ones who care about ssh it's an option, but where's the fun in that? > > And yes you should be worried about those attacks if you habe weak passwords. That's trivial to fix, even in large sites. Min password lenghts of 8 characters with a minimum of two character classes are going to interfere with any random login based password guessing. Especially since, from what I hear about this scanner that's responsible for all these login attempts, it's trying mind-numbingly simple passwords, like root/root, guest/guest, empty passwords, and things like that. noah pgpQFIu4sdpQp.pgp Description: PGP signature
Re: failed root login attempts
also sprach Bernd Eckenfels <[EMAIL PROTECTED]> [2004.09.19.2153 +0200]: > You can either move your ssh to another port, that will greatly > reduce the distributed brute force attacks, or you can put > a filter with port knocking in front of it. Another option is to > turn off password authentication, completely. All of which are not options when you have a couple hundred users accessing the machine from anywhere on the globe, including from Windoze machines and Internet cafes. > And yes you should be worried about those attacks if you habe weak > passwords. If you have a weak password, you should be worried anyway. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: failed root login attempts
In article <[EMAIL PROTECTED]> you wrote: > Other than blacklisting the IPs (which is a race I am going to > lose), what are people doing? Are there any distinctive marks in the > SSH login attempt that one could filter on? You can either move your ssh to another port, that will greatly reduce the distributed brute force attacks, or you can put a filter with port knocking in front of it. Another option is to turn off password authentication, completely. And yes you should be worried about those attacks if you habe weak passwords. Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
also sprach Dossy Shiobara <[EMAIL PROTECTED]> [2004.09.19.2203 +0200]: > > If I notice the scan immediately, I will occasionally blackhole > > the source IP at our network border, but it's rare that I notice > > in time. > > That's why I suggested writing something that tail's the syslog > and detects the scan immediately ... These scripts already exist. However, they require you to look continuously. That's not an option. And it has to keep the admin in the loop (and thus not be an automated blocker) because otherwise you are open for denial-of-service attacks. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: failed root login attempts
On 2004.09.19, Noah Meyerhans <[EMAIL PROTECTED]> wrote: > If I notice the scan immediately, I will occasionally blackhole the > source IP at our network border, but it's rare that I notice in time. That's why I suggested writing something that tail's the syslog and detects the scan immediately ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
On Sun, Sep 19, 2004 at 02:42:08PM -0400, Dossy Shiobara wrote: > > Other than blacklisting the IPs (which is a race I am going to > > lose), > > Why do you say that? I haven't seen this more than a few times a week > so I haven't bothered to do anything yet, but I'm very close to writing > a script that tail's the syslog and on more than X repeat failures, > add a rule to iptables -j DROP traffic from the offending IP address. I see several of these attempts every day, always hitting sequential IP addresses. When you have dozens of servers that otherwise wouldn't log anything worth a logcheck report, this means lots and lots of unnecessary mail. > If I'm feeling nice, I'll keep a list of the IPs that have been > temporarily blacklisted with a timestamp of when they were added, and > expire them after X time has passed ... I have found it mostly futile to blacklist them at all, unless I catch them as soon as the scanning starts. They hit IP addresses in sequential order, and once they're done scanning my netblock, I haven't seen any more of them. So logcheck, running only once an hour, is useless. It lets me know that such a scan happened, but by the time I get the mail, I don't care. If I notice the scan immediately, I will occasionally blackhole the source IP at our network border, but it's rare that I notice in time. noah pgpQVMcxhr9qu.pgp Description: PGP signature
Re: failed root login attempts
On Sun, 19 Sep 2004, Dossy Shiobara wrote: > On 2004.09.19, martin f krafft <[EMAIL PROTECTED]> wrote: > > Other than blacklisting the IPs (which is a race I am going to > > lose), > Why do you say that? I haven't seen this more than a few times a week > so I haven't bothered to do anything yet, but I'm very close to writing > a script that tail's the syslog and on more than X repeat failures, > add a rule to iptables -j DROP traffic from the offending IP address. > > If I'm feeling nice, I'll keep a list of the IPs that have been > temporarily blacklisted with a timestamp of when they were added, and > expire them after X time has passed ... why don't you create host based access controls? or use only public key authentication? I'm using that for a few years without any problems... ByeZ, WaS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
On 2004.09.19, martin f krafft <[EMAIL PROTECTED]> wrote: > Other than blacklisting the IPs (which is a race I am going to > lose), Why do you say that? I haven't seen this more than a few times a week so I haven't bothered to do anything yet, but I'm very close to writing a script that tail's the syslog and on more than X repeat failures, add a rule to iptables -j DROP traffic from the offending IP address. If I'm feeling nice, I'll keep a list of the IPs that have been temporarily blacklisted with a timestamp of when they were added, and expire them after X time has passed ... Same goes for failed FTP login attempts ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
failed root login attempts
I am seeing millions (literally) of these in the logs of my machines: sshd[30216]: Failed password for root from 203.71.62.9 port 35778 ssh2 I understand that this is some kind of virus, but it's not making me very happy because logcheck and and some of our IDS systems are going haywire, creating streams of false alarms. Other than blacklisting the IPs (which is a race I am going to lose), what are people doing? Are there any distinctive marks in the SSH login attempt that one could filter on? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: [EMAIL PROTECTED] "i wish there was a knob on the tv to turn up the intelligence. there's a knob called 'brightness', but it doesn't seem to work." -- gallagher signature.asc Description: Digital signature
Re: Securetty: limits root login while allowing 'su -'
* Ennio-Sr <[EMAIL PROTECTED]> [Thu, 23 Oct 2003 at 23:00 GMT]: > Hi, everybody on the NG. > I limited root login to two ttys only (in /etc/securetty) but yesterday > I discovered I could 'su -' to root in the excluded ttys. Do you think > [...] Many thanks to all of you for the reassuring answers ... As a matter of fact I do have: authrequired pam_wheel.so group=wheel debug in /etc/pam.d/su. Regards, -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ] (°|°) [Why to use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (used to say Henry Miller) ] Ennio. (Please change . for .dot. and @ for .at. in my Reply-To) )=(
Re: Securetty: limits root login while allowing 'su -'
* Ennio-Sr <[EMAIL PROTECTED]> [Thu, 23 Oct 2003 at 23:00 GMT]: > Hi, everybody on the NG. > I limited root login to two ttys only (in /etc/securetty) but yesterday > I discovered I could 'su -' to root in the excluded ttys. Do you think > [...] Many thanks to all of you for the reassuring answers ... As a matter of fact I do have: authrequired pam_wheel.so group=wheel debug in /etc/pam.d/su. Regards, -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ] (°|°) [Why to use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (used to say Henry Miller) ] Ennio. (Please change . for .dot. and @ for .at. in my Reply-To) )=( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Securetty: limits root login while allowing 'su -'
On Fri, 24 Oct 2003 10:50, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > I discovered I could 'su -' to root in the excluded ttys. Do you think > > this is normal behaviour or does my system need re-configuration ? > > This is the intended normal behaviour. Idea behind it is to avoid random > admins logging into the system as root so they are not trackable. If the > login as non root and use su, they at least are visible in last. I think that the idea is to prevent password guessing. If an attacker successfully logs in as root then in 99.9% of cases they can remove any log entries showing how they did it. If the user knows that they can't just login as root then they have to su from their own account, which means that their attempts are logged and appropriate action can be taken long before they guess the right password. > I think you could, however add "auth requisite pam_securetty.so" to > /etc/pam.d/su, but havent tried. Another possibility is pam_wheel.so... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Securetty: limits root login while allowing 'su -'
In article <[EMAIL PROTECTED]> you wrote: > I discovered I could 'su -' to root in the excluded ttys. Do you think > this is normal behaviour or does my system need re-configuration ? This is the intended normal behaviour. Idea behind it is to avoid random admins logging into the system as root so they are not trackable. If the login as non root and use su, they at least are visible in last. I think you could, however add "auth requisite pam_securetty.so" to /etc/pam.d/su, but havent tried. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/
Re: Securetty: limits root login while allowing 'su -'
On Thu, Oct 23, 2003 at 10:13:16PM +, Ennio-Sr wrote: > I limited root login to two ttys only (in /etc/securetty) but yesterday > I discovered I could 'su -' to root in the excluded ttys. Do you think > this is normal behaviour Yes. | [EMAIL PROTECTED]:/etc/pam.d# grep securetty * | login:# Disallows root logins except on tty's listed in /etc/securetty | login:auth requisite pam_securetty.so | [EMAIL PROTECTED]:/etc/pam.d# You could try adding this line to the file and see what happens: | auth requisite pam_securetty.so Just make sure you can get to root in a way other than the command if things break. -- Tom Goulet mail: [EMAIL PROTECTED] UID0 Unix Consultingweb: em.ca/uid0/
Re: Securetty: limits root login while allowing 'su -'
On Fri, 24 Oct 2003 10:50, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > I discovered I could 'su -' to root in the excluded ttys. Do you think > > this is normal behaviour or does my system need re-configuration ? > > This is the intended normal behaviour. Idea behind it is to avoid random > admins logging into the system as root so they are not trackable. If the > login as non root and use su, they at least are visible in last. I think that the idea is to prevent password guessing. If an attacker successfully logs in as root then in 99.9% of cases they can remove any log entries showing how they did it. If the user knows that they can't just login as root then they have to su from their own account, which means that their attempts are logged and appropriate action can be taken long before they guess the right password. > I think you could, however add "auth requisite pam_securetty.so" to > /etc/pam.d/su, but havent tried. Another possibility is pam_wheel.so... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Securetty: limits root login while allowing 'su -'
In article <[EMAIL PROTECTED]> you wrote: > I discovered I could 'su -' to root in the excluded ttys. Do you think > this is normal behaviour or does my system need re-configuration ? This is the intended normal behaviour. Idea behind it is to avoid random admins logging into the system as root so they are not trackable. If the login as non root and use su, they at least are visible in last. I think you could, however add "auth requisite pam_securetty.so" to /etc/pam.d/su, but havent tried. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Securetty: limits root login while allowing 'su -'
Hi, everybody on the NG. This is my first post here and I hope it won't be the last one too :-) [Using Debian/Woody-3.0 on knl 2.2.22 on a home PC.] I limited root login to two ttys only (in /etc/securetty) but yesterday I discovered I could 'su -' to root in the excluded ttys. Do you think this is normal behaviour or does my system need re-configuration ? Thanks for your attention. Regards, Ennio -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ] (°|°) [Why to use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (used to say Henry Miller) ] Ennio. (Please change . for .dot. and @ for .at. in my Reply-To) -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo.\\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) Ennio. (Please change . for .dot. and @ for .at. in my Reply-To) )=(
Re: Securetty: limits root login while allowing 'su -'
On Thu, Oct 23, 2003 at 10:13:16PM +, Ennio-Sr wrote: > I limited root login to two ttys only (in /etc/securetty) but yesterday > I discovered I could 'su -' to root in the excluded ttys. Do you think > this is normal behaviour Yes. | [EMAIL PROTECTED]:/etc/pam.d# grep securetty * | login:# Disallows root logins except on tty's listed in /etc/securetty | login:auth requisite pam_securetty.so | [EMAIL PROTECTED]:/etc/pam.d# You could try adding this line to the file and see what happens: | auth requisite pam_securetty.so Just make sure you can get to root in a way other than the command if things break. -- Tom Goulet mail: [EMAIL PROTECTED] UID0 Unix Consultingweb: em.ca/uid0/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Securetty: limits root login while allowing 'su -'
Hi, everybody on the NG. This is my first post here and I hope it won't be the last one too :-) [Using Debian/Woody-3.0 on knl 2.2.22 on a home PC.] I limited root login to two ttys only (in /etc/securetty) but yesterday I discovered I could 'su -' to root in the excluded ttys. Do you think this is normal behaviour or does my system need re-configuration ? Thanks for your attention. Regards, Ennio -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ] (°|°) [Why to use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (used to say Henry Miller) ] Ennio. (Please change . for .dot. and @ for .at. in my Reply-To) -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo.\\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) Ennio. (Please change . for .dot. and @ for .at. in my Reply-To) )=( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
