11:25 a.m.
Does anybody know which mailing list addresses security issues?
Logwatch on my server reported this:
apache logged in from dsl-82-199-133-138.dutchdsl.nl (82.199.133.138) using password: 1
Time(s)
My apache account is active so I can su to it to administer postgresql databases
accessable via php scripts. No password is set. It was my understanding that it would be
impossible to log in except via su from root. Either I'm dead wrong or there's a
security hole which needs fixed.
thanks
Scott Becker
12:23 p.m.
On Mon, Feb 14, 2005 at 09:25:43AM -0800, Scott Becker wrote:
Does anybody know which mailing list addresses security issues?
fedora-list is best for this in general. But there is a "-devel" issue
here.....
Logwatch on my server reported this:
apache logged in from dsl-82-199-133-138.dutchdsl.nl (82.199.133.138) using
password: 1 Time(s)
My apache account is active so I can su to it to administer postgresql
databases accessable via php scripts. No password is set. It was my
understanding that it would be impossible to log in except via su from
root. Either I'm dead wrong or there's a security hole which needs fixed.
I think the problem here is that you're dead wrong. If no password is set
and the account isn't locked, anyone can log in. Make sure the account is
locked.
For this reason, I apply the following patch to authconfig, to make the
default configuration disallow logins with null passwords. I think it'd be a
good idea to make this be the default, in fact. People who really want empty
passwords should have to do this to themselves.
--- ../authconfig-4.1.6.orig/authinfo.c Wed Aug 29 14:26:40 2001
+++ ./authinfo.c Wed Aug 29 14:29:46 2001
@@ -2061,9 +2061,7 @@
static const char *argv_unix_auth[] = {
"likeauth",
- "nullok",
NULL,
};
static const char *argv_unix_password[] = {
- "nullok",
"use_authtok",
NULL,
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
--> Fedora Users & Developers Conference, hosted by Boston University <--
February 18th, 2005 <http://fedoraproject.org/fudcon/>
12:28 p.m.
Hi.
Scott Becker <scottb(a)bxwa.com> wrote:
My apache account is active so I can su to it to administer
postgresql
databases accessable via php scripts.
You do not need a password for that, or change anything about the
account.
"sudo -u apache" (as normal user) or just "su -m apache" (as root)
ought
to do the job.
--
"Your reality, sir, is lies and balderdash and I am delighted to say
that I have no grasp of it whatsoever." -- Baron Munchausen
12:35 p.m.
On Mon, Feb 14, 2005 at 07:28:57PM +0100, Ralf Ertzinger wrote:
Hi.
Scott Becker <scottb(a)bxwa.com> wrote:
> My apache account is active so I can su to it to administer postgresql
> databases accessable via php scripts.
You do not need a password for that, or change anything about the
account.
"sudo -u apache" (as normal user) or just "su -m apache" (as root)
ought
to do the job.
Or just psql -U apache.
And login with empty passwords can be disabled by removing nullok from
/etc/pam.d/system-auth.
--
"Your reality, sir, is lies and balderdash and I am delighted to say
that I have no grasp of it whatsoever." -- Baron Munchausen
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--
4/11
1:04 p.m.
On Mon, Feb 14, 2005 at 18:35:01 +0000,
Luciano Miguel Ferreira Rocha <strange(a)nsk.no-ip.org> wrote:
Or just psql -U apache.
If you go that route, you can set up ident authentication for postgres
so that this command will work from your normal user account, without
having to switch to root first or supply an additional password.
12:57 p.m.
I started with the default apache user and ran the following commands:
#bring up apache account-
mkdir /home/apache
cp /etc/skel/.* /home/apache
chown -R apache: /home/apache
usermod -d /home/apache apache
usermod -s /bin/bash apache
This way I can access it with a simple 'su apache' command ran as root
and there's a home directory to store the .psql_history file so the
command history is saved across sessions. I fear that by setting the
shell with 'usermod -s /bin/bash apache' I've opened a can of worms. I
just set a password on the account to prevent any more logins but if
there's a security hole it would be nice to fix it and if not I would
like to know how they logged in and understand the process. I tried
(just before setting the password) to login hitting enter for the
password and I couldn't get in.
Luciano Miguel Ferreira Rocha wrote:
And login with empty passwords can be disabled by removing nullok
from
/etc/pam.d/system-auth.
I found nullok twice in the file. Perhaps I couldn't get in on my test
because PuTTY doesn't pass null. I guess I shall always set a password
from now on.
thanks all
scottb
Ralf Ertzinger wrote:
Hi.
Scott Becker <scottb(a)bxwa.com> wrote:
>My apache account is active so I can su to it to administer postgresql
>databases accessable via php scripts.
>
>
You do not need a password for that, or change anything about the
account.
"sudo -u apache" (as normal user) or just "su -m apache" (as root)
ought
to do the job.
6:54 a.m.
On Mon, 2005-02-14 at 10:57 -0800, Scott Becker wrote:
I started with the default apache user and ran the following
commands:
#bring up apache account-
mkdir /home/apache
cp /etc/skel/.* /home/apache
chown -R apache: /home/apache
usermod -d /home/apache apache
usermod -s /bin/bash apache
This way I can access it with a simple 'su apache' command ran as root
and there's a home directory to store the .psql_history file so the
command history is saved across sessions. I fear that by setting the
shell with 'usermod -s /bin/bash apache' I've opened a can of worms. I
just set a password on the account to prevent any more logins but if
there's a security hole it would be nice to fix it and if not I would
like to know how they logged in and understand the process. I tried
(just before setting the password) to login hitting enter for the
password and I couldn't get in.
....
I found nullok twice in the file. Perhaps I couldn't get in on my
test
because PuTTY doesn't pass null. I guess I shall always set a password
from now on.
What does 'getent shadow apache' gives you if you call it from root
account?
If it's something like:
apache:!!:xxxxx::::::
^^ note these. If the exclamation marks are missing it means that
this account is without a password and nullok allows to login to it. But
if the !! (or *) is there it means something is broken on your system if
it allowed login to that account. Can you find the messages from
the /var/log/ surrounding the 'apache logged in from
dsl-82-199-133-138.dutchdsl.nl (82.199.133.138)' message?
--
Tomas Mraz <tmraz(a)redhat.com>
4:11 p.m.
I've already set a proper password but on a twin testing machine the !!s
are there, before and after running my setup commands to change the
shell. Here's the top of message with the login and logout lines:
Feb 13 04:05:24 backup syslogd 1.4.1: restart.
Feb 13 05:39:25 backup named[31607]: lame server resolving
'191.236.191.211.in-addr.arpa' (in '236.191.211.in-addr.arpa'?):
203.251.201.1#53
Feb 13 05:45:51 backup named[31607]: lame server resolving
'201.32.110.61.in-addr.arpa' (in '32.110.61.in-addr.arpa'?):
203.240.193.11#53
Feb 13 05:45:51 backup named[31607]: lame server resolving
'201.32.110.61.in-addr.arpa' (in '32.110.61.in-addr.arpa'?):
203.251.201.1#53
Feb 13 06:36:09 backup sshd(pam_unix)[422]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser=
rhost=dsl-82-199-133-138.dutchdsl.nl user=apache
Feb 13 06:36:17 backup sshd(pam_unix)[425]: session opened for user
apache by (uid=48)
Feb 13 06:53:58 backup named[31607]: lame server resolving
'173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?):
203.240.193.11#53
Feb 13 06:53:58 backup named[31607]: lame server resolving
'173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?):
203.251.201.1#53
Feb 13 07:00:44 backup sshd(pam_unix)[425]: session closed for user apache
Feb 13 07:39:19 backup sshd(pam_unix)[710]: check pass; user unknown
Feb 13 07:39:19 backup sshd(pam_unix)[710]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131
Feb 13 07:39:23 backup sshd(pam_unix)[713]: check pass; user unknown
Feb 13 07:39:23 backup sshd(pam_unix)[713]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131
Feb 13 07:39:27 backup sshd(pam_unix)[715]: check pass; user unknown
Feb 13 07:39:27 backup sshd(pam_unix)[715]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131
Feb 13 07:39:31 backup sshd(pam_unix)[717]: check pass; user unknown
Feb 13 07:39:31 backup sshd(pam_unix)[717]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131
Feb 13 07:39:34 backup sshd(pam_unix)[720]: check pass; user unknown
Feb 13 07:39:34 backup sshd(pam_unix)[720]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131
Feb 13 07:39:38 backup sshd(pam_unix)[722]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 user=root
Feb 13 07:39:42 backup sshd(pam_unix)[724]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 user=root
Feb 13 07:39:46 backup sshd(pam_unix)[726]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=211.184.142.131 user=root
One failed attempt, one successful attempt and a logout 24 minutes later.
scottb
Tomas Mraz wrote:
On Mon, 2005-02-14 at 10:57 -0800, Scott Becker wrote:
>
>
What does 'getent shadow apache' gives you if you call it from root
account?
If it's something like:
apache:!!:xxxxx::::::
^^ note these. If the exclamation marks are missing it means that
this account is without a password and nullok allows to login to it. But
if the !! (or *) is there it means something is broken on your system if
it allowed login to that account. Can you find the messages from
the /var/log/ surrounding the 'apache logged in from
dsl-82-199-133-138.dutchdsl.nl (82.199.133.138)' message?
3:51 a.m.
On Tue, 2005-02-15 at 14:11 -0800, Scott Becker wrote:
I've already set a proper password but on a twin testing machine
the !!s
are there, before and after running my setup commands to change the
shell. Here's the top of message with the login and logout lines:
Feb 13 06:36:09 backup sshd(pam_unix)[422]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser=
rhost=dsl-82-199-133-138.dutchdsl.nl user=apache
Feb 13 06:36:17 backup sshd(pam_unix)[425]: session opened for user
apache by (uid=48)
Feb 13 06:53:58 backup named[31607]: lame server resolving
'173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?):
203.240.193.11#53
Feb 13 06:53:58 backup named[31607]: lame server resolving
'173.4.248.61.in-addr.arpa' (in '4.248.61.in-addr.arpa'?):
203.251.201.1#53
Feb 13 07:00:44 backup sshd(pam_unix)[425]: session closed for user apache
The problem is that I don't see how anyone could login using ssh to
account with !! in /etc/shadow. I have to suppose that there were
nothing instead of !! and then the login could succeed - the attacker
would first try no password which wouldn't be allowed if
PermitEmptyPassword is set to 'no' in /etc/ssh/sshd_config and then he
would try any password and he would be allowed in. What versions of pam
and openssh do you have?
--
Tomas Mraz <tmraz(a)redhat.com>
7:37 a.m.
<snip>
The problem is that I don't see how anyone could login using ssh
to
account with !! in /etc/shadow. I have to suppose that there were
three words, ssh
pubkey authentication.
<snip>
--
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
8:04 a.m.
On Wed, 2005-02-16 at 08:37 -0500, Richard June wrote:
<snip>
> The problem is that I don't see how anyone could login using ssh to
> account with !! in /etc/shadow. I have to suppose that there were
three words, ssh pubkey authentication.
This doesn't apply as the attacker
would have to have the ssh private
key of a public key which would have to be installed in the
~apache/.ssh/authorized_keys what I don't suppose.
However I've been mistaken with the /etc/shadow - the real thing is in
the /etc/passwd line - if the second field is empty (no 'x' there) that
means the password is empty and sshd would allow logging in.
--
Tomas Mraz <tmraz(a)redhat.com>
8:28 a.m.
On Wednesday 16 February 2005 09:04, Tomas Mraz wrote:
On Wed, 2005-02-16 at 08:37 -0500, Richard June wrote:
> <snip>
>
> > The problem is that I don't see how anyone could login using ssh to
> > account with !! in /etc/shadow. I have to suppose that there were
>
> three words, ssh pubkey authentication.
This doesn't apply as the attacker would have to have the ssh private
key of a public key which would have to be installed in the
~apache/.ssh/authorized_keys what I don't suppose.
However I've been mistaken with the /etc/shadow - the real thing is in
the /etc/passwd line - if the second field is empty (no 'x' there) that
means the password is empty and sshd would allow logging in.
Default config is for
ssh to not allow emtpy passwords to login *AND* to put
either x or !! into the passwd field in /etc/passwd.
Thus for sshd to allow sombody to log in like that, the user (or the attacker
through some other means) would have to edit /etc/passwd, and enable empty
passwords in sshd_config, and restart ssh(though if you have the first two
done, the last should be simple)
and in the event of users such as apache, you have to change the shell
from /bin/false to /bin/bash or something.
--
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
7024
days inactive
7026
days old
11 comments
7 participants
participants (7)
-
Bruno Wolff III -
Luciano Miguel Ferreira Rocha -
Matthew Miller -
Ralf Ertzinger -
Richard June -
Scott Becker -
Tomas Mraz