Re: chroot environment for ssh...
On Sat, 15 Mar 2003 20:24:04 +0100 Arnaud Fontaine <[EMAIL PROTECTED]> wrote: > Hello everybody, > > I have installed a chroot environment on my web server under a Debian Woody in > /var/services/chroot/sshs. > > /etc/passwd : > sshd:x:100:65534::/var/run/sshd:/bin/false > me:x:101:100:onlyatest:/home/arnaud/./:/bin/bash > debug1: Found key in /root/.ssh/known_hosts:2 Maybe you need a line for root in /etc/passwd ? Do you have something in /var/log/auth.log ? Or do you try to connect as [EMAIL PROTECTED] ? Try running makejail with this option: testCommandsOutsideJail=["ssh [EMAIL PROTECTED]"] so it can detect files specifically accessed when this user tries to connect. > I want to know if i could use the same directory for chroot environment for > apache and ssh ? By example i use chroot for directory /var/services/chroot > and > i put ssh and apache in this directory. The point of chroot is to isolate a service so if you don't have any reason to do it you should avoid putting two different services in the same chroot environment so they can't interfere. Or do you mean two different directories under /var/services/chroot ? No problem, but whatever the directories are it's better to have a partition for each service. Alain
Re: expiring passwords
On Sat, 15 Mar 2003 at 06:26:31PM +0100, martin f krafft wrote: > it), and will have to write a custom notification script that parses > /ec/shadow? No need to parse /etc/shadow. Just parse the output of passwd -S. I wrote a perl script that utilized process pipes to get output from passwd -S and send input to exim (to send the user an email). People don't usually log into the system I run either. I replaced the login shell with a carefully audited/environment sanitized perl script that (at the moment) allows them to change their password or log out. If you would like any of these resources, let me know via off-list email. -- Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import -- Excuse #133: Root rot pgprK8FLtGqqN.pgp Description: PGP signature
Re: chroot environment for ssh...
On Sat, 15 Mar 2003 20:24:04 +0100 Arnaud Fontaine <[EMAIL PROTECTED]> wrote: > Hello everybody, > > I have installed a chroot environment on my web server under a Debian Woody in > /var/services/chroot/sshs. > > /etc/passwd : > sshd:x:100:65534::/var/run/sshd:/bin/false > me:x:101:100:onlyatest:/home/arnaud/./:/bin/bash > debug1: Found key in /root/.ssh/known_hosts:2 Maybe you need a line for root in /etc/passwd ? Do you have something in /var/log/auth.log ? Or do you try to connect as [EMAIL PROTECTED] ? Try running makejail with this option: testCommandsOutsideJail=["ssh [EMAIL PROTECTED]"] so it can detect files specifically accessed when this user tries to connect. > I want to know if i could use the same directory for chroot environment for > apache and ssh ? By example i use chroot for directory /var/services/chroot and > i put ssh and apache in this directory. The point of chroot is to isolate a service so if you don't have any reason to do it you should avoid putting two different services in the same chroot environment so they can't interfere. Or do you mean two different directories under /var/services/chroot ? No problem, but whatever the directories are it's better to have a partition for each service. Alain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: expiring passwords
On Sat, 15 Mar 2003 at 06:26:31PM +0100, martin f krafft wrote: > it), and will have to write a custom notification script that parses > /ec/shadow? No need to parse /etc/shadow. Just parse the output of passwd -S. I wrote a perl script that utilized process pipes to get output from passwd -S and send input to exim (to send the user an email). People don't usually log into the system I run either. I replaced the login shell with a carefully audited/environment sanitized perl script that (at the moment) allows them to change their password or log out. If you would like any of these resources, let me know via off-list email. -- Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import -- Excuse #133: Root rot pgp0.pgp Description: PGP signature
chroot environment for ssh...
Hello everybody, I have installed a chroot environment on my web server under a Debian Woody in /var/services/chroot/sshs. I have follow this documentation : http://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-ssh-env.en.html I have used the makejail method to do this. Ssh inside the jail work correctly but i have a problem with authentification. But i can start ssh without any problem. So i have put here my /etc/passwd, /etc/group and/etc/pam.d/ssh files here: /etc/passwd : sshd:x:100:65534::/var/run/sshd:/bin/false me:x:101:100:onlyatest:/home/arnaud/./:/bin/bash /etc/group : root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: mail:x:8: news:x:9: uucp:x:10: kmem:x:15: sudo:x:27: audio:x:29: www-data:x:33: backup:x:34: operator:x:37: list:x:38: src:x:40: gnats:x:41: shadow:x:42: utmp:x:43: staff:x:50: users:x:100: nogroup:x:65534: wheel:x:101:me /etc/pam.d/ssh : auth required pam_nologin.so auth required pam_unix.so auth required pam_env.so auth required pam_listfile.so accountrequired pam_unix.so sessionrequired pam_unix.so sessionoptional pam_lastlog.so sessionoptional pam_motd.so sessionoptional pam_mail.so standard noenv sessionrequired pam_limits.so password required pam_unix.so I have also installed the ssh debian package patch for chroot that i have found here: http://debian.home-dn.net/woody/ssh/ssh_3.4p1-1+chroot3.5p1_i386.deb I have join to this mail a log when i have wanted to login on an other computer with debian too. I want to know if i could use the same directory for chroot environment for apache and ssh ? By example i use chroot for directory /var/services/chroot and i put ssh and apache in this directory. Thanks for you help Arnaud Fontaine --- * fingerprint of my gnupg key : 1F88 8886 A466 EF50 0F29 CC13 E045 70B2 5306 691E * you can find my gnupg public at this address : http://www.andesi.org/gpg/[EMAIL PROTECTED] chroot-ssh.log Description: Binary data pgp2z20AqOZzd.pgp Description: PGP signature
chroot environment for ssh...
Hello everybody, I have installed a chroot environment on my web server under a Debian Woody in /var/services/chroot/sshs. I have follow this documentation : http://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-ssh-env.en.html I have used the makejail method to do this. Ssh inside the jail work correctly but i have a problem with authentification. But i can start ssh without any problem. So i have put here my /etc/passwd, /etc/group and/etc/pam.d/ssh files here: /etc/passwd : sshd:x:100:65534::/var/run/sshd:/bin/false me:x:101:100:onlyatest:/home/arnaud/./:/bin/bash /etc/group : root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: mail:x:8: news:x:9: uucp:x:10: kmem:x:15: sudo:x:27: audio:x:29: www-data:x:33: backup:x:34: operator:x:37: list:x:38: src:x:40: gnats:x:41: shadow:x:42: utmp:x:43: staff:x:50: users:x:100: nogroup:x:65534: wheel:x:101:me /etc/pam.d/ssh : auth required pam_nologin.so auth required pam_unix.so auth required pam_env.so auth required pam_listfile.so accountrequired pam_unix.so sessionrequired pam_unix.so sessionoptional pam_lastlog.so sessionoptional pam_motd.so sessionoptional pam_mail.so standard noenv sessionrequired pam_limits.so password required pam_unix.so I have also installed the ssh debian package patch for chroot that i have found here: http://debian.home-dn.net/woody/ssh/ssh_3.4p1-1+chroot3.5p1_i386.deb I have join to this mail a log when i have wanted to login on an other computer with debian too. I want to know if i could use the same directory for chroot environment for apache and ssh ? By example i use chroot for directory /var/services/chroot and i put ssh and apache in this directory. Thanks for you help Arnaud Fontaine --- * fingerprint of my gnupg key : 1F88 8886 A466 EF50 0F29 CC13 E045 70B2 5306 691E * you can find my gnupg public at this address : http://www.andesi.org/gpg/[EMAIL PROTECTED] chroot-ssh.log Description: Binary data pgp0.pgp Description: PGP signature
expiring passwords
I am looking for ways to expire the passwords on my systems. However, since there are many users that use the systems without logging in to the shell, the shadow aging mechanism won't cut it. Apart from that, it's quite crap anyway. I already have a means to change the password through a web interface, so now what I need is a better aging mechanism and a notification mechanism. I would like to be able to have users change the password every 90 days, but not before the password is 7 days old. Moreover, the current password cannot be the same as the previous xx ones (13 would be appropriate here). Two weeks before the password expires, the users is supposed to start geting a daily mail reminding her of that fact. Is this all possible, or am I stuck with the shadow aging mechanism (which lies about the -I option to chage, or I didn't understand it), and will have to write a custom notification script that parses /ec/shadow? Thanks, -- 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 Keyserver problems? http://keyserver.kjsl.com/~jharris/keyserver.html Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc pgp3pLfe2aVzQ.pgp Description: PGP signature
expiring passwords
I am looking for ways to expire the passwords on my systems. However, since there are many users that use the systems without logging in to the shell, the shadow aging mechanism won't cut it. Apart from that, it's quite crap anyway. I already have a means to change the password through a web interface, so now what I need is a better aging mechanism and a notification mechanism. I would like to be able to have users change the password every 90 days, but not before the password is 7 days old. Moreover, the current password cannot be the same as the previous xx ones (13 would be appropriate here). Two weeks before the password expires, the users is supposed to start geting a daily mail reminding her of that fact. Is this all possible, or am I stuck with the shadow aging mechanism (which lies about the -I option to chage, or I didn't understand it), and will have to write a custom notification script that parses /ec/shadow? Thanks, -- 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 Keyserver problems? http://keyserver.kjsl.com/~jharris/keyserver.html Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc pgp0.pgp Description: PGP signature
Review (2): sect. 4.16.2 of the Securing Debian manual
Thanks to comments from Alexander Reelsen, Adam Endrodi and Peter Cordes,
I made some more changes to the section on the ext2fs attributes. As Adam
pointed out, the term "extended attributes" seems to refer to ACLs (which
are also missing from the manual), so I renamed the section "ext2fs
specific attributes". I also removed the paragraph that was suggesting a
"security by obscurity" method -- even with the caveats, it wasn't a good
idea to put that here (it still says something about the method, but only
because it was mentioned in previous versions of the manual, and just to
mention that it is a very bad idea).
Also, I've been happy to see that what I wrote seems more or less
technically sound, but the people who read the text and commented on it
needed some more explanations -- this makes me think that there is still
plenty of room for improvment in my writing style :-( again, any comment
welcome !
I kept some of the comments for the future section on capabilities, thanks
to those who made them.
Here is the new version, just in case someone wants to have another look.
Frédéric
The ext2 filesystem specific attributes (chattr/lsattr)
In addition to the usual Unix permissions, the ext2 and ext3
filesystems offer a set of specific attributes that give you more control
over the files on your system. Unlike the basic permissions, these
attributes are not displayed by the usual ls -l command or
changed using chmod, and you need two other utilities,
lsattr and chattr (in package
e2fsprogs) to manage them. Note that this means that
these attributes will usually not be saved when you backup your system, so
if you change any of them, it may be worth saving the successive
chattr commands in a script so that you can set them again
later if you have to restore a backup.
Among all available attributes, the two that are most important for
increasing security are referenced by the letters 'i' and 'a', and they
can only be set (or removed) by the superuser:
The 'i' attribute ('immutable'): a file with this attribute can
neither be modified nor deleted or renamed and no link can be created
to it, even by the superuser.
The 'a' attribute ('append'): this attribute has the same effect
that the immutable attribute, except that you can still open the file in
append mode. This means that you can still add more content to it but it
is impossible to modify previous content. This attribute is especially
useful for the log files stored in /var/log/, though you
should consider that they get moved sometimes due to the log rotation
scripts.
These attributes can also be set for directories, in which case everyone
is denied the right to modify the contents of a directory list (eg. rename
or remove a file, ...). When applied to a directory, the append attribute
only allows file creation.
It is easy to see how the 'a' attribute improves security, by giving
to programs that are not running as the superuser the ability to add
data to a file without modifying its previous content. On the other
hand, the 'i' attribute seems less interesting: after all, the
superuser can already use the basic Unix permissions to restrict
access to a file, and an intruder that would get access to the
superuser account could always use the chattr program to
remove the attribute. Such an intruder may first be confused when he
sees that he is not able to remove a file, but you should not assume
that he is blind - after all, he got into your system ! Some manuals
(including a previous version of this document) suggest to simply
remove the chattr and lsattr programs from
the system to increase security, but this kind of strategy, also known as
"security by obscurity", is to be absolutely avoided, since it
provides a false sense of security.
A secure way to solve this problem is to use the capabilities of the Linux
kernel, as described in . The capability of
interest here is called CAP_LINUX_IMMUTABLE: if you remove it
from the capabilities bounding set (using for example the command
lcap CAP_LINUX_IMMUTABLE) it won't be possible to change any
'a' or 'i' attribute on your system anymore, even by the superuser ! A
complete strategy could be as follows:
Set the attributes 'a' and 'i' on any file you want;
Add the command lcap CAP_LINUX_IMMUTABLE (as well as
lcap CAP_SYS_MODULE, as suggested in )
to one of the startup scripts;
Set the 'i' attribute on this script and other startup files, as
well as on the lcap binary itself;
Execute the above command manually (or reboot your system to
make sure everything works as planned).
Now that the capability has been removed from the system, an intruder
can not change any attribute on the protected files, and thus can not
change or remove the files. If he forces the machine to reboot (which is
the only way to restore the capabilities bounding set), it will easily be
detected, and the capability will be removed again as soon as the system
restarts anyway. The
Re: Traffic monitoring
Am Saturday 15 March 2003 00:15 schrieb Stefan Neufeind: > You might want to try out the packat "iptraf" and monitor the > interface ipsec0. It gives you various overwiews on traffic going > over each port in / out as well as other statistics. Only drawback: > It only counts as long as you leave it running on console. [...] Hi, iptraf runs also in the background, try the "-B" option. Regards, Marcus
Review (2): sect. 4.16.2 of the Securing Debian manual
Thanks to comments from Alexander Reelsen, Adam Endrodi and Peter Cordes,
I made some more changes to the section on the ext2fs attributes. As Adam
pointed out, the term "extended attributes" seems to refer to ACLs (which
are also missing from the manual), so I renamed the section "ext2fs
specific attributes". I also removed the paragraph that was suggesting a
"security by obscurity" method -- even with the caveats, it wasn't a good
idea to put that here (it still says something about the method, but only
because it was mentioned in previous versions of the manual, and just to
mention that it is a very bad idea).
Also, I've been happy to see that what I wrote seems more or less
technically sound, but the people who read the text and commented on it
needed some more explanations -- this makes me think that there is still
plenty of room for improvment in my writing style :-( again, any comment
welcome !
I kept some of the comments for the future section on capabilities, thanks
to those who made them.
Here is the new version, just in case someone wants to have another look.
Frédéric
The ext2 filesystem specific attributes (chattr/lsattr)
In addition to the usual Unix permissions, the ext2 and ext3
filesystems offer a set of specific attributes that give you more control
over the files on your system. Unlike the basic permissions, these
attributes are not displayed by the usual ls -l command or
changed using chmod, and you need two other utilities,
lsattr and chattr (in package
e2fsprogs) to manage them. Note that this means that
these attributes will usually not be saved when you backup your system, so
if you change any of them, it may be worth saving the successive
chattr commands in a script so that you can set them again
later if you have to restore a backup.
Among all available attributes, the two that are most important for
increasing security are referenced by the letters 'i' and 'a', and they
can only be set (or removed) by the superuser:
The 'i' attribute ('immutable'): a file with this attribute can
neither be modified nor deleted or renamed and no link can be created
to it, even by the superuser.
The 'a' attribute ('append'): this attribute has the same effect
that the immutable attribute, except that you can still open the file in
append mode. This means that you can still add more content to it but it
is impossible to modify previous content. This attribute is especially
useful for the log files stored in /var/log/, though you
should consider that they get moved sometimes due to the log rotation
scripts.
These attributes can also be set for directories, in which case everyone
is denied the right to modify the contents of a directory list (eg. rename
or remove a file, ...). When applied to a directory, the append attribute
only allows file creation.
It is easy to see how the 'a' attribute improves security, by giving
to programs that are not running as the superuser the ability to add
data to a file without modifying its previous content. On the other
hand, the 'i' attribute seems less interesting: after all, the
superuser can already use the basic Unix permissions to restrict
access to a file, and an intruder that would get access to the
superuser account could always use the chattr program to
remove the attribute. Such an intruder may first be confused when he
sees that he is not able to remove a file, but you should not assume
that he is blind - after all, he got into your system ! Some manuals
(including a previous version of this document) suggest to simply
remove the chattr and lsattr programs from
the system to increase security, but this kind of strategy, also known as
"security by obscurity", is to be absolutely avoided, since it
provides a false sense of security.
A secure way to solve this problem is to use the capabilities of the Linux
kernel, as described in . The capability of
interest here is called CAP_LINUX_IMMUTABLE: if you remove it
from the capabilities bounding set (using for example the command
lcap CAP_LINUX_IMMUTABLE) it won't be possible to change any
'a' or 'i' attribute on your system anymore, even by the superuser ! A
complete strategy could be as follows:
Set the attributes 'a' and 'i' on any file you want;
Add the command lcap CAP_LINUX_IMMUTABLE (as well as
lcap CAP_SYS_MODULE, as suggested in )
to one of the startup scripts;
Set the 'i' attribute on this script and other startup files, as
well as on the lcap binary itself;
Execute the above command manually (or reboot your system to
make sure everything works as planned).
Now that the capability has been removed from the system, an intruder
can not change any attribute on the protected files, and thus can not
change or remove the files. If he forces the machine to reboot (which is
the only way to restore the capabilities bounding set), it will easily be
detected, and the capability will be removed again as soon as the system
restarts anyway. The
Re: Traffic monitoring
Am Saturday 15 March 2003 00:15 schrieb Stefan Neufeind: > You might want to try out the packat "iptraf" and monitor the > interface ipsec0. It gives you various overwiews on traffic going > over each port in / out as well as other statistics. Only drawback: > It only counts as long as you leave it running on console. [...] Hi, iptraf runs also in the background, try the "-B" option. Regards, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
