[SECURITY] [DSA 585-1] New shadow packages fix unintended behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 585-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze November 5th, 2004 http://www.debian.org/security/faq - -- Package: shadow Vulnerability : programming error Problem-Type : local Debian-specific: no CVE ID : CAN-2004-1001 A vulnerability has been discovered in the shadow suite which provides programs like chfn and chsh. It is possible for a user, who is logged in but has an expired password to alter his account information with chfn or chsh without having to change the password. The problem was originally thought to be more severe. For the stable distribution (woody) this problem has been fixed in version 2902-12woody1. For the unstable distribution (sid) this problem has been fixed in version 4.0.3-30.3. We recommend that you upgrade your passwd package (from the shadow suite). Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/s/shadow/shadow_2902-12woody1.dsc Size/MD5 checksum: 639 0cf86eed97dc4d7e378828e2fe28e886 http://security.debian.org/pool/updates/main/s/shadow/shadow_2902-12woody1.diff.gz Size/MD5 checksum:92075 5e6f576d4f073a114473126ce9e90c10 http://security.debian.org/pool/updates/main/s/shadow/shadow_2902.orig.tar.gz Size/MD5 checksum: 733922 b51537fa6f3f717d440b6f0cf95eab57 Alpha architecture: http://security.debian.org/pool/updates/main/s/shadow/login_2902-12woody1_alpha.deb Size/MD5 checksum: 119920 a8cb335e5b64386c204c98664a2498bf http://security.debian.org/pool/updates/main/s/shadow/passwd_2902-12woody1_alpha.deb Size/MD5 checksum: 406874 e12a34689305388ff172511188b179a4 ARM architecture: http://security.debian.org/pool/updates/main/s/shadow/login_2902-12woody1_arm.deb Size/MD5 checksum: 103790 87fe95eac228c211f551b3a4de8bb8a5 http://security.debian.org/pool/updates/main/s/shadow/passwd_2902-12woody1_arm.deb Size/MD5 checksum: 272012 4a2cea7a31236ed7b0472f59edf01f4a Intel IA-32 architecture: http://security.debian.org/pool/updates/main/s/shadow/login_2902-12woody1_i386.deb Size/MD5 checksum: 103778 338095117a08787f51256fa2e86661c3 http://security.debian.org/pool/updates/main/s/shadow/passwd_2902-12woody1_i386.deb Size/MD5 checksum: 275410 bd5487f119d3837150a4aee18ade236b Intel IA-64 architecture: http://security.debian.org/pool/updates/main/s/shadow/login_2902-12woody1_ia64.deb Size/MD5 checksum: 133494 bbd187d6fe4da8a8c503141e7c234802 http://security.debian.org/pool/updates/main/s/shadow/passwd_2902-12woody1_ia64.deb Size/MD5 checksum: 507214 37128be0a49818afc7dd9fac3d0d2f88 HP Precision architecture: http://security.debian.org/pool/updates/main/s/shadow/login_2902-12woody1_hppa.deb Size/MD5 checksum: 109046 773cf097fbb1dcce39a23bd5be1f49e7 http://security.debian.org/pool/updates/main/s/shadow/passwd_2902-12woody1_hppa.deb Size/MD5 checksum: 313074 ee019fbdbc733b59a0d0a71b82d05c66 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/s/shadow/login_2902-12woody1_m68k.deb Size/MD5 checksum: 101886 4d9a34f0172a44de4611b83c9c89f339 http://security.debian.org/pool/updates/main/s/shadow/passwd_2902-12woody1_m68k.deb Size/MD5 checksum: 259036 20dba3b63116c50ed1e1480a5da34e10 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/s/shadow/login_2902-12woody1_mips.deb Size/MD5 checksum: 109012 6e50e2fa756270744ce99233e080d4c0 http://security.debian.org/pool/updates/main/s/shadow/passwd_2902-12woody1_mips.deb Size/MD5 checksum: 368544 a7a3ad3c0a6bf2acf78e43f89ba7b428 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/s/shadow/login_2902-12woody1_mipsel.deb Size/MD5 checksum: 109206 b461b11835846033937877db49915aee http://security.debian.org/pool/updates/main/s/shadow/passwd_2902-12woody1_mipsel.deb Size/MD5 checksum: 366398 0a7d4f1b15b0088272160ffd68970374 PowerPC architecture:
Re: TCP SYN packets which have the FIN flag set.
On Thu, 2004-11-04 at 17:48, Luis Pérez Meliá wrote: I'm using iptables. In my rules I have this: . . . iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT Please dont do that! You are not only blocking illegal flag combinations, you are also blocking perfectly legal ones! And then spreading this bad configuration. There are flags in the TCP that we want to be allowed on start of connections, specifically ECN flags, you can look at http://www.icir.org/floyd/ecnProblems.html Note that you will not be able to receive mails from the LKML with such a setup since LKML server uses ECN. You can use SYN,ACK,FIN,RST SYN to check for illegal flags. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Thu, 2004-11-04 at 18:41, martin f krafft wrote: also sprach Luis Pérez Meliá [EMAIL PROTECTED] [2004.11.04.1848 +0100]: iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT What's the point of matching state NEW *and* SYN packets? Just SYN packets should suffice. This comes from the fact that the NEW state of Netfilter only means that this is the first time this connection is seen by the firewall. What you really want is the connection to be NEW and a valid connection opening, so you check the SYN flag too. A former e-mail of mine explains why the --tcp-flags ALL SYN check is a bad idea. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
* Jan Minar: Is this a serious problem? Maybe. It is a very serious bug. Actually, it's a feature because some TCP extensions use SYN+FIN (TCP for Transactions or something like that). The real, nasty bug was in stacks that accepted SYN+RST as a regular SYN, easily passing through to quite a few stateless packet filters. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, Nov 05, 2004 at 11:29:21AM +, Baruch Even wrote: On Thu, 2004-11-04 at 18:41, martin f krafft wrote: also sprach Luis Prez Meli [EMAIL PROTECTED] [2004.11.04.1848 +0100]: iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT What's the point of matching state NEW *and* SYN packets? Just SYN packets should suffice. This comes from the fact that the NEW state of Netfilter only means that this is the first time this connection is seen by the firewall. What you really want is the connection to be NEW and a valid connection opening, so you check the SYN flag too. Serious documentation bug. Just count the number of sites that give wrong examples. Patch against woody's iptables: --- iptables-1.2.6a.ORIG/iptables.8 Fri Nov 5 12:28:43 2004 +++ iptables-1.2.6a-local.0/iptables.8 Fri Nov 5 12:47:14 2004 @@ -521,7 +521,12 @@ supporting this feature) .SS state This module, when combined with connection tracking, allows access to -the connection tracking state for this packet. +the connection tracking state for this packet. Note that no +.I validity +check is performed, so for example \fB--state NEW\fP will match SYN,FIN packets. +Some TCP stacks assign special meanings to such packets, and this actually might +be what you want. For a more stringent filtering, see the \fB--tcp-flags\fP and +\fB--syn\fP options.. .TP .BI --state state Where state is a comma separated list of the connection states to Please comment. -- Jan pgpa5lBfTvuXG.pgp Description: PGP signature
Re: TCP SYN packets which have the FIN flag set.
Hi! On Friday 05 November 2004 12:27, Baruch Even wrote: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT Please dont do that! You can use SYN,ACK,FIN,RST SYN to check for illegal flags. Shouldn't iptables -A INPUT -m state --state INVALID -j DROP as the _first_ rule take care of all packages with illegal flags? Unfortunately, I haven't found any documentation what exactly is considered INVALID. Anybody? Cheers, Stefan -- Technische Universitaet Muenchen Raum: 1131 Physik-Department T39 Tel.: 089/289-12197 James-Franck-Strasse E-Mail: [EMAIL PROTECTED] D-85748 Garching -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
Please do not CC me on list replies. It's in the header, it's in my signature, it's in the list policy. also sprach Baruch Even [EMAIL PROTECTED] [2004.11.05.1229 +0100]: This comes from the fact that the NEW state of Netfilter only means that this is the first time this connection is seen by the firewall. What you really want is the connection to be NEW and a valid connection opening, so you check the SYN flag too. Why do you care about the connection being NEW? I am not challenging, I just can't figure out an attack scenario that could exploit the fact that I only check for --syn. A former e-mail of mine explains why the --tcp-flags ALL SYN check is a bad idea. You say to use RST,ACK,FIN,SYN SYN which makes sense. If you use --syn and iptables-save, RST,ACK,SYN SYN is stored, so this is what --syn seems to mean. Why does --syn not set FIN in the mask? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: TCP SYN packets which have the FIN flag set.
On Fri, 2004-11-05 at 12:03, Florian Weimer wrote: * Jan Minar: Is this a serious problem? Maybe. It is a very serious bug. Actually, it's a feature because some TCP extensions use SYN+FIN (TCP for Transactions or something like that). TTCP is a dead proposal, it brings into TCP the IP spoofing problems of UDP, if you want to speed TCP startup time just send the data with the third packet. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, 2004-11-05 at 14:27, martin f krafft wrote: also sprach Baruch Even [EMAIL PROTECTED] [2004.11.05.1229 +0100]: This comes from the fact that the NEW state of Netfilter only means that this is the first time this connection is seen by the firewall. What you really want is the connection to be NEW and a valid connection opening, so you check the SYN flag too. Why do you care about the connection being NEW? I am not challenging, I just can't figure out an attack scenario that could exploit the fact that I only check for --syn. You have three categories into which all sessions go: ESTABLISHED,RELATED NEW INVALID pick two to cover the spectrum of attacks. If you don't check for NEW, a SYN packet which is INVALID for some connection can be accepted. If you check for INVALID before you check for SYN you're covered. A former e-mail of mine explains why the --tcp-flags ALL SYN check is a bad idea. You say to use RST,ACK,FIN,SYN SYN which makes sense. If you use --syn and iptables-save, RST,ACK,SYN SYN is stored, so this is what --syn seems to mean. Why does --syn not set FIN in the mask? Because of ideas like TTCP (as mentioned before in this thread), for the exact reasons you'll have to ask the netfilter team, I developed a firewall but it wasn't netfilter. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, 2004-11-05 at 13:06, Stefan Fritsch wrote: Hi! On Friday 05 November 2004 12:27, Baruch Even wrote: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT Please dont do that! You can use SYN,ACK,FIN,RST SYN to check for illegal flags. Shouldn't iptables -A INPUT -m state --state INVALID -j DROP as the _first_ rule take care of all packages with illegal flags? Unfortunately, I haven't found any documentation what exactly is considered INVALID. Anybody? I started to read the netfilter source to be sure but it's too much work so take this answer with a grain of salt. As far as I know the INVALID bit will be flagged if a packet matched a connection but is invalid in the connection context, a SYN packet for an established connection or a packet without an ACK in the established connection. Things like that. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, 2004-11-05 at 12:49, Jan Minar wrote: On Fri, Nov 05, 2004 at 11:29:21AM +, Baruch Even wrote: On Thu, 2004-11-04 at 18:41, martin f krafft wrote: What's the point of matching state NEW *and* SYN packets? Just SYN packets should suffice. This comes from the fact that the NEW state of Netfilter only means that this is the first time this connection is seen by the firewall. What you really want is the connection to be NEW and a valid connection opening, so you check the SYN flag too. Serious documentation bug. Just count the number of sites that give wrong examples. Patch against woody's iptables: --- iptables-1.2.6a.ORIG/iptables.8 Fri Nov 5 12:28:43 2004 +++ iptables-1.2.6a-local.0/iptables.8Fri Nov 5 12:47:14 2004 @@ -521,7 +521,12 @@ supporting this feature) .SS state This module, when combined with connection tracking, allows access to -the connection tracking state for this packet. +the connection tracking state for this packet. Note that no +.I validity +check is performed, so for example \fB--state NEW\fP will match SYN,FIN packets. +Some TCP stacks assign special meanings to such packets, and this actually might +be what you want. For a more stringent filtering, see the \fB--tcp-flags\fP and +\fB--syn\fP options.. .TP .BI --state state Where state is a comma separated list of the connection states to I disagree with this description, the --state NEW case should be described for what it is, there should be no expectation of a validity check for it, but the ESTABLISHED and RELATED cases do check for validity. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
restricting to local access with pam_access
I want to restrict access to a set of machines to all users to local access only. Effectively, I only want to allow login and kdm access, unless the user is a meember of group 'remote', in which case s/he should also be able to use ssh, cron, and other PAM-using software. I think this has to be done with pam_access, but I am not arriving. Using something like +|ALL|LOCAL -|ALL EXCEPT remote|ALL (with fieldsep=|) does not work because LOCAL uses reverse DNS lookups, which can be trivially spoofed. Thus I tried +|ALL|tty1 tty2 tty3 tty4 tty5 tty6 :0 -|ALL EXCEPT remote|ALL which works for login, but kdm logins are still not allowed. The log does not help though: pam_access[21656]: access denied for user `kvai2004-50' from `:0' So the origin seems to be `:0', but that is not being correctly interpreted by PAM. Am I doing something wrong? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: TCP SYN packets which have the FIN flag set.
On Fri, Nov 05, 2004 at 03:04:34PM +, Baruch Even wrote: ESTABLISHED,RELATED NEW INVALID pick two to cover the spectrum of attacks. Why not all three in this order... INVALID -j REJECT ESTABLISHED,RELATED -j ACCEPT NEW -j ACCEPT (if allowed) I'm thinking PREROUTING is the best table (covers localhost, nat and bridge connections); but historically I've used it on INPUT. // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, 2004-11-05 at 17:13, George Georgalis wrote: On Fri, Nov 05, 2004 at 03:04:34PM +, Baruch Even wrote: ESTABLISHED,RELATED NEW INVALID pick two to cover the spectrum of attacks. Why not all three in this order... INVALID -j REJECT ESTABLISHED,RELATED -j ACCEPT NEW -j ACCEPT (if allowed) If you checked INVALID and ESTABLISHED, the rest has to be NEW. You can check it if you want for completeness, you can avoid checking it to save a few bits compared. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, Nov 05, 2004 at 03:04:34PM +, Baruch Even wrote: On Fri, 2004-11-05 at 14:27, martin f krafft wrote: You have three categories into which all sessions go: ESTABLISHED,RELATED NEW INVALID pick two to cover the spectrum of attacks. If you don't check for NEW, a SYN packet which is INVALID for some connection can be accepted. If you check for INVALID before you check for SYN you're covered. Here again, at least the manpage seems to be misleading. Quoting the iptables(8) manpage from woody: Possible states are INVALID meaning that the packet is associated with no known connection, [...] NEW meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions At least one of INVALID and NEW definitions is invalid. If the NEW was to match INVALID packets, these packets will be by definition ``associated with no known connection'', and vice versa. -- Jan pgpbANUptwNjH.pgp Description: PGP signature
Re: TCP SYN packets which have the FIN flag set.
On Fri, Nov 05, 2004 at 05:57:18PM +, Baruch Even wrote: On Fri, 2004-11-05 at 17:13, George Georgalis wrote: On Fri, Nov 05, 2004 at 03:04:34PM +, Baruch Even wrote: ESTABLISHED,RELATED NEW INVALID pick two to cover the spectrum of attacks. Why not all three in this order... INVALID -j REJECT ESTABLISHED,RELATED -j ACCEPT NEW -j ACCEPT (if allowed) If you checked INVALID and ESTABLISHED, the rest has to be NEW. You can check it if you want for completeness, you can avoid checking it to save a few bits compared. performance isn't really an issue for me. but I do accept only certain new connections from certain networks. and for anybody who is interested, I've found the limit function works well to manage logging and types of deny. -m limit --limit-burst 50 --limit 1/s At the end of my NEW ACCEPT set, I call a chain that, within the limit, logs and rejects remaining connections, beyond the limit it returns. the next two rules log some (with limit again) of the remaining connections and drops them all. The setup gives a balance between the problems of logging and rejecting everything bad and just dropping everything bad. // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, Nov 05, 2004 at 03:10:00PM +, Baruch Even wrote: On Fri, 2004-11-05 at 12:49, Jan Minar wrote: --- iptables-1.2.6a.ORIG/iptables.8 Fri Nov 5 12:28:43 2004 +++ iptables-1.2.6a-local.0/iptables.8 Fri Nov 5 12:47:14 2004 @@ -521,7 +521,12 @@ supporting this feature) .SS state This module, when combined with connection tracking, allows access to -the connection tracking state for this packet. +the connection tracking state for this packet. Note that no +.I validity +check is performed, so for example \fB--state NEW\fP will match SYN,FIN packets. +Some TCP stacks assign special meanings to such packets, and this actually might +be what you want. For a more stringent filtering, see the \fB--tcp-flags\fP and +\fB--syn\fP options.. .TP .BI --state state Where state is a comma separated list of the connection states to I disagree with this description, the --state NEW case should be described for what it is, there should be no expectation of a validity check for it, but the ESTABLISHED and RELATED cases do check for validity. The term INVALID is somewhat unfortunate, and the Woody's manpage really enforces the confusion. The wording of the NEW explanation is obviously misleading. The following should clean the mess: After some questions and answers on #iptables @ freenode, and some RTFMing, here goes the second version of the patch. It's against the iptables in Sarge. When the dust settles, it should be backported to Woody, as usually. The problem with the conntrack mechanism vs. flagwise filtering maybe requires someone who understands the inner workings. --- iptables.8.ORIG 2004-11-05 23:16:40.0 +0100 +++ iptables.8 2004-11-06 00:25:53.0 +0100 @@ -470,7 +470,10 @@ .B RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, -or an ICMP error. +or an ICMP error. If you want to track complex application layer +protocols such as FTP, IRC, or SNMP-ALG, you will need a protocol +helper, either compiled in the kernel, or as a module. Without one, +tracking RELATED packets will not work fully (or even at all). .B SNAT A virtual state, matching if the original source address differs from the reply destination. @@ -831,7 +834,11 @@ Matches a given realm number (and optionally mask). .SS state This module, when combined with connection tracking, allows access to -the connection tracking state for this packet. +the connection tracking state for this packet. Note that the tracking isn't +\ XXX ``isn't really stateful'' -- so what *is* it? +really stateful. If you need real stateful filtering that requires correct +connection initiation and tracks sequence numbers, you may want to apply the +tcp-window-tracking patch from patch-o-matic. .TP .BI --state state Where state is a comma separated list of the connection states to @@ -834,21 +841,44 @@ .B INVALID meaning that the packet could not be identified for some reason which includes running out of memory and ICMP errors which don't correspond to any -known connection, +known connection. Note that malformed packets not necessarily are INVALID. +In particular, non-compliant combination of TCP flags does not make that +particular packet INVALID. (The term INVALID is somewhat unfortunate.) +See \fB--tcp-flags\fR if you need to match packets according to their TCP +flags. Note however, that because of the intrinsic limitations of the +connection tracking mechanism, flagwise filtering in combination with this +module may result in dropping legitimate connections prematurely, +\ +\ This is what I'm ^^talking^^ about: +\ +\ iptables -A INPUT -p tcp ! --tcp-flags SYN SYN,ACK,RST -m state --state \ +\ NEW -j DROP +\ +\ Note that doing this will prevent idle sessions from continuing once they +\ have expired from the conntrack table. In the normal relaxed view such +\ connections initiated from the correct direction (i.e. the direction you +\ allow NEW packets through) can normally continue even if expired from +\ conntrack, provided that the first data/ack packet that resumes the +\ connection comes from the correct direction. +\ +\ Shamelessly stolen on 2004-11-05 from: +\ http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html .B ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions, +\ XXX When exactly is a connection ESTABLISHED? .B NEW -meaning that the packet has started a new connection, or otherwise -associated with a connection which has not seen packets in both +meaning that the packet is attempting to start a new connection, or is +otherwise associated with a connection which has not seen packets in both directions, and + .B RELATED -meaning that the packet is starting a new connection, but is +meaning that the packet is attempting to start a new connection, but is associated with an existing
rkhunter / chkrootkit
Hello, it now it was a couple of days ago but I've to concern another time to in this case a compromised woody system. chkrootkit found nothing but rkhunter found quite a lot: /bin/login /bin/su /usr/bin/locate /usr/sbin/useradd /usr/sbin/usermod /usr/sbin/vip All these binaries have been alerted within rkhunter. I got a message like this [ and there was indeed an debian update of passwd(login) but to get sure I need reilly competent advices]: Rootkit Hunter found some bad or unknown hashes. This can be happen due replaced binaries or updated packages (which give other hashes). Be sure your hashes are fully updated (rkhunter --update). If you're in doubt about these hashes, contact the author ... And another alert was this: Checking /dev for suspicious files... [ Warning! (unusual files found) ] What's up now I would expect someone has replaced my /bin/login binary which makes me feel unhappy or is there nothing to worry about ? - ProFTPd 1.2.5rc1 [Vulnerable ] - OpenSSH 3.4p1[Vulnerable ] - GnuPG 1.0.6 [Vulnerable ] Ok, this could be solved by compiling from sources and indeed I've to do it. At last there was this error messages: Incorrect MD5 checksums: 6 Would this solve my problem and I've to update the hash within mkhunter as describe avove ? -- Best Regards, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
