Re: [SECURITY] [DSA 765-1] New heimdal packages fix arbitrary code execution
[EMAIL PROTECTED] (Martin Schulze) writes: -- Debian Security Advisory DSA 765-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze July 22nd, 2005http://www.debian.org/security/faq -- Package: heimdal Vulnerability : buffer overflow Problem-Type : remote Debian-specific: no CVE ID : CAN-2005-0469 CERT advisory : VU#291924 Debian Bug : 305574 Gaël Delalleau discovered a buffer overflow in the handling of the LINEMODE suboptions in telnet clients. Heimdal, a free implementation of Kerberos 5, also contains such a client. This can lead to the execution of arbitrary code when connected to a malicious server. For the old stable distribution (woody) this problem has been fixed in version 0.4e-7.woody.11. For the stable distribution (sarge) this problem has been fixed in version 0.6.3-10. Huh? DSA 758 says that a buffer overflow in the telnet _server_ was fixed in sarge by version 0.6.3-10sarge1. I would think that either 0.6.3-10sarge1 is not affected or that 0.6.3-10sarge2 is needed. For the unstable distribution (sid) this problem has been fixed in version 0.6.3-10. Similar story here, I'd say. We recommend that you upgrade your heimdal package. [snip] -- Olaf Meeuwissen EPSON AVASYS Corporation, LAN FSF Associate Member #1962 sign up at http://member.fsf.org/ GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 Penguin's lib! -- I hack, therefore I am -- LPIC-2
Re: [SECURITY] [DSA 765-1] New heimdal packages fix arbitrary code execution
Moritz Muehlenhoff [EMAIL PROTECTED] writes: In gmane.linux.debian.devel.security, you wrote: Package: heimdal Vulnerability : buffer overflow Problem-Type : remote Debian-specific: no CVE ID : CAN-2005-0469 Gaël Delalleau discovered a buffer overflow in the handling of the LINEMODE suboptions in telnet clients. Heimdal, a free implementation of Kerberos 5, also contains such a client. This can lead to the execution of arbitrary code when connected to a malicious server. Huh? DSA 758 says that a buffer overflow in the telnet _server_ was fixed in sarge by version 0.6.3-10sarge1. I would think that either 0.6.3-10sarge1 is not affected or that 0.6.3-10sarge2 is needed. This is the heimdal equivalent to the MIT Kerberos fix from DSA-703. That is not really my point. DSA 758 made 0.6.3-10sarge1 the newest version for sarge. Now DSA 765 claims that 0.6.3-10 fixes another problem. My point is that this version is *not* newer than the version introduced by DSA 758 so the various package managers will not pick it up. -- Olaf Meeuwissen EPSON AVASYS Corporation, LAN FSF Associate Member #1962 sign up at http://member.fsf.org/ GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 Penguin's lib! -- I hack, therefore I am -- LPIC-2
Re: TCP port 6352?
Josh Carroll [EMAIL PROTECTED] writes: Having failed to find any information about TCP port 6352 via google or /etc/services, I figured I'd ask here. I'm seeing an awful lot of dropped packets on this port recently, and I'm curious if anyone else has seen this. If so, what purpose does TCP port 6352 serve (either in the *nix domain or windows if known), and should it be a concern. Below is an example of the dropped packets I'm seeing. According to http://www.portsdb.org/bin/portsdb.cgi?portnumber=6352 they are in the range used for Cisco AUX/TTY/VTY, whatever that is. -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 Penguin's lib! -- I hack, therefore I am -- LPIC-2
Re: File system integrity checkers - comparison?
Johannes Graumann [EMAIL PROTECTED] writes: I'm looking at this triade: Tripwire Aide Fcheck and was wondering as to what this group is prefering and why or whether there are other more trusted alternatives. You might want to include integrit and samhain as well. May filetraq too. I'm using integrit, fcheck and filetraq on a fairly minimal internal server running sarge. Integrit is fine, plenty of ways to customize it to your setup and I use it with a daily cron job (I believe that's what the default setup does, but I've mucked around with that). These runs check the whole system (in principle everything below /) quite thoroughly. Fcheck is not as flexible (I'm thinking of replacing it with aide once I have some time) but I use it for a quick hourly check of the more important stuff (/bin, /sbin, /lib and the /usr versions of these) I used to have fcheck go over /etc as well, but am using filetraq for that now. The main advantage is that it will keep time-stamped backups of all files so you can go back a version or more. Drawback is that you may have to clean out the backups occasionally. What I like most though, is that it sends you diffs(!) of the changes made to any file monitored. I think my set up check every 10 minutes or so for changes. My main argument ageinst tripwire is it's pseudo-commercial source. If it ain't in main, it ain't debian :-P -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 Penguin's lib! -- I hack, therefore I am -- LPIC-2
Re: NetFilter connection tracking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 19 November 2002 07:04, you wrote: If it is a client machine and has a default DROP policy on incoming packets, then ALLOW packets associated with open connections. You probably don't need any other special rules. Just set up policies to allow OUTPUT packets on the ports you want. Only associated packets will be accepted IN. Thanks for the feedback. All I am still a little worried about is what are associated packets, I guess. So suppose I initiate a non-anonymous FTP session, I've seen that generate ident packets. Are these associated? Similar worries about other protocols. - -- Olaf Meeuwissen GnuPG key: 91114EAF/C3E1 2D40 C7CC AEB2 FB15 8BDF 60C2 5B3F 9111 4EAF -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE94f3zYMJbP5ERTq8RAjN5AKCAyPxuehx4PzfXJq80+2gja8pTtQCeMUv+ pp38qUZv8BkiWZ0u9d2dZLk= =WFzS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-200-1] Samba buffer overflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 23 November 2002 05:21, Wichert Akkerman wrote: Package : samba Problem type : remote exploit Debian-specific: no Steve Langasek found an exploitable bug in the password handling code in samba: when converting from DOS code-page to little endian UCS2 unicode a buffer length was not checked and a buffer could be overflowed. There is no known exploit for this, but an upgrade is strongly recommended. This problem has been fixed in version 2.2.3a-12 of the Debian samba packages and upstream version 2.2.7. Hmm, from the version numbers (2.2.3a-6 to 2.2.3a-12) and changelog entries since the version in stable it looks as if this upgrade does a little more than just fix the security problem. Whatever happened to just backporting the security fix? - -- Olaf Meeuwissen GnuPG key: 91114EAF/C3E1 2D40 C7CC AEB2 FB15 8BDF 60C2 5B3F 9111 4EAF -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE94gh/YMJbP5ERTq8RAqqKAJ0dSXqwMlWAW8ybI/rypU3wK+yPlwCeOGG4 2KGV9KVjWT1tizDIgsBy8KM= =Sask -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-200-1] Samba buffer overflow
Matt Zimmerman [EMAIL PROTECTED] writes: On Mon, Nov 25, 2002 at 08:24:45PM +0900, Olaf Meeuwissen wrote: Hmm, from the version numbers (2.2.3a-6 to 2.2.3a-12) and changelog entries since the version in stable it looks as if this upgrade does a little more than just fix the security problem. Whatever happened to just backporting the security fix? The samba maintainers had already prepared an update for stable which contained backported fixes for important bugs. These fixes were appropriate for the next point release, so rather than build a security update based on 2.2.3a-6 and then a new stable upload based on 2.2.3a-9, the security update was based on 2.2.3a-9 with its fixes. You did not get any changes which were not already destined for stable. It'd be nice if the DSA could say so much. BTW, thanks for all the good work getting security.debian.org back up so fast. -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 Penguin's lib! -- I hack, therefore I am -- LPIC-2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NetFilter connection tracking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 19 November 2002 07:04, you wrote: If it is a client machine and has a default DROP policy on incoming packets, then ALLOW packets associated with open connections. You probably don't need any other special rules. Just set up policies to allow OUTPUT packets on the ports you want. Only associated packets will be accepted IN. Thanks for the feedback. All I am still a little worried about is what are associated packets, I guess. So suppose I initiate a non-anonymous FTP session, I've seen that generate ident packets. Are these associated? Similar worries about other protocols. - -- Olaf Meeuwissen GnuPG key: 91114EAF/C3E1 2D40 C7CC AEB2 FB15 8BDF 60C2 5B3F 9111 4EAF -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE94f3zYMJbP5ERTq8RAjN5AKCAyPxuehx4PzfXJq80+2gja8pTtQCeMUv+ pp38qUZv8BkiWZ0u9d2dZLk= =WFzS -END PGP SIGNATURE-
Re: [SECURITY] [DSA-200-1] Samba buffer overflow
Matt Zimmerman [EMAIL PROTECTED] writes: On Mon, Nov 25, 2002 at 08:24:45PM +0900, Olaf Meeuwissen wrote: Hmm, from the version numbers (2.2.3a-6 to 2.2.3a-12) and changelog entries since the version in stable it looks as if this upgrade does a little more than just fix the security problem. Whatever happened to just backporting the security fix? The samba maintainers had already prepared an update for stable which contained backported fixes for important bugs. These fixes were appropriate for the next point release, so rather than build a security update based on 2.2.3a-6 and then a new stable upload based on 2.2.3a-9, the security update was based on 2.2.3a-9 with its fixes. You did not get any changes which were not already destined for stable. It'd be nice if the DSA could say so much. BTW, thanks for all the good work getting security.debian.org back up so fast. -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 Penguin's lib! -- I hack, therefore I am -- LPIC-2
Re: [SECURITY] [DSA 187-1] New Apache packages fix several vulnerabilities
Roger Ward [EMAIL PROTECTED] writes: Anyone know how to see if UseCannocialName is on or off by default? I am using Apache 1.3.26. Apart from `grep -r UseCanonicalName /etc/apache` you mean? If you don't know what the hard-coded default is and can't find it in the documentation (or don't want to rely on it), by all means, be explicit and set it in your configuration file. HTH, -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 187-1] New Apache packages fix several vulnerabilities
Roger Ward [EMAIL PROTECTED] writes: Anyone know how to see if UseCannocialName is on or off by default? I am using Apache 1.3.26. Apart from `grep -r UseCanonicalName /etc/apache` you mean? If you don't know what the hard-coded default is and can't find it in the documentation (or don't want to rely on it), by all means, be explicit and set it in your configuration file. HTH, -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
NetFilter connection tracking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear .debs,
I've setup iptables on my woody box with a policy to drop. After some
tinkering I'd punched holes for the things I wanted to do (note this is
a *client* machine). Then I got into the wonders of setting up rules
for active and passive FTP. It works now, but I am asking myself
whether I can simplify my rules for all those other protocols.
For example, to get web browsing going I have:
# Allow HTTP connections initiated from here and replies back in, but
# do NOT allow connection requests from servers on the outside in.
#
/sbin/iptables --append $O --protocol tcp \
--source ${PPP_LOCAL} --source-port 1024: \
--destination-port 80 \
--jump ACCEPT
/sbin/iptables --append $I --protocol tcp ! --syn \
--source-port80 \
--destination ${PPP_LOCAL} --destination-port 1024: \
--jump ACCEPT
in my /etc/ppp/ip-up.d/1firewall script where $O and $I are the output
and input chains dedicated to the ppp device.
Now to get FTP going I added
/sbin/iptables --append $O --match state\
--state ESTABLISHED,RELATED --jump ACCEPT
/sbin/iptables --append $I --match state\
--state ESTABLISHED,RELATED --jump ACCEPT
I was thinking I could put these two rules near the top of my script,
remove the second HTTP rule and still have the same protection. I
could also drop the counter part rules for all those other nice
protocols I would like to use (ssh, hkp, smtp, imap, ...). It would
quite drastically simplify my script. Question is, does it still give
me the same kind of protection?
OT: I noticed scans for an HTTP server and more (logging what I drop)
while I was connected via dial-up. It's not safe out there! But you
already knew that of course :-)
While I'm at it I might as well append my scripts for everyone to give
a once over.
- --
Olaf Meeuwissen
GnuPG key: 91114EAF/C3E1 2D40 C7CC AEB2 FB15 8BDF 60C2 5B3F 9111 4EAF
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE92MBWYMJbP5ERTq8RAlSYAKCPd2AHg513RiAEqFr/0cZWbqukOwCgqc3b
vG4i5JsyZFoJ09420i3Ns7w=
=jrje
-END PGP SIGNATURE-
1firewall
Description: application/shellscript
1firewall
Description: application/shellscript
NetFilter connection tracking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear .debs,
I've setup iptables on my woody box with a policy to drop. After some
tinkering I'd punched holes for the things I wanted to do (note this is
a *client* machine). Then I got into the wonders of setting up rules
for active and passive FTP. It works now, but I am asking myself
whether I can simplify my rules for all those other protocols.
For example, to get web browsing going I have:
# Allow HTTP connections initiated from here and replies back in, but
# do NOT allow connection requests from servers on the outside in.
#
/sbin/iptables --append $O --protocol tcp \
--source ${PPP_LOCAL} --source-port 1024: \
--destination-port 80 \
--jump ACCEPT
/sbin/iptables --append $I --protocol tcp ! --syn \
--source-port80 \
--destination ${PPP_LOCAL} --destination-port 1024: \
--jump ACCEPT
in my /etc/ppp/ip-up.d/1firewall script where $O and $I are the output
and input chains dedicated to the ppp device.
Now to get FTP going I added
/sbin/iptables --append $O --match state\
--state ESTABLISHED,RELATED --jump ACCEPT
/sbin/iptables --append $I --match state\
--state ESTABLISHED,RELATED --jump ACCEPT
I was thinking I could put these two rules near the top of my script,
remove the second HTTP rule and still have the same protection. I
could also drop the counter part rules for all those other nice
protocols I would like to use (ssh, hkp, smtp, imap, ...). It would
quite drastically simplify my script. Question is, does it still give
me the same kind of protection?
OT: I noticed scans for an HTTP server and more (logging what I drop)
while I was connected via dial-up. It's not safe out there! But you
already knew that of course :-)
While I'm at it I might as well append my scripts for everyone to give
a once over.
- --
Olaf Meeuwissen
GnuPG key: 91114EAF/C3E1 2D40 C7CC AEB2 FB15 8BDF 60C2 5B3F 9111 4EAF
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE92MBWYMJbP5ERTq8RAlSYAKCPd2AHg513RiAEqFr/0cZWbqukOwCgqc3b
vG4i5JsyZFoJ09420i3Ns7w=
=jrje
-END PGP SIGNATURE-
/etc/ppp/ip-up.d/1firewall
Description: application/shellscript
/etc/ppp/ip-down.d/1firewall
Description: application/shellscript
Re: base-passwd bug?
Jussi Ekholm [EMAIL PROTECTED] writes: J.H.M. Dassen (Ray) [EMAIL PROTECTED] wrote: On Thu, Oct 10, 2002 at 21:31:13 -, Kisteleki Róbert wrote: Yesterday I upgraded two severs with apt, which in turn upgraded the base-passwd package. The root password seems to be upgraded also, since one of the two machines doesn't allow su-ing to root any more; regular users can log in normally. Try logging in on a tty/console. A new PAM has been introduced in unstable recently as well; it may well still have a few rough edges which could affect 'su'. I'm running roughly 90% testing and 10% unstable system, and the base-passwd which got upgraded yesterday, works just fine here. It added one new group, though, which I'm concerned of because I don't know what this group is. It's called 'sasl' -- what uses it? From /usr/share/doc/base-passwd/changelog.gz base-passwd (3.4.2) unstable; urgency=low * Add new sasl group used to regulate access to the sasl secrets * Drop prerm * No longer make /usr/doc symlinks -- Wichert Akkerman [EMAIL PROTECTED] Fri, 27 Sep 2002 19:35:30 +0200 Install apt-listchanges and you can get to see these kind of things before you upgrade and/or mailed to an address of your choice. -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-passwd bug?
Jussi Ekholm [EMAIL PROTECTED] writes: J.H.M. Dassen (Ray) [EMAIL PROTECTED] wrote: On Thu, Oct 10, 2002 at 21:31:13 -, Kisteleki Róbert wrote: Yesterday I upgraded two severs with apt, which in turn upgraded the base-passwd package. The root password seems to be upgraded also, since one of the two machines doesn't allow su-ing to root any more; regular users can log in normally. Try logging in on a tty/console. A new PAM has been introduced in unstable recently as well; it may well still have a few rough edges which could affect 'su'. I'm running roughly 90% testing and 10% unstable system, and the base-passwd which got upgraded yesterday, works just fine here. It added one new group, though, which I'm concerned of because I don't know what this group is. It's called 'sasl' -- what uses it? From /usr/share/doc/base-passwd/changelog.gz base-passwd (3.4.2) unstable; urgency=low * Add new sasl group used to regulate access to the sasl secrets * Drop prerm * No longer make /usr/doc symlinks -- Wichert Akkerman [EMAIL PROTECTED] Fri, 27 Sep 2002 19:35:30 +0200 Install apt-listchanges and you can get to see these kind of things before you upgrade and/or mailed to an address of your choice. -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: Security updates without DSA?
Peter Mathiasson [EMAIL PROTECTED] writes: On Mon, Sep 30, 2002 at 10:57:18AM +0900, Olaf Meeuwissen wrote: fetchmail (5.9.11-6) testing-security; urgency=high -- Henrique de Moraes Holschuh [EMAIL PROTECTED] Sat, 8 Jun 2002 09:40:46 -0300 kdenetwork (4:2.2.2-14.0woody1) testing-security; urgency=high -- Daniel Jacobowitz [EMAIL PROTECTED] Sun, 7 Jul 2002 14:12:03 -0400 So we have one maintainer and one security team upgrade for the woody distribution that have never been publicly announced. From the looks of it, it would seem that these upgrades somehow got lost (them being upgrades to *testing*). I am aware of the fact that security for the testing distribution is non-existent, but as woody is now stable, I'd say these are security issues for the stable distribution and should probably be announced (even if it's a bit late). Theese packages were added to woody before the release. Using a woody Packages file... $ grep-dctrl -F Package -s Package,Version fetchmail Packages Package: fetchmail-ssl Version: 5.9.11-6 I double checked and you are right about this one. It's in my woody Packages file, but it is also in my Packages file for the security updates to stable. Since the sources.list has security.d.o as its very first entry, the download was from security.d.o and apt-get showed the package as coming from Debian/Security (or whatever it exactly says). $ grep-dctrl -F Source -s Package,Version kdenetwork Packages Package: kdict Version: 4:2.2.2-14 On this one you are wrong. The security upgrade is 4:2.2.2-14.0woody1 which is not in the woody Packages file as your grep-dctrl clearly shows. -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security updates without DSA?
Peter Mathiasson [EMAIL PROTECTED] writes: On Mon, Sep 30, 2002 at 10:57:18AM +0900, Olaf Meeuwissen wrote: fetchmail (5.9.11-6) testing-security; urgency=high -- Henrique de Moraes Holschuh [EMAIL PROTECTED] Sat, 8 Jun 2002 09:40:46 -0300 kdenetwork (4:2.2.2-14.0woody1) testing-security; urgency=high -- Daniel Jacobowitz [EMAIL PROTECTED] Sun, 7 Jul 2002 14:12:03 -0400 So we have one maintainer and one security team upgrade for the woody distribution that have never been publicly announced. From the looks of it, it would seem that these upgrades somehow got lost (them being upgrades to *testing*). I am aware of the fact that security for the testing distribution is non-existent, but as woody is now stable, I'd say these are security issues for the stable distribution and should probably be announced (even if it's a bit late). Theese packages were added to woody before the release. Using a woody Packages file... $ grep-dctrl -F Package -s Package,Version fetchmail Packages Package: fetchmail-ssl Version: 5.9.11-6 I double checked and you are right about this one. It's in my woody Packages file, but it is also in my Packages file for the security updates to stable. Since the sources.list has security.d.o as its very first entry, the download was from security.d.o and apt-get showed the package as coming from Debian/Security (or whatever it exactly says). $ grep-dctrl -F Source -s Package,Version kdenetwork Packages Package: kdict Version: 4:2.2.2-14 On this one you are wrong. The security upgrade is 4:2.2.2-14.0woody1 which is not in the woody Packages file as your grep-dctrl clearly shows. -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: Security updates without DSA?
Martin Schulze [EMAIL PROTECTED] writes: Olaf Meeuwissen wrote: Olaf Meeuwissen [EMAIL PROTECTED] (that's me!) writes: Dear .debs, I recently wanted to apply security updates to a machine I'd installed from woody pre6 CDs, hardened and upgraded to woody proper. [...] Before applying the upgrades I checked whether there was a DSA for the packages that were going to be upgraded. Surprise, there were several that did not (seem to) have a corresponding DSA. Question: Is that normal and OK? Yes. During the deep freeze of woody the security infrastructure was implemented. Security updates were added to woody before it was released without issuing a DSA for each and every package. As mentioned in another mail to the debian-security list, this is true for the fetchmail-ssl package, but *not* for the kdenetwork packages. The security upgrades are not the packages that were in woody when it got released. -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: Security updates without DSA?
Matt Zimmerman [EMAIL PROTECTED] writes: On Mon, Sep 30, 2002 at 10:57:18AM +0900, Olaf Meeuwissen wrote: Olaf Meeuwissen [EMAIL PROTECTED] (that's me!) writes: Dear .debs, I recently wanted to apply security updates to a machine I'd installed from woody pre6 CDs, hardened and upgraded to woody proper. [...] Before applying the upgrades I checked whether there was a DSA for the packages that were going to be upgraded. Surprise, there were several that did not (seem to) have a corresponding DSA. Question: Is that normal and OK? This is normal in general, as the stable distribution is updated from time to time by point releases, which fix critical non-security bugs. However, woody has not received such an update as yet. I'd say critical non-security bug fixes should go to proposed-updates, but that's debatable. Nevertheless, I'd expect a DSA for everything that ends up in deb http://security.debian.org/ stable/updates main I looked into this a bit more and from the changelogs it seems that it really concerned security upgrades. In the case of fetchmail-ssl, the woody release shipped with 5.9.11-5, the upgrade is 5.9.11-6 and the changelog says: Why do you say that woody released with 5.9.11-5? I believe woody released with 5.9.11-6. Perhaps you did not upgrade all packages to the final woody versions, and you had an older version from 'testing'? 5.9.11-6 is both in the Packages file for woody and the security updates as I noted in another mail to the list. This got me mixed up. For the KDE packages I found out that they all come from the same source package: kdenetwork. The woody release shipped 4:2.2.2-14, the upgrade is 4:2.2.2-14.0woody1 and the changelog says: [...] Likewise here. I (as well as Peter Mathiasson in his) see 4:2.2.2-14 in my Packages file for woody. security.d.o has 4:2.2.2-14.0woody1. For the record, I apt-get update'd yesterday from ftp.jp.debian.org, a primary mirror. -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: Security updates without DSA?
Olaf Meeuwissen [EMAIL PROTECTED] (that's me!) writes: Dear .debs, I recently wanted to apply security updates to a machine I'd installed from woody pre6 CDs, hardened and upgraded to woody proper. [...] Before applying the upgrades I checked whether there was a DSA for the packages that were going to be upgraded. Surprise, there were several that did not (seem to) have a corresponding DSA. Question: Is that normal and OK? Packages in question are, amongst others, fetchmail-ssl, kmail, kppp, korn, kit ksirc and several other KDE packages. Since there are DSA's for openssl and kdelibs, my guess is that the aforementioned packages are just recompiles against the fixed libraries. Should there not be DSA's for that as well? After all, the package seems to be affected by the security issue to some extent (otherwise recompilation is rather pointless). I looked into this a bit more and from the changelogs it seems that it really concerned security upgrades. In the case of fetchmail-ssl, the woody release shipped with 5.9.11-5, the upgrade is 5.9.11-6 and the changelog says: fetchmail (5.9.11-6) testing-security; urgency=high * SECURITY FIX: avoid buffer overflow on 64bit archs (imap.c) This is a remote-expolitable buffer overflow, if the imap server is hostile (backported from new upstream 5.9.12, bug found and fixed by Nalin Dahyabhai) * Minor fix to avoid leaking children (driver.c) (backported from new upstream 5.9.12) * Avoid trying to speak kpop to a imap server (driver.c) (backported from new upstream 5.9.12) * MINOR SECURITY FIX: better password shrounding (fetchmail.h, imap.c, transact.c) (backported from new upstream 5.9.12) * Handle empty addresses from a To: header containing only a comment (transact.c) (backported from new upstream 5.9.12) -- Henrique de Moraes Holschuh [EMAIL PROTECTED] Sat, 8 Jun 2002 09:40:46 -0300 For the KDE packages I found out that they all come from the same source package: kdenetwork. The woody release shipped 4:2.2.2-14, the upgrade is 4:2.2.2-14.0woody1 and the changelog says: kdenetwork (4:2.2.2-14.0woody1) testing-security; urgency=high * NMU by the security team. - Fix format string bug (Closes: #147762) -- Daniel Jacobowitz [EMAIL PROTECTED] Sun, 7 Jul 2002 14:12:03 -0400 So we have one maintainer and one security team upgrade for the woody distribution that have never been publicly announced. From the looks of it, it would seem that these upgrades somehow got lost (them being upgrades to *testing*). I am aware of the fact that security for the testing distribution is non-existent, but as woody is now stable, I'd say these are security issues for the stable distribution and should probably be announced (even if it's a bit late). Hope this helps, -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Security updates without DSA?
Dear .debs, I recently wanted to apply security updates to a machine I'd installed from woody pre6 CDs, hardened and upgraded to woody proper. That is, the machine is up-to-date with respect to deb ftp://ftp.debian.org/debian stable main deb ftp://non-us.debian.org/debian-non-US stable/non-US main and iptables drops everything but DNS to my provider's DNS servers and HTTP (drops incoming connection requests). # There's some more to the hardening bit, but that's not relevant. Before applying the upgrades I checked whether there was a DSA for the packages that were going to be upgraded. Surprise, there were several that did not (seem to) have a corresponding DSA. Question: Is that normal and OK? Packages in question are, amongst others, fetchmail-ssl, kmail, kppp, korn, kit ksirc and several other KDE packages. Since there are DSA's for openssl and kdelibs, my guess is that the aforementioned packages are just recompiles against the fixed libraries. Should there not be DSA's for that as well? After all, the package seems to be affected by the security issue to some extent (otherwise recompilation is rather pointless). TIA, -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: Problem with logcheck
David Caplan [EMAIL PROTECTED] writes: I've got a problem with logcheck that I wondered if anyone else has been seeing. Just after the logrotation in the early morning, I get one screwed up logcheck report back from each machine. The report contains fragments of months old data. For the other 23 hours of the day, all log reports are just fine. Any ideas? Is there a bug in the initial processing by logcheck after the rotate? I get the very same problem! but since it is only from one machine, i haven't bothered to fix it... :) I've seen it only once, a few days ago, but that was after I changed the /etc/logcheck/logcheck.logfiles. There were also a bunch of warnings from logcheck that it could not create files in /var/lib/logcheck/. Have not seen it after (even though I changed /etc/logcheck/logcheck.logfiles back again). FYI, the machine is running testing, is updated two, three times a week and logcheck has not been updated since I installed it on March 5 (version 1.1.1-13.1). Ditto for logcheck-database. -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: Updated Package List
Jens Hafner [EMAIL PROTECTED] writes: some of you suggested to remove portmap in order close some more port and thereby increase security. Since I never really understood what the pormapper was doing, I though I could do without it. However, once I tried to uninstall the package with dselect, I got a dependency issue saying that netbase suggests on portmap. Is that something I can ignore? Thanks for your help. Yes. Only if a package (pre-)depends on another package you can not ignore it. Packages that are merely recommended or suggested should always be removable without breaking things (unless you specifically activated functionality that depends on the presence of such packages of course). -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: glibc_2.2.5-9.woody.4.deb is missing
Bob Nielsen [EMAIL PROTECTED] writes: Today's release of 2.2.5-10 appears to have resolved the problem. For unstable perhaps, but not for us folks sticking with testing. On a side note, I get this: # /usr/bin/apt-get -d upgrade Readin Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded glibc-doc libc6 2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 6081kB of archives. After unpacking 0B will be used. Do you want to continue? [Y/n] Get:1 http://security.debian.org woody/updates/main libc6 2.2.5-9.woody.4 [3382kB] Get:2 http://security.debian.org woody/updates/main glibc-doc 2.2.5-9.woody.4 [2698kB] Fetched 6081kB in 10s (594kB/s) Failed to fetch http://security.debian.org/pool/updates/main/g/glibc/libc6_2.2.5-9.woody.4_i386.deb MD5Sum mismatch Failed to fetch http://security.debian.org/pool/updates/main/g/glibc/glibc-doc_2.2.5-9.woody.4_all.deb MD5Sum mismatch E: Some files failed to download I checked file sizes in /var/cache/apt/archives/partial and they match what is in my Packages file for woody updates. The md5sum obviously don't so at least apt-get is sane. The totally weird thing is that the md5sums for second and later attempts differ from those for the first attempt. So I have 1st attempt -- file sizes OK, md5sums don't match those in Packages 2nd attempt -- file sizes OK, md5sums don't match those in Packages and differ from those of first attempt download 3rd attempt -- file sizes OK, md5sums don't match those in Packages and differ from those of first attempt download BUT identical to those of second attempt download 4th and later attempts identical to 3rd attempt Assuming the packages on security.debian.org have the md5sums listed in the Packages file, I'm now wondering if our proxy is mangling the packages during the download and mangling them again when caching. FWIW, I believe our proxy uses DeleGate and a quick look over at http://www.delegate.org/ learns that it is possible to set it up to do on the fly conversion. Hmm. My Packages file says: a730d3b53c235b172a0d34028e438fc02698500 glibc-doc f099723966e3593e6a048f2f9167a1783382190 libc6 I have seen similar behaviour here before trying to install additional packages from sources I do not mirror locally. Funny thing is that my mirror is kept up-to-date using the same transmission protocol that is used by apt-get (HTTP in my case) and those don't get screwed up. Can it be that conversion is only active during parts of the day? Sorry to ramble on a bit. Any insights are welcome. -- Olaf MeeuwissenEPSON KOWA Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc_2.2.5-9.woody.4.deb is missing
Olaf Meeuwissen [EMAIL PROTECTED] writes: On a side note, I get this: # /usr/bin/apt-get -d upgrade Readin Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded glibc-doc libc6 2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 6081kB of archives. After unpacking 0B will be used. Do you want to continue? [Y/n] Get:1 http://security.debian.org woody/updates/main libc6 2.2.5-9.woody.4 [3382kB] Get:2 http://security.debian.org woody/updates/main glibc-doc 2.2.5-9.woody.4 [2698kB] Fetched 6081kB in 10s (594kB/s) Failed to fetch http://security.debian.org/pool/updates/main/g/glibc/libc6_2.2.5-9.woody.4_i386.deb MD5Sum mismatch Failed to fetch http://security.debian.org/pool/updates/main/g/glibc/glibc-doc_2.2.5-9.woody.4_all.deb MD5Sum mismatch E: Some files failed to download I checked file sizes in /var/cache/apt/archives/partial and they match what is in my Packages file for woody updates. The md5sum obviously don't so at least apt-get is sane. The totally weird thing is that the md5sums for second and later attempts differ from those for the first attempt. So I have 1st attempt -- file sizes OK, md5sums don't match those in Packages 2nd attempt -- file sizes OK, md5sums don't match those in Packages and differ from those of first attempt download 3rd attempt -- file sizes OK, md5sums don't match those in Packages and differ from those of first attempt download BUT identical to those of second attempt download 4th and later attempts identical to 3rd attempt Assuming the packages on security.debian.org have the md5sums listed in the Packages file, I'm now wondering if our proxy is mangling the packages during the download and mangling them again when caching. FWIW, I believe our proxy uses DeleGate and a quick look over at http://www.delegate.org/ learns that it is possible to set it up to do on the fly conversion. Hmm. My Packages file says: a730d3b53c235b172a0d34028e438fc02698500 glibc-doc f099723966e3593e6a048f2f9167a1783382190 libc6 I have seen similar behaviour here before trying to install additional packages from sources I do not mirror locally. Funny thing is that my mirror is kept up-to-date using the same transmission protocol that is used by apt-get (HTTP in my case) and those don't get screwed up. Can it be that conversion is only active during parts of the day? Sorry to ramble on a bit. Any insights are welcome. Well, let me add my own. I just pulled down the updates bypassing our proxy and the md5sums match, so security.debian.org is fine. No need to worry about that. Now I just have to get someone to go hunt down whatever is wrong with our proxy and fix it. Pronto! -- Olaf MeeuwissenEPSON KOWA Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc_2.2.5-9.woody.4.deb is missing
Bob Nielsen [EMAIL PROTECTED] writes: On Fri, Jul 19, 2002 at 09:36:01AM +0900, Olaf Meeuwissen wrote: Bob Nielsen [EMAIL PROTECTED] writes: Today's release of 2.2.5-10 appears to have resolved the problem. For unstable perhaps, but not for us folks sticking with testing. I am running woody and it showed up and it showed up for me earlier today as part of security.debian.org_dists_woody_updates_main_binary-i386_Packages Hmm, I'm not seeing it here. # date Fri Jul 19 12:44:21 JST 2002 # /usr/bin/apt-get update [...] Hit http://security.debian.org woody/updates/main Packages [...] # grep libc6_2.2.5 /var/lib/apt/lists/security.debian.org_*_Packages Filename: pool/updates/main/g/glibc/libc6_2.2.5-9.woody.4_i386.deb # ls -l /var/lib/apt/lists/security.debian.org_*_Packages -rw-r--r--1 root root 140060 Jul 18 18-07 security.debian.org_dists_woody_updates_main_binary-i386_Packages Checking the site with lynx: [ ] Packages 18-Jul-2002 23:07137k [CMP] Packages.gz18-Jul-2002 23:07 29k and searching for libc6_2.2.5 gives Filename: pool/updates/main/g/glibc/libc6_2.2.5-10_i386.deb for the Packages file, but Filename: pool/updates/main/g/glibc/libc6_2.2.5-9.woody.4_i386.deb for Packages.gz! Looks like our proxy is caching outdated downloads. Time for a chat with our proxy admin, I guess. -- Olaf MeeuwissenEPSON KOWA Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
Travis Cole [EMAIL PROTECTED] writes: On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: Hi all Messing up with sshd_config for all the privsep stuff, I've noticed that PermitRootLogin was set to yes in my three woody boxes. I usually consider this a problem (although it has been my fault - i should have checked and noticed this much time ago). What do you think of this? IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? I thank my lucky stars every day that it was decided to allow root logins by default. If it did default to off then I would have to carefully change that every single time I upgrade ssh packages, or roll my own ssh packages. Huh? If an upgrade clobbers your configuration without asking you for permission that is a bug. File a bug report. Quoting from debian-policy 11.7.3 Behavior Configuration file handling must conform to the following behavior: * local changes must be preserved during a package upgrade, and * configuration files must be preserved when the package is re- moved, and only deleted when the package is purged. -- Olaf MeeuwissenEPSON KOWA Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sources.list for potato
Wichert Akkerman [EMAIL PROTECTED] writes: Previously Olaf Meeuwissen wrote: For a truly stable Debian system, drop deb http://http.us.debian.org/debian dists/potato-proposed-updates/ I wouldn't recommend that, on occasion a package makes it into proposed-updates that really should not be installed on a potato reason for some reason. Uhm, I suggested to *drop* that line from one's sources.list. Surely, you would recommend that if packages in proposed-updates really should not be installed on a potato machine, wouldn't you? -- Olaf MeeuwissenEPSON KOWA Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sources.list for potato
Mike Dresser [EMAIL PROTECTED] writes: Hate to beat a dead horse, but deb http://http.us.debian.org/debian potato main contrib non-free deb http://http.us.debian.org/debian dists/potato-proposed-updates/ deb http://non-us.debian.org/debian-non-US potato/non-US main contrib non-free deb http://non-us.debian.org/debian-security potato/updates main contrib non-free deb http://security.debian.org/debian-security potato/updates main contrib non-free is all I need on my sources.list for potato, right? And when I move to woody someday, just s/potato/woody/, correct? For a truly stable Debian system, drop deb http://http.us.debian.org/debian dists/potato-proposed-updates/ (wait for official release updates) and then just s/potato/stable/g. Note that non-US is being phased out. -- Olaf MeeuwissenEPSON KOWA Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sources.list for potato
Geoff Crompton [EMAIL PROTECTED] writes: Oops! I confused the crypto in main issue with non-US being phased out. Of course, the patented bits will stay in non-US so it will not disappear in the foreseeable future. What is the 'cypto in main' issue? (Or better, have you got a URL on it?) I searched the devel mailing archive for 'crypto AND in AND main' to no avail. Try again for the debian-legal mailing archive and at http://www.debian.org/legal/cryptoinmain HTH, -- Olaf MeeuwissenEPSON KOWA Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sources.list for potato
Mike Dresser [EMAIL PROTECTED] writes: For a truly stable Debian system, drop deb http://http.us.debian.org/debian dists/potato-proposed-updates/ (wait for official release updates) and then just s/potato/stable/g. Note that non-US is being phased out. I've seen way too many packages that take too long to get into stable when there's security holes. That's why you have deb http://security.debian.org/ stable/updates main at the top of your /etc/apt/sources.list, not? -- Olaf MeeuwissenEPSON KOWA Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security Updates Sources
Tuyen DINH [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Olaf Meeuwissen) wrote: Just put deb http://security.debian.org stable/updates main et cetera in your /etc/apt/sources.list and you'll get the woody security updates as soon as it has become stable What about this line : deb http://security.debian.org/woody/updates main ? It seems there's already a woody directory : ftp://security.debian.org/debian-security/dists/woody/updates/main/binary-i386/ You'll be getting packages for which no DSA has been sent out. It is up to you whether you would want to blindly install these. Speaking for myself, I pull down security updates, manually check the MD5sum with those in the DSA (just matching the MD5sum in the Packages is not good enough for me) and only then install them. One of these days, I should also start checking the GPG signatures on DSAs for real. Right now, for binary-i386 you'll be getting packages for new upstream releases. Packages concerned: qpopper, qpopper-drac and squirrelmail. It looks pretty much the same for the other architectures I looked at. HTH, -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security Updates Sources
Jean-Charles Preaux [EMAIL PROTECTED] writes: Hello Just a little question : is there a security updates sources for the woody release ? as : deb http://security.debian.org/ http://security.debian.org/ potato/updates main contrib non-free for the potato release ? Which i can put in my /etc/apt/sources.list ? Thanks Just put deb http://security.debian.org stable/updates main et cetera in your /etc/apt/sources.list and you'll get the woody security updates as soon as it has become stable (and woody+1 once that becomes stable, ad infinitum, the universe stops being or until security.debian.org goes belly up, whichever comes first). -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security Updates Sources
Jean-Charles Preaux [EMAIL PROTECTED] writes: Hello Just a little question : is there a security updates sources for the woody release ? as : deb http://security.debian.org/ http://security.debian.org/ potato/updates main contrib non-free for the potato release ? Which i can put in my /etc/apt/sources.list ? Thanks Just put deb http://security.debian.org stable/updates main et cetera in your /etc/apt/sources.list and you'll get the woody security updates as soon as it has become stable (and woody+1 once that becomes stable, ad infinitum, the universe stops being or until security.debian.org goes belly up, whichever comes first). -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: auth.log
Oki DZ [EMAIL PROTECTED] writes: Hi, I have quite many of the following lines in auth.log. bdg:/var/log# tail auth.log May 22 12:55:02 bdg PAM_unix[1477]: (cron) session closed for user root May 22 12:55:02 bdg PAM_unix[1476]: (cron) session closed for user root May 22 13:00:01 bdg PAM_unix[1536]: (cron) session opened for user root by (uid=0) May 22 13:00:02 bdg PAM_unix[1536]: (cron) session closed for user root May 22 13:05:01 bdg PAM_unix[1597]: (cron) session opened for user root by (uid=0) May 22 13:05:01 bdg PAM_unix[1596]: (cron) session opened for user root by (uid=0) May 22 13:05:01 bdg PAM_unix[1597]: (cron) session closed for user root May 22 13:05:02 bdg PAM_unix[1596]: (cron) session closed for user root May 22 13:10:01 bdg PAM_unix[1633]: (cron) session opened for user root by (uid=0) May 22 13:10:01 bdg PAM_unix[1633]: (cron) session closed for user root Does it mean that somebody has been trying to log in? Looks like you have a cron job running every five minutes. As I don't recall anything out of the box that does this, it's probably something you configured yourself. I'd guess a mail-transfer-agent. Check /etc/crontab and /etc/cron.d/* for culprits. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: auth.log
Oki DZ [EMAIL PROTECTED] writes: Hi, I have quite many of the following lines in auth.log. bdg:/var/log# tail auth.log May 22 12:55:02 bdg PAM_unix[1477]: (cron) session closed for user root May 22 12:55:02 bdg PAM_unix[1476]: (cron) session closed for user root May 22 13:00:01 bdg PAM_unix[1536]: (cron) session opened for user root by (uid=0) May 22 13:00:02 bdg PAM_unix[1536]: (cron) session closed for user root May 22 13:05:01 bdg PAM_unix[1597]: (cron) session opened for user root by (uid=0) May 22 13:05:01 bdg PAM_unix[1596]: (cron) session opened for user root by (uid=0) May 22 13:05:01 bdg PAM_unix[1597]: (cron) session closed for user root May 22 13:05:02 bdg PAM_unix[1596]: (cron) session closed for user root May 22 13:10:01 bdg PAM_unix[1633]: (cron) session opened for user root by (uid=0) May 22 13:10:01 bdg PAM_unix[1633]: (cron) session closed for user root Does it mean that somebody has been trying to log in? Looks like you have a cron job running every five minutes. As I don't recall anything out of the box that does this, it's probably something you configured yourself. I'd guess a mail-transfer-agent. Check /etc/crontab and /etc/cron.d/* for culprits. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
corrupted Packages files for testing
Dear .debs, As of yesterday, I see the following during my daily apt-get upgrade # /usr/bin/apt-get update Get:1 http://ftp.debian.org testng/main Packages [1745kB] [...] gzip: stdin: invalid compressed data--crc error gzip: stdin: invalid compressed data--length error Err http://ftp.debian.org testing/main Packages Sub-process gzip returned an error code (1) [...] Manually pulling in the gzip'ed Packages files gives the same result. Not surprisingly, pulling in the uncompressed versions works fine. I've also checked these files against http://ftp.debian.org/debian/dists/testing/Release and the MD5 and SHA1 checksums for the binary-i386 Packages.gz do NOT match. Any reason for concern? -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
corrupted Packages files for testing
Dear .debs, As of yesterday, I see the following during my daily apt-get upgrade # /usr/bin/apt-get update Get:1 http://ftp.debian.org testng/main Packages [1745kB] [...] gzip: stdin: invalid compressed data--crc error gzip: stdin: invalid compressed data--length error Err http://ftp.debian.org testing/main Packages Sub-process gzip returned an error code (1) [...] Manually pulling in the gzip'ed Packages files gives the same result. Not surprisingly, pulling in the uncompressed versions works fine. I've also checked these files against http://ftp.debian.org/debian/dists/testing/Release and the MD5 and SHA1 checksums for the binary-i386 Packages.gz do NOT match. Any reason for concern? -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Services using Ports 1 6
tony mancill [EMAIL PROTECTED] writes: On Sun, 14 Apr 2002, Noah L. Meyerhans wrote: These are not services listening on ports 1 and 6. Look in the left column, where it says raw. The lines above indicate that you have something listening for raw ICMP (protocol 1) and TCP (proto 6) packets coming from any remote address to any local address. Are you running something like portsentry, ippl, or iplogger? If so, that's what you're seeing. For a list of the IP protocols (in case you notice other raw sockets on your box), see: http://www.networksorcery.com/enp/protocol/ip.htm#Protocol Or closer to home, file://localhost/etc/protocols. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
Olaf Meeuwissen [EMAIL PROTECTED] writes: Gabor Kovacs [EMAIL PROTECTED] writes: Olaf Meeuwissen wrote: Basically, I'd like to keep the setup as closed as possible so I make a hole in /etc/dhclient-enter-hooks during the PREINIT stage to let the DHCPDISCOVER broadcast out (and a reply back in eventually, taking this one step at a time ;-). At least, that's what I thought I should do, but I noticed that packets are not logged! I think (but not sure) DHCP client is using (so called) raw sockets which are below the layer where iptables is in the kernel. That's why iptables is unable to see the packets. Looks like you are right. I set all built-in chains to LOG and a DROP policy (no other rules) and my interface configures fine. Once it is up there's an incessant stream of logged packets (mainly win-DoS hosts letting everyone know who and where they are by shouting all over the subnet and, occasionally, beyond). Oh well, I guess I can forget about making and plugging holes for the DHCPDISCOVER (and probably DHCPREQUEST) requests and their replies. That makes my job easier, but I guess the docs then need a fix ;-) I gotta set myself straight here. The DHCPDISCOVER does not need a hole to make it past the packet filtering layer, but the DHCPREQUEST does. And from experience, it seems that dhclient starts requesting without going through the /etc/dhclient-script. Bummer, 'cause that means you don't get the chance to open up a hole for the request and close it once your lease has been renewed. Oh well, I guess I have to leave a hole open permanently for the requests to and replies from the dhcp-server-identifier ... -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
Olaf Meeuwissen [EMAIL PROTECTED] writes: Gabor Kovacs [EMAIL PROTECTED] writes: Olaf Meeuwissen wrote: Basically, I'd like to keep the setup as closed as possible so I make a hole in /etc/dhclient-enter-hooks during the PREINIT stage to let the DHCPDISCOVER broadcast out (and a reply back in eventually, taking this one step at a time ;-). At least, that's what I thought I should do, but I noticed that packets are not logged! I think (but not sure) DHCP client is using (so called) raw sockets which are below the layer where iptables is in the kernel. That's why iptables is unable to see the packets. Looks like you are right. I set all built-in chains to LOG and a DROP policy (no other rules) and my interface configures fine. Once it is up there's an incessant stream of logged packets (mainly win-DoS hosts letting everyone know who and where they are by shouting all over the subnet and, occasionally, beyond). Oh well, I guess I can forget about making and plugging holes for the DHCPDISCOVER (and probably DHCPREQUEST) requests and their replies. That makes my job easier, but I guess the docs then need a fix ;-) I gotta set myself straight here. The DHCPDISCOVER does not need a hole to make it past the packet filtering layer, but the DHCPREQUEST does. And from experience, it seems that dhclient starts requesting without going through the /etc/dhclient-script. Bummer, 'cause that means you don't get the chance to open up a hole for the request and close it once your lease has been renewed. Oh well, I guess I have to leave a hole open permanently for the requests to and replies from the dhcp-server-identifier ... -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security updates for hppa
Chris Gray [EMAIL PROTECTED] writes: I'm new to debian linux, and I am having trouble finding the security updates for the HPPA system. I have looked all through http://security.debian.org/dists/ I found the updates for the other ports, but not hppa. Any thoughts on where I might find them or what to put in the sources.list file? I think I installed 'woody' from the 0.9.3 CD. I am also using the 32bit kernel. security.debian.org only contains security updates for the stable distribution which is still potato. The hppa port was not released with potato, hence no security updates at security.debian.org. You will have to get the updates from unstable. HTH, -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: security updates for hppa
Chris Gray [EMAIL PROTECTED] writes: I'm new to debian linux, and I am having trouble finding the security updates for the HPPA system. I have looked all through http://security.debian.org/dists/ I found the updates for the other ports, but not hppa. Any thoughts on where I might find them or what to put in the sources.list file? I think I installed 'woody' from the 0.9.3 CD. I am also using the 32bit kernel. security.debian.org only contains security updates for the stable distribution which is still potato. The hppa port was not released with potato, hence no security updates at security.debian.org. You will have to get the updates from unstable. HTH, -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
Gabor Kovacs [EMAIL PROTECTED] writes: Olaf Meeuwissen wrote: Basically, I'd like to keep the setup as closed as possible so I make a hole in /etc/dhclient-enter-hooks during the PREINIT stage to let the DHCPDISCOVER broadcast out (and a reply back in eventually, taking this one step at a time ;-). At least, that's what I thought I should do, but I noticed that packets are not logged! I think (but not sure) DHCP client is using (so called) raw sockets which are below the layer where iptables is in the kernel. That's why iptables is unable to see the packets. Looks like you are right. I set all built-in chains to LOG and a DROP policy (no other rules) and my interface configures fine. Once it is up there's an incessant stream of logged packets (mainly win-DoS hosts letting everyone know who and where they are by shouting all over the subnet and, occasionally, beyond). Oh well, I guess I can forget about making and plugging holes for the DHCPDISCOVER (and probably DHCPREQUEST) requests and their replies. That makes my job easier, but I guess the docs then need a fix ;-) Thanks, -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
Gabor Kovacs [EMAIL PROTECTED] writes: Olaf Meeuwissen wrote: Basically, I'd like to keep the setup as closed as possible so I make a hole in /etc/dhclient-enter-hooks during the PREINIT stage to let the DHCPDISCOVER broadcast out (and a reply back in eventually, taking this one step at a time ;-). At least, that's what I thought I should do, but I noticed that packets are not logged! I think (but not sure) DHCP client is using (so called) raw sockets which are below the layer where iptables is in the kernel. That's why iptables is unable to see the packets. Looks like you are right. I set all built-in chains to LOG and a DROP policy (no other rules) and my interface configures fine. Once it is up there's an incessant stream of logged packets (mainly win-DoS hosts letting everyone know who and where they are by shouting all over the subnet and, occasionally, beyond). Oh well, I guess I can forget about making and plugging holes for the DHCPDISCOVER (and probably DHCPREQUEST) requests and their replies. That makes my job easier, but I guess the docs then need a fix ;-) Thanks, -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lupe Christoph [EMAIL PROTECTED] writes: On Wednesday, 2002-04-03 at 14:02:20 +0900, Olaf Meeuwissen wrote: I am playing with packet filtering on a DHCP client and trying to get it done the right way. The right way is to dispense with DHCP. The protocol has no security whatsoever. Read RFC2131, 7. Security Considerations for details. Although I may share your sympaties on this point (still have to read up on it), you assume I am in a position to do so. - -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8qsWeFsfyfWvjfZARAjQLAJ0cA8X1NNPGDWBeVT2yh2PAp/2ZJwCfZf44 gDj83SMnXI2ATIDfg8SQGMA= =G8AJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lupe Christoph [EMAIL PROTECTED] writes: On Wednesday, 2002-04-03 at 14:02:20 +0900, Olaf Meeuwissen wrote: I am playing with packet filtering on a DHCP client and trying to get it done the right way. The right way is to dispense with DHCP. The protocol has no security whatsoever. Read RFC2131, 7. Security Considerations for details. Although I may share your sympaties on this point (still have to read up on it), you assume I am in a position to do so. - -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8qsWeFsfyfWvjfZARAjQLAJ0cA8X1NNPGDWBeVT2yh2PAp/2ZJwCfZf44 gDj83SMnXI2ATIDfg8SQGMA= =G8AJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
iptables not logging or dhcp-client lying?
Dear .debs, I am playing with packet filtering on a DHCP client and trying to get it done the right way. Policy for all built-in chains is DROP and all packets are logged before they go plonk. I pulled the network cable while playing around. Debian GNU/Linux 3.0 kernel 2.4.18-tux, iptables 1.2.5-7, dhcp-client 2.0pl5-7 Basically, I'd like to keep the setup as closed as possible so I make a hole in /etc/dhclient-enter-hooks during the PREINIT stage to let the DHCPDISCOVER broadcast out (and a reply back in eventually, taking this one step at a time ;-). At least, that's what I thought I should do, but I noticed that packets are not logged! That is, if I don't open up said hole, there is nothing in the logs! I also inserted logging rules at the very beginning of all built-in chains, but I still don't see the broadcast logged by iptables. Only the dhcp-client message saying it is broadcasting to 255.255.255.255 on port 67 on eth0 shows up in the system logs. What's going on? Why do those broadcast packets not show up? Any clues anyone? # If you need more info, please ask. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
iptables not logging or dhcp-client lying?
Dear .debs, I am playing with packet filtering on a DHCP client and trying to get it done the right way. Policy for all built-in chains is DROP and all packets are logged before they go plonk. I pulled the network cable while playing around. Debian GNU/Linux 3.0 kernel 2.4.18-tux, iptables 1.2.5-7, dhcp-client 2.0pl5-7 Basically, I'd like to keep the setup as closed as possible so I make a hole in /etc/dhclient-enter-hooks during the PREINIT stage to let the DHCPDISCOVER broadcast out (and a reply back in eventually, taking this one step at a time ;-). At least, that's what I thought I should do, but I noticed that packets are not logged! That is, if I don't open up said hole, there is nothing in the logs! I also inserted logging rules at the very beginning of all built-in chains, but I still don't see the broadcast logged by iptables. Only the dhcp-client message saying it is broadcasting to 255.255.255.255 on port 67 on eth0 shows up in the system logs. What's going on? Why do those broadcast packets not show up? Any clues anyone? # If you need more info, please ask. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default Apache configuration
Ralf Dreibrodt [EMAIL PROTECTED] writes: i just saw an error on a debian box with apache(-common) 1.3.9-13.2: Time to upgrade ;-), potato's apache is at 1.3.9-14. drwxr-xr-x 14 root root 4096 Dec 7 13:52 /var drwxr-xr-x6 root root 4096 Mar 11 06:30 /var/log drwxr-xr-x2 root root 4096 Mar 10 06:25 /var/log/apache -rw-rw-r--1 www-data nogroup134382 Mar 12 13:45 /var/log/apache/access.log The ownership and permissions of apache log files is known to be (have been?) a problem. See #72468. I have recently done a fresh install of 1.3.23-1 and noticed that all of these problems have gone away, but for the fact that the initial logs are created root.root 0644. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default Apache configuration
Ralf Dreibrodt [EMAIL PROTECTED] writes: i just saw an error on a debian box with apache(-common) 1.3.9-13.2: Time to upgrade ;-), potato's apache is at 1.3.9-14. drwxr-xr-x 14 root root 4096 Dec 7 13:52 /var drwxr-xr-x6 root root 4096 Mar 11 06:30 /var/log drwxr-xr-x2 root root 4096 Mar 10 06:25 /var/log/apache -rw-rw-r--1 www-data nogroup134382 Mar 12 13:45 /var/log/apache/access.log The ownership and permissions of apache log files is known to be (have been?) a problem. See #72468. I have recently done a fresh install of 1.3.23-1 and noticed that all of these problems have gone away, but for the fact that the initial logs are created root.root 0644. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: iptables vs DHCP
Osvaldo Mundim Junior [EMAIL PROTECTED] writes: Does anybody use iptables in a DHCP network? I want to know how would be some rule in this case... There were some messages flying around debian-firewall concerning DHCP and iptables. They don't seem to be in the archive yet, though. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: wtmp non readable?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Juchem [EMAIL PROTECTED] writes: Am Freitag, 1. März 2002 19:45 schrieb Andrew Tsen: Does anyone know whether wtmp has to be readable for world? I was not sure whether last and finger were the only programs that read wtmp. So there are not any vital programs that must have read access to wtmp as a normal user? Permissions 0660 and owned by root.utmp should be fine. In case that breaks anything, you can always make it 0664 again, make the program that needs access sgid utmp (eek!?) or file a bug report :-) - -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8grNoFsfyfWvjfZARAp/tAKClaF/Gjr2obz3ux+XlL7k77zJzEwCfYu1J I/FEJ9ClGmBMAByr00V2rmk= =EbTT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hosts.{allow,deny} vs iptables.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joao Luis Meloni Assirati [EMAIL PROTECTED] writes:
Recently I learned how to use linux2.4 netfilter. Since it is a fairly
complete ip tool (tcp, udp, icmp), capable of a wide set of matchings
(source IP, dest port, ...) and also able to LOG, it seemed to me that all
hosts.{allow,deny} control through tcpd could be done by a convenient set
of host based (i.e. not in a firewall gateway) iptables rules. More than
this, speed seems to be improved by eliminating inetd - tcpd latency.
I want to know if my point of view is right, or if there is any
functionality that hosts.{allow,deny} scheme provides which iptables
can't.
Yes, you can achieve the same control with netfilter as you can with
hosts.{allow,deny}. However, that doesn't mean you should throw out
tcp wrappers (even if that improves throughput).
# Rather easily done by putting ALL: ALL in your hosts.allow.
It is usually desirable to have more than one line of defense. Just
for the sake of argument, suppose you happened to
~# /etc/init.d/iptables clear
and as a result tear down your whole firewall. You'd be very happy to
a hosts.deny lying around that says ALL: ALL. This example is perhaps
very unlikely to occur, but what if you happened to make a mistake in
your firewall rules or, eek!, a bug in the kernel code implementing
netfilter?
- --
Olaf MeeuwissenEpson Kowa Corporation, CID
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
LPIC-2 -- I hack, therefore I am -- BOFH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/
iD8DBQE8grxhFsfyfWvjfZARAlNpAJ9R9limzM711W+n0HU+r91/QGtToACgxi0X
JSPo/zUMHGqKp4Vdk/zp8Go=
=doh1
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: wtmp non readable?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Juchem [EMAIL PROTECTED] writes: Am Freitag, 1. März 2002 19:45 schrieb Andrew Tsen: Does anyone know whether wtmp has to be readable for world? I was not sure whether last and finger were the only programs that read wtmp. So there are not any vital programs that must have read access to wtmp as a normal user? Permissions 0660 and owned by root.utmp should be fine. In case that breaks anything, you can always make it 0664 again, make the program that needs access sgid utmp (eek!?) or file a bug report :-) - -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8grNoFsfyfWvjfZARAp/tAKClaF/Gjr2obz3ux+XlL7k77zJzEwCfYu1J I/FEJ9ClGmBMAByr00V2rmk= =EbTT -END PGP SIGNATURE-
Re: hosts.{allow,deny} vs iptables.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joao Luis Meloni Assirati [EMAIL PROTECTED] writes:
Recently I learned how to use linux2.4 netfilter. Since it is a fairly
complete ip tool (tcp, udp, icmp), capable of a wide set of matchings
(source IP, dest port, ...) and also able to LOG, it seemed to me that all
hosts.{allow,deny} control through tcpd could be done by a convenient set
of host based (i.e. not in a firewall gateway) iptables rules. More than
this, speed seems to be improved by eliminating inetd - tcpd latency.
I want to know if my point of view is right, or if there is any
functionality that hosts.{allow,deny} scheme provides which iptables
can't.
Yes, you can achieve the same control with netfilter as you can with
hosts.{allow,deny}. However, that doesn't mean you should throw out
tcp wrappers (even if that improves throughput).
# Rather easily done by putting ALL: ALL in your hosts.allow.
It is usually desirable to have more than one line of defense. Just
for the sake of argument, suppose you happened to
~# /etc/init.d/iptables clear
and as a result tear down your whole firewall. You'd be very happy to
a hosts.deny lying around that says ALL: ALL. This example is perhaps
very unlikely to occur, but what if you happened to make a mistake in
your firewall rules or, eek!, a bug in the kernel code implementing
netfilter?
- --
Olaf MeeuwissenEpson Kowa Corporation, CID
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
LPIC-2 -- I hack, therefore I am -- BOFH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/
iD8DBQE8grxhFsfyfWvjfZARAlNpAJ9R9limzM711W+n0HU+r91/QGtToACgxi0X
JSPo/zUMHGqKp4Vdk/zp8Go=
=doh1
-END PGP SIGNATURE-
Re: root's home world readable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin R. Miller [EMAIL PROTECTED] writes: Said Francesco P. Lovergine on Wed, Feb 27, 2002 at 11:52:01PM +0100: Debian asks if home dirs should be word readable or not at installation time. I assume this is true for root also. I wouldn't count on it. Does anyone know where one could reconfigure this? During installation: ALT+F2 # chmod 0700 /target/root ALT+F1 would do the trick, methinks. - -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8fZZFFsfyfWvjfZARAiRPAKCkMFBRhU8Yt608GGGOzKTiImIzNQCfb14X nk3/rUDhlVF9AJXeZYZR7mU= =8lIn -END PGP SIGNATURE-
Re: Un-installing inetd on Woody.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Srdic [EMAIL PROTECTED] writes: On Wed 13 Feb 02 19:14, Howland, Curtis wrote: Would simply commenting out all the lines in inetd.conf be sufficient? I realize that this is not the same as uninstalling, but it's not clear what the goal is. If the machine is isolated, it doesn't matter. If it's not isolated, iptables/ipchains firewall functions are a better idea anyway. My system is my desktop and my server. The machine is connected to the internet and I use my own IPTables script to protect my network. I've used the update-rc.d script to remove the inetd init scripts from all runlevels. But, I still want to un-install it completely. I've heard that the inet daemon can be used in many different types of attacks and I don't want to experience any first hand. If you've removed all links from /etc/rc?.d and made sure it is not running anymore, what is it that is bothering you? For good measure you can stick in an `exit 0` at the beginning of /etc/init.d/inetd. After you've also commented out everything in /etc/inetd.conf. The only thing that I can think of that might be bothering anyone is packages adding uncommented entries in /etc/inetd.conf and somebody starting inetd manually (which requires access to the machine) after that. - -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8a1jzFsfyfWvjfZARAiKHAKCgsHeHLCJiPkJYOL1G8wSXGCX7vACfUQ72 q6pVMCEW4dgm6OTKoHeryDs= =wzAx -END PGP SIGNATURE-
Re: Un-installing inetd on Woody.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Srdic [EMAIL PROTECTED] writes: On Wed 13 Feb 02 19:14, Howland, Curtis wrote: Would simply commenting out all the lines in inetd.conf be sufficient? I realize that this is not the same as uninstalling, but it's not clear what the goal is. If the machine is isolated, it doesn't matter. If it's not isolated, iptables/ipchains firewall functions are a better idea anyway. My system is my desktop and my server. The machine is connected to the internet and I use my own IPTables script to protect my network. I've used the update-rc.d script to remove the inetd init scripts from all runlevels. But, I still want to un-install it completely. I've heard that the inet daemon can be used in many different types of attacks and I don't want to experience any first hand. If you've removed all links from /etc/rc?.d and made sure it is not running anymore, what is it that is bothering you? For good measure you can stick in an `exit 0` at the beginning of /etc/init.d/inetd. After you've also commented out everything in /etc/inetd.conf. The only thing that I can think of that might be bothering anyone is packages adding uncommented entries in /etc/inetd.conf and somebody starting inetd manually (which requires access to the machine) after that. - -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8a1jzFsfyfWvjfZARAiKHAKCgsHeHLCJiPkJYOL1G8wSXGCX7vACfUQ72 q6pVMCEW4dgm6OTKoHeryDs= =wzAx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Setting apt to mount partitions read|read-only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Bonner [EMAIL PROTECTED] writes:
The Securing Debian HOWTO makes mention of the possibility that you can
set a partition as read-only, to further protect the various things in
/usr/bin for example. Then when you apt-get upgrade, you can configure
apt to automagically turn off the read-only while needed, then turn it
back on (facilitating the install of new items).
However, I don't immediately see anything in 'man apt.conf' that tells
how to do it, assuming that's where you control this behavior from.
Does anyone have instructions on how to accomplish this?
I'm doing exactly this for a read-only mounted /usr partition with the
following in /etc/apt/apt.conf:
DPkg
{
Pre-Invoke { mount /usr -o remount,rw };
Post-Invoke { mount /usr -o remount,ro };
};
Note that the Post-Invoke may fail with a /usr busy error message.
This happens mainly when you are using files during the update that
got updated. Annoying but not really a big deal. Just make sure
these are no longer used and run the Post-Invoke manually.
Hope this helps,
- --
Olaf MeeuwissenEpson Kowa Corporation, CID
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
LPIC-2 -- I hack, therefore I am -- BOFH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/
iD8DBQE8av6+FsfyfWvjfZARAs/ZAJ0ZZ/hym5EN6M4CGXQtuTff/SWSKgCdFHd+
VF3mZMhU96oA+jE1e9OjWSA=
=6tGy
-END PGP SIGNATURE-
Re: Debian security being trashed in Linux Today comments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Cordes [EMAIL PROTECTED] writes: [...] To get testing better tested (by providing the service more people need to run it), and to get the security team familiar with the soon-to-be-stable release, there could be a mechanism for security fixes to get done on woody, etc. I don't know what kind of security promises would be appropriate, or what, but I think it would be a good idea to do something along these lines. Maybe someone should make a list of packages that the security team would take time to deal with in woody, and add packages to it over time. Starting with popular packages and/or packages classified as required/important might make sense. Currently, testing is getting frozen in steps as far as I understand the process. What about providing proper security updates for those parts that have already been frozen? These would have be dealt with in a special way to get upgraded anyway so you might as well provide the upgrade as a proper security update. This could also serve as a handle for the folks who are coordinating the release process. - -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8Q7YAFsfyfWvjfZARAn2mAKCh20XSbZlJ+wjtiOJP/zGv8z3yTwCgxOlw S0PF5uSNo7KeuY9ONzBCYl8= =FSYR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Cordes [EMAIL PROTECTED] writes: [...] To get testing better tested (by providing the service more people need to run it), and to get the security team familiar with the soon-to-be-stable release, there could be a mechanism for security fixes to get done on woody, etc. I don't know what kind of security promises would be appropriate, or what, but I think it would be a good idea to do something along these lines. Maybe someone should make a list of packages that the security team would take time to deal with in woody, and add packages to it over time. Starting with popular packages and/or packages classified as required/important might make sense. Currently, testing is getting frozen in steps as far as I understand the process. What about providing proper security updates for those parts that have already been frozen? These would have be dealt with in a special way to get upgraded anyway so you might as well provide the upgrade as a proper security update. This could also serve as a handle for the folks who are coordinating the release process. - -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8Q7YAFsfyfWvjfZARAn2mAKCh20XSbZlJ+wjtiOJP/zGv8z3yTwCgxOlw S0PF5uSNo7KeuY9ONzBCYl8= =FSYR -END PGP SIGNATURE-
Re: ssh and root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vineet Kumar [EMAIL PROTECTED] writes: * Robert Epprecht ([EMAIL PROTECTED]) [011208 02:31]: I need ssh to access some cvs servers. As the files are stored locally below /usr/local/ and ordinary users have no write access there I called ssh-keygen as root. But now I have my doubts if this was The Right Thing to do regarding security. I *do* trust the cvs servers in question and am not paranoid about security, but I do want a reasonable security level. Comments welcome. Rather than root, add your user account to group staff. This gives you access to /usr/local. That would indeed be a lot better than ssh'ing in as root. I believe the default setup doesn't even let you (or was that a configuration question?). It should be noted, though, that this account becomes stronger than you can possibly imagine. (Well, not really, but it's easy for it to get root). One prime example of this is that /usr/local/sbin and /usr/local/bin come first in root's path. On my machine these come last by default(!) when I su user@frodo:~$ su Password: frodo:/home/user# echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin frodo:/home/user# and they are not even there when logging in as root frodo login: root Password: [...] Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. frodo:~# echo $PATH /usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 frodo:~# Besides, when r00t you use full pathnames, not? - -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8FUqCFsfyfWvjfZARAldtAJ47K/2STWf/fWny6AwLN2gC+k+VYwCcCQAH Bt1IvMKp58m/g2VDpQQFxoE= =CVXg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
thanks! [was Re: shutdown user and accountability]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olaf Meeuwissen [EMAIL PROTECTED] wrote: I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, Thanks to everyone who responded. I should have been a little clearer on the system setup. The machine in question consists of a main unit and a bunch of externally attached hard disks connected to a network. It has no monitor, keyboard (what Ctrl-Alt-Del?) and mouse. As I already feared, it is impossible to provide a shutdown account without giving up accountability. Some pointed out (correctly) that without physical security I didn't have accountability to begin with, but I was wondering whether I needed to sacrifice it even further. Some replies suggested I validate against a general database, e.g. for Winblows logon (that'd be just about the only viable alternative in my situation). That could be a nice approach, but one would have to be able to trust that database (and since it is not under my control ... btw, I hope it stays that way, win-DoS shudder ;-) The replies regarding journalling file systems reminded me of the fact that I still have to look into those (especially since we have annual thunderstorms occasionally knocking the power out). I liked the camera idea! If I get some time, I may give it a go. We have quite a few digital camera's around here and one on my machine wouldn't look like an obvious security measure. Finally, one reply mentioned that I would have the IP address logged right before the shutdown because people that want to shut down the machine have to ssh in. Shame on me for forgetting that. In the mean time, our network administrator seems to have seen the light and now requires a shutdown account so he can shut the machine down anytime he needs to. With that I can live, so I provided one where all he can do is shut the machine down. Should he choose to share the password, then that is his problem. So, I've added a user along the following line shutdown:x:1000:1000::/tmp:/usr/local/sbin/shutdown where /usr/local/sbin/shutdown (root.root 0755) looks like #! /bin/sh exec /usr/bin/sudo -K /sbin/halt and added the shutdown user to the users allowed to run /sbin/halt in my sudo setup. I liked this better than another setup they suggested at work (for a Solaris box) where they add a user as shutdown:x:0:0::/etc/shutdown:/etc/shutdown/shutdown with /etc/shutdown/shutdown (root.root 0744) looking like #! /bin/sh echo Do you want to shutdown now? (y or n): \c read yn if [ $yn = 'y' -o $yn = 'Y' ] ; then sync sync sync sleep 3 /usr/sbin/shutdown -i0 -g0 fi exit 0 I didn't see any obvious flaws in the above script, but I disliked the prompting and, what's more, the shutdown user has r00t privileges! Anyway, thanks to all the paranoid folks who responded. - -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8FY+RFsfyfWvjfZARAl79AJ9dl/klAaeBF3dpm7IhUE1lG1FLXwCcC8EK udWwBZsyQAsDaVNVEpt3Yh0= =tMSt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh and root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vineet Kumar [EMAIL PROTECTED] writes: * Robert Epprecht ([EMAIL PROTECTED]) [011208 02:31]: I need ssh to access some cvs servers. As the files are stored locally below /usr/local/ and ordinary users have no write access there I called ssh-keygen as root. But now I have my doubts if this was The Right Thing to do regarding security. I *do* trust the cvs servers in question and am not paranoid about security, but I do want a reasonable security level. Comments welcome. Rather than root, add your user account to group staff. This gives you access to /usr/local. That would indeed be a lot better than ssh'ing in as root. I believe the default setup doesn't even let you (or was that a configuration question?). It should be noted, though, that this account becomes stronger than you can possibly imagine. (Well, not really, but it's easy for it to get root). One prime example of this is that /usr/local/sbin and /usr/local/bin come first in root's path. On my machine these come last by default(!) when I su [EMAIL PROTECTED]:~$ su Password: frodo:/home/user# echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin frodo:/home/user# and they are not even there when logging in as root frodo login: root Password: [...] Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. frodo:~# echo $PATH /usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 frodo:~# Besides, when r00t you use full pathnames, not? - -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8FUqCFsfyfWvjfZARAldtAJ47K/2STWf/fWny6AwLN2gC+k+VYwCcCQAH Bt1IvMKp58m/g2VDpQQFxoE= =CVXg -END PGP SIGNATURE-
thanks! [was Re: shutdown user and accountability]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olaf Meeuwissen [EMAIL PROTECTED] wrote: I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, Thanks to everyone who responded. I should have been a little clearer on the system setup. The machine in question consists of a main unit and a bunch of externally attached hard disks connected to a network. It has no monitor, keyboard (what Ctrl-Alt-Del?) and mouse. As I already feared, it is impossible to provide a shutdown account without giving up accountability. Some pointed out (correctly) that without physical security I didn't have accountability to begin with, but I was wondering whether I needed to sacrifice it even further. Some replies suggested I validate against a general database, e.g. for Winblows logon (that'd be just about the only viable alternative in my situation). That could be a nice approach, but one would have to be able to trust that database (and since it is not under my control ... btw, I hope it stays that way, win-DoS shudder ;-) The replies regarding journalling file systems reminded me of the fact that I still have to look into those (especially since we have annual thunderstorms occasionally knocking the power out). I liked the camera idea! If I get some time, I may give it a go. We have quite a few digital camera's around here and one on my machine wouldn't look like an obvious security measure. Finally, one reply mentioned that I would have the IP address logged right before the shutdown because people that want to shut down the machine have to ssh in. Shame on me for forgetting that. In the mean time, our network administrator seems to have seen the light and now requires a shutdown account so he can shut the machine down anytime he needs to. With that I can live, so I provided one where all he can do is shut the machine down. Should he choose to share the password, then that is his problem. So, I've added a user along the following line shutdown:x:1000:1000::/tmp:/usr/local/sbin/shutdown where /usr/local/sbin/shutdown (root.root 0755) looks like #! /bin/sh exec /usr/bin/sudo -K /sbin/halt and added the shutdown user to the users allowed to run /sbin/halt in my sudo setup. I liked this better than another setup they suggested at work (for a Solaris box) where they add a user as shutdown:x:0:0::/etc/shutdown:/etc/shutdown/shutdown with /etc/shutdown/shutdown (root.root 0744) looking like #! /bin/sh echo Do you want to shutdown now? (y or n): \c read yn if [ $yn = 'y' -o $yn = 'Y' ] ; then sync sync sync sleep 3 /usr/sbin/shutdown -i0 -g0 fi exit 0 I didn't see any obvious flaws in the above script, but I disliked the prompting and, what's more, the shutdown user has r00t privileges! Anyway, thanks to all the paranoid folks who responded. - -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8FY+RFsfyfWvjfZARAl79AJ9dl/klAaeBF3dpm7IhUE1lG1FLXwCcC8EK udWwBZsyQAsDaVNVEpt3Yh0= =tMSt -END PGP SIGNATURE-
shutdown user and accountability
Dear .debs, I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shutdown user and accountability
Blake Barnett [EMAIL PROTECTED] writes: Can't you give a group sudo access? If so, just add everyone to a group and give that group sudo /sbin/halt or sudo /sbin/shutdown or both. That's exactly what my sudo setup does right now. The problem is that apparently *everyone* needs to be able to shut down the machine (for reasons that are beyond me). Added accounts on an as needed basis is fine with me, but I don't fancy creating, oh, 250+ password protected accounts just to meet policy. Or you could write your own script which wraps around halt/shutdown and logs what it's doing via logger or syslog... On Tue, 2001-11-27 at 17:51, Olaf Meeuwissen wrote: Dear .debs, I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Blake Barnett (bdb) [EMAIL PROTECTED] Sr. Unix Administrator DevelopOnline.com office: 480-377-6816 Do, or do not. There is no try. --Yoda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shutdown user and accountability
Blake Barnett [EMAIL PROTECTED] writes: On Tue, 2001-11-27 at 18:58, Olaf Meeuwissen wrote: Blake Barnett [EMAIL PROTECTED] writes: Can't you give a group sudo access? If so, just add everyone to a group and give that group sudo /sbin/halt or sudo /sbin/shutdown or both. That's exactly what my sudo setup does right now. The problem is that apparently *everyone* needs to be able to shut down the machine (for reasons that are beyond me). Added accounts on an as needed basis is fine with me, but I don't fancy creating, oh, 250+ password protected accounts just to meet policy. Ok, I guess I didn't understand that the accounts didn't already exist. Is this some sort of kiosk or something? Nope, just a file/web server (but I'm thinking of adding a programming environment (EEK!) for educational purposes) that is in a place that does not allow physical access restrictions (beyond being able to enter the company premises). If you can't wrap the stuff in a script --maybe it needs to be setuid? blech!--, and log it there, then I dunno what to tell ya. Not much use ;-), but thanks anyway! -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
shutdown user and accountability
Dear .debs, I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: shutdown user and accountability
Blake Barnett [EMAIL PROTECTED] writes: Can't you give a group sudo access? If so, just add everyone to a group and give that group sudo /sbin/halt or sudo /sbin/shutdown or both. That's exactly what my sudo setup does right now. The problem is that apparently *everyone* needs to be able to shut down the machine (for reasons that are beyond me). Added accounts on an as needed basis is fine with me, but I don't fancy creating, oh, 250+ password protected accounts just to meet policy. Or you could write your own script which wraps around halt/shutdown and logs what it's doing via logger or syslog... On Tue, 2001-11-27 at 17:51, Olaf Meeuwissen wrote: Dear .debs, I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Blake Barnett (bdb) [EMAIL PROTECTED] Sr. Unix Administrator DevelopOnline.com office: 480-377-6816 Do, or do not. There is no try. --Yoda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
Re: shutdown user and accountability
Blake Barnett [EMAIL PROTECTED] writes: On Tue, 2001-11-27 at 18:58, Olaf Meeuwissen wrote: Blake Barnett [EMAIL PROTECTED] writes: Can't you give a group sudo access? If so, just add everyone to a group and give that group sudo /sbin/halt or sudo /sbin/shutdown or both. That's exactly what my sudo setup does right now. The problem is that apparently *everyone* needs to be able to shut down the machine (for reasons that are beyond me). Added accounts on an as needed basis is fine with me, but I don't fancy creating, oh, 250+ password protected accounts just to meet policy. Ok, I guess I didn't understand that the accounts didn't already exist. Is this some sort of kiosk or something? Nope, just a file/web server (but I'm thinking of adding a programming environment (EEK!) for educational purposes) that is in a place that does not allow physical access restrictions (beyond being able to enter the company premises). If you can't wrap the stuff in a script --maybe it needs to be setuid? blech!--, and log it there, then I dunno what to tell ya. Not much use ;-), but thanks anyway! -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
repeated UDP 62516 access attempts, what is this for?
I noticed repeated UDP 62516 access attempts on our network. Now I'm wondering what is going on. Anyone have any info/ideas. The attempts repeat every 5 seconds and come in packages of 3. The first two originate from port 62516 and the third from a steadily increasing port above 1024. The destination port is 62516 in all cases. Furthermore, the destination host is 255.255.255.255. Yup, that could include you if it weren't for the firewall here. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
repeated UDP 62516 access attempts, what is this for?
I noticed repeated UDP 62516 access attempts on our network. Now I'm wondering what is going on. Anyone have any info/ideas. The attempts repeat every 5 seconds and come in packages of 3. The first two originate from port 62516 and the third from a steadily increasing port above 1024. The destination port is 62516 in all cases. Furthermore, the destination host is 255.255.255.255. Yup, that could include you if it weren't for the firewall here. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Re: Is ident secure?
Brandon High [EMAIL PROTECTED] writes: On Thu, Aug 30, 2001 at 11:14:33PM -0300, Alisson Sellaro wrote: I was checking my firewall logs and have detected lots of TCP/113 dropped packets. Checking /etc/services I realized it was ident traffic. What do you think about such service? Should I let it blocked or should I allow it without further security exposure? The general rule applies: If you don't need it, block it. Correction: If you don't need it, don't install it! -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is ident secure?
Brandon High [EMAIL PROTECTED] writes: On Thu, Aug 30, 2001 at 11:14:33PM -0300, Alisson Sellaro wrote: I was checking my firewall logs and have detected lots of TCP/113 dropped packets. Checking /etc/services I realized it was ident traffic. What do you think about such service? Should I let it blocked or should I allow it without further security exposure? The general rule applies: If you don't need it, block it. Correction: If you don't need it, don't install it! -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Re: Package: ssh 1:1.2.3-9.3 (stable)
Simon Boulet [EMAIL PROTECTED] writes: Hi, I had some problems today with sshd. Here is what was reported in my log files: Aug 23 00:23:24 host01 kernel: VM: killing process sshd Aug 23 00:23:24 host01 kernel: swap_free: swap-space map bad (entry f000) Aug 23 00:24:23 host01 kernel: VM: killing process sshd Aug 23 00:24:23 host01 kernel: swap_free: swap-space map bad (entry f000) Aug 23 00:27:51 host01 kernel: VM: killing process sshd Aug 23 00:27:51 host01 kernel: swap_free: swap-space map bad (entry f000) Aug 23 00:28:11 host01 kernel: VM: killing process sshd Aug 23 00:28:11 host01 kernel: swap_free: swap-space map bad (entry f000) Looks more like a problem with swap space than with ssh to me. Just happened to hit sshd. I was just wondering if ssh 1.2.3 was not quite old enough to release the ssh 1:2.5.2p2-3 (testing) package? Anyone can help or has any ideas of what went wrong tonight? Should I upgrade to sshd 2.5.2? Hopefully I have telnet still open and I was able to /etc/init.d/ssh restart and now it seems to work as normal. Having telnet around kind of defeats the purpose of ssh, not? You su to root on your telnet connection and your root password flies over the wire for all the snoop. Eek! -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: File transfer using ssh
Philipp Schulte [EMAIL PROTECTED] writes: On Thu, Aug 23, 2001 at 05:08:48PM +1000, Jason Thomas wrote: On Thu, Aug 23, 2001 at 09:02:35AM +0200, Jaan Sarv wrote: root? root?!?!??? ROOT! first of all, example!! secondly, secure shell protocol, secure! That's supposed to be a joke, right? Just because something can be used in a secure manner doesn't mean you can't use it in a more insecure manner. third, sometimes when your lazy you just have too! You should never be too lazy to log in as a user and su to root. Better yet, stick `PermitRootLogin no' in /etc/ssh/sshd_config. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: File transfer using ssh
Sam Couter [EMAIL PROTECTED] writes: Philipp Schulte [EMAIL PROTECTED] wrote: You should never be too lazy to log in as a user and su to root. su to root: 8 character password. ssh directly as root: 1024 bit RSA key. Eh, ssh in as user and su to root is what Phil is talking about ... Which one is easiest to crack? I don't allow telnet logins as root, but I'm quite happy to allow RSA authenticated root logins with SSH. su to root after ssh'ing and you will have a log entry telling you who su'd to root (assuming you're not tossing authpriv which you shouldn't to begin with) Plus, su doesn't forward X connections. Real sysadmins don't need X to admin! (duck) -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: UP2DATE
=?x-user-defined?Q?--=3D=5B_..::_V=EDr=F9=A7_::.._=5D=3D--?= [EMAIL PROTECTED] writes: Hmm, can't say I'm overly fond of your email address, but ... I saw many Debian users get their system up2date using apt-get. But their versions of the applications are _the_ latest one, when I look at my system I seem to have, up2date, but older versions. Those folks are running unstable/testing. If you don't know how to get that in your sources.list, it's probably not for you. Could anyone tell me what I can change to get the latest verions ? For a purist setup: deb http://security.debian.org stable/updates main deb http://your debian mirror here/debian stable main deb http://your debian-non-US mirror here/debian-non-US stable non-US/main #deb http://your debian mirror here/debian testing main #deb http://your debian-non-US mirror here/debian-non-US testing non-US/main #deb http://your debian mirror here/debian unstable main #deb http://your debian-non-US mirror here/debian-non-US unstable non-US/main Where I've commented out testing and unstable so you don't shoot yourself in the foot unless you uncomment them. Feel free to add contrib, non-free, non-US/contrib and/or non-US/non-free as you see fit. And what do I need to chang in /etc/apt/sources.list in the security line. See above, first line of sources.list, covers non-US/main too. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package: ssh 1:1.2.3-9.3 (stable)
Simon Boulet [EMAIL PROTECTED] writes: Hi, I had some problems today with sshd. Here is what was reported in my log files: Aug 23 00:23:24 host01 kernel: VM: killing process sshd Aug 23 00:23:24 host01 kernel: swap_free: swap-space map bad (entry f000) Aug 23 00:24:23 host01 kernel: VM: killing process sshd Aug 23 00:24:23 host01 kernel: swap_free: swap-space map bad (entry f000) Aug 23 00:27:51 host01 kernel: VM: killing process sshd Aug 23 00:27:51 host01 kernel: swap_free: swap-space map bad (entry f000) Aug 23 00:28:11 host01 kernel: VM: killing process sshd Aug 23 00:28:11 host01 kernel: swap_free: swap-space map bad (entry f000) Looks more like a problem with swap space than with ssh to me. Just happened to hit sshd. I was just wondering if ssh 1.2.3 was not quite old enough to release the ssh 1:2.5.2p2-3 (testing) package? Anyone can help or has any ideas of what went wrong tonight? Should I upgrade to sshd 2.5.2? Hopefully I have telnet still open and I was able to /etc/init.d/ssh restart and now it seems to work as normal. Having telnet around kind of defeats the purpose of ssh, not? You su to root on your telnet connection and your root password flies over the wire for all the snoop. Eek! -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Re: File transfer using ssh
Philipp Schulte [EMAIL PROTECTED] writes: On Thu, Aug 23, 2001 at 05:08:48PM +1000, Jason Thomas wrote: On Thu, Aug 23, 2001 at 09:02:35AM +0200, Jaan Sarv wrote: root? root?!?!??? ROOT! first of all, example!! secondly, secure shell protocol, secure! That's supposed to be a joke, right? Just because something can be used in a secure manner doesn't mean you can't use it in a more insecure manner. third, sometimes when your lazy you just have too! You should never be too lazy to log in as a user and su to root. Better yet, stick `PermitRootLogin no' in /etc/ssh/sshd_config. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Re: File transfer using ssh
Sam Couter [EMAIL PROTECTED] writes: Philipp Schulte [EMAIL PROTECTED] wrote: You should never be too lazy to log in as a user and su to root. su to root: 8 character password. ssh directly as root: 1024 bit RSA key. Eh, ssh in as user and su to root is what Phil is talking about ... Which one is easiest to crack? I don't allow telnet logins as root, but I'm quite happy to allow RSA authenticated root logins with SSH. su to root after ssh'ing and you will have a log entry telling you who su'd to root (assuming you're not tossing authpriv which you shouldn't to begin with) Plus, su doesn't forward X connections. Real sysadmins don't need X to admin! (duck) -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Re: UP2DATE
=?x-user-defined?Q?--=3D=5B_..::_V=EDr=F9=A7_::.._=5D=3D--?= [EMAIL PROTECTED] writes: Hmm, can't say I'm overly fond of your email address, but ... I saw many Debian users get their system up2date using apt-get. But their versions of the applications are _the_ latest one, when I look at my system I seem to have, up2date, but older versions. Those folks are running unstable/testing. If you don't know how to get that in your sources.list, it's probably not for you. Could anyone tell me what I can change to get the latest verions ? For a purist setup: deb http://security.debian.org stable/updates main deb http://your debian mirror here/debian stable main deb http://your debian-non-US mirror here/debian-non-US stable non-US/main #deb http://your debian mirror here/debian testing main #deb http://your debian-non-US mirror here/debian-non-US testing non-US/main #deb http://your debian mirror here/debian unstable main #deb http://your debian-non-US mirror here/debian-non-US unstable non-US/main Where I've commented out testing and unstable so you don't shoot yourself in the foot unless you uncomment them. Feel free to add contrib, non-free, non-US/contrib and/or non-US/non-free as you see fit. And what do I need to chang in /etc/apt/sources.list in the security line. See above, first line of sources.list, covers non-US/main too. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Re: Unidentified subject!
Nick Name [EMAIL PROTECTED] writes: Hi all. I run a stable with some package from testing (XFree86 4.02 and konqueror). Some week ago in the morning I found my computer had been rebooted by night and found some zeroes in my syslog, just before the reboot. I first thought of a worm, the latest ramen variant (don't remember the name right now), but I didn't find any sign of it. I have changed my passwords, however I am using ipchains. Today my computer has freezed (!!! Its a debian it really shouldn't :) ) and I found those zeroes again after pressing that big red button. Hmm, sounds similar to what I experienced. Have a look at http://lists.debian.org/debian-user-0106/msg01977.html and follow-ups for details. I finally ended up blaming it on a bad graphics card, switched to using the frame buffer and haven't had any trouble since. Hope this helps, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development Free Software: `No walls, no windows! No fences, no gates!' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nmap 2.12
Gregoire Welraeds [EMAIL PROTECTED] writes: I have recently installed a basic potato on a PII. While playing a little bit around a find that the provided nmap was only a 2.12 version. It is a rather old version of nmap (I have a 2.53 installed on a SuSE 6.3). Is there any known reason for this choice ? The reason is called 'stable' ;-) Debian does not put new versions into stable. It just allows security fixes to be made to it. Okay, ocassionally a new upgrade (e.g. 2.2r1 to 2.2r2) may fix some serious breakage as well, but that's about it. If you want more recent versions of various packages, point yourself at 'testing' or 'unstable'. My nmap is 2.54.22.BETA-2 (from testing) which beats your 2.53. The preference functionality in apt should let you pull down only selected packages from testing and/or unstable. I don't know if potato's apt already supports this though. Hope this helps, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development Free Software: `No walls, no windows! No fences, no gates!' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nmap 2.12
Tim Haynes [EMAIL PROTECTED] writes: Olaf Meeuwissen [EMAIL PROTECTED] writes: [snip] The reason is called 'stable' ;-) Debian does not put new versions into stable. It just allows security fixes to be made to it. Okay, ocassionally a new upgrade (e.g. 2.2r1 to 2.2r2) may fix some serious breakage as well, but that's about it. Indeed. If you want more recent versions of various packages, point yourself at 'testing' or 'unstable'. My nmap is 2.54.22.BETA-2 (from testing) which beats your 2.53. The preference functionality in apt should let you pull down only selected packages from testing and/or unstable. I don't know if potato's apt already supports this though. FWIW, one way that I used until I recently converted this whole box up to Testing was to have sources that came from unstable/testing/secure/stable in that order, while binary packages only came from secure/stable in that order. Hence, if I wanted a newer version I didn't have to dist-upgrade the whole box, but could (normally) build on stable. On a really secure box I wouldn't want to have the build environment needed to do this. Perhaps on another reasonably secure box where I am the one and only normal user, but that's another story. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development Free Software: `No walls, no windows! No fences, no gates!' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nmap 2.12
Hubert Chan [EMAIL PROTECTED] writes: Olaf == Olaf Meeuwissen [EMAIL PROTECTED] writes: Olaf On a really secure box I wouldn't want to have the build Olaf environment needed to do this. Perhaps on another reasonably Olaf secure box where I am the one and only normal user, but that's Olaf another story. Well, you can build on one box, and install the packages on the other. AFAIK, to install the new packages, you wouldn't need anything that you don't already have. I know, but from the original poster's mail I got the impression he was doing this on a single machine. Just wanted to point out that that might not be the ultimate in security :-) -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development Free Software: `No walls, no windows! No fences, no gates!' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nmap 2.12
Gregoire Welraeds [EMAIL PROTECTED] writes: I have recently installed a basic potato on a PII. While playing a little bit around a find that the provided nmap was only a 2.12 version. It is a rather old version of nmap (I have a 2.53 installed on a SuSE 6.3). Is there any known reason for this choice ? The reason is called 'stable' ;-) Debian does not put new versions into stable. It just allows security fixes to be made to it. Okay, ocassionally a new upgrade (e.g. 2.2r1 to 2.2r2) may fix some serious breakage as well, but that's about it. If you want more recent versions of various packages, point yourself at 'testing' or 'unstable'. My nmap is 2.54.22.BETA-2 (from testing) which beats your 2.53. The preference functionality in apt should let you pull down only selected packages from testing and/or unstable. I don't know if potato's apt already supports this though. Hope this helps, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development Free Software: `No walls, no windows! No fences, no gates!'
Re: nmap 2.12
Tim Haynes [EMAIL PROTECTED] writes: Olaf Meeuwissen [EMAIL PROTECTED] writes: [snip] The reason is called 'stable' ;-) Debian does not put new versions into stable. It just allows security fixes to be made to it. Okay, ocassionally a new upgrade (e.g. 2.2r1 to 2.2r2) may fix some serious breakage as well, but that's about it. Indeed. If you want more recent versions of various packages, point yourself at 'testing' or 'unstable'. My nmap is 2.54.22.BETA-2 (from testing) which beats your 2.53. The preference functionality in apt should let you pull down only selected packages from testing and/or unstable. I don't know if potato's apt already supports this though. FWIW, one way that I used until I recently converted this whole box up to Testing was to have sources that came from unstable/testing/secure/stable in that order, while binary packages only came from secure/stable in that order. Hence, if I wanted a newer version I didn't have to dist-upgrade the whole box, but could (normally) build on stable. On a really secure box I wouldn't want to have the build environment needed to do this. Perhaps on another reasonably secure box where I am the one and only normal user, but that's another story. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development Free Software: `No walls, no windows! No fences, no gates!'
Re: nmap 2.12
Hubert Chan [EMAIL PROTECTED] writes: Olaf == Olaf Meeuwissen [EMAIL PROTECTED] writes: Olaf On a really secure box I wouldn't want to have the build Olaf environment needed to do this. Perhaps on another reasonably Olaf secure box where I am the one and only normal user, but that's Olaf another story. Well, you can build on one box, and install the packages on the other. AFAIK, to install the new packages, you wouldn't need anything that you don't already have. I know, but from the original poster's mail I got the impression he was doing this on a single machine. Just wanted to point out that that might not be the ultimate in security :-) -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development Free Software: `No walls, no windows! No fences, no gates!'
Re: MD5 sums of induvidual files?
Brandon High [EMAIL PROTECTED] writes: On Wed, 18 Apr 2001, Michael Boman wrote: Is there a repository of MD5 sums for single files in a package? Look under /var/lib/dpkg/info/*.md5sums I don't know if there is an automated method of verifying that the sums match currently installed files though. Try debsums -s and read man debsums. Note that not all packages come with an *.md5sums file :-( [EMAIL PROTECTED]:~$ dpkg -l | grep ^.i | wc -l 536 [EMAIL PROTECTED]:~$ ls /var/lib/dpkg/info/*.list | wc -l # faster 536 [EMAIL PROTECTED]:~$ ls /var/lib/dpkg/info/*.md5sums | wc -l 429 -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it -- Richard Feynman
Re: MD5 sums of individual files?
[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. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MD5 sums of individual files?
[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. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Re: SSH and RSA
Stephen Andrew [EMAIL PROTECTED] writes: Mike Dresser wrote: You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want, and he'll still be able to connect, assuming he can get to the machine via your network/internet. Mike has an exceptionally pertinant point here. Right now - even before you start trying to load your own RSA key in, log into all machines running SSH and remove the previous admins key from ~root/.ssh/authorized_keys; Be paranoid. Remove the ~root/.shh/autohorized_keys from all boxen (you might want to move it out of the way till you're set up though) and start from scratch. As the admin you want to know who can get in as root on your machines. Besides script kiddies of course :-) There was a good mini HOWTO kind of posting on debian-user a while back that got me started without much trouble. The original is at: http://home.netcom.com/~kmself/Linux/FAQs/sshrsakey.html Hope this helps, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH and RSA
Stephen Andrew [EMAIL PROTECTED] writes: Mike Dresser wrote: You don't mention whether the previous admin is still with you, but if not, you'll want to remove his RSA keys from the server, or else you can change your root password all you want, and he'll still be able to connect, assuming he can get to the machine via your network/internet. Mike has an exceptionally pertinant point here. Right now - even before you start trying to load your own RSA key in, log into all machines running SSH and remove the previous admins key from ~root/.ssh/authorized_keys; Be paranoid. Remove the ~root/.shh/autohorized_keys from all boxen (you might want to move it out of the way till you're set up though) and start from scratch. As the admin you want to know who can get in as root on your machines. Besides script kiddies of course :-) There was a good mini HOWTO kind of posting on debian-user a while back that got me started without much trouble. The original is at: http://home.netcom.com/~kmself/Linux/FAQs/sshrsakey.html Hope this helps, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Re: secure install
Izak Burger [EMAIL PROTECTED] writes: On Thu, 15 Feb 2001, Raphael Bauduin wrote: Does that mean that if someone installs a package with dselect, dselect will in any case install all those unwanted packages? Nope, see below. It's just that dselect believes you need everything (well most at least) that is priority important or standard unless you tell it otherwise. I had this experience too. I install a nice working system and the moment I run dselect to install a few other things, it installs a whole lot of things I'm REALLY not interested in. These days I try to stick with apt-get. I developed a habit of pressing `_' with the cursor on the `Available packages (not currently installed)' line, fix up the conflicts and hit `Q' (shift-q). Not elegant, but very effective. BTW, if your access method is apt based it _asks_ you if you want to continue IIRC. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Re: secure install
[EMAIL PROTECTED] writes: In reply to Olaf Meeuwissen [EMAIL PROTECTED] BTW, if your access method is apt based it _asks_ you if you want to continue IIRC. what about apt-get --assume-yes ? Hmm, I think your sig is rather appropriate ... He who sacrifices functionality for ease of use Loses both and deserves neither :-) Seriously though, if you've set assume-yes in your apt.conf file you ought to know you're in for surprises. -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development
