Re: shared root account
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha Jäykkä wrote: Make multiple root-accounts. We for example have normal users accounts and 3-5 root-accounts depending on machine. Just give UID/GID to new user. I have a bit of a situation: I have a handful of linux machines (almost all with different distributions and kernels and software - one hell to keep secure) and all the machines have different roots. These guys want to keep their root passwords (or at least the root privileges) so they can update their X/KDE/whatever when/if they feel like it but on the other hand, they would like to see someone (me) keep their machines secure - something they themselves do not have time (we all know keeping up security is a fulltime job). Obviously to install patches etc I, also, need root privileges. This poses a problem if I am not to remember all those different root passwords and without making all the passwords the same! How can that _safely_ be accomplished? There are versions of su, sudo etc) that do not ask passwords, there are suid binaries but which is _THE_ way of accomplishing this? Presently there are only shared root passwords between the server admins but now we are trying to get the workstation security boosted up as well - being behind one firewall does not seem to be enough in an environment where a whole class B network is behind that one fw... -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- ytti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 12:25:20PM +0300, Saku Ytti wrote: On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha Jäykkä wrote: Make multiple root-accounts. We for example have normal users accounts and 3-5 root-accounts depending on machine. Just give UID/GID to new user. Insert 0 where appropriate :) -- ytti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha J?ykk? wrote: I have a bit of a situation: I have a handful of linux machines (almost all with different distributions and kernels and software - .. time (we all know keeping up security is a fulltime job). Obviously to install patches etc I, also, need root privileges. This poses a problem if I am not to remember all those different root passwords and without making all the passwords the same! How can that _safely_ be accomplished? There are versions of su, sudo etc) that do not ask passwords, there are suid binaries but which is _THE_ way You could also use SSH to accomplish this. Set it up so you log in with RSA/DSA key's (and no passwords) and authenticate with your key's passphrase. You will become root on the machine, and you'll be able to use your own passphrase, as will the other 'root's on the machine, each his own keypair and passphrase (Put the public key in the .authorized_keys file for the root user) TUrn on RSA/DSA authentication and 'allow root login' Mark Janssen Unix Consultant @ SyConOS IT E-mail: [EMAIL PROTECTED] GnuPG Key Id: 357D2178 http: maniac.nl, unix-god.[net|org], markjanssen.[com|net|org|nl] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 11:35:16AM +0200, Mark Janssen wrote: (Put the public key in the .authorized_keys file for the root user) TUrn on RSA/DSA authentication and 'allow root login' One word of warning aboce would allow logging in using root password as well which might not be the best sollution. Using without-password gives You somewhat more control over who can log on remotely using ssh (public ssh key needs to be present in ~root/.ssh/authorized_keys to log in) Way proposed by Mark is of course not bad it's just a matter of Security Policy and personal taste =o) -- Robert Ramiega | [EMAIL PROTECTED] IRC: _Jedi_ | Do not underestimate UIN: 13201047 | http://www.plukwa.net/ | the power of Source -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 01:19:24PM +0300, Juha Jykk wrote: I distrust allowing root logins from anywhere but local console(s) or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. umm do You want to run in circles from one machine to another? ;o)) if not than You need to remotely logon somehow, right? i think that ssh'ing into the machine and than than su'ing to root is no different than ssh'ing directly as root into that machine... (well when You do a su You leave a trace in logs of that fact, while You are directly ssh'ing into there is no info in logs on who actually logged on as root; there is some patch to at least partialy fix the latter and it was mentioned on debian-devel i think) -- Robert Ramiega | [EMAIL PROTECTED] IRC: _Jedi_ | Do not underestimate UIN: 13201047 | http://www.plukwa.net/ | the power of Source -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
Am Freitag, 6. Juli 2001 12:19 schrieb Juha Jäykkä: (Put the public key in the .authorized_keys file for the root user) TUrn on RSA/DSA authentication and 'allow root login' One word of warning aboce would allow logging in using root password as well I distrust allowing root logins from anywhere but local console(s) or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. Any other ideas? Or is it really safe to allow root logins to sshd? As already stated by someone else in this thread: Just create another user (say, root1) with UID==0 and GID==0. No need for direct root logins over the net. Although it should be much more secure when using SSH compared to say, telnet I would feel uncomfortable, because direct root login usually means, that you do not know WHO actually got root when he logs on. SSH to normal user, and the su - root1 at least tells you in the logs which user account opened the root session... I like to know what's going on on my systems. It is just an old rule of thumb that root must never log on over the wire but that may be old news from times of telnet - never had any need of root logins over the wire until perhaps now. -- Patrick Dreker - Is there anything else I can contribute? The latitude and longtitude of the bios writers current position, and a ballistic missile. Alan Cox on [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
Just a friendly Jedi Knight wrote: On Fri, Jul 06, 2001 at 01:19:24PM +0300, Juha Jykk wrote: I distrust allowing root logins from anywhere but local console(s) or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. umm do You want to run in circles from one machine to another? ;o)) if not than You need to remotely logon somehow, right? i think that ssh'ing into the machine and than than su'ing to root is no different than ssh'ing directly as root into that machine... (well when You do a su You leave a trace in logs of that fact, while You are directly ssh'ing into there is no info in logs on who actually logged on as root; there is some patch to at least partialy fix the latter and it was mentioned on debian-devel i think) Disable every direct root login altogether (suppress root's password) and add anyone who needs root access to your /etc/sudoers file (if necessary, apt-get install sudo, of course). Need a root shell? sudo bash, and you're using only your own password ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
At 994443564s since epoch (07/06/01 06:19:24 -0400 UTC), Juha J?ykk? wrote: I distrust allowing root logins from anywhere but local console(s) or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. Any other ideas? Or is it really safe to allow root logins to sshd? It is just an old rule of thumb that root must never log on over the wire but that may be old news from times of telnet - never had any need of root logins over the wire until perhaps now. I agree with others here: use sudo. Even on my own box I use sudo, rather than using my root password. I worked at a company where all the employees had their own linux box. We gave them sudo on their own machines, but only the IT staff had root on the boxes. This way, the staff could do updates (they set up an admin account with sudo), and the users could fudge their own configs, but nobody needed actual 'root' to do anything. I do not recommend the UID=0 trick. Too many ways to make typos and hose your passwd file. Also, sudo leaves a nice audit trail, and has many more features that you may find handy in the future (such as the ability to restrict commands run as root, times of day, types of passwords accepted to run root commands, etc). Finally, if you're doing a lot of work and don't want to have to keep typing sudo in front of everything, try: sudo -s To get a root shell. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On 06-Jul-01, 05:34 (CDT), Patrice Neff [EMAIL PROTECTED] wrote: What you want to accomplish might be possible with sudo. Install sudo and thenn add the following line to the configuration file. (/etc/sudoers on my machine) yourusername ALL=(ALL) ALL this will allow you to execute any command you want with sudo command but you still don't have to know the root password. The password you're providing when executing sudo is yours. Let me add another vote for using sudo. Additional advantages are that one can limit what the sudoer can do, and that it logs (or can be set to log) all issued commands. (Except that if you allow 'sudo bash' or some variation, it won't log the session, just that bash started, of course.). But at least you'll have some audit trail. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Attack alert from snort
I got the following from snort : Active System Attack Alerts =-=-=-=-=-=-=-=-=-=-=-=-=-= Jul 6 07:48:19 canopus snort[3884]: spp_http_decode: IIS Unicode attack detected: 128.95.75.153:1647 - 208.52.11.121:80 Active System Attack Alerts =-=-=-=-=-=-=-=-=-=-=-=-=-= Jul 6 05:36:39 canopus snort[526]: spp_http_decode: IIS Unicode attack detected: 204.253.198.48:61383 - 216.136.172.167:80 The bottom one particularly worries me as that seems to come from my system. Should I worry? If so how do I go about getting out of trouble? Thanks Best regards, Philippe Clérié (philippe[at]gcal.net) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
Hello, I am a new debian user and someone still learning linux. I have a small problem. In my company ( which is a microsoft developer ) I insisted on using a firewall created with Ipchains of 3 zones ( dmz - local - internet ) on a Intel Pentium Pro processor machine running Debian 2.2r3 on it ( base system + mc + tcpdump + nano ) instead of Microshit's ISA Server. Strangely enough one of the interfaces ( the internet interface ) completely at arbitrary times start sending packets to itself. Packet proto=1 sourceip:3 rd port to sourceip:1 st port s=0xc0 f=0x t=255 log says. As far as I understand from this log the packet sent is an ICMP packet from port 3 to tcpmux port ( icmp's have ports ? knew they did not ) of size 13 hexadecimals not fragmented and time to live is 255. But this is not possible. 1st no one can use this machine as a terminal and no one can telnet to it's interfaces. 2nd rp_filter is set to 1 for all interfaces ( in case of a spoof attack ) . Can anyone help me about that ? I am sure there is something I do not know but what is it ? Thanx John. Note : If I succeed on this debian firewall the ftp server will also be Linux and web server as well . _ Get your free e-mail account: http://www.petekmail.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
Juha Jäykkä [EMAIL PROTECTED] writes: Any other ideas? Or is it really safe to allow root logins to sshd? It is just an old rule of thumb that root must never log on over the wire but that may be old news from times of telnet - never had any need of root logins over the wire until perhaps now. The traditional reason for disallowing root logins has nothing to do with security; the reason is to give (maybe) more accountability because a real user id is logged along with the actions that root does. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 03:24:56PM -0800, Ethan Benson wrote: On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote: OTOH if you restrict the user to a list of commands in /etc/sudoers, it's wise to consider whether the user might be able to leverage one of those commands to edit /etc/sudoers (or any other file). If you're going to list emacs or vi in /etc/sudoers, you might as well just list ALL :) or even seemingly innocuous things like less or even cat. sudo less anything !/bin/sh whoami r00t! echo me ALL=ALL s sudo 'cat s /etc/sudoers' IOW, it's safe to say that allowing access to a shell via sudo means you trust that user as root. sudo is a very large cannon which is difficult to keep aimed away from the foot... Depends on how you use it. At my last job, we used sudo for two reasons: 1) I didn't have to inform all the admins whenever the root password changed. 2) techs had a script which ran as root under sudo for creating user accounts, etc. The script was written in perl ... I'm sure there was something wrong with it but it worked well for us and kept techs in the box where they did the least damage. Cheers, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton PGP signature
Re: shared root account
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: [cut] I would be very shocked if you could compromise a system with a sudoers entry of: me hostname = (root) /bin/cat Depends on what's on the system. I've thought of four similar ways. 1: With Kerberos, you can steal someone's ticket-granting ticket and use it until it expires. My example also uses AFS: | test@pentagram:~$ klist | Ticket cache: FILE:/tmp/krb5cc_q5bOCp | Default principal: [EMAIL PROTECTED] | | Valid starting ExpiresService principal | 07/06/01 22:29:11 07/07/01 08:29:11 [EMAIL PROTECTED] | 07/06/01 22:29:11 07/07/01 08:29:11 [EMAIL PROTECTED] | 07/06/01 22:29:11 07/07/01 08:29:11 [EMAIL PROTECTED] | | | Kerberos 4 ticket cache: /tmp/tkt1001 | klist: You have no tickets cached | test@pentagram:~$ cd /tmp | test@pentagram:/tmp$ ls -al | total 20 | drwxrwxrwt3 root root 1024 Jul 6 22:29 . | drwxr-xr-x 21 root root 1024 Jun 27 23:41 .. | -rw---1 waokiwaoki 892 Jul 6 01:40 krb5cc_1002 | -rw---1 waokiwaoki 848 Jul 6 22:22 krb5cc_GMJQN9 | -rw---1 test test 885 Jul 6 22:28 krb5cc_SyJR0W | -rw---1 test test 885 Jul 6 22:26 krb5cc_YzLI0R | -rw---1 test test 1243 Jul 6 22:29 krb5cc_q5bOCp | drwxr-xr-x2 root root12288 Nov 14 2000 lost+found | test@pentagram:/tmp$ ls -al /afs/g6net.com/user/waoki/secure | ls: /afs/g6net.com/user/waoki/secure: Permission denied | test@pentagram:/afs/g6net.com/user/waoki$ touch /afs/g6net.com/user/waoki/afile | touch: creating `/afs/g6net.com/user/waoki/afile': Permission denied Nope, can't access someone else's homedir... | test@pentagram:/tmp$ sudo -v | | We trust you have received the usual lecture from the local System | Administrator. It usually boils down to these two things: | | #1) Respect the privacy of others. | #2) Think before you type. | | Password for [EMAIL PROTECTED]: Now we steal a TGT (but we could also go after the keytab)... | test@pentagram:/tmp$ sudo /bin/cat krb5cc_GMJQN9 krb5cc_q5bOCp | test@pentagram:/tmp$ aklog ...and now I'm someone else! | test@pentagram:/tmp$ klist | Ticket cache: FILE:/tmp/krb5cc_q5bOCp | Default principal: [EMAIL PROTECTED] | | Valid starting ExpiresService principal | 07/06/01 22:21:56 07/07/01 08:21:52 [EMAIL PROTECTED] | 07/06/01 22:22:03 07/07/01 08:21:52 [EMAIL PROTECTED] | | | Kerberos 4 ticket cache: /tmp/tkt1001 | klist: You have no tickets cached | | test@pentagram:/tmp$ ls -al /afs/g6net.com/user/waoki/secure | total 4 | drwxr-xr-x2 waokiwaoki2048 Jul 6 01:39 . | drwxr-xr-x5 waokiwaoki2048 Jul 6 22:33 .. | -rw-r--r--1 waokiwaoki 0 Jul 6 01:39 file (As an aside, although the 'secure' directory above is mode 755, it's on AFS, so the Unix mode bits don't apply.) Now let's set up some trojans: | test@pentagram:/tmp$ cp ~/.su.trojan ~/.sudo.trojan ~/.kadmin.trojan |/afs/g6net.com/user/waoki/ | test@pentagram:/tmp$ echo alias su=~/.su.trojan /afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ echo alias /bin/su=~/.su.trojan |/afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ echo alias sudo=~/.sudo.trojan |/afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ echo alias /usr/bin/sudo=~/.sudo.trojan |/afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ echo alias kadmin=~/.kadmin.trojan |/afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ echo alias /usr/sbin/kadmin=~/.kadmin.trojan |/afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ 2: Something similar could be done if someone's ssh identity or id_dsa keys aren't password protected: | [test@tertia test]$ sudo cat /home/waoki/.ssh/id_dsa .ssh/id_dsa | [test@tertia test]$ ssh localhost -l waoki and now I can trojan apps, or (since the default Debian sudo uses one timestamp file per user, instead of one per user per tty) I can wait for the victim to sudo, and then sudo without entering his password. 3 and 4: If the system's running Samba, access to /etc/smbpasswd lets me log in to Samba as anyone who appears in /etc/smbpasswd. If the system is using Netatalk with randnum authentication, users' AppleTalk passwords will be stored in plaintext in ~/.passwd. Once again, I can trojan binaries and scripts. Oh, and catting /proc/kcore could yield interesting information. -- William Aoki[EMAIL PROTECTED] (801)-(58)5-1924 UMNH Computer Support Room 001, GTB (801)-(58)1-6928 1390 E President's Circle Salt Lake City, Utah84112-0050 Key 199D8C7B Fingerprint 3B0A 6800 8A1A 78A7 9A26 BB92 6329 2D3E 199D 8C7B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
shared root account
I have a bit of a situation: I have a handful of linux machines (almost all with different distributions and kernels and software - one hell to keep secure) and all the machines have different roots. These guys want to keep their root passwords (or at least the root privileges) so they can update their X/KDE/whatever when/if they feel like it but on the other hand, they would like to see someone (me) keep their machines secure - something they themselves do not have time (we all know keeping up security is a fulltime job). Obviously to install patches etc I, also, need root privileges. This poses a problem if I am not to remember all those different root passwords and without making all the passwords the same! How can that _safely_ be accomplished? There are versions of su, sudo etc) that do not ask passwords, there are suid binaries but which is _THE_ way of accomplishing this? Presently there are only shared root passwords between the server admins but now we are trying to get the workstation security boosted up as well - being behind one firewall does not seem to be enough in an environment where a whole class B network is behind that one fw... -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: shared root account
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha Jäykkä wrote: Make multiple root-accounts. We for example have normal users accounts and 3-5 root-accounts depending on machine. Just give UID/GID to new user. I have a bit of a situation: I have a handful of linux machines (almost all with different distributions and kernels and software - one hell to keep secure) and all the machines have different roots. These guys want to keep their root passwords (or at least the root privileges) so they can update their X/KDE/whatever when/if they feel like it but on the other hand, they would like to see someone (me) keep their machines secure - something they themselves do not have time (we all know keeping up security is a fulltime job). Obviously to install patches etc I, also, need root privileges. This poses a problem if I am not to remember all those different root passwords and without making all the passwords the same! How can that _safely_ be accomplished? There are versions of su, sudo etc) that do not ask passwords, there are suid binaries but which is _THE_ way of accomplishing this? Presently there are only shared root passwords between the server admins but now we are trying to get the workstation security boosted up as well - being behind one firewall does not seem to be enough in an environment where a whole class B network is behind that one fw... -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- ytti
Re: shared root account
On Fri, Jul 06, 2001 at 12:25:20PM +0300, Saku Ytti wrote: On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha Jäykkä wrote: Make multiple root-accounts. We for example have normal users accounts and 3-5 root-accounts depending on machine. Just give UID/GID to new user. Insert 0 where appropriate :) -- ytti
Re: shared root account
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha J?ykk? wrote: I have a bit of a situation: I have a handful of linux machines (almost all with different distributions and kernels and software - .. time (we all know keeping up security is a fulltime job). Obviously to install patches etc I, also, need root privileges. This poses a problem if I am not to remember all those different root passwords and without making all the passwords the same! How can that _safely_ be accomplished? There are versions of su, sudo etc) that do not ask passwords, there are suid binaries but which is _THE_ way You could also use SSH to accomplish this. Set it up so you log in with RSA/DSA key's (and no passwords) and authenticate with your key's passphrase. You will become root on the machine, and you'll be able to use your own passphrase, as will the other 'root's on the machine, each his own keypair and passphrase (Put the public key in the .authorized_keys file for the root user) TUrn on RSA/DSA authentication and 'allow root login' Mark Janssen Unix Consultant @ SyConOS IT E-mail: [EMAIL PROTECTED] GnuPG Key Id: 357D2178 http: maniac.nl, unix-god.[net|org], markjanssen.[com|net|org|nl]
Re: shared root account
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha Jäykkä wrote: I have a bit of a situation: I have a handful of linux machines (almost all with different distributions and kernels and software - one hell to keep secure) and all the machines have different roots. These guys want to keep their root passwords (or at least the root privileges) so they can update their X/KDE/whatever when/if they feel like it but on the other hand, they would like to see someone (me) keep their machines secure - something they themselves do not have time (we all know keeping up security is a fulltime job). Obviously to install patches etc I, also, need root privileges. This poses a problem if I am not to remember all those different root passwords and without making all the passwords the same! How can that _safely_ be accomplished? There are versions of su, sudo etc) that Use SSH and its RSA authentications (preferably with ssh-agent). With OpenSSH You can change /etc/ssh/sshd_config to read: PermitRootLogin without-password (quoting from memory) and put Your RSA public key in ~root/.ssh/authorized_keys This solution works flawlesly in my company (several machines spread all over the country with different people doing day-to-day management) -- Robert Ramiega | [EMAIL PROTECTED] IRC: _Jedi_ | Do not underestimate UIN: 13201047 | http://www.plukwa.net/ | the power of Source
Re: shared root account
On Fri, Jul 06, 2001 at 11:35:16AM +0200, Mark Janssen wrote: (Put the public key in the .authorized_keys file for the root user) TUrn on RSA/DSA authentication and 'allow root login' One word of warning aboce would allow logging in using root password as well which might not be the best sollution. Using without-password gives You somewhat more control over who can log on remotely using ssh (public ssh key needs to be present in ~root/.ssh/authorized_keys to log in) Way proposed by Mark is of course not bad it's just a matter of Security Policy and personal taste =o) -- Robert Ramiega | [EMAIL PROTECTED] IRC: _Jedi_ | Do not underestimate UIN: 13201047 | http://www.plukwa.net/ | the power of Source
Re: shared root account
(Put the public key in the .authorized_keys file for the root user) TUrn on RSA/DSA authentication and 'allow root login' One word of warning aboce would allow logging in using root password as well I distrust allowing root logins from anywhere but local console(s) or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. Any other ideas? Or is it really safe to allow root logins to sshd? It is just an old rule of thumb that root must never log on over the wire but that may be old news from times of telnet - never had any need of root logins over the wire until perhaps now. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: shared root account
On Fri, Jul 06, 2001 at 01:19:24PM +0300, Juha Jäykkä wrote: I distrust allowing root logins from anywhere but local console(s) or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. umm do You want to run in circles from one machine to another? ;o)) if not than You need to remotely logon somehow, right? i think that ssh'ing into the machine and than than su'ing to root is no different than ssh'ing directly as root into that machine... (well when You do a su You leave a trace in logs of that fact, while You are directly ssh'ing into there is no info in logs on who actually logged on as root; there is some patch to at least partialy fix the latter and it was mentioned on debian-devel i think) -- Robert Ramiega | [EMAIL PROTECTED] IRC: _Jedi_ | Do not underestimate UIN: 13201047 | http://www.plukwa.net/ | the power of Source
Re: shared root account
Am Freitag, 6. Juli 2001 12:19 schrieb Juha Jäykkä: (Put the public key in the .authorized_keys file for the root user) TUrn on RSA/DSA authentication and 'allow root login' One word of warning aboce would allow logging in using root password as well I distrust allowing root logins from anywhere but local console(s) or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. Any other ideas? Or is it really safe to allow root logins to sshd? As already stated by someone else in this thread: Just create another user (say, root1) with UID==0 and GID==0. No need for direct root logins over the net. Although it should be much more secure when using SSH compared to say, telnet I would feel uncomfortable, because direct root login usually means, that you do not know WHO actually got root when he logs on. SSH to normal user, and the su - root1 at least tells you in the logs which user account opened the root session... I like to know what's going on on my systems. It is just an old rule of thumb that root must never log on over the wire but that may be old news from times of telnet - never had any need of root logins over the wire until perhaps now. -- Patrick Dreker - Is there anything else I can contribute? The latitude and longtitude of the bios writers current position, and a ballistic missile. Alan Cox on linux-kernel@vger.kernel.org
Re: shared root account
Juha Jäykkä [EMAIL PROTECTED] writes: How can that _safely_ be accomplished? There are versions of su, sudo etc) that do not ask passwords, there are suid binaries but which is _THE_ way of accomplishing this? I've never been in a situation like yours. But I can tell how I do it at home. I think this might be possible for you, too. What you want to accomplish might be possible with sudo. Install sudo and thenn add the following line to the configuration file. (/etc/sudoers on my machine) yourusername ALL=(ALL) ALL this will allow you to execute any command you want with sudo command but you still don't have to know the root password. The password you're providing when executing sudo is yours. Bye, patrice
Re: shared root account
At 994443564s since epoch (07/06/01 06:19:24 -0400 UTC), Juha J?ykk? wrote: I distrust allowing root logins from anywhere but local console(s) or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. Any other ideas? Or is it really safe to allow root logins to sshd? It is just an old rule of thumb that root must never log on over the wire but that may be old news from times of telnet - never had any need of root logins over the wire until perhaps now. I agree with others here: use sudo. Even on my own box I use sudo, rather than using my root password. I worked at a company where all the employees had their own linux box. We gave them sudo on their own machines, but only the IT staff had root on the boxes. This way, the staff could do updates (they set up an admin account with sudo), and the users could fudge their own configs, but nobody needed actual 'root' to do anything. I do not recommend the UID=0 trick. Too many ways to make typos and hose your passwd file. Also, sudo leaves a nice audit trail, and has many more features that you may find handy in the future (such as the ability to restrict commands run as root, times of day, types of passwords accepted to run root commands, etc). Finally, if you're doing a lot of work and don't want to have to keep typing sudo in front of everything, try: sudo -s To get a root shell. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/
Re: shared root account
On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote: types of passwords accepted to run root commands, etc). elaborate. the main reason i don't use sudo except for small things which cannot grant a root shell in any way is for the simple reason the sudo converts a normal unprivleged user password into another root password. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpvZtKZdIlLD.pgp Description: PGP signature
Re: shared root account
admittedly, i am not very familiar with sudo because i have never seen the practical advantages of making su'ing more of a hassle by having to manage another set of conf files and keeping track of who's a sudoer and, therefore, have chosen not to use it. what's to stop a person, once they've sudo'd, from editing /etc/sudoers and giving themselves more privs? kind regards, ~rob on 7/6/01 6:57 AM, Steve Greenland at [EMAIL PROTECTED] wrote: On 06-Jul-01, 05:34 (CDT), Patrice Neff [EMAIL PROTECTED] wrote: What you want to accomplish might be possible with sudo. Install sudo and thenn add the following line to the configuration file. (/etc/sudoers on my machine) yourusername ALL=(ALL) ALL this will allow you to execute any command you want with sudo command but you still don't have to know the root password. The password you're providing when executing sudo is yours. Let me add another vote for using sudo. Additional advantages are that one can limit what the sudoer can do, and that it logs (or can be set to log) all issued commands. (Except that if you allow 'sudo bash' or some variation, it won't log the session, just that bash started, of course.). But at least you'll have some audit trail. Steve
Re: shared root account
On Fri, Jul 06, 2001 at 09:29:54AM -0700, Robert L. Yelvington wrote: admittedly, i am not very familiar with sudo because i have never seen the practical advantages of making su'ing more of a hassle by having to manage another set of conf files and keeping track of who's a sudoer and, therefore, have chosen not to use it. what's to stop a person, once they've sudo'd, from editing /etc/sudoers and giving themselves more privs? [ please avoid jeopardy style quoting ] If sudo already allows a user to run ALL commands as root, what privs could they possibly gain? OTOH if you restrict the user to a list of commands in /etc/sudoers, it's wise to consider whether the user might be able to leverage one of those commands to edit /etc/sudoers (or any other file). If you're going to list emacs or vi in /etc/sudoers, you might as well just list ALL :) -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpI4pZGDfr8C.pgp Description: PGP signature
Attack alert from snort
I got the following from snort : Active System Attack Alerts =-=-=-=-=-=-=-=-=-=-=-=-=-= Jul 6 07:48:19 canopus snort[3884]: spp_http_decode: IIS Unicode attack detected: 128.95.75.153:1647 - 208.52.11.121:80 Active System Attack Alerts =-=-=-=-=-=-=-=-=-=-=-=-=-= Jul 6 05:36:39 canopus snort[526]: spp_http_decode: IIS Unicode attack detected: 204.253.198.48:61383 - 216.136.172.167:80 The bottom one particularly worries me as that seems to come from my system. Should I worry? If so how do I go about getting out of trouble? Thanks Best regards, Philippe Clérié (philippe[at]gcal.net)
Unidentified subject!
Hello, I am a new debian user and someone still learning linux. I have a small problem. In my company ( which is a microsoft developer ) I insisted on using a firewall created with Ipchains of 3 zones ( dmz - local - internet ) on a Intel Pentium Pro processor machine running Debian 2.2r3 on it ( base system + mc + tcpdump + nano ) instead of Microshit's ISA Server. Strangely enough one of the interfaces ( the internet interface ) completely at arbitrary times start sending packets to itself. Packet proto=1 sourceip:3 rd port to sourceip:1 st port s=0xc0 f=0x t=255 log says. As far as I understand from this log the packet sent is an ICMP packet from port 3 to tcpmux port ( icmp's have ports ? knew they did not ) of size 13 hexadecimals not fragmented and time to live is 255. But this is not possible. 1st no one can use this machine as a terminal and no one can telnet to it's interfaces. 2nd rp_filter is set to 1 for all interfaces ( in case of a spoof attack ) . Can anyone help me about that ? I am sure there is something I do not know but what is it ? Thanx John. Note : If I succeed on this debian firewall the ftp server will also be Linux and web server as well . _ Get your free e-mail account: http://www.petekmail.com
Re: shared root account
Juha Jäykkä [EMAIL PROTECTED] writes: Any other ideas? Or is it really safe to allow root logins to sshd? It is just an old rule of thumb that root must never log on over the wire but that may be old news from times of telnet - never had any need of root logins over the wire until perhaps now. The traditional reason for disallowing root logins has nothing to do with security; the reason is to give (maybe) more accountability because a real user id is logged along with the actions that root does.
Re: shared root account
At 994418143s since epoch (07/06/01 10:15:43 -0400 UTC), Ethan Benson wrote: On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote: types of passwords accepted to run root commands, etc). elaborate. the main reason i don't use sudo except for small things which cannot grant a root shell in any way is for the simple reason the sudo converts a normal unprivleged user password into another root password. I'm not a sudo expert, but I do use it and like it. I'll try to answer the questions asked here, but you really should READ THE DOCS before you believe everything I say. To your point (types of passwords), you can configure sudo (I think using PAM) to only work with user passwords, or one-time passwords (OTP), or whatever else PAM will take. This allows you to force sudo users to use passwords other than their standard account passwords. I'm a fan of OTP because when used correctly they're very secure, even over insecure connections (telnet). Other people asked why sudo is better than su. The main reason is audit trail; sudo keeps logs of commands. Additionally, you can grant limited command access to people. Admittedly, most commands can be leveraged to gain full root privs (shells, editors, cat, chmod, and so on), so you need to TRUST people you're giving sudo to. However, sudo is never any more dangerous than plain old su, if you think about it. Also, you don't want root logins to be a normal thing. You want to KNOW if root is logged in on your box. Script kiddies trying to get in will try to get in as root first. If you often log in as root, it's less likely that you'll notice if someone else logs in as root. Also, if you never use root as your login, you can restrict it severely (only allow root logins on the console, for example). Kiddies who break into user accounts pose less of a threat. Sure, one of those user accounts might be sudo-enabled, but to find out for sure, they have to run a command under sudo. If they aren't in the sudoers file, then sudo will log the incident and e-mail it to root. The odds of a script kiddie randomly hacking a sudo-enabled account on a box with hundreds of accounts is very low. Especially because anybody you give sudo to should be extra careful about security. Whew... that was a rant. Anyway, here are my tips for using sudo well. Feel free to add your own: 1) Trust the people you give sudo to (assume they can get root with whatever access you give them) 2) Make sure those people are extra anal about security (secure logins, good passwords, etc) 3) Check your logs religiously 4) Disable root from logging in, except from the console 5) Never log in as root. Use 'sudo -s' to get a shell if you must 6) Clamp down sudo as much as you are comfortable with, but don't drive people nuts. For example, think about using OTP, but don't do it if people are going to hate it so much that they'll undermine the system. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/
Re: shared root account
On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote: OTOH if you restrict the user to a list of commands in /etc/sudoers, it's wise to consider whether the user might be able to leverage one of those commands to edit /etc/sudoers (or any other file). If you're going to list emacs or vi in /etc/sudoers, you might as well just list ALL :) or even seemingly innocuous things like less or even cat. sudo less anything !/bin/sh whoami r00t! echo me ALL=ALL s sudo 'cat s /etc/sudoers' sudo is a very large cannon which is difficult to keep aimed away from the foot... -- Ethan Benson http://www.alaska.net/~erbenson/ pgpZgdNZaFtrL.pgp Description: PGP signature
Re: shared root account
You make a good point, even if one of your examples is flawed:
$ sudo 'cat s /etc/sudoers'
sudo: cat s /etc/sudoers: command not found
sudo is a very useful tool in the type of situation described in this
thread. Even if you give everyone ALL=(ALL) ALL, it's better than su
or even .ssh/authorized_keys{,2} because of one thing in particular:
It's log! It's loog! It's big! It's heavy! It's wood!
Okay, so it's not really big or heavy, nor remotely wood. But it does
give you things like this to peer at later:
Jul 6 17:24:59 gobo sudo: vineet : TTY=pts/1 ; PWD=/tmp/ucspi-tcp ;
USER=root ; COMMAND=/usr/bin/dpkg -i
/home/vineet/ucspi-tcp_0.88-5_i386.deb
Jul 6 17:32:10 gobo sudo: vineet : TTY=pts/2 ; PWD=/etc/init.d ;
USER=root ; COMMAND=/etc/init.d/qmail restart
Which can be very useful. It's not foolproof by any means, and as you
demonstrate, can usually be trivially reduced to su, but it's better
as a *standard* way of doing things on a system on which multiple people
play root. If you can't trust those people, then you're screwed no
matter what tools you use.
Vineet
* Ethan Benson ([EMAIL PROTECTED]) [010706 16:27]:
On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote:
OTOH if you restrict the user to a list of commands in /etc/sudoers,
it's wise to consider whether the user might be able to leverage one of
those commands to edit /etc/sudoers (or any other file). If you're
going to list emacs or vi in /etc/sudoers, you might as well just
list ALL :)
or even seemingly innocuous things like less or even cat.
sudo less anything
!/bin/sh
whoami
r00t!
echo me ALL=ALL s
sudo 'cat s /etc/sudoers'
sudo is a very large cannon which is difficult to keep aimed away from
the foot...
--
Ethan Benson
http://www.alaska.net/~erbenson/
pgplw7jW3RBN4.pgp
Description: PGP signature
Re: shared root account
On Fri, Jul 06, 2001 at 06:15:43AM -0800, Ethan Benson wrote: the main reason i don't use sudo except for small things which cannot grant a root shell in any way is for the simple reason the sudo converts a normal unprivleged user password into another root password. Any user account that has access to the administrative account if compromised can give the attacker the admin account etc. sudo here is no worse than having your account compromised, your keys sniffed and su really. Simon. -- oOoOo CATS. CATS ARE NICE. - Death, Sourcery oOoOo oOoOooOoOo oOoOo oOoOo htag.pl 0.0.19 ::: http://www.earth.li/~huggie/
Re: shared root account
Ethan == Ethan Benson [EMAIL PROTECTED] writes: Ethan or even seemingly innocuous things like less or even cat. Less is a problem, yes, as is anything else with a shell escape. Ethan sudo less anything !/bin/sh whoami r00t! Ethan echo me ALL=ALL s sudo 'cat s /etc/sudoers' doesn't work. the is a shell redirection, but sudo doesn't evaluate in a shell. $ echo me ALL=ALL s $ cat s me ALL=ALL $ sudo 'cat s foo' sudo: cat s foo: command not found $ sudo cat s \ foo me ALL=ALL cat: : No such file or directory cat: foo: No such file or directory I would be very shocked if you could compromise a system with a sudoers entry of: me hostname = (root) /bin/cat Ethan sudo is a very large cannon which is difficult to keep aimed Ethan away from the foot... That it is. But then, the root password is basically a very large cannon built into your shoe. -Eric
Re: shared root account
On Fri, Jul 06, 2001 at 03:24:56PM -0800, Ethan Benson wrote: On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote: OTOH if you restrict the user to a list of commands in /etc/sudoers, it's wise to consider whether the user might be able to leverage one of those commands to edit /etc/sudoers (or any other file). If you're going to list emacs or vi in /etc/sudoers, you might as well just list ALL :) or even seemingly innocuous things like less or even cat. sudo less anything !/bin/sh whoami r00t! echo me ALL=ALL s sudo 'cat s /etc/sudoers' IOW, it's safe to say that allowing access to a shell via sudo means you trust that user as root. sudo is a very large cannon which is difficult to keep aimed away from the foot... Depends on how you use it. At my last job, we used sudo for two reasons: 1) I didn't have to inform all the admins whenever the root password changed. 2) techs had a script which ran as root under sudo for creating user accounts, etc. The script was written in perl ... I'm sure there was something wrong with it but it worked well for us and kept techs in the box where they did the least damage. Cheers, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpJ8WZEmTXDr.pgp Description: PGP signature
