Re: VI wrapper for SUDO? - another bad way ??
martin f krafft [EMAIL PROTECTED] writes: * William R. Ward [EMAIL PROTECTED] [2001.11.29 18:00:40-0800]: Question: Is it generally considered secure enough to sudo a bash script like your sucpaliases? Or should a C equivalent be written instead? no. especially not the quick'n'dirty version that alvin posted. i am not criticizing, but there is an art to writing secure shell scripts. i can't give you full details, but two things that you should *never* forget is using absolute paths for binaries only. in addition, set your PATH to the standard explicitly. [example snipped] Right; but assumin gone takes care of this kind of issue, is there anything inherently unsafe about running shell scripts through sudo? I understand that there are risks of race conditions with setuid shell scripts, and so they are disabled on most Linux boxen. Is that also an issue for sudo shell scripts? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
Gerfried Fuchs writes: * William R. Ward [EMAIL PROTECTED] [2001-12-04 11:56]: Because the thread originated there. I haven't seen it before here. Do you really mean [EMAIL PROTECTED] and not [EMAIL PROTECTED]? Those are two totally different things Maybe you have to resend your message there to let it show up in the correct list. You have my permission to send my messages there, too. For completeness. But please add that I don't read [EMAIL PROTECTED] so if someone answers s/he should consider to Cc: me if it seems relevant. I accidentally sent it to @debian.org, and Colin Watson pointed that error out to me. I re-sent it to @lists.debian.org, which is where the thread belongs. Note that I removed the CC to [EMAIL PROTECTED] The similarity of those two aliases is very confusing. I am also on a number of perl.org's lists, and for that domain the correct address is @perl.org, not @lists.perl.org. I think I confused the two. The original idea was debian-related, in that I wanted to be able to have /etc/alternatives be consulted when deciding what editor to invoke. /etc/alternatives is readable by every user. If you want just to decide there is no need to do this as root. If you want to participate in that part of the discussion I suggest you read the list archives for [EMAIL PROTECTED] --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
martin f krafft [EMAIL PROTECTED] writes: * William R. Ward [EMAIL PROTECTED] [2001.11.29 18:00:40-0800]: Question: Is it generally considered secure enough to sudo a bash script like your sucpaliases? Or should a C equivalent be written instead? no. especially not the quick'n'dirty version that alvin posted. i am not criticizing, but there is an art to writing secure shell scripts. i can't give you full details, but two things that you should *never* forget is using absolute paths for binaries only. in addition, set your PATH to the standard explicitly. [example snipped] Right; but assumin gone takes care of this kind of issue, is there anything inherently unsafe about running shell scripts through sudo? I understand that there are risks of race conditions with setuid shell scripts, and so they are disabled on most Linux boxen. Is that also an issue for sudo shell scripts? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO? - another bad way ??
Gerfried Fuchs writes: * William R Ward [EMAIL PROTECTED] [2001-12-03 00:50]: Right; but assuming one takes care of this kind of issue, is there anything inherently unsafe about running shell scripts through sudo? shell scripts usually call other programs - whose behavior could be most of the time changed with env-variables. It's almost impossible to think of all those things. Yes, it is difficult, but if one is conscientious enough about checking all the environment variables and such it can be done. I understand that there are risks of race conditions with setuid shell scripts, and so they are disabled on most Linux boxen. You have a misinformation/misinterpretation there. It's not disabled, it's simply not possible in the way scripts are run. They are passed to the program that is given in it's first line, after the #! - or to the current shell, if there is no such line. As *argument*. If you think about it how should the suid/sgid bit from an argument be given over to the program which handles that file? There's no way other than using wrappers, like sudo. It's been an option on traditional Unix systems for a long time. When kernel runs the interpreter listed on the #! line, it does so with suid/sgid access enabled. It's not really any more difficult than launching binaries. It's the kernel, not the shell, that parses the #! line. I'm not sure in what ways Linux may differ from traditional Unix on this point, however. Is that also an issue for sudo shell scripts? You should give sudo access to a shell script only to those persons who you trust. After all, think about it - is root really needed there? Most parts don't really need root but can be done through group usages, like most things in Debian works. That gives you another level of abstraction/security. A lot of things, like sendmail for a prominent example, may use group accounts but still expect the files to be owned and writable only by root. Btw, why was this mailed to debian-security? I don't see anything related to debian in that, some general linux (security) mailinglist/newsgroup would suit better. Because the thread originated there. The original idea was debian-related, in that I wanted to be able to have /etc/alternatives be consulted when deciding what editor to invoke. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO? - another bad way ??
Gerfried Fuchs writes: * William R. Ward [EMAIL PROTECTED] [2001-12-04 11:56]: Because the thread originated there. I haven't seen it before here. Do you really mean [EMAIL PROTECTED] and not debian-security@LISTS.debian.org? Those are two totally different things Maybe you have to resend your message there to let it show up in the correct list. You have my permission to send my messages there, too. For completeness. But please add that I don't read debian-security@LISTS.debian.org so if someone answers s/he should consider to Cc: me if it seems relevant. I accidentally sent it to @debian.org, and Colin Watson pointed that error out to me. I re-sent it to @lists.debian.org, which is where the thread belongs. Note that I removed the CC to [EMAIL PROTECTED] The similarity of those two aliases is very confusing. I am also on a number of perl.org's lists, and for that domain the correct address is @perl.org, not @lists.perl.org. I think I confused the two. The original idea was debian-related, in that I wanted to be able to have /etc/alternatives be consulted when deciding what editor to invoke. /etc/alternatives is readable by every user. If you want just to decide there is no need to do this as root. If you want to participate in that part of the discussion I suggest you read the list archives for [EMAIL PROTECTED] --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
VI wrapper for SUDO?
A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. Does such a beast exist? If not, I think it should. It should probably obey the /etc/alternatives preferences for editors, too. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO?
William R Ward [EMAIL PROTECTED] writes: Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. People have mentioned that nvi and vim have secure modes but there is still the risk of running a program that really wasn't designed with modern security issues in mind. Also, for people who don't like to use vi, or who prefer a different version of vi than the one that has the best secure mode, it wouldn't work. It would be better if it was /etc/alternatives/editor rather than nvi or vim. This *is* Debian we're talking about :-) Since the editing can be done with normal user privileges (assuming the source file is readable, and even that can be got around), any editor could be used. Trouble is, that doesn't work with sudo. What I think is needed is a new program that is sudo-aware (probably linked with many of sudo's object files), uses /etc/sudoers for permission, etc. but uses $EDITOR or /etc/alternatives or whatever to choose the actual program for editing. Even emacsclient/gnuclient could do the trick. The only part where root privs are needed is *installing* the edited file. It'd be best to limit the root privs to where they are actually needed. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: how about: ( maybe a dumb idea but...a temporary answer?? user vi /etc/aliases - save it to /tmp/aliases user sucpaliases where sucp: and allow users to run sucp as root - add sucpaliases into the sudo file Not bad... then wrap the whole thing in a script.. editaliases would do the above steps #!/bin/sh tmpfile=/tmp/editaliases$$ cp /etc/aliases $tmpfile /etc/alternatives/editor $tmpfile sudo sucpaliases $tmpfile sudo newaliases # for good measure # end editaliases Question: Is it generally considered secure enough to sudo a bash script like your sucpaliases? Or should a C equivalent be written instead? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: if that sh script is called sucpaliases... you cannot(should not) put sudo sucpaliases inside of it - infinite recursion... Of course not. The script I wrote is editaliases and inside that script, your sucpaliases is called. -- another simpler way is to make /etc/aliases group writable and newaliases for sudo by certain users -- good and bad idea.. -- and you can put /etc/aliases into cvs control tooo These ideas are OK for some things, not for others. Sendmail is picky about the ownership and permissions on certain files. -- c code is subject to buffer overflow problems... -- scripts are susceptable to environment variables changing... Right - but I think the former is easier to thwart. Don't most Linux systems prohibit setuid shell scripts, for example? -- in either case... you have to trust your users that run the scripts/apps to replace /etc/aliases w/o giving um root access Of course, the idea is to give certain permissions to certain users without giving away the farm. That's what sudo's all about. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
VI wrapper for SUDO?
A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. Does such a beast exist? If not, I think it should. It should probably obey the /etc/alternatives preferences for editors, too. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO?
William R Ward [EMAIL PROTECTED] writes: Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. People have mentioned that nvi and vim have secure modes but there is still the risk of running a program that really wasn't designed with modern security issues in mind. Also, for people who don't like to use vi, or who prefer a different version of vi than the one that has the best secure mode, it wouldn't work. It would be better if it was /etc/alternatives/editor rather than nvi or vim. This *is* Debian we're talking about :-) Since the editing can be done with normal user privileges (assuming the source file is readable, and even that can be got around), any editor could be used. Trouble is, that doesn't work with sudo. What I think is needed is a new program that is sudo-aware (probably linked with many of sudo's object files), uses /etc/sudoers for permission, etc. but uses $EDITOR or /etc/alternatives or whatever to choose the actual program for editing. Even emacsclient/gnuclient could do the trick. The only part where root privs are needed is *installing* the edited file. It'd be best to limit the root privs to where they are actually needed. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: how about: ( maybe a dumb idea but...a temporary answer?? user vi /etc/aliases - save it to /tmp/aliases user sucpaliases where sucp: and allow users to run sucp as root - add sucpaliases into the sudo file Not bad... then wrap the whole thing in a script.. editaliases would do the above steps #!/bin/sh tmpfile=/tmp/editaliases$$ cp /etc/aliases $tmpfile /etc/alternatives/editor $tmpfile sudo sucpaliases $tmpfile sudo newaliases # for good measure # end editaliases Question: Is it generally considered secure enough to sudo a bash script like your sucpaliases? Or should a C equivalent be written instead? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: if that sh script is called sucpaliases... you cannot(should not) put sudo sucpaliases inside of it - infinite recursion... Of course not. The script I wrote is editaliases and inside that script, your sucpaliases is called. -- another simpler way is to make /etc/aliases group writable and newaliases for sudo by certain users -- good and bad idea.. -- and you can put /etc/aliases into cvs control tooo These ideas are OK for some things, not for others. Sendmail is picky about the ownership and permissions on certain files. -- c code is subject to buffer overflow problems... -- scripts are susceptable to environment variables changing... Right - but I think the former is easier to thwart. Don't most Linux systems prohibit setuid shell scripts, for example? -- in either case... you have to trust your users that run the scripts/apps to replace /etc/aliases w/o giving um root access Of course, the idea is to give certain permissions to certain users without giving away the farm. That's what sudo's all about. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: shutdown user and accountability
Do you have any source of information about the employees? HR database or something like that? You could cobble together a setuid Perl or C program that asks them information only they would know to authenticate them, verifies it, logs it, and then does a shutdown. Set up a guest account with minimal privileges except for the ability to run that program, and put the login name and password on the keyboard. Even if you don't have the info in the database, you could at least ask them a question only they would know, log it, and then after the fact if you want to find out who it was you could confirm it that way. It's not perfect, but given the policies you have to live with, it may be the only type of solution you can come up with. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shutdown user and accountability
Do you have any source of information about the employees? HR database or something like that? You could cobble together a setuid Perl or C program that asks them information only they would know to authenticate them, verifies it, logs it, and then does a shutdown. Set up a guest account with minimal privileges except for the ability to run that program, and put the login name and password on the keyboard. Even if you don't have the info in the database, you could at least ask them a question only they would know, log it, and then after the fact if you want to find out who it was you could confirm it that way. It's not perfect, but given the policies you have to live with, it may be the only type of solution you can come up with. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: apache log entry
brendan hack writes: Hi All, I found a strange entry hidden among all the IIS exploit attempts in my apache access log today: 61.177.66.228 - - [07/Oct/2001:21:28:44 +1000] GET http://61.177.66.228:8283/ HTTP/1.0 200 756 Does anyone know if this is some sort of attack attempt? It doesn't seem to make any sense as a log entry as there is no leading '/' on the url portion and there is no corresponding error log entry saying that the file 'http://61.177.66.228:8283/' couldn't be found. I also find the fact that the client IP and the url are the same suspicious. I tried retrieving the same file myself using mozilla (http://webserver/http://61.177.66.228:8283/) and it created a similar access entry but with a '/' at the start of the url and there was an error log entry generated. There was a peak in traffic from the server the day after this log entry which instigated the check. Any suggestions will be appreciated. Someone's trying to use you as a proxy. That's what proxy HTTP requests look like. The 200 code suggests that they succeeded. Add something like this to your httpd.conf to block these. (Delete the allow part if you don't want proxying at all; if you do, change the IP addresses to whatever is appropriate for your system.) Directory proxy:* order deny,allow deny from all allow from 192.168.0.0/255.255.0.0 /Directory HTH. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ (formerly known as [EMAIL PROTECTED]) - Life is too important to take seriously. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apache log entry
brendan hack writes: Hi All, I found a strange entry hidden among all the IIS exploit attempts in my apache access log today: 61.177.66.228 - - [07/Oct/2001:21:28:44 +1000] GET http://61.177.66.228:8283/ HTTP/1.0 200 756 Does anyone know if this is some sort of attack attempt? It doesn't seem to make any sense as a log entry as there is no leading '/' on the url portion and there is no corresponding error log entry saying that the file 'http://61.177.66.228:8283/' couldn't be found. I also find the fact that the client IP and the url are the same suspicious. I tried retrieving the same file myself using mozilla (http://webserver/http://61.177.66.228:8283/) and it created a similar access entry but with a '/' at the start of the url and there was an error log entry generated. There was a peak in traffic from the server the day after this log entry which instigated the check. Any suggestions will be appreciated. Someone's trying to use you as a proxy. That's what proxy HTTP requests look like. The 200 code suggests that they succeeded. Add something like this to your httpd.conf to block these. (Delete the allow part if you don't want proxying at all; if you do, change the IP addresses to whatever is appropriate for your system.) Directory proxy:* order deny,allow deny from all allow from 192.168.0.0/255.255.0.0 /Directory HTH. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ (formerly known as [EMAIL PROTECTED]) - Life is too important to take seriously.
Re: Logging practices (and why does it suck in Debian?)
Peter Cordes [EMAIL PROTECTED] writes: On Sat, Apr 14, 2001 at 07:29:05PM -0700, Tim Uckun wrote: Ideally the packages themselves should be labled stable, milestone, snapshot (or something similar) and you ought to be able to subscribe to packages themselves. This way if you trust the authors of a package (say postgres) then you could subscribe to postgres snapshot, but if you are not so sure about mozzilla you could subscribe to mozilla milestone. Well, assuming the version of the package in stable is stable, and the version in unstable is a snapshot, then you can do this with apt. According to apt-preferences(8), installing a package from unstable will cause your system to track the unstable version of that package for future upgrades. This seems to work, from what I've seen :) The trouble is, unstable packages tend to rely on a new version of things like libc6 and other important shared libraries that I don't want to upgrade because it would destabilize the whole system. What I'd like to see is some kind of snapshot status where it was linked against the stable versions of all the common libraries etc. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - Those are my principles. If you don't like them I have others.-Groucho Marx
Re: MD5 sums of individual files?
Olaf Meeuwissen writes: [EMAIL PROTECTED] (William R. Ward) writes: One way to test if you have been hacked is to run an MD5 checksum of key binaries and look to see if it's been replaced by the intruder. Is there any place where the MD5 sums of individual executable files (not the .deb files, but the /usr/bin/ files that come from them) can be obtained? The info you're looking for can, for most packages at least, be found in /var/lib/dpkg/info/*.md5sums. These files have MD5 sums for all files included in the .deb. Note that if you get hacked you can no longer rely on these files (so put them some place safe *before* you let other folks use or connect to your machine). Of course, /usr/bin/md5sum is also suspect and can not be relied upon to tell you the truth. Of course. I'd have to burn a CDROM or something. But it's something I've been meaning to find out about, just in case... -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - Those are my principles. If you don't like them I have others.-Groucho Marx
MD5 sums of individual files?
One way to test if you have been hacked is to run an MD5 checksum of key binaries and look to see if it's been replaced by the intruder. Is there any place where the MD5 sums of individual executable files (not the .deb files, but the /usr/bin/ files that come from them) can be obtained? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - "Those are my principles. If you don't like them I have others."-Groucho Marx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MD5 sums of individual files?
Olaf Meeuwissen writes: [EMAIL PROTECTED] (William R. Ward) writes: One way to test if you have been hacked is to run an MD5 checksum of key binaries and look to see if it's been replaced by the intruder. Is there any place where the MD5 sums of individual executable files (not the .deb files, but the /usr/bin/ files that come from them) can be obtained? The info you're looking for can, for most packages at least, be found in /var/lib/dpkg/info/*.md5sums. These files have MD5 sums for all files included in the .deb. Note that if you get hacked you can no longer rely on these files (so put them some place safe *before* you let other folks use or connect to your machine). Of course, /usr/bin/md5sum is also suspect and can not be relied upon to tell you the truth. Of course. I'd have to burn a CDROM or something. But it's something I've been meaning to find out about, just in case... -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - "Those are my principles. If you don't like them I have others."-Groucho Marx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
MD5 sums of individual files?
One way to test if you have been hacked is to run an MD5 checksum of key binaries and look to see if it's been replaced by the intruder. Is there any place where the MD5 sums of individual executable files (not the .deb files, but the /usr/bin/ files that come from them) can be obtained? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - Those are my principles. If you don't like them I have others.-Groucho Marx
Strange output from last command
My wtmp file seems to have some rather strange entries...
xx pts/3xxx.xxx.xxx.xxx Wed Mar 21 14:17 still logged in
date { Wed Mar 21 02:00 still logged in
date | Wed Mar 21 02:00 still logged in
pts/1xxx.xxx.xxx.xxx Wed Mar 21 01:23 still logged in
pts/3xxx.xxx.xxx.xxx Wed Mar 21 00:09 - 01:23 (01:13)
xxx ftpd23719xxx.xxx.xxx.xxx Tue Mar 20 23:25 - 23:35 (00:10)
xxx ftpd23714xxx.xxx.xxx.xxx Tue Mar 20 23:25 - 23:35 (00:10)
xxx ftpd23702xxx.xxx.xxx.xxx Tue Mar 20 23:24 - 23:25 (00:01)
xx pts/3xxx.xxx.xxx.xxx Tue Mar 20 20:00 - 20:17 (00:17)
xx pts/3xxx.xxx.xxx.xxx Tue Mar 20 19:01 - 19:09 (00:07)
I've replaced the legit usernames and IP's with "xxx" but left them in
for context. I'm worried that the "date" entries are a consequence of
some hacker activity, but I have been unable to find any other
symptoms. I did a web search and did not find any mention of this
sort of thing. I'm using the stable distribution of Debian, with a
2.2.17 kernel.
--Bill.
--
William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/
-
"Those are my principles. If you don't like them I have others."-Groucho Marx
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange output from last command
Mike Dresser writes: "William R. Ward" wrote: I've replaced the legit usernames and IP's with "xxx" but left them in for context. I'm worried that the "date" entries are a consequence of some hacker activity, but I have been unable to find any other symptoms. I did a web search and did not find any mention of this if i run rdate, i get the same thing, entries as date. That's my theory as to what's causing it. That would explain it. I have a cron job that runs rdate and sysclock nightly to set the clock from the NIST atomic clock. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - "Those are my principles. If you don't like them I have others."-Groucho Marx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Strange output from last command
My wtmp file seems to have some rather strange entries...
xx pts/3xxx.xxx.xxx.xxx Wed Mar 21 14:17 still logged in
date { Wed Mar 21 02:00 still logged in
date | Wed Mar 21 02:00 still logged in
pts/1xxx.xxx.xxx.xxx Wed Mar 21 01:23 still logged in
pts/3xxx.xxx.xxx.xxx Wed Mar 21 00:09 - 01:23 (01:13)
xxx ftpd23719xxx.xxx.xxx.xxx Tue Mar 20 23:25 - 23:35 (00:10)
xxx ftpd23714xxx.xxx.xxx.xxx Tue Mar 20 23:25 - 23:35 (00:10)
xxx ftpd23702xxx.xxx.xxx.xxx Tue Mar 20 23:24 - 23:25 (00:01)
xx pts/3xxx.xxx.xxx.xxx Tue Mar 20 20:00 - 20:17 (00:17)
xx pts/3xxx.xxx.xxx.xxx Tue Mar 20 19:01 - 19:09 (00:07)
I've replaced the legit usernames and IP's with xxx but left them in
for context. I'm worried that the date entries are a consequence of
some hacker activity, but I have been unable to find any other
symptoms. I did a web search and did not find any mention of this
sort of thing. I'm using the stable distribution of Debian, with a
2.2.17 kernel.
--Bill.
--
William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/
-
Those are my principles. If you don't like them I have others.-Groucho Marx
Re: Strange output from last command
Mike Dresser writes: William R. Ward wrote: I've replaced the legit usernames and IP's with xxx but left them in for context. I'm worried that the date entries are a consequence of some hacker activity, but I have been unable to find any other symptoms. I did a web search and did not find any mention of this if i run rdate, i get the same thing, entries as date. That's my theory as to what's causing it. That would explain it. I have a cron job that runs rdate and sysclock nightly to set the clock from the NIST atomic clock. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - Those are my principles. If you don't like them I have others.-Groucho Marx
Re: News server ?
"Matus \"fantomas\" Uhlar" [EMAIL PROTECTED] writes: - Is there any other way to get your mails? I have to fetch about a 20 mailis - per day, Is the debian-security on any news server? like - debian.security.annonce ? - thx pshemol - - i was informed last time that i asked that all debian lists should be in USENET - under linux.debian.* and this particular list should be - linux.debian.announce.security (although all servers i've checked don't have - this group) well so, 1. I've heard some time ago the linux.* hierarchy is dead. Yes, I don't think that ever really got off the ground. 2. debian is NOT a linux distribution - it's packaging system It's both. so, if at all, comp.os.debian or comp.unix.debian would be much better. Usenet is such a zoo nowadays that would be too painful to contemplate. I am planning to make gateway with debian mailing lists gatewayed for my personal tests, on my machine or our firm news server, but it will take some time. Then, probably... I wonder if the maintainers of lists.debian.org would consider running INND and converting the lists to newsgroups. There are tools to translate newsgroups to/from mailing lists for those who want that, and you can also access them directly with a newsreader if you wish. It's not really common, but it's not unusual for sites that have a lot of mailing lists to run a news server in this way, and I'm sure some of the software for it is already part of Debian. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - "Those are my principles. If you don't like them I have others."-Groucho Marx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: News server ?
Matus \fantomas\ Uhlar [EMAIL PROTECTED] writes: - Is there any other way to get your mails? I have to fetch about a 20 mailis - per day, Is the debian-security on any news server? like - debian.security.annonce ? - thx pshemol - - i was informed last time that i asked that all debian lists should be in USENET - under linux.debian.* and this particular list should be - linux.debian.announce.security (although all servers i've checked don't have - this group) well so, 1. I've heard some time ago the linux.* hierarchy is dead. Yes, I don't think that ever really got off the ground. 2. debian is NOT a linux distribution - it's packaging system It's both. so, if at all, comp.os.debian or comp.unix.debian would be much better. Usenet is such a zoo nowadays that would be too painful to contemplate. I am planning to make gateway with debian mailing lists gatewayed for my personal tests, on my machine or our firm news server, but it will take some time. Then, probably... I wonder if the maintainers of lists.debian.org would consider running INND and converting the lists to newsgroups. There are tools to translate newsgroups to/from mailing lists for those who want that, and you can also access them directly with a newsreader if you wish. It's not really common, but it's not unusual for sites that have a lot of mailing lists to run a news server in this way, and I'm sure some of the software for it is already part of Debian. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - Those are my principles. If you don't like them I have others.-Groucho Marx
Re: SSH with potato, not very secure?
Ethan Benson [EMAIL PROTECTED] writes: One reason why I did not install any security-updates to SSH1.1 is that on the web page of www.debian.org they say that there is a remote exploit in OpenSSH (DSA-027) but it is fixed in Debian 2.2 (potato) and that is the one I installed. I did not think that I had to install all security-updates as well, figured they would be in the install. Perhaps that is something which should be clearly stated on the debian pages? always install security updates, thats HOW debian fixes security problems. =20 That's all well and good if people know about security.debian.org. I've been running debian for many years and only found out about it a couple of weeks ago. All this time I've been assuming that security updates were merged into the "stable" branch, and as long as I periodically ran dselect and [U]pdated and [I]nstalled the updates, I'd be covered. Since this appears to not be the case, is there something that can be done to make this fact more readily apparent to users? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - "Those are my principles. If you don't like them I have others."-Groucho Marx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH with potato, not very secure?
Ethan Benson [EMAIL PROTECTED] writes: One reason why I did not install any security-updates to SSH1.1 is that on the web page of www.debian.org they say that there is a remote exploit in OpenSSH (DSA-027) but it is fixed in Debian 2.2 (potato) and that is the one I installed. I did not think that I had to install all security-updates as well, figured they would be in the install. Perhaps that is something which should be clearly stated on the debian pages? always install security updates, thats HOW debian fixes security problems. =20 That's all well and good if people know about security.debian.org. I've been running debian for many years and only found out about it a couple of weeks ago. All this time I've been assuming that security updates were merged into the stable branch, and as long as I periodically ran dselect and [U]pdated and [I]nstalled the updates, I'd be covered. Since this appears to not be the case, is there something that can be done to make this fact more readily apparent to users? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - Those are my principles. If you don't like them I have others.-Groucho Marx
