Re: rkhunter on Etch
2008/8/29 Andrei Popescu [EMAIL PROTECTED] Say package foo has a security issue and upstream is at 1.4 and Debian still has 1.3. Upstream will most likely release 1.4.1 to fix the issue (which could be just a few lines of code) and maybe some others small bugfixes that were pending. Debian instead will look for the exact change for the security fix and apply it to the 1.3 version. In most cases it will not even need adaptation for 1.3 so they can just apply the specific patch. However, they will ignore whatever *other* changes have happened between 1.3 and 1.4 and also between 1.4 and 1.4.1. Unstable will of course get 1.4.1 ASAP. volatile is suited for packages that change *often* and will become unusable unless you upgrade. A good example is an antivirus software and its definition files. Even if you upgrade the definitions you also have to upgrade the software itself in order for it to detect new viruses. I'm not sure rkhunter qualifies for volatile, but you should be able to find the requirements somewhere on the 'net. Making backports.org an official Debian service would solve issues like this, but I guess manpower is lacking... Thanks for the comments, Andrei. I feel I'm starting to understand much better how Debian packages are maintained, and when I should consider backports or non-stable packages (i.e. only as a last resort, if the needed functionality isn't available in stable). Sam
Re: rkhunter on Etch
On Thu,28.Aug.08, 22:27:04, Sam Kuper wrote: [...] Okay, so if I understand you correctly, a backport is a kind of refactoring: the overt functionality doesn't change, but the underlying functionality does (the refactored code is more secure, or less memory intensive, or what-have-you depending on the nature of the fix). I hadn't previously quite been sure that backports really are intended to *not change the overt functionality*. Say package foo has a security issue and upstream is at 1.4 and Debian still has 1.3. Upstream will most likely release 1.4.1 to fix the issue (which could be just a few lines of code) and maybe some others small bugfixes that were pending. Debian instead will look for the exact change for the security fix and apply it to the 1.3 version. In most cases it will not even need adaptation for 1.3 so they can just apply the specific patch. However, they will ignore whatever *other* changes have happened between 1.3 and 1.4 and also between 1.4 and 1.4.1. Unstable will of course get 1.4.1 ASAP. It looks like your environment requires you to use new features in the latest version of this package so you should just use that package from lenny - mixing one or 2 packages from lenny isn't going to cause any harm. This is an interesting suggestion, given that near the start of this thread, one of Debian's rkhunter package maintainers recommended against this approach, and advised using his unofficial rkhunter backport instead. So now I'm confused: which is the better approach for me to take? Also, why would a maintainer be maintaining unofficial backports instead of (or as well as) official ones? volatile is suited for packages that change *often* and will become unusable unless you upgrade. A good example is an antivirus software and its definition files. Even if you upgrade the definitions you also have to upgrade the software itself in order for it to detect new viruses. I'm not sure rkhunter qualifies for volatile, but you should be able to find the requirements somewhere on the 'net. Making backports.org an official Debian service would solve issues like this, but I guess manpower is lacking... Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: rkhunter on Etch
Sam Kuper wrote: Okay, so if I understand you correctly, a backport is a kind of refactoring: the overt functionality doesn't change, but the underlying functionality does (the refactored code is more secure, or less memory intensive, or what-have-you depending on the nature of the fix). I hadn't previously quite been sure that backports really are intended to *not change the overt functionality*. The idea with backporting is you only backport the particular patch necessary to close the security hole or fix the bug, not any other patches/code changes that have occured since your release version. So yes the idea is to make the minimum change necessary to fix the bug, and it shouldn't change the functionality of the program. So now I'm confused: which is the better approach for me to take? Also, why would a maintainer be maintaining unofficial backports instead of (or as well as) official ones? With thanks in advance for your advice! Sam Probably better to take the maintainer's advice as he knows more about it than I do. I was just saying that when I've been in this situation, whether on Redhat, Debian or other distros I usually take the more updated package from the next in-development version of the distro. I haven't had many problems with this, but as always YMMV, good luck. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rkhunter on Etch
On 2008-08-28 10:00, Tim Edwards wrote: The way Debian does it this is the same as virtually every other major Linux distro - Suse/OpenSuse, Redhat, Fedora, Mandriva, Ubuntu etc. That is they release a new distro version every X months, in Debian-speak these are called 'stable' releases, and then provide *backported* security and bug fix updates for however long that version is in support. These fixes are backported into the version of each package that was released with the distro to ensure stability - as no new features are being added the behaviour of the packaged software shouldn't change. But you still get the benefit of security and bug fixes so you get both a stable system (as in the behaviour of the software on it is consistent) and a secure one (up-to-date on all security patches). That's new to me. Were did you get this information? IIRC it's a unique feature of debian (and/or debian based systems) to get security fixes backported. As an example, see suse's security annnouncements, where first firefox is updated to version 2.0.0.13 [1] and later to 2.0.0.13 [2], ie. the fixes are *not* backported to 2.0.0.13. Debian is famous for its stability, especially for servers, so it shouldn't be questioned as that. People who prefer more regular updates have either the option to use the unofficial and not so stable and reliable 'testing' and 'unstable' branches or to switch to other distros. This is the freedom of the software, debian provides. Please don't forget that security is a _concept_ not just _one_ particular piece of software installed on your system[*]. I believe that you will get a really secure system, if you configure and maintain your 'stable' debian responsibly. A slightly outdated version of rkhunter is of minor importance here. A careful study of 'harden-doc' (install it with aptitude) will probably lead to a more secure system than to solely rely on one piece of software. Just MHO, take care, IANAL nor a security expert, Johannes [1] http://www.novell.com/linux/security/advisories/2008_19_firefox.html [2] http://www.novell.com/linux/security/advisories/2008_34_firefox.html [*] For obvious reasons, more or less all *vendors* of security 'suites' that fix some of the shortcomings of the OS with the largest market capitalisation (in ) will claim the opposite. If it was that simple, however, there would be much less talk about security problems of that certain OS than we hear in the media and elsewhere. (But I am drifting OT...) signature.asc Description: OpenPGP digital signature
Re: rkhunter on Etch
2008/8/29 Tim Edwards [EMAIL PROTECTED] Probably better to take the maintainer's advice as he knows more about it than I do. Thanks for clearing this up; will do. I was just saying that when I've been in this situation, whether on Redhat, Debian or other distros I usually take the more updated package from the next in-development version of the distro. I haven't had many problems with this, but as always YMMV, good luck. Cheers for this explanation too. If I find any other packages for which I need newer versions than are in Etch, I'll try using backports or Lenny packages. Sam
Re: rkhunter on Etch
2008/8/29 Johannes Wiedersich [EMAIL PROTECTED] A careful study of 'harden-doc' (install it with aptitude) will probably lead to a more secure system than to solely rely on one piece of software. Agreed. I'm planning to use some packages from the hardening suite. The problem with rkhunter in Etch is that it relies on a script called hashupd.sh that isn't included in the package, and is not easy to find online. If rkhunter in Etch was a complete version of rkhunter 1.2.9, I wouldn't be asking these questions, but it's not. Thanks for the advice, though, Sam
Re: rkhunter on Etch
Johannes Wiedersich wrote: On 2008-08-28 10:00, Tim Edwards wrote: The way Debian does it this is the same as virtually every other major Linux distro - Suse/OpenSuse, Redhat, Fedora, Mandriva, Ubuntu etc. That is they release a new distro version every X months, in Debian-speak these are called 'stable' releases, and then provide *backported* security and bug fix updates for however long that version is in support. These fixes are backported into the version of each package that was released with the distro to ensure stability - as no new features are being added the behaviour of the packaged software shouldn't change. But you still get the benefit of security and bug fixes so you get both a stable system (as in the behaviour of the software on it is consistent) and a secure one (up-to-date on all security patches). That's new to me. Were did you get this information? IIRC it's a unique feature of debian (and/or debian based systems) to get security fixes backported. As an example, see suse's security annnouncements, where first firefox is updated to version 2.0.0.13 [1] and later to 2.0.0.13 [2], ie. the fixes are *not* backported to 2.0.0.13. That's what I mean - they've backported the security/bug updates into their firefox 2.0.0.13 package, ie. it's still firefox 2.0.0.13 but with some fixes from 2.0.0.16 (or whatever the latest is) included. This is taking a patch and applying it to an older version of the software than it was intended (http://www.reference.com/search?r=13q=Backporting) and it's certainly not unique to Debian. On RPM distros they increment the release number on the RPM when they do this. http://www.redhat.com/security/updates/backporting/?sc_cid=3093 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rkhunter on Etch
On 2008-08-29 11:42, Tim Edwards wrote: Johannes Wiedersich wrote: On 2008-08-28 10:00, Tim Edwards wrote: That's new to me. Were did you get this information? IIRC it's a unique feature of debian (and/or debian based systems) to get security fixes backported. As an example, see suse's security annnouncements, where first firefox is updated to version 2.0.0.13 [1] and later to 2.0.0.13 ^^^ Sorry for the typo, it should read: 2.0.0.15 [2], ie. the fixes are *not* backported to 2.0.0.13. That's what I mean - they've backported the security/bug updates into their firefox 2.0.0.13 package, ie. it's still firefox 2.0.0.13 but with some fixes from 2.0.0.16 (or whatever the latest is) included. No. In this case it seems they replaced firefox 2.0.0.13 by upstream's next version. (If they'd fix mozilla's code by themselfs in a similar fashion as debian, they wouldn't be allowed to call it 'firefox'. This is the reason why firefox [was|had to be] rebranded to iceweasel in debian. ) This is taking a patch and applying it to an older version of the software than it was intended (http://www.reference.com/search?r=13q=Backporting) and it's certainly not unique to Debian. On RPM distros they increment the release number on the RPM when they do this. http://www.redhat.com/security/updates/backporting/?sc_cid=3093 From this and [1] and [2] (look at the version number of firefox) I infer that Redhat *sometimes* employs security backports (if they can't escape it) and usually just upgrades to the next upstream version. Debian *always* backports security fixes to its stable release. Cheers, Johannes [1] https://www.redhat.com/archives/enterprise-watch-list/2008-July/msg2.html [2] https://www.redhat.com/archives/enterprise-watch-list/2008-July/msg00017.html signature.asc Description: OpenPGP digital signature
Re: rkhunter on Etch
Johannes Wiedersich wrote: On 2008-08-29 11:42, Tim Edwards wrote: Johannes Wiedersich wrote: On 2008-08-28 10:00, Tim Edwards wrote: That's new to me. Were did you get this information? IIRC it's a unique feature of debian (and/or debian based systems) to get security fixes backported. As an example, see suse's security annnouncements, where first firefox is updated to version 2.0.0.13 [1] and later to 2.0.0.13 ^^^ Sorry for the typo, it should read: 2.0.0.15 [2], ie. the fixes are *not* backported to 2.0.0.13. That's what I mean - they've backported the security/bug updates into their firefox 2.0.0.13 package, ie. it's still firefox 2.0.0.13 but with some fixes from 2.0.0.16 (or whatever the latest is) included. No. In this case it seems they replaced firefox 2.0.0.13 by upstream's next version. (If they'd fix mozilla's code by themselfs in a similar fashion as debian, they wouldn't be allowed to call it 'firefox'. This is the reason why firefox [was|had to be] rebranded to iceweasel in debian. ) This is taking a patch and applying it to an older version of the software than it was intended (http://www.reference.com/search?r=13q=Backporting) and it's certainly not unique to Debian. On RPM distros they increment the release number on the RPM when they do this. http://www.redhat.com/security/updates/backporting/?sc_cid=3093 From this and [1] and [2] (look at the version number of firefox) I infer that Redhat *sometimes* employs security backports (if they can't escape it) and usually just upgrades to the next upstream version. Debian *always* backports security fixes to its stable release. Cheers, Johannes [1] https://www.redhat.com/archives/enterprise-watch-list/2008-July/msg2.html [2] https://www.redhat.com/archives/enterprise-watch-list/2008-July/msg00017.html Ok I take your point about Firefox, I have seen some distros (eg. Mandriva) do this - just upgrade to the next minor version. But with Firefox it's no different to a backport as the minor versions are only security/bug fixes, no feature changes. If you have even a quick glance over the updates repo vs. the release repos for any of the non-Deb distros I mentioned you will see Firefox is definitely the exception to the rule. Also the article I linked definitely doesn't say that Redhat only *sometimes* employs security backports (if they can't escape it)! It says that they sometimes make special exceptions to their *default* policy of backporting: Whilst on some products our default policy is to backport security fixes, we do from time to time provide version updates of some packages after careful testing and analysis. These are likely to be packages that have no interaction with others, or are used by an end-user (such as a web browser). Backporting is not unique to Debian, it is the usual behaviour of the maintainers of other distros as well, otherwise these distros just wouldn't be stable enough production. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rkhunter on Etch
Sam Kuper wrote: 2008/8/27 Chris Bannister [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: On Tue, Aug 26, 2008 at 03:30:37AM +0100, Sam Kuper wrote: (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter in Etch to version 1.3.2. http://1.3.2. If successful, this would undoubtedly be the best solution. Dear Micah and Julien, how about it? Sysadmins will love you even more than they do already! :) Not a chance. Why do you think its called stable? Perhaps naively, I thought it was called stable because it was for systems that had to be stable, stable in this case meaning reliable. To me, this suggests that stable releases should not have the latest toys packaged (most people don't need a Mozilla Ubiquity beta on their production servers), nor even necessarily the latest utilities, in order to minimise potential conflicts between packages. What it should have, however, are up-to-date security packages. A rooted server is not a stable one: it could be brought down, outside of its sysadmin's control, at any minute. Maybe I was wrong to think that the priority is that the computer on which the OS is installed is stable (reliable), and not that the OS itself is stable (unchanging). Furthermore, even on the latter interpretation of the significance of calling the release stable, isn't it the case that Etch still includes security fixes? Well, if in order to run rkhunter - a program which can be important to maintaining a system's security - a download is needed that is no longer available and isn't included in the stable package, shouldn't that be fixed? I think it should, which is why I wrote the email that generated this thread. The way Debian does it this is the same as virtually every other major Linux distro - Suse/OpenSuse, Redhat, Fedora, Mandriva, Ubuntu etc. That is they release a new distro version every X months, in Debian-speak these are called 'stable' releases, and then provide *backported* security and bug fix updates for however long that version is in support. These fixes are backported into the version of each package that was released with the distro to ensure stability - as no new features are being added the behaviour of the packaged software shouldn't change. But you still get the benefit of security and bug fixes so you get both a stable system (as in the behaviour of the software on it is consistent) and a secure one (up-to-date on all security patches). The tradeoff of course is that you don't get the latest versions of every package that's just been released. It's alright to think about upgrading one package to the latest version but when you have 20,000 or so, all constantly changing and on the bleeding-edge version you wouldn't have a very usable distro. It looks like your environment requires you to use new features in the latest version of this package so you should just use that package from lenny - mixing one or 2 packages from lenny isn't going to cause any harm. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rkhunter on Etch
2008/8/28 Tim Edwards [EMAIL PROTECTED] The way Debian does it this is [...] release a new distro version every X months, in Debian-speak these are called 'stable' releases, and then provide *backported* security and bug fix updates for however long that version is in support. These fixes are backported into the version of each package that was released with the distro to ensure stability - as no new features are being added the behaviour of the packaged software shouldn't change. But you still get the benefit of security and bug fixes so you get both a stable system (as in the behaviour of the software on it is consistent) and a secure one (up-to-date on all security patches). Okay, so if I understand you correctly, a backport is a kind of refactoring: the overt functionality doesn't change, but the underlying functionality does (the refactored code is more secure, or less memory intensive, or what-have-you depending on the nature of the fix). I hadn't previously quite been sure that backports really are intended to *not change the overt functionality*. The tradeoff of course is that you don't get the latest versions of every package that's just been released. It's alright to think about upgrading one package to the latest version but when you have 20,000 or so, all constantly changing and on the bleeding-edge version you wouldn't have a very usable distro. Agreed, for the most part. With security packages, I'm less certain. I guess this is because with security packages, there's a grey area in which what constitutes a security fix (and therefore will be backported) and what constitutes a new feature, is disputable. My impression is that perhaps not everything It looks like your environment requires you to use new features in the latest version of this package so you should just use that package from lenny - mixing one or 2 packages from lenny isn't going to cause any harm. This is an interesting suggestion, given that near the start of this thread, one of Debian's rkhunter package maintainers recommended against this approach, and advised using his unofficial rkhunter backport instead. So now I'm confused: which is the better approach for me to take? Also, why would a maintainer be maintaining unofficial backports instead of (or as well as) official ones? With thanks in advance for your advice! Sam
Re: rkhunter on Etch
On Tue, Aug 26, 2008 at 03:30:37AM +0100, Sam Kuper wrote: (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter in Etch to version 1.3.2. If successful, this would undoubtedly be the best solution. Dear Micah and Julien, how about it? Sysadmins will love you even more than they do already! :) Not a chance. Why do you think its called stable? -- Chris. == I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. -- Sir Stephen Henry Roberts -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rkhunter on Etch
2008/8/27 Chris Bannister [EMAIL PROTECTED]: On Tue, Aug 26, 2008 at 03:30:37AM +0100, Sam Kuper wrote: (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter in Etch to version 1.3.2. If successful, this would undoubtedly be the best solution. Dear Micah and Julien, how about it? Sysadmins will love you even more than they do already! :) Not a chance. Why do you think its called stable? Perhaps naively, I thought it was called stable because it was for systems that had to be stable, stable in this case meaning reliable. To me, this suggests that stable releases should not have the latest toys packaged (most people don't need a Mozilla Ubiquity beta on their production servers), nor even necessarily the latest utilities, in order to minimise potential conflicts between packages. What it should have, however, are up-to-date security packages. A rooted server is not a stable one: it could be brought down, outside of its sysadmin's control, at any minute. Maybe I was wrong to think that the priority is that the computer on which the OS is installed is stable (reliable), and not that the OS itself is stable (unchanging). Furthermore, even on the latter interpretation of the significance of calling the release stable, isn't it the case that Etch still includes security fixes? Well, if in order to run rkhunter - a program which can be important to maintaining a system's security - a download is needed that is no longer available and isn't included in the stable package, shouldn't that be fixed? I think it should, which is why I wrote the email that generated this thread. That said, if this isn't the Debian way, and/or I'm misunderstanding the significance, in the Debian context, of the term stable (this is quite possible - in which case, I'd welcome correction), it's not the end of the world. It'll just mean that pure Etch systems aren't quite as secure as they could be. Sam PS. Hmm, I delayed sending the reply above in order to have some more time to think about the different kinds of stability that are important for production servers, etc. While I've explained above that I place great store by the reliability of a computer system, and have emphasised that this can be aided by updates that add missing security functionality, I've not examined the merits of the other kind of stability: the kind of stability that refers to the intentional unchanging or barely-changing nature of the software on the system. I'll do that a bit more here, to see if I'm understanding its importance, and the reason there's not a chance (see Chris Bannister above) rkhunter in Etch will be upgraded to 1.3.2. The reason is: *rkhunter 1.3.2 works differently to 1.2.9. If you have a script that calls 1.2.9 a particular way, that script may just possibly get broken by upgrading to rkhunter 1.3.2. This sort of thing could pose a security risk. Therefore, it's better to keep Etch's rkhunter at 1.2.9 and only patch it if an exploit in it is discovered.* Now, I'm not sure I agree with that reason entirely. I think it has merit, but then so does the alternative approach I raised earlier in this email. Which has the greater merit? I guess the community's judgement has been that the Stable software should change as little as possible argument beats the Stable software should change as much as it needs to to ensure packages useful for security are up-to-date and usable without requiring external downloads one. And you know what? After this extra reflection, I'm almost convinced that the community's judgement was correct. With more time, I might become wholly convinced; we'll see... :) Chris, thank you for the thought-provoking question. Sam
Re: rkhunter on Etch
On Thu, Aug 28, 2008 at 04:01:40AM +0100, Sam Kuper wrote: 2008/8/27 Chris Bannister [EMAIL PROTECTED]: On Tue, Aug 26, 2008 at 03:30:37AM +0100, Sam Kuper wrote: (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter in Etch to version 1.3.2. If successful, this would undoubtedly be the best solution. Dear Micah and Julien, how about it? Sysadmins will love you even more than they do already! :) Not a chance. Why do you think its called stable? Perhaps naively, I thought it was called stable because it was for systems that had to be stable, stable in this case meaning reliable. To me, this suggests that stable releases should not have the latest toys packaged (most people don't need a Mozilla Ubiquity beta on their production servers), nor even necessarily the latest utilities, in order to minimise potential conflicts between packages. What it should have, however, are up-to-date security packages. A rooted server is not a stable one: it could be brought down, outside of its sysadmin's control, at any minute. I'm not familiar with rkhunter, but wouldn't this kind of situation make it a candidate for volatile? Cheers, Tom -- Out of register space (ugh) -- vi signature.asc Description: Digital signature
Re: rkhunter on Etch
Hi Sam, Thanks for your e-mail. Le mardi 26 août 2008 à 03:30 +0100, Sam Kuper a écrit : Dear Debian users and rkhunter maintainers for Etch, I've been trying to set up rkhunter on my Debian Etch VPS, and I've run into a few problems. (In case it's significant, this VPS is virtualised via OpenVZ; I have root access to the VPS but not the underlying system.) The first problem is this. When I run rkhunter -c, after performing the 'known bad' checks, rkhunter gives the message, Performing 'known good' check... Info: Check skipped - no hashes available. This is the default situation, you first have to create the hashes database. [...] Be sure to understand that rkhunter hashes test is not meant to replace more powerful tools, like eg. integrit. (1*) Use the version of hashupd.sh at http://rkhunter.cvs.sourceforge.net/rkhunter/hashupd/ . I'm a little nervous about doing this, as it's not the same age as rkhunter 1.2.9 and may not be totally compatible. Rootkit detection isn't to be trifled with, so I'd rather not take the risk without assurances from Debian's rkhunter maintainer that this version of hashupd.sh is okay for use with 1.2.9. (NB. I've asked the rkhunter-users list if I can ask for support there for 1.2.9; the answer was: no. See email below.) Micah, Julien, is this version of hashupd.sh okay for use with rkhunter 1.2.9? Yes, I think so, though not recently tested. 1.3.2 has a replacement tool for hashupd.sh embedded in the core package. (2*) Use the package from Lenny instead. I'm loath to do this. It feels like a slippery slope. I really want to run a pure Debian Stable system if at all possible. But if consensus among users/maintainers is that using the package from Lenny is the best solution to problem 2, I'll be willing to try it. Not needed (3*) Forego the Debian packages altogether; just download the source and build it myself. Well, it's certainly possible. But that would kind of defeat the main reason I chose to run Debian: easy and fast package management and upgrades; minimal compiling necessary. I supply ***unofficial*** backports of rkhunter package in my personal repository at http://packages.kirya.net I use these backports on my servers. This might be the best solution for you is you want to benefit from all the improvements of the newer releases. (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter in Etch to version 1.3.2. If successful, this would undoubtedly be the best solution. Dear Micah and Julien, how about it? Sysadmins will love you even more than they do already! :) Etch is the current stable distribution, hence cannot be updated (except for major issues, eg. security fixes). Looking forward to your replies, Sam -- Forwarded message -- From: Nils Breunese (Lemonbit) [EMAIL PROTECTED] Date: 2008/8/25 Subject: Re: [Rkhunter-users] Welcome to the Rkhunter-users mailing list To: [EMAIL PROTECTED] Sam Kuper wrote: Q1) The advice page for this mailing list states, If you are not running the latest version: please check the website for the latest version and upgrade first. I use Debian 4 (Etch), which is the latest stable Debian release. Like most users of Debian stable, I upgrade by using apt-get update; apt-get upgrade. Doing this gives me rkhunter 1.2.9, whereas running rkhunter --versioncheck reveals that the latest release of rkhunter is 1.3.2. I do not want to use testing Debian packages on my server, as I am concerned about stability. Yet rkhunter 1.2.9 is giving me some problems. My question is, then: can I expect support from this mailing list for rkhunter 1.2.9 or must I look elsewhere? rkhunter 1.2.9 is not supported anymore. Contact Debian's package maintainer if you have problems with this old version. Q2) The advice page for this mailing list states, Hashupd is on our download page. Please see the FAQ for details. Actually, it isn't, and yes, I have checked the online FAQ for an up-to-date link to the download page, in case I was looking in the wrong place. So, please could you tell me where I can obtain Hashupd? hashupd was a script for rkhunter 1.2.9. The rkhunter 1.2.9 files are no longer available on the project page, so that's probably why hashupd is also no longer there. The FAQ should be updated, yes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rkhunter on Etch
Dear Julien, Thanks for your prompt reply (below). I suppose that as long as I'm sticking with Etch, I'll have to decide between: option 1; option 3; or using integrit or suchlike, and not bothering to update rkhunter's hashes (I wasn't previously aware of integrit, so thanks for the pointer). All best, Sam 2008/8/26 Julien Valroff [EMAIL PROTECTED]: Hi Sam, Thanks for your e-mail. Le mardi 26 août 2008 à 03:30 +0100, Sam Kuper a écrit : Dear Debian users and rkhunter maintainers for Etch, I've been trying to set up rkhunter on my Debian Etch VPS, and I've run into a few problems. (In case it's significant, this VPS is virtualised via OpenVZ; I have root access to the VPS but not the underlying system.) The first problem is this. When I run rkhunter -c, after performing the 'known bad' checks, rkhunter gives the message, Performing 'known good' check... Info: Check skipped - no hashes available. This is the default situation, you first have to create the hashes database. [...] Be sure to understand that rkhunter hashes test is not meant to replace more powerful tools, like eg. integrit. (1*) Use the version of hashupd.sh at http://rkhunter.cvs.sourceforge.net/rkhunter/hashupd/ . I'm a little nervous about doing this, as it's not the same age as rkhunter 1.2.9 and may not be totally compatible. Rootkit detection isn't to be trifled with, so I'd rather not take the risk without assurances from Debian's rkhunter maintainer that this version of hashupd.sh is okay for use with 1.2.9. (NB. I've asked the rkhunter-users list if I can ask for support there for 1.2.9; the answer was: no. See email below.) Micah, Julien, is this version of hashupd.sh okay for use with rkhunter 1.2.9? Yes, I think so, though not recently tested. 1.3.2 has a replacement tool for hashupd.sh embedded in the core package. (2*) Use the package from Lenny instead. I'm loath to do this. It feels like a slippery slope. I really want to run a pure Debian Stable system if at all possible. But if consensus among users/maintainers is that using the package from Lenny is the best solution to problem 2, I'll be willing to try it. Not needed (3*) Forego the Debian packages altogether; just download the source and build it myself. Well, it's certainly possible. But that would kind of defeat the main reason I chose to run Debian: easy and fast package management and upgrades; minimal compiling necessary. I supply ***unofficial*** backports of rkhunter package in my personal repository at http://packages.kirya.net I use these backports on my servers. This might be the best solution for you is you want to benefit from all the improvements of the newer releases. (4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter in Etch to version 1.3.2. If successful, this would undoubtedly be the best solution. Dear Micah and Julien, how about it? Sysadmins will love you even more than they do already! :) Etch is the current stable distribution, hence cannot be updated (except for major issues, eg. security fixes). Looking forward to your replies, Sam -- Forwarded message -- From: Nils Breunese (Lemonbit) [EMAIL PROTECTED] Date: 2008/8/25 Subject: Re: [Rkhunter-users] Welcome to the Rkhunter-users mailing list To: [EMAIL PROTECTED] Sam Kuper wrote: Q1) The advice page for this mailing list states, If you are not running the latest version: please check the website for the latest version and upgrade first. I use Debian 4 (Etch), which is the latest stable Debian release. Like most users of Debian stable, I upgrade by using apt-get update; apt-get upgrade. Doing this gives me rkhunter 1.2.9, whereas running rkhunter --versioncheck reveals that the latest release of rkhunter is 1.3.2. I do not want to use testing Debian packages on my server, as I am concerned about stability. Yet rkhunter 1.2.9 is giving me some problems. My question is, then: can I expect support from this mailing list for rkhunter 1.2.9 or must I look elsewhere? rkhunter 1.2.9 is not supported anymore. Contact Debian's package maintainer if you have problems with this old version. Q2) The advice page for this mailing list states, Hashupd is on our download page. Please see the FAQ for details. Actually, it isn't, and yes, I have checked the online FAQ for an up-to-date link to the download page, in case I was looking in the wrong place. So, please could you tell me where I can obtain Hashupd? hashupd was a script for rkhunter 1.2.9. The rkhunter 1.2.9 files are no longer available on the project page, so that's probably why hashupd is also no longer there. The FAQ should be updated, yes.
rkhunter on Etch
Dear Debian users and rkhunter maintainers for Etch,
I've been trying to set up rkhunter on my Debian Etch VPS, and I've
run into a few problems. (In case it's significant, this VPS is
virtualised via OpenVZ; I have root access to the VPS but not the
underlying system.)
The first problem is this. When I run rkhunter -c, after performing
the 'known bad' checks, rkhunter gives the message, Performing 'known
good' check... Info: Check skipped - no hashes available.
Now, my understanding (from reading rkhunter documentation on the web,
and mailing list posts) is that the solution to this problem is to run
a script called hashupd.sh, which is made available by the rkhunter
developers. However, it turns out that hashupd.sh is not included with
the rkhunter package in Etch. Nor does it have its own package. Nor is
it any longer available on rkhunter's SourceForge download page,
because the latest version of rkhunter (1.3.2) does not require it.
Yet the version of rkhunter available in Etch is 1.2.9, which does
require it.
So in order to solve the first problem ('known good' check being
skipped), I have to solve a second, harder problem, which is: how do I
provide hashes to rkhunter on my server?
I can think of four solutions to this, three of which (starred below)
should not be required, IMHO, for users of a widely adopted, widely
recommended package for a stable OS release. They are:
(1*) Use the version of hashupd.sh at
http://rkhunter.cvs.sourceforge.net/rkhunter/hashupd/ . I'm a little
nervous about doing this, as it's not the same age as rkhunter 1.2.9
and may not be totally compatible. Rootkit detection isn't to be
trifled with, so I'd rather not take the risk without assurances from
Debian's rkhunter maintainer that this version of hashupd.sh is okay
for use with 1.2.9. (NB. I've asked the rkhunter-users list if I can
ask for support there for 1.2.9; the answer was: no. See email below.)
Micah, Julien, is this version of hashupd.sh okay for use with
rkhunter 1.2.9?
(2*) Use the package from Lenny instead. I'm loath to do this. It
feels like a slippery slope. I really want to run a pure Debian Stable
system if at all possible. But if consensus among users/maintainers is
that using the package from Lenny is the best solution to problem 2,
I'll be willing to try it.
(3*) Forego the Debian packages altogether; just download the source
and build it myself. Well, it's certainly possible. But that would
kind of defeat the main reason I chose to run Debian: easy and fast
package management and upgrades; minimal compiling necessary.
(4) Request the Debian Etch rkhunter maintainers to upgrade rkhunter
in Etch to version 1.3.2. If successful, this would undoubtedly be the
best solution. Dear Micah and Julien, how about it? Sysadmins will
love you even more than they do already! :)
Looking forward to your replies,
Sam
-- Forwarded message --
From: Nils Breunese (Lemonbit) [EMAIL PROTECTED]
Date: 2008/8/25
Subject: Re: [Rkhunter-users] Welcome to the Rkhunter-users mailing list
To: [EMAIL PROTECTED]
Sam Kuper wrote:
Q1) The advice page for this mailing list states, If you are not
running the latest version: please check the website for the latest
version and upgrade first. I use Debian 4 (Etch), which is the
latest stable Debian release. Like most users of Debian stable, I
upgrade by using apt-get update; apt-get upgrade. Doing this gives
me rkhunter 1.2.9, whereas running rkhunter --versioncheck reveals
that the latest release of rkhunter is 1.3.2. I do not want to use
testing Debian packages on my server, as I am concerned about
stability. Yet rkhunter 1.2.9 is giving me some problems. My
question is, then: can I expect support from this mailing list for
rkhunter 1.2.9 or must I look elsewhere?
rkhunter 1.2.9 is not supported anymore. Contact Debian's package
maintainer if you have problems with this old version.
Q2) The advice page for this mailing list states, Hashupd is on our
download page. Please see the FAQ for details. Actually, it isn't,
and yes, I have checked the online FAQ for an up-to-date link to the
download page, in case I was looking in the wrong place. So, please
could you tell me where I can obtain Hashupd?
hashupd was a script for rkhunter 1.2.9. The rkhunter 1.2.9 files are
no longer available on the project page, so that's probably why
hashupd is also no longer there. The FAQ should be updated, yes.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
