Re: Hi :
I do have snort installed and it gives me nicely daily status logs containing absolutly nothing :( There might be more programs mailing root(or alias for root) with nothingCRON maybe... Gr, Ivo Without the darkness, how would you recognize the light? -Original Message- From: Tom Breza [EMAIL PROTECTED] Date: Thu, 18 Oct 2001 21:24:41 +0100 (BST) Subject: Re: Hi : Previously Tom Breza wrote: Hi I got this today in my mail box, this is generated by somthing but I don't know what is it? Why I got message from root? and why is empty? Do you have snort installed? Hi Wichert No I don't have a snort in the system Any other sugestions? Tom -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hi :
[Fri, Oct 19, 2001 at 08:42:34AM +0200] vdongen :
I do have snort installed and it gives me nicely daily status logs
containing absolutely nothing
Have you configured snort ? Iff not, this can be done via the debconf
front-end or via 'hand'.
--
ragOO, VU2RGU http://gnuhead.net.dhis.org/ GPG: 1024D/F1624A6E
Helping to keep the Air-Waves FREE Amateur Radio
Helping to keep your Software FREE the GNU Project
Helping to keep the W W W FREE Debian GNU/${kernel}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
central administration techniques
I was wondering if there are any secure methods of centrally managing the versions of certain files on Debian machines. I currently have a woody, two sids and several potatos which need to be kept up to date. The security patches are not much of a concern since they are quite infrequent (except for woody and sid where I do not discriminate between security, bug and other fixes) but certain configuration files change often, like the files /etc/ssh/ssh_known_hosts*. Every time a new host is added into the network, I need to add its host key into the others' known_hosts and copy the all default configuration files into the new host as well. There are quite a few of these that are easily forgotten. Forgetting to copy some files like /etc/printcap is soon noticed and fixed, no harm done, but files like /etc/pam.d/* are not. And results in decreased security! I am now considering different possibilities of doing these updates by simply saying update-debian-machines on one of the computers. It would require some shell scripts and asking the relevant passwords it would keep me waiting at my console. I do circumvent the login passwords with ssh/DSA auth, but resenting root logins over the net, I would still need to type sudo's passwords. Now, is there a package to do this or which could be easily converted to do this? Otherwise I will fall back to scripting. In that case, which is the safest option? Currently I am considering configuring sudo to enable the admin user to execute a single script (mods 0700) without a password or just chmod that script 4700. I am not certain about the first, but the latter would be as secure as my connection (ssh2) and my real password. The real password being broken would mean unlimited access to sudo (it is the admin, after all) so I am not worried by that part. Also, the ssh connection part worries me a little: I would basically be giving root access to all our machines to anyone who can steal/spoof/abuse my ssh private key. I can think of three scenarios to compromise the network: 1. To break into my admin console, so as to get my DSA private key (mod 0600) and break its passphrase. 2. To break into my admin machine (Getting on any machine would not do - the DSA key only exists on one, so the cracker would need to break into my admin console.) and steal my DSA key while it is being used. Ssh-agent keeps the key (or does it keep the passphrase? in this case it does not matter) in memory so this should be possible at least for root on a machine with /dev/mem. 3. Break into one of the other machines, use the suided script to trojan the system and propagate to the other machines that way. The last one might prove difficult: the admin user on non-admin-console machines does not have any DSA keys used for password-less authentication - so this basically means breaking into a single machine which I am not concerned of here. Breaking into a single machine should be about equally difficult for all machines, since I doubt my little scheme would be the weakest link in security. The only problem I can see is in 1. and 2. - could the DSA key be abused to automatically root all the machines? Ideas? -- --- | 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]
Re: central administration techniques
On Fri, 19 Oct 2001 at 17:54:28 +0300, Juha Jykk wrote: [...] case, which is the safest option? Currently I am considering configuring sudo to enable the admin user to execute a single script (mods 0700) without a password or just chmod that script 4700. I am not ^^^ certain about the first, but the latter would be as secure as my connection (ssh2) and my real password. The real password being broken [...] 3. Break into one of the other machines, use the suided script to ^ I can't answer your questions - I know too little. Just one remark: AFAIK, Linux doesn't support suided shell scripts. At least it didn't do that a few years ago when I tried to use a suided script. I haven't checked that since then. Hope it helps -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: central administration techniques
3. Break into one of the other machines, use the suided script to ^ I can't answer your questions - I know too little. Just one remark: AFAIK, Linux doesn't support suided shell scripts. At least it didn't do that a few years ago when I tried to use a suided script. I haven't - use C-code. Does not matter. I can code buffer overflow -proof routines for this simple stuff. Or just code a suid binary which runs the script and does nothing else.. An additional security hole there, though: I basically would have TWO suided programs now though crashing a program which only runs another should be impossible (unless the init routines can be crashed). -- --- | 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]
Re: central administration techniques
On Fri, Oct 19, 2001 at 06:33:43PM +0300, Juha J?ykk? wrote: 3. Break into one of the other machines, use the suided script to ^ I can't answer your questions - I know too little. Just one remark: AFAIK, Linux doesn't support suided shell scripts. At least it didn't do that a few years ago when I tried to use a suided script. I haven't - use C-code. Does not matter. I can code buffer overflow -proof routines for this simple stuff. Or just code a suid binary which runs the script and does nothing else.. An additional security hole there, though: I basically would have TWO suided programs now though crashing a program which only runs another should be impossible (unless the init routines can be crashed). Only the C-wrapper should be SUID I think, and since it then already runs as root, there's no need to set the SUID bit for the shell script (it will just be ignored). -- ,---. Name: Alson van der Meulen Personal:[EMAIL PROTECTED] School: [EMAIL PROTECTED] `---' Where's the DIR command? - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: central administration techniques
On Fri, Oct 19, 2001 at 05:54:28PM +0300, Juha J?ykk? wrote: I was wondering if there are any secure methods of centrally managing the versions of certain files on Debian machines. I currently have a woody, two sids and several potatos which need to be kept up to date. The security patches are not much of a concern since they are quite infrequent (except for woody and sid where I do not discriminate between security, bug and other fixes) but certain configuration files change often, like the files /etc/ssh/ssh_known_hosts*. Every time a new host is added into the network, I need to add its host key into the others' known_hosts and copy the all default configuration files into the new host as well. There are quite a few of these that are easily forgotten. Forgetting to copy some files like /etc/printcap is soon noticed and fixed, no harm done, but files like /etc/pam.d/* are not. And results in decreased security! I am now considering different possibilities of doing these updates by simply saying update-debian-machines on one of the computers. It would require some shell scripts and asking the relevant passwords it would keep me waiting at my console. I do circumvent the login passwords with ssh/DSA auth, but resenting root logins over the net, I would still need to type sudo's passwords. Now, is there a package to do this or which could be easily converted to do this? Otherwise I will fall back to scripting. In that maybe have a look at cfengine? or apt-cache search / freshmeat / google for other options case, which is the safest option? Currently I am considering configuring sudo to enable the admin user to execute a single script (mods 0700) without a password or just chmod that script 4700. I am not certain about the first, but the latter would be as secure as my connection (ssh2) and my real password. The real password being broken would mean unlimited access to sudo (it is the admin, after all) so I am not worried by that part. Also, the ssh connection part worries me a little: I would basically be giving root access to all our machines to anyone who can steal/spoof/abuse my ssh private key. I can think of three scenarios to compromise the network: 1. To break into my admin console, so as to get my DSA private key (mod 0600) and break its passphrase. AFAIK, breaking the passphrase is really difficult, with these ~1024bit RSA/DSA keys. 2. To break into my admin machine (Getting on any machine would not do - the DSA key only exists on one, so the cracker would need to break into my admin console.) and steal my DSA key while it is being used. Ssh-agent keeps the key (or does it keep the passphrase? in this case it does not matter) in memory so this should be possible at least for root on a machine with /dev/mem. Use a separate DSA key, and don't add that to ssh-agent, just type your passphrase every time (they could still trojan your ssh, but hey, the could also install a keyboard logger to sniff passwords then) BTW: ssh-agent keeps the decrypted private key (private key decrypted using the passphrase). Be sure to use strict host key checking, and _never_ agree with an unexpected host key change. 3. Break into one of the other machines, use the suided script to trojan the system and propagate to the other machines that way. The last one might prove difficult: the admin user on non-admin-console machines does not have any DSA keys used for password-less authentication - so this basically means breaking into a single machine which I am not concerned of here. Breaking into a single machine should be about equally difficult for all machines, since I doubt my little scheme would be the weakest link in security. The only problem I can see is in 1. and 2. - could the DSA key be abused to automatically root all the machines? Ideas? Be sure to * out the password of admin, so it can _only_ login via DSA keys. IMHO, it's more difficult to steal a private DSA key _and_ the passphrase (as long as you don't use ssh-agent), than to steal a password (DSA keys are less sensitive for social engineering and stuff). You should really close _all_ incoming ports on your admin machine, including ssh. Then it will be quite difficult to break in as long as they don't have physical access). Just be sure your admin console is as secure as possible, don't run any foreign programs, etc. As long as they don't break root on your admin box, and you don't run anything unecessary under the admin account, i.e. no games and other 'funny' programs, I don't think the security will be weakened. They can of course still break root on a server if it runs a vulnarable daemon (if you're paranoid, read bugtraq friends, since debian security advisories are sometimes issued a short time after it was reported on bugtraq. The FreeBSD security manpage: http://www.freebsd.org/cgi/man.cgi?query=securityapropos=0sektion=0manpath=FreeBSD+5.0-currentformat=html contains some useful
BugTraq Kernel 2.2.19
Hi, I just discovered http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 thanks to /. (so I'm sure more of you are aware of it). I was just wondering if anyone can let me know how we discover when we are likely to see an update for the kernel on security.debian.org to patch this issue (their seems to be at least one potential patch available, though for the symlink exploit it does alter the spec of the system :-( If the fix has appeared in the last few minutes since I apt-get update apt-get dist-upgrade d my box congrats guys and sorry to bother you :-) With this bug receiving /. coverage and the exploit code available (as it should be, all in the open please) I think we need to ensure that Debian gets this covered asap before some MS lovers go writing code to exploit boxes just to prove that their boxes are as good as ours. Niall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Virtual Congress in UniNet; Congreso Virtual en UniNet
First announcement of II INTERNACIONAL UNIX MEETING IN UNINET (UMEET 2001) December 1st -- December 15th, 2001 (Excuse us if you recive this letter more than once) UniNet, is a University Network, a non profit organization, which target is to integrate services provided trough Internet, to offer them to virtual communities, created by persons and organizations. It's main target is to disclose and foment Sciences and Humanity Sciences, and one of those created communities have been, of course, the Unix like systems enthusiastic people. With the same target of last years, that is, to share and disclose experiences, and foment relationship between people interested in same subjects, the Unix users comunity and UniNet are pleased to announce the II International Unix Meeting in UniNET UMEET 2001. Which will be celebrated in Internet from December 1st until 15th, 2001. The participation on this meeting es open for every person interested on Unix systems world, and will be celebrated remotely, on the Internet, in both ways, interactively (text-conference, irc), and by publishing many documentation (www) which will remain on our web. The participation is free and no cost, for all listeners and lecturers. For more information we invite you to: Meeting home page: http://umeet.uninet.edu/ You can register, without any charge, with the target of subscribing to the meeting mailing list, and get the participant accreditation at the end of the event on: http://compendium.ar.uninet.edu/cgi-bin/umeet2001/register?lang=en Sincerely, UMEET 2001 Organizing Committee http://umeet.uninet.edu/ [EMAIL PROTECTED] Primer anuncio del II CONGRESO INTERNACIONAL DE UNIX EN UNINET (UMEET 2001) 1 de Diciembre -- 15 de Diciembre de 2001 UniNet, es una Red Universitaria, sin ánimo de lucro cuyo fin es integrar servicios proporcionados a través de Internet, para ofrecerlos a comunidades virtuales, creadas por personas y organizaciones. Su principal objetivo es la divulgación y fomento de las Ciencias y Humanidades, y una de las comunidades creadas ha sido, como no, la de los entusiastas de los sistemas tipo Unix. Con objetivos análogos a los del años pasado, esto es, de compartir y difundir experiencias, y fomentar la relación entre personas con sus mismas inquietudes, la comunidad de usuarios de Unix en UniNet tiene la satisfacción de anunciar el II Congreso Internacional de UNIX en UniNET UMEET 2001. a celebrar en Internet entre los dias 1 y 15 de Diciembre de 2001. La participación en este encuentro está abierta a cualquier persona interesada en el mundo de los sistemas Unix, y se realiza de forma remota, a través de Internet, tanto de forma interactiva (textoconferencia, irc), como mediante la publicación de trabajos (www), de los cuales quedará constancia en nuestra web. La participación es libre y gratuita, tanto siendo asistente como ponente. Para más detalles le invitamos a visitar: Página web del Congreso: http://umeet.uninet.edu/ Quien lo desee, puede registrarse, sin cargo alguno, con el fin de inscribirse en la lista de mail del congreso, y recibir la acreditación de participante al final del evento, en: http://compendium.ar.uninet.edu/cgi-bin/umeet2001/register?lang=es Atentamente, -- Comité Organizador de UMEET 2000 http://umeet.uninet.edu/ [EMAIL PROTECTED] UMeet. UniNet UNIX Meeting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: central administration techniques
changes via cvs to a nfs mount, all the client machines download changes via a cron job. Whoooa... nfs? Security++... I could consider using some secure networked file system, though but I doubt cron would be a good idea. Or maybe it is. Anyone any concerns? Another thing that crossed my mind: a local apt-repository. I could put my config files in machine-specific .deb's and even wget all the fixes there plus clean the old ones. Then just run apt-get to install them... There is a slight concern, though: our network is a shared coaxial net... (10Base-2) -- --- | 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]
Re: central administration techniques
maybe have a look at cfengine? or apt-cache search / freshmeat / google for other options I was down this road just a few months ago. cfengine is nice except that the author doesn't believe that 'administrative information' is something that should be protected and thus has no plans to move from rsh to an SSH tunnel or SSL. Imagine syncing /etc/shadow or some other information that should be kept secret over RSH. Yuck. Beyond cfengine, there are a couple of tools out there although I never really grew to like any of them. There is one called PiKT and another called Palantir. Palantir is sorta like SourceForge in that it has a lot of hard-coded stuff that makes it very difficult to get working in an environment other than the one it is developed in. The PiKT author gave a presentation at LISA 2000 and seems to be actively hacking on the project. I never really liked his custom scripting language though so... I ended up taking much the same approach that you offer except that my private keys are kept offsite and behind a very tight firewall. Whenever a change needs to be made I have to write a script and put it in a globally accessible NFS share. I then use the machine behind the firewall to iterate through the address space of the target machines using ssh-agent and with a command line something like: $ ssh -l root 'path to update script' It works but is very kludgey. There is a commercial software package called NetShell that will do a lot of the remote admin kind of tasks but I have not had a chance to purchase a copy and try it out. Regardless, it is non-free. I am mostly interested in NetShell as another data point regarding how these kind of problems can be solved. -- --- Nathan Valentine - [EMAIL PROTECTED] University of Kentucky Lab for Advanced Networking Jabber: NRVesKY AIM: NRVesKY ICQ: 39023424 PGP signature
Re: BugTraq Kernel 2.2.19
On Fri, Oct 19, 2001 at 05:13:19PM +0100, Niall Walsh wrote: Hi, I just discovered http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 thanks to /. (so I'm sure more of you are aware of it). I was just wondering if anyone can let me know how we discover when we are likely to see an update for the kernel on security.debian.org to patch this issue (their seems to be at least one potential patch available, though for the symlink exploit it does alter the spec of the system :-( If the fix has appeared in the last few minutes since I apt-get update apt-get dist-upgrade d my box congrats guys and sorry to bother you :-) With this bug receiving /. coverage and the exploit code available (as it should be, all in the open please) I think we need to ensure that Debian gets this covered asap before some MS lovers go writing code to exploit boxes just to prove that their boxes are as good as ours. Niall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] i think Linus has already approved the patch. im not sure yet when will it arrive though.. -- When you have eliminated the impossible, whatever remains, however improbable, must be the truth. --Sherlock Holmes _The Sign of Four_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BugTraq Kernel 2.2.19
i think Linus has already approved the patch. im not sure yet when will it arrive though.. Yes, the email linked to by that /. posting : http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 has attached to it the Linus-blessed 2.2.19 patch. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] Personal Homepage: http://www.skyjammer.com/~pronovic/ I have zero tolerance for zero-tolerance policies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BugTraq Kernel 2.2.19
On Fri, Oct 19, 2001 at 12:24:45PM -0500, Kenneth Pronovici wrote: i think Linus has already approved the patch. im not sure yet when will it arrive though.. Yes, the email linked to by that /. posting : http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 has attached to it the Linus-blessed 2.2.19 patch. Has anyone else noticed that the included exploit does not affect 2.2.19? I tested it on one of my boxes and got the expected 'Operation not permitted'. Maybe I'm misunderstanding the problem, but I thought taht 2.2.19 took care of (well hindered) the ptrace problems. -Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BugTraq Kernel 2.2.19
Has anyone else noticed that the included exploit does not affect 2.2.19? I tested it on one of my boxes and got the expected 'Operation not permitted'. Maybe I'm misunderstanding the problem, but I thought taht 2.2.19 took care of (well hindered) the ptrace problems. I can't make the ptrace exploit work on my 2.2.19 system... but I might be doing something wrong (I'm not quite sure what to expect). I get: attached exec ./insert_shellcode 30505 execl: Operation not permitted The mklink.sh script definitely works as advertised. If I use an argument of 10, I'm dead in the water until the script finishes. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] Personal Homepage: http://www.skyjammer.com/~pronovic/ I have zero tolerance for zero-tolerance policies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BugTraq Kernel 2.2.19
Hello,
I run Woody with 2.2.19 compiled from source, and the ptrace exploited worked
even with an older version of Openwall applied (scary...), but I snagged
fresh kernel source and the new Openwall patch, and it fails with the message
you receive ("execl: Operation not permitted.").
Regards,
Jovan Rivera
Email: [EMAIL PROTECTED]
Kenneth Pronovici wrote:
[EMAIL PROTECTED]">
Has anyone else noticed that the included exploit does not affect2.2.19? I tested it on one of my boxes and got the expected 'Operationnot permitted'. Maybe I'm misunderstanding the problem, but I thoughttaht 2.2.19 took care of (well hindered) the ptrace problems.
I can't make the ptrace exploit work on my 2.2.19 system... but I mightbe doing something wrong (I'm not quite sure what to expect). I get: attached exec ./insert_shellcode 30505 execl: Operation not permittedThe mklink.sh script definitely works as advertised. If I use an argumentof 10, I'm dead in the water until the script finishes.KEN
Re: central administration techniques
On Fri, Oct 19, 2001 at 09:41:22AM -0700, nrvale0 wrote: maybe have a look at cfengine? or apt-cache search / freshmeat / google for other options I was down this road just a few months ago. cfengine is nice except that the author doesn't believe that 'administrative information' is something that should be protected and thus has no plans to move from rsh to an SSH tunnel or SSL. Imagine syncing /etc/shadow or some other information that should be kept secret over RSH. Yuck. It it's on the wire, it should be encrypted. -- Share and Enjoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: central administration techniques
* Juha J?ykk? ([EMAIL PROTECTED]) [011019 07:57]:
I was wondering if there are any secure methods of centrally
managing the versions of certain files on Debian machines. I currently
have a woody, two sids and several potatos which need to be kept up to
date. The security patches are not much of a concern since they are
quite infrequent (except for woody and sid where I do not discriminate
between security, bug and other fixes) but certain configuration files
change often, like the files /etc/ssh/ssh_known_hosts*.
Every time a new host is added into the network, I need to add its
host key into the others' known_hosts and copy the all default
configuration files into the new host as well. There are quite a few
of these that are easily forgotten. Forgetting to copy some files
like /etc/printcap is soon noticed and fixed, no harm done, but files
like /etc/pam.d/* are not. And results in decreased security!
I am now considering different possibilities of doing these updates
by simply saying update-debian-machines on one of the computers. It
would require some shell scripts and asking the relevant passwords it
would keep me waiting at my console. I do circumvent the login
passwords with ssh/DSA auth, but resenting root logins over the net, I
would still need to type sudo's passwords.
Check out the command= option in the authorized_keys{2,} file. This
info is given in sshd(8). This will allow you to connect with a certain
key and execute a certain command, and no more. This means that even if
someone does steal your unencrypted key somehow, the worst they can do
is run your update script -- never get a login shell. This also saves
you from having to type your sudo password for this purpose, and from
having to keep any suid binaries on your system. Make sure you also set
PermitRootLogin=forced-commands-only in sshd_config. This feature is
very useful for exactly this sort of purpose, when you need a
{semi-,}automated process to run for updates, backups, etc.
I also recommend you use a from= option in the authorized_keys2 file,
as this will require not only retrieval of the secret key, but also
breaking the nameserver/router to spoof the source address (or that the
attacker tries to connect from your admin console). Most likely, someone
trying to abuse your secret key will have gotten your key from the admin
console and will try to abuse it from elsewhere. USe logwatch or
something similar on the target machines to throw up Red Flags if anyone
tries to connect as root from anywhere else.
For added security: no-port-forwarding, no-X11-forwarding,
no-agent-forwarding, and (assuming your script can get away with it)
no-pty.
I can think of three scenarios to compromise the network:
1. To break into my admin console, so as to get my DSA private
key (mod 0600) and break its passphrase.
This is difficult, especially if you use a very difficult passphrase!
2. To break into my admin machine (Getting on any machine would not do
- the DSA key only exists on one, so the cracker would need to break
into my admin console.) and steal my DSA key while it is being used.
Ssh-agent keeps the key (or does it keep the passphrase?
in this case it does not matter) in memory so this should be possible
at least for root on a machine with /dev/mem.
If this is a concern, don't use ssh-agent. Also, With the setup I
suggest, even compromising this key only gives the attacker the ability
to run your update script; nothing more. I'd be worried more about him
exploiting the target machines in the same way your admin console was
compromised, since, in theory, the admin console should be the most
difficult to crack!
3. Break into one of the other machines, use the suided script to
trojan the system and propagate to the other machines that way.
I suggest tripwire to help manage the risk of the update script on the
target machines being trojaned/replaced.
good times,
--
Vineet http://www.anti-dmca.org
Unauthorized use of this .sig may constitute violation of US law.
echo Qba\'g gernq ba zr\! |tr 'a-zA-Z' 'n-za-mN-ZA-M'
PGP signature
ssh vulernability
Hello, Has debian released a new ssh dpkg yet? Thanks. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh vulernability
On Fri, Oct 19, 2001 at 06:06:34PM -0400, [EMAIL PROTECTED] wrote: Hello, Has debian released a new ssh dpkg yet? no -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: ssh vulernability
I run Debian; and I applied the OpenSSH patch myself as soon as it was posted. Does anybody know of the advantages of waiting for a new .deb file to get circulated are? The patch was a change to two lines of code; so I just made the changes and rebuilt OpenSSH. That's how I do all of my non-kernel patches; seems a bit odd to wait around for the distribution's official patch-maker-squad to churn out a new .DEB file. Garrett Ethan Benson wrote: On Fri, Oct 19, 2001 at 06:06:34PM -0400, [EMAIL PROTECTED] wrote: Hello, Has debian released a new ssh dpkg yet? no -- Ethan Benson http://www.alaska.net/~erbenson/ Part 1.2Type: application/pgp-signature -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.4.12 ???
is stock (non Debian) 2.4.12 now secure or not? i am getting confused. if it isn't, where can i find patches for it to make it secure? sorry to be asking so blatantly, but i don't have much time to worry about my private systems these days. please help. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck there's someone in my head but its not me. -- pink floyd, the dark side of the moon, 1972 PGP signature
Re: 2.4.12 ???
As far as I can tell, yes, the 2.4.12 kernel from kernel.org is secure (at least w/ regard to the bugs listed at http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 I've just built the kernel and ran the exploits provided in the securityfocus article; so far they've failed. Cheng H. Lee On Sat, Oct 20, 2001 at 02:41:08AM +0200, martin f krafft wrote: is stock (non Debian) 2.4.12 now secure or not? i am getting confused. if it isn't, where can i find patches for it to make it secure? sorry to be asking so blatantly, but i don't have much time to worry about my private systems these days. please help. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck there's someone in my head but its not me. -- pink floyd, the dark side of the moon, 1972 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hi :
I do have snort installed and it gives me nicely daily status logs containing absolutly nothing :( There might be more programs mailing root(or alias for root) with nothingCRON maybe... Gr, Ivo Without the darkness, how would you recognize the light? -Original Message- From: Tom Breza [EMAIL PROTECTED] Date: Thu, 18 Oct 2001 21:24:41 +0100 (BST) Subject: Re: Hi : Previously Tom Breza wrote: Hi I got this today in my mail box, this is generated by somthing but I don't know what is it? Why I got message from root? and why is empty? Do you have snort installed? Hi Wichert No I don't have a snort in the system Any other sugestions? Tom -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- 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: Hi :
[Fri, Oct 19, 2001 at 08:42:34AM +0200] vdongen :
I do have snort installed and it gives me nicely daily status logs
containing absolutely nothing
Have you configured snort ? Iff not, this can be done via the debconf
front-end or via 'hand'.
--
ragOO, VU2RGU http://gnuhead.net.dhis.org/ GPG: 1024D/F1624A6E
Helping to keep the Air-Waves FREE Amateur Radio
Helping to keep your Software FREE the GNU Project
Helping to keep the W W W FREE Debian GNU/${kernel}
central administration techniques
I was wondering if there are any secure methods of centrally managing the versions of certain files on Debian machines. I currently have a woody, two sids and several potatos which need to be kept up to date. The security patches are not much of a concern since they are quite infrequent (except for woody and sid where I do not discriminate between security, bug and other fixes) but certain configuration files change often, like the files /etc/ssh/ssh_known_hosts*. Every time a new host is added into the network, I need to add its host key into the others' known_hosts and copy the all default configuration files into the new host as well. There are quite a few of these that are easily forgotten. Forgetting to copy some files like /etc/printcap is soon noticed and fixed, no harm done, but files like /etc/pam.d/* are not. And results in decreased security! I am now considering different possibilities of doing these updates by simply saying update-debian-machines on one of the computers. It would require some shell scripts and asking the relevant passwords it would keep me waiting at my console. I do circumvent the login passwords with ssh/DSA auth, but resenting root logins over the net, I would still need to type sudo's passwords. Now, is there a package to do this or which could be easily converted to do this? Otherwise I will fall back to scripting. In that case, which is the safest option? Currently I am considering configuring sudo to enable the admin user to execute a single script (mods 0700) without a password or just chmod that script 4700. I am not certain about the first, but the latter would be as secure as my connection (ssh2) and my real password. The real password being broken would mean unlimited access to sudo (it is the admin, after all) so I am not worried by that part. Also, the ssh connection part worries me a little: I would basically be giving root access to all our machines to anyone who can steal/spoof/abuse my ssh private key. I can think of three scenarios to compromise the network: 1. To break into my admin console, so as to get my DSA private key (mod 0600) and break its passphrase. 2. To break into my admin machine (Getting on any machine would not do - the DSA key only exists on one, so the cracker would need to break into my admin console.) and steal my DSA key while it is being used. Ssh-agent keeps the key (or does it keep the passphrase? in this case it does not matter) in memory so this should be possible at least for root on a machine with /dev/mem. 3. Break into one of the other machines, use the suided script to trojan the system and propagate to the other machines that way. The last one might prove difficult: the admin user on non-admin-console machines does not have any DSA keys used for password-less authentication - so this basically means breaking into a single machine which I am not concerned of here. Breaking into a single machine should be about equally difficult for all machines, since I doubt my little scheme would be the weakest link in security. The only problem I can see is in 1. and 2. - could the DSA key be abused to automatically root all the machines? Ideas? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: central administration techniques
On Fri, 19 Oct 2001 at 17:54:28 +0300, Juha Jäykkä wrote: [...] case, which is the safest option? Currently I am considering configuring sudo to enable the admin user to execute a single script (mods 0700) without a password or just chmod that script 4700. I am not ^^^ certain about the first, but the latter would be as secure as my connection (ssh2) and my real password. The real password being broken [...] 3. Break into one of the other machines, use the suided script to ^ I can't answer your questions - I know too little. Just one remark: AFAIK, Linux doesn't support suided shell scripts. At least it didn't do that a few years ago when I tried to use a suided script. I haven't checked that since then. Hope it helps -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros.
Re: central administration techniques
3. Break into one of the other machines, use the suided script to ^ I can't answer your questions - I know too little. Just one remark: AFAIK, Linux doesn't support suided shell scripts. At least it didn't do that a few years ago when I tried to use a suided script. I haven't - use C-code. Does not matter. I can code buffer overflow -proof routines for this simple stuff. Or just code a suid binary which runs the script and does nothing else.. An additional security hole there, though: I basically would have TWO suided programs now though crashing a program which only runs another should be impossible (unless the init routines can be crashed). -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: central administration techniques
On Fri, Oct 19, 2001 at 06:33:43PM +0300, Juha J?ykk? wrote: 3. Break into one of the other machines, use the suided script to ^ I can't answer your questions - I know too little. Just one remark: AFAIK, Linux doesn't support suided shell scripts. At least it didn't do that a few years ago when I tried to use a suided script. I haven't - use C-code. Does not matter. I can code buffer overflow -proof routines for this simple stuff. Or just code a suid binary which runs the script and does nothing else.. An additional security hole there, though: I basically would have TWO suided programs now though crashing a program which only runs another should be impossible (unless the init routines can be crashed). Only the C-wrapper should be SUID I think, and since it then already runs as root, there's no need to set the SUID bit for the shell script (it will just be ignored). -- ,---. Name: Alson van der Meulen Personal:[EMAIL PROTECTED] School: [EMAIL PROTECTED] `---' Where's the DIR command? -
Re: central administration techniques
On Fri, Oct 19, 2001 at 05:54:28PM +0300, Juha J?ykk? wrote: I was wondering if there are any secure methods of centrally managing the versions of certain files on Debian machines. I currently have a woody, two sids and several potatos which need to be kept up to date. The security patches are not much of a concern since they are quite infrequent (except for woody and sid where I do not discriminate between security, bug and other fixes) but certain configuration files change often, like the files /etc/ssh/ssh_known_hosts*. Every time a new host is added into the network, I need to add its host key into the others' known_hosts and copy the all default configuration files into the new host as well. There are quite a few of these that are easily forgotten. Forgetting to copy some files like /etc/printcap is soon noticed and fixed, no harm done, but files like /etc/pam.d/* are not. And results in decreased security! I am now considering different possibilities of doing these updates by simply saying update-debian-machines on one of the computers. It would require some shell scripts and asking the relevant passwords it would keep me waiting at my console. I do circumvent the login passwords with ssh/DSA auth, but resenting root logins over the net, I would still need to type sudo's passwords. Now, is there a package to do this or which could be easily converted to do this? Otherwise I will fall back to scripting. In that maybe have a look at cfengine? or apt-cache search / freshmeat / google for other options case, which is the safest option? Currently I am considering configuring sudo to enable the admin user to execute a single script (mods 0700) without a password or just chmod that script 4700. I am not certain about the first, but the latter would be as secure as my connection (ssh2) and my real password. The real password being broken would mean unlimited access to sudo (it is the admin, after all) so I am not worried by that part. Also, the ssh connection part worries me a little: I would basically be giving root access to all our machines to anyone who can steal/spoof/abuse my ssh private key. I can think of three scenarios to compromise the network: 1. To break into my admin console, so as to get my DSA private key (mod 0600) and break its passphrase. AFAIK, breaking the passphrase is really difficult, with these ~1024bit RSA/DSA keys. 2. To break into my admin machine (Getting on any machine would not do - the DSA key only exists on one, so the cracker would need to break into my admin console.) and steal my DSA key while it is being used. Ssh-agent keeps the key (or does it keep the passphrase? in this case it does not matter) in memory so this should be possible at least for root on a machine with /dev/mem. Use a separate DSA key, and don't add that to ssh-agent, just type your passphrase every time (they could still trojan your ssh, but hey, the could also install a keyboard logger to sniff passwords then) BTW: ssh-agent keeps the decrypted private key (private key decrypted using the passphrase). Be sure to use strict host key checking, and _never_ agree with an unexpected host key change. 3. Break into one of the other machines, use the suided script to trojan the system and propagate to the other machines that way. The last one might prove difficult: the admin user on non-admin-console machines does not have any DSA keys used for password-less authentication - so this basically means breaking into a single machine which I am not concerned of here. Breaking into a single machine should be about equally difficult for all machines, since I doubt my little scheme would be the weakest link in security. The only problem I can see is in 1. and 2. - could the DSA key be abused to automatically root all the machines? Ideas? Be sure to * out the password of admin, so it can _only_ login via DSA keys. IMHO, it's more difficult to steal a private DSA key _and_ the passphrase (as long as you don't use ssh-agent), than to steal a password (DSA keys are less sensitive for social engineering and stuff). You should really close _all_ incoming ports on your admin machine, including ssh. Then it will be quite difficult to break in as long as they don't have physical access). Just be sure your admin console is as secure as possible, don't run any foreign programs, etc. As long as they don't break root on your admin box, and you don't run anything unecessary under the admin account, i.e. no games and other 'funny' programs, I don't think the security will be weakened. They can of course still break root on a server if it runs a vulnarable daemon (if you're paranoid, read bugtraq friends, since debian security advisories are sometimes issued a short time after it was reported on bugtraq. The FreeBSD security manpage: http://www.freebsd.org/cgi/man.cgi?query=securityapropos=0sektion=0manpath=FreeBSD+5.0-currentformat=html contains some useful
BugTraq Kernel 2.2.19
Hi, I just discovered http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 thanks to /. (so I'm sure more of you are aware of it). I was just wondering if anyone can let me know how we discover when we are likely to see an update for the kernel on security.debian.org to patch this issue (their seems to be at least one potential patch available, though for the symlink exploit it does alter the spec of the system :-( If the fix has appeared in the last few minutes since I apt-get update apt-get dist-upgrade d my box congrats guys and sorry to bother you :-) With this bug receiving /. coverage and the exploit code available (as it should be, all in the open please) I think we need to ensure that Debian gets this covered asap before some MS lovers go writing code to exploit boxes just to prove that their boxes are as good as ours. Niall
Virtual Congress in UniNet; Congreso Virtual en UniNet
First announcement of II INTERNACIONAL UNIX MEETING IN UNINET (UMEET 2001) December 1st -- December 15th, 2001 (Excuse us if you recive this letter more than once) UniNet, is a University Network, a non profit organization, which target is to integrate services provided trough Internet, to offer them to virtual communities, created by persons and organizations. It's main target is to disclose and foment Sciences and Humanity Sciences, and one of those created communities have been, of course, the Unix like systems enthusiastic people. With the same target of last years, that is, to share and disclose experiences, and foment relationship between people interested in same subjects, the Unix users comunity and UniNet are pleased to announce the II International Unix Meeting in UniNET UMEET 2001. Which will be celebrated in Internet from December 1st until 15th, 2001. The participation on this meeting es open for every person interested on Unix systems world, and will be celebrated remotely, on the Internet, in both ways, interactively (text-conference, irc), and by publishing many documentation (www) which will remain on our web. The participation is free and no cost, for all listeners and lecturers. For more information we invite you to: Meeting home page: http://umeet.uninet.edu/ You can register, without any charge, with the target of subscribing to the meeting mailing list, and get the participant accreditation at the end of the event on: http://compendium.ar.uninet.edu/cgi-bin/umeet2001/register?lang=en Sincerely, UMEET 2001 Organizing Committee http://umeet.uninet.edu/ [EMAIL PROTECTED] Primer anuncio del II CONGRESO INTERNACIONAL DE UNIX EN UNINET (UMEET 2001) 1 de Diciembre -- 15 de Diciembre de 2001 UniNet, es una Red Universitaria, sin ánimo de lucro cuyo fin es integrar servicios proporcionados a través de Internet, para ofrecerlos a comunidades virtuales, creadas por personas y organizaciones. Su principal objetivo es la divulgación y fomento de las Ciencias y Humanidades, y una de las comunidades creadas ha sido, como no, la de los entusiastas de los sistemas tipo Unix. Con objetivos análogos a los del años pasado, esto es, de compartir y difundir experiencias, y fomentar la relación entre personas con sus mismas inquietudes, la comunidad de usuarios de Unix en UniNet tiene la satisfacción de anunciar el II Congreso Internacional de UNIX en UniNET UMEET 2001. a celebrar en Internet entre los dias 1 y 15 de Diciembre de 2001. La participación en este encuentro está abierta a cualquier persona interesada en el mundo de los sistemas Unix, y se realiza de forma remota, a través de Internet, tanto de forma interactiva (textoconferencia, irc), como mediante la publicación de trabajos (www), de los cuales quedará constancia en nuestra web. La participación es libre y gratuita, tanto siendo asistente como ponente. Para más detalles le invitamos a visitar: Página web del Congreso: http://umeet.uninet.edu/ Quien lo desee, puede registrarse, sin cargo alguno, con el fin de inscribirse en la lista de mail del congreso, y recibir la acreditación de participante al final del evento, en: http://compendium.ar.uninet.edu/cgi-bin/umeet2001/register?lang=es Atentamente, -- Comité Organizador de UMEET 2000 http://umeet.uninet.edu/ [EMAIL PROTECTED] UMeet. UniNet UNIX Meeting
Re: central administration techniques
changes via cvs to a nfs mount, all the client machines download changes via a cron job. Whoooa... nfs? Security++... I could consider using some secure networked file system, though but I doubt cron would be a good idea. Or maybe it is. Anyone any concerns? Another thing that crossed my mind: a local apt-repository. I could put my config files in machine-specific .deb's and even wget all the fixes there plus clean the old ones. Then just run apt-get to install them... There is a slight concern, though: our network is a shared coaxial net... (10Base-2) -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: central administration techniques
maybe have a look at cfengine? or apt-cache search / freshmeat / google for other options I was down this road just a few months ago. cfengine is nice except that the author doesn't believe that 'administrative information' is something that should be protected and thus has no plans to move from rsh to an SSH tunnel or SSL. Imagine syncing /etc/shadow or some other information that should be kept secret over RSH. Yuck. Beyond cfengine, there are a couple of tools out there although I never really grew to like any of them. There is one called PiKT and another called Palantir. Palantir is sorta like SourceForge in that it has a lot of hard-coded stuff that makes it very difficult to get working in an environment other than the one it is developed in. The PiKT author gave a presentation at LISA 2000 and seems to be actively hacking on the project. I never really liked his custom scripting language though so... I ended up taking much the same approach that you offer except that my private keys are kept offsite and behind a very tight firewall. Whenever a change needs to be made I have to write a script and put it in a globally accessible NFS share. I then use the machine behind the firewall to iterate through the address space of the target machines using ssh-agent and with a command line something like: $ ssh -l root 'path to update script' It works but is very kludgey. There is a commercial software package called NetShell that will do a lot of the remote admin kind of tasks but I have not had a chance to purchase a copy and try it out. Regardless, it is non-free. I am mostly interested in NetShell as another data point regarding how these kind of problems can be solved. -- --- Nathan Valentine - [EMAIL PROTECTED] University of Kentucky Lab for Advanced Networking Jabber: NRVesKY AIM: NRVesKY ICQ: 39023424 pgpEp4lgTyeXa.pgp Description: PGP signature
Re: BugTraq Kernel 2.2.19
On Fri, Oct 19, 2001 at 05:13:19PM +0100, Niall Walsh wrote: Hi, I just discovered http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 thanks to /. (so I'm sure more of you are aware of it). I was just wondering if anyone can let me know how we discover when we are likely to see an update for the kernel on security.debian.org to patch this issue (their seems to be at least one potential patch available, though for the symlink exploit it does alter the spec of the system :-( If the fix has appeared in the last few minutes since I apt-get update apt-get dist-upgrade d my box congrats guys and sorry to bother you :-) With this bug receiving /. coverage and the exploit code available (as it should be, all in the open please) I think we need to ensure that Debian gets this covered asap before some MS lovers go writing code to exploit boxes just to prove that their boxes are as good as ours. Niall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] i think Linus has already approved the patch. im not sure yet when will it arrive though.. -- When you have eliminated the impossible, whatever remains, however improbable, must be the truth. --Sherlock Holmes _The Sign of Four_
Re: BugTraq Kernel 2.2.19
i think Linus has already approved the patch. im not sure yet when will it arrive though.. Yes, the email linked to by that /. posting : http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 has attached to it the Linus-blessed 2.2.19 patch. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] Personal Homepage: http://www.skyjammer.com/~pronovic/ I have zero tolerance for zero-tolerance policies.
Re: BugTraq Kernel 2.2.19
On Fri, Oct 19, 2001 at 12:24:45PM -0500, Kenneth Pronovici wrote: i think Linus has already approved the patch. im not sure yet when will it arrive though.. Yes, the email linked to by that /. posting : http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 has attached to it the Linus-blessed 2.2.19 patch. Has anyone else noticed that the included exploit does not affect 2.2.19? I tested it on one of my boxes and got the expected 'Operation not permitted'. Maybe I'm misunderstanding the problem, but I thought taht 2.2.19 took care of (well hindered) the ptrace problems. -Rob
Re: BugTraq Kernel 2.2.19
Has anyone else noticed that the included exploit does not affect 2.2.19? I tested it on one of my boxes and got the expected 'Operation not permitted'. Maybe I'm misunderstanding the problem, but I thought taht 2.2.19 took care of (well hindered) the ptrace problems. I can't make the ptrace exploit work on my 2.2.19 system... but I might be doing something wrong (I'm not quite sure what to expect). I get: attached exec ./insert_shellcode 30505 execl: Operation not permitted The mklink.sh script definitely works as advertised. If I use an argument of 10, I'm dead in the water until the script finishes. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] Personal Homepage: http://www.skyjammer.com/~pronovic/ I have zero tolerance for zero-tolerance policies.
Re: BugTraq Kernel 2.2.19
Hello,
I run Woody with 2.2.19 compiled from source, and the ptrace exploited worked
even with an older version of Openwall applied (scary...), but I snagged
fresh kernel source and the new Openwall patch, and it fails with the message
you receive ("execl: Operation not permitted.").
Regards,
Jovan Rivera
Email: [EMAIL PROTECTED]
Kenneth Pronovici wrote:
Has anyone else noticed that the included exploit does not affect2.2.19? I tested it on one of my boxes and got the expected 'Operationnot permitted'. Maybe I'm misunderstanding the problem, but I thoughttaht 2.2.19 took care of (well hindered) the ptrace problems.
I can't make the ptrace exploit work on my 2.2.19 system... but I mightbe doing something wrong (I'm not quite sure what to expect). I get: attached exec ./insert_shellcode 30505 execl: Operation not permittedThe mklink.sh script definitely works as advertised. If I use an argumentof 10, I'm dead in the water until the script finishes.KEN
Re: central administration techniques
On Fri, Oct 19, 2001 at 09:41:22AM -0700, nrvale0 wrote: maybe have a look at cfengine? or apt-cache search / freshmeat / google for other options I was down this road just a few months ago. cfengine is nice except that the author doesn't believe that 'administrative information' is something that should be protected and thus has no plans to move from rsh to an SSH tunnel or SSL. Imagine syncing /etc/shadow or some other information that should be kept secret over RSH. Yuck. It it's on the wire, it should be encrypted. -- Share and Enjoy.
Re: central administration techniques
* Juha J?ykk? ([EMAIL PROTECTED]) [011019 07:57]:
I was wondering if there are any secure methods of centrally
managing the versions of certain files on Debian machines. I currently
have a woody, two sids and several potatos which need to be kept up to
date. The security patches are not much of a concern since they are
quite infrequent (except for woody and sid where I do not discriminate
between security, bug and other fixes) but certain configuration files
change often, like the files /etc/ssh/ssh_known_hosts*.
Every time a new host is added into the network, I need to add its
host key into the others' known_hosts and copy the all default
configuration files into the new host as well. There are quite a few
of these that are easily forgotten. Forgetting to copy some files
like /etc/printcap is soon noticed and fixed, no harm done, but files
like /etc/pam.d/* are not. And results in decreased security!
I am now considering different possibilities of doing these updates
by simply saying update-debian-machines on one of the computers. It
would require some shell scripts and asking the relevant passwords it
would keep me waiting at my console. I do circumvent the login
passwords with ssh/DSA auth, but resenting root logins over the net, I
would still need to type sudo's passwords.
Check out the command= option in the authorized_keys{2,} file. This
info is given in sshd(8). This will allow you to connect with a certain
key and execute a certain command, and no more. This means that even if
someone does steal your unencrypted key somehow, the worst they can do
is run your update script -- never get a login shell. This also saves
you from having to type your sudo password for this purpose, and from
having to keep any suid binaries on your system. Make sure you also set
PermitRootLogin=forced-commands-only in sshd_config. This feature is
very useful for exactly this sort of purpose, when you need a
{semi-,}automated process to run for updates, backups, etc.
I also recommend you use a from= option in the authorized_keys2 file,
as this will require not only retrieval of the secret key, but also
breaking the nameserver/router to spoof the source address (or that the
attacker tries to connect from your admin console). Most likely, someone
trying to abuse your secret key will have gotten your key from the admin
console and will try to abuse it from elsewhere. USe logwatch or
something similar on the target machines to throw up Red Flags if anyone
tries to connect as root from anywhere else.
For added security: no-port-forwarding, no-X11-forwarding,
no-agent-forwarding, and (assuming your script can get away with it)
no-pty.
I can think of three scenarios to compromise the network:
1. To break into my admin console, so as to get my DSA private
key (mod 0600) and break its passphrase.
This is difficult, especially if you use a very difficult passphrase!
2. To break into my admin machine (Getting on any machine would not do
- the DSA key only exists on one, so the cracker would need to break
into my admin console.) and steal my DSA key while it is being used.
Ssh-agent keeps the key (or does it keep the passphrase?
in this case it does not matter) in memory so this should be possible
at least for root on a machine with /dev/mem.
If this is a concern, don't use ssh-agent. Also, With the setup I
suggest, even compromising this key only gives the attacker the ability
to run your update script; nothing more. I'd be worried more about him
exploiting the target machines in the same way your admin console was
compromised, since, in theory, the admin console should be the most
difficult to crack!
3. Break into one of the other machines, use the suided script to
trojan the system and propagate to the other machines that way.
I suggest tripwire to help manage the risk of the update script on the
target machines being trojaned/replaced.
good times,
--
Vineet http://www.anti-dmca.org
Unauthorized use of this .sig may constitute violation of US law.
echo Qba\'g gernq ba zr\! |tr 'a-zA-Z' 'n-za-mN-ZA-M'
pgpRaIYWVzbsu.pgp
Description: PGP signature
ssh vulernability
Hello, Has debian released a new ssh dpkg yet? Thanks. Andrew
Re: ssh vulernability
On Fri, Oct 19, 2001 at 06:06:34PM -0400, [EMAIL PROTECTED] wrote: Hello, Has debian released a new ssh dpkg yet? no -- Ethan Benson http://www.alaska.net/~erbenson/ pgpKxRSjHMTTx.pgp Description: PGP signature
Re: ssh vulernability
I run Debian; and I applied the OpenSSH patch myself as soon as it was posted. Does anybody know of the advantages of waiting for a new .deb file to get circulated are? The patch was a change to two lines of code; so I just made the changes and rebuilt OpenSSH. That's how I do all of my non-kernel patches; seems a bit odd to wait around for the distribution's official patch-maker-squad to churn out a new .DEB file. Garrett Ethan Benson wrote: On Fri, Oct 19, 2001 at 06:06:34PM -0400, [EMAIL PROTECTED] wrote: Hello, Has debian released a new ssh dpkg yet? no -- Ethan Benson http://www.alaska.net/~erbenson/ Part 1.2Type: application/pgp-signature
2.4.12 ???
is stock (non Debian) 2.4.12 now secure or not? i am getting confused. if it isn't, where can i find patches for it to make it secure? sorry to be asking so blatantly, but i don't have much time to worry about my private systems these days. please help. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] there's someone in my head but its not me. -- pink floyd, the dark side of the moon, 1972 pgprosQvJf9fo.pgp Description: PGP signature
Re: 2.4.12 ???
As far as I can tell, yes, the 2.4.12 kernel from kernel.org is secure (at least w/ regard to the bugs listed at http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 I've just built the kernel and ran the exploits provided in the securityfocus article; so far they've failed. Cheng H. Lee On Sat, Oct 20, 2001 at 02:41:08AM +0200, martin f krafft wrote: is stock (non Debian) 2.4.12 now secure or not? i am getting confused. if it isn't, where can i find patches for it to make it secure? sorry to be asking so blatantly, but i don't have much time to worry about my private systems these days. please help. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] there's someone in my head but its not me. -- pink floyd, the dark side of the moon, 1972
