Re: Debian security being trashed in Linux Today comments
On Monday, 2002-01-14 at 23:20:21 -0400, Peter Cordes wrote: On Mon, Jan 14, 2002 at 01:25:11PM -0500, Jeremy L. Gaddis wrote: I recompressed it as a real PNG, and attached it to this mail, for your viewing pleasure :) PNG gets 3.5 times better compression, probably because this image only uses 8 bits of colour, and the xwd was 24bit. I hadn't tried to view it when it first came around. As a graph, it is not very impressive. Hard to judge x and y for any point on the curve. This would probably be better done as a histogram. Someone else mentioned that this graph should go up on a website, but someone else shot them down. I think the suggestion was just for this image in particular, not that this should be done for every image-attachment on all lists. Anyway, I agree that it would be cool to have this graph and the data available on a web site. (With the data in a two-column ascii list, rather than a spreadsheet or something that needs to be downloaded and dealt with separately.) Of course, then we might need to make up excuses, or preferably find solutions, for the exceptionally long bugs. I still think a table and graph would be a god addition to the security FAQ, as an answer to the question How long does Debian take to fix known vulnerabilities. Tne table could go in the FAQ, and the graph could be linked. (Dunno how the FAQ gets set up, but I guess there will be an ASCII-only version.) I believe the most useful format would be linear for the number of bugs fixed, and log for the time. Like this Time (days) No of fixes 1 ? 2-3 ? 4-7 ? 8-15? 16-31 ? etc. I'd be *really* interested in seeing that kind of table for more OSes. Not only Linux distributions, but also Solaris, *BSD, and Windowses. My gut feeling is that Debian would shine in such a comparison. Initially, I came to Debian because I had the feeling that it was the Linux dustribution with the fastest reaction to the discovery of vulnerabilities. Judging from BUGTRAQ. Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
default security
I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. I know this would take some time to implement, but I think it would help the image of debian and linux over time. I'm often frustrated that the big distros (rh, mandrake) doesn't do more to harden their distros. For example the default install of ssh in RH still provides both ssh1 and ssh2 root login. I know this is a rant, but maybe it would be wise to think of a way to implement this. At least, put more deamons in chroot jails and get libsafe compiled into every package. Tarjei -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
I'd agree with your comments. I being looking at OpenBSD (for various reasons) and the default setup is reasonable secure (there are still some things left on , which supprised me). Not sure if Debian needs to go as far as OpenBSD but I think that it is a good referance base Jon --- Tarjei [EMAIL PROTECTED] wrote: Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. I know this would take some time to implement, but I think it would help the image of debian and linux over time. I'm often frustrated that the big distros (rh, mandrake) doesn't do more to harden their distros. For example the default install of ssh in RH still provides both ssh1 and ssh2 root login. Tarjei __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Tue, 2002-01-15 at 09:44, Florian Weimer wrote: Adam Warner [EMAIL PROTECTED] writes: http://www.linuxtoday.com/news_story.php3?ltsn=2002-01-14-002-20-SC-DB Someone with better knowledge of all the facts might want to comment on the claim that Debian is always the last to fix security holes and the tag team follow up I've been fighting for months now to try to convince them to release an advisory or fix for ftpd... Of course, libc problems are a bit unfair for comparison. Red Hat runs the official CVS repository, and they probably knew about the problem by mid-November or something like that (the fix was committed on 2001-11-29, IIRC). I've just found that some anonymous poster promoted the Linux Today comments on Debian Planet: http://www.debianplanet.org//article.php?sid=568 At this rate Slashdot isn't far off ;-) Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Mon, Jan 14, 2002 at 09:53:15AM -0500, Noah L. Meyerhans wrote: On Mon, Jan 14, 2002 at 01:37:50PM +, Simon Huggins wrote: So perhaps Debian security is only as good as the package maintainers? I'm sure most maintainers do care and do investigate bugs I probably just had a bad experience. That is the case in unstable and testing, but not stable. You seem to be implying I was talking about woody or sid yet the bug in the BTS says potato. That is why you're encouraged to run stable on any machine connected to the internet. In its case, there is a group within Debian who is responsible for providing security updates in a timely manner with or without assistance from the package maintainer. I should probably have emailed security-team instead of security when I found the bug. Ho hum. -- --( Lefinnois[away] huggie: dans ton troupeau de )-- Simon ( clef public c'est la quelle la bonne ? ) Nomis Htag.pl 0.0.19 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Tue, Jan 15, 2002 at 09:23:20AM +0100, Lupe Christoph wrote: On Monday, 2002-01-14 at 23:20:21 -0400, Peter Cordes wrote: On Mon, Jan 14, 2002 at 01:25:11PM -0500, Jeremy L. Gaddis wrote: I recompressed it as a real PNG, and attached it to this mail, for your viewing pleasure :) PNG gets 3.5 times better compression, probably because this image only uses 8 bits of colour, and the xwd was 24bit. I hadn't tried to view it when it first came around. As a graph, it is not very impressive. Hard to judge x and y for any point on the curve. This would probably be better done as a histogram. Well. Take in account it was done somewhat in a hurry... IIRC x = number of days taken to fix bug y = number of bugs fixed Someone else mentioned that this graph should go up on a website, but someone else shot them down. I think the suggestion was just for this image I did not shot him down just said I did not think it would be possible. Problem is, debiandoc-sgml has no support for inline images. I still think a table and graph would be a god addition to the security FAQ, as an answer to the question How long does Debian take to fix known vulnerabilities. Tne table could go in the FAQ, and the graph could be linked. (Dunno how the FAQ gets set up, but I guess there will be an ASCII-only version.) Already did it yesterday (except for th column with the data). See http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.3 Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
J.T. Sterlings Daily Special - January 15, 2002
Title: Welcome to J.T. Sterlings J.T. Sterlings Daily Specials - January 15, 2002Our Daily Specials change once every day at Midnight, Eastern Time. You are subscribed to J.T. Sterlings Daily Special mailings. Visit us at www.jtsterlings.com or click below to place your order. Item 21531 Rose bush with a butterfly that flutters by. Tune: "Rose Garden." 12" high. $21.95 Regular Price. Regular Price $21.95 Sale Price $16.02 Today's Special Price $14.42 You save 10% Click Here To Order! Item 21564 Delicate pink shell vase with flowers and parrot are the designs on this lacquered wood screen. 9 3/4" x 1" x 28" high. $29.95 Regular Price. Regular Price $29.95 Sale Price $21.86 Today's Special Price $19.67 You save 10% Click Here To Order! Item 21565 Lacquered wood screen with peach and blue birds with yellow and green shell leaves and flowers. 9 3/4" x 1" x 28" high. $29.95 Regular Price. Regular Price $29.95 Sale Price $21.86 Today's Special Price $19.67 You save 10% Click Here To Order! Item 21566 Blue, yellow and pink birds with pink and green leaves and flowers bedeck this lacquered wood screen. 9 3/4" x 1" x 28" high. $29.95 Regular Price. Regular Price $29.95 Sale Price $21.86 Today's Special Price $19.67 You save 10% Click Here To Order! You are receiving this special offer because you have provided permission to receive third party email communications regarding special online promotions or offers. Any third-party offers contained in this email are the sole responsibility of the offer originator. Copyright © 2001 J.T. Sterlings - 5700 Memorial Highway Suite 206, Tampa FL 33615. All Rights Reserved. J.T. Sterlings does not condone the use of unsolicited email (spam). If you do not wish to receive any further messages from J.T. Sterlings, please follow the instructions below to unsubscribe. --- You are currently subscribed to dailyspecial as: [EMAIL PROTECTED] To unsubscribe send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Asking for documentation help (Re: IPSec questions...)
On Mon, Jan 14, 2002 at 07:52:59AM -0700, Stefan Srdic wrote: I don't have any pratical experience with FreeSWAN at all, however, I have statically compiled BIND 9 and placed it in a chroot jail on Debian. I wonder if it would hard to packge a chroot'ed setup of BIND9 once it completely configured? As already said, documentation is a *Very* important part of a distribution. IMHO the Securing Debian HOWTO (might change it to Manual sometime in the future) does tackle an important issue. I would be very grateful if you reviewed and improved the (incomplete) information I wrote regarding Bind security in Debian (IMHO it's better placed here than in a separate HOWTO). Please read: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind SGML sources are available through CVS (check http://www.debian.org/doc/ddp), patches for the CVS sources are prefered but I will also accept any other suggestions. Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. Agreed. Feel free to point to better security measures in the Default installation and document them, once done it is a major point of pressure to change Debian policy. I know this would take some time to implement, but I think it would help the image of debian and linux over time. I'm often frustrated that the big distros (rh, mandrake) doesn't do more to harden their distros. For example the default install of ssh in RH still provides both ssh1 and ssh2 root login. Debian, unlike RedHat or Mandrake provides and gives support for Bastille Linux. Even if the default setup is quite good (security-wise) it can easily be made even better. I know this is a rant, but maybe it would be wise to think of a way to implement this. At least, put more deamons in chroot jails and get libsafe compiled into every package. Debian could provide, with only some effort from package maintainers versions of daemons chrooted to given environments. This however, might break Policy (IMHO). BTW, Bastille does have modules for chrooting services (it has one for Bind) that can be selected when hardening the system. You could also help having Bastille's module (for Bind) adapted to Debian (I have not had time to do so myself) Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Asking for documentation help (Re: IPSec questions...)
That would be great. I will accept patches anytime. Please don't forget about writting it! (I will keep this mail, just as a reminder :) Javi On Mon, Jan 14, 2002 at 10:46:48AM -0500, Noah L. Meyerhans wrote: I'd happily volunteer to write the whole chapter, but I don't forsee having enough free time for that until sometime in mid March. If anybody wants to work on it, though, let me know, and I'll lend a hand. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Wed, 2002-01-16 at 01:07, Javier Fernández-Sanguino Peña wrote: Already did it yesterday (except for th column with the data). See http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.3 Please consider removing any reference to the average amount of time in the FAQ: ...it took the Debian Security Team an average of 35 days to fix security-related vulnerabilites. An average based upon a very long tail is highly misleading. Please quote the median time to fix a vulnerability instead. This will will be less than or equal to 10 days given this statistic: over 50% of the vulnerabilities where fixed in a 10-days time Because of this research it looks like Debian's security information page will have to be changed: http://www.debian.org/security/ Debian takes security very seriously. Most security problems brought to our attention are corrected within 48 hours. That's just not an honest description of what's occurred. It appears from the research that most (i.e. 50%) of security problems are corrected within 10 days, not 48 hours. I still need to be able to download that spreadsheet. I have viewed the PNG picture. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) | Regarding limiting BIND's privileges you must be aware that if a | non-root user runs BIND, then BIND cannot detect new interfaces | automatically. For example, if you stick a PCMCIA card into your laptop. Like anyone would really want to run bind automatically on all transient interfaces... It's a *service*, to be run on *serv-ers*! If you want a named listening on such an interface, the due pain is deserved, IMHO. (I've been meaning to get that off my chest for a few months :8) The above URL links to a bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no\bug=50013, which seems to imply that chroot()ed behaviour will be expected ere long. Have I missed it, or shall I carry on hoping? :) [snip] ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
faster -- Re: Debian security being trashed in Linux Today comments
hi ya i did an dist-upgrade update upgrade today... and saw sudo get update before fixes to sudo was posted to bugtraq c ya alvin On 15 Jan 2002, Adam Warner wrote: On Tue, 2002-01-15 at 09:44, Florian Weimer wrote: Adam Warner [EMAIL PROTECTED] writes: http://www.linuxtoday.com/news_story.php3?ltsn=2002-01-14-002-20-SC-DB Someone with better knowledge of all the facts might want to comment on the claim that Debian is always the last to fix security holes and the tag team follow up I've been fighting for months now to try to convince them to release an advisory or fix for ftpd... Of course, libc problems are a bit unfair for comparison. Red Hat runs the official CVS repository, and they probably knew about the problem by mid-November or something like that (the fix was committed on 2001-11-29, IIRC). I've just found that some anonymous poster promoted the Linux Today comments on Debian Planet: http://www.debianplanet.org//article.php?sid=568 At this rate Slashdot isn't far off ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
also sprach Javier Fernández-Sanguino Peña [EMAIL PROTECTED] [2002.01.15.1316 +0100]: Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) well, first of all, this document refers to a bug, #50013 (to which this is CCd). in the bug, the argument comes up that opinions differ from running bind non-root. but a chroot jail is advised. i'd love to know just why you'd ever run bind as root, even in a jail. if i have root rights in a jail, i'll break out of the jail within minutes (e.g. [1]). second, why would you *need* bind running as root? and thirdly, please check the threads at [2] and [3] if you are interested in a discussion on bind9 and chroot. One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. Agreed. Feel free to point to better security measures in the Default installation and document them, once done it is a major point of pressure to change Debian policy. running non-root *and* chrooting. Debian could provide, with only some effort from package maintainers versions of daemons chrooted to given environments. This however, might break Policy (IMHO). how would it break policy? 1. http://www.bpfh.net/simes/computing/chroot-break.html 2. http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg01393.html 3. http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg01001.html -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck above all, we should not wish to divest our existence of its rich ambiguity. -- nietzsche msg05281/pgp0.pgp Description: PGP signature
Re: faster -- Re: Debian security being trashed in Linux Today comments
Previously Alvin Oga wrote: i did an dist-upgrade update upgrade today... and saw sudo get update before fixes to sudo was posted to bugtraq Actually it was posted to bugtraq about 15 minutes before but you only saw it later due to moderation :) Wichert. -- _ [EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Wed, Jan 16, 2002 at 01:42:50AM +1300, Adam Warner wrote: ...it took the Debian Security Team an average of 35 days to fix security-related vulnerabilites. An average based upon a very long tail is highly misleading. Please quote the median time to fix a vulnerability instead. It is not misleading in this case, the tail is the _most_ important part of the data. It doesn't matter if we patch every other hole in 10 minutes if we leave one open for months. Furthermore I think the mean is exactly the right measure of this: from the user point of view, the important figure is total exposure time, i.e. sum of time between vulnerability discovery and patch (for installed packages) for all vulns. For someone who installs every Debian package, this is equal to (# of vulnerabilities)x(mean time to patch). The former measures how well packages are audited in advance, the latter measures how quickly vulnerabilities are corrected. It's the right statistic. -- Colin Phipps PGP 0x689E463E http://www.netcraft.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
Previously Colin Phipps wrote: It is not misleading in this case, the tail is the _most_ important part of the data. It doesn't matter if we patch every other hole in 10 minutes if we leave one open for months. Both are interesting though. Wichert. -- _ [EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
Tarjei [EMAIL PROTECTED] writes: Hmm. Here's a suggestion. - This idea is based on the asumtion that espesially serversystems need good security. *All* installed boxes need adequate securing. Linux worms would not propagate if it weren't for a critical mass of idiots running unpatched daemons packages; scanning by IP# is no respector of `this is a server' or `this is a workstation'; it just happens that servers *have* to be secure while workstations tend not to be. 1. Make a votingpage and anounce it on debian-users asking what are the main servers people are running on their debian systems. You'd want a control poll e.g. on slashdot or somewhere as well because the Internet as a whole will run different servers in different amounts - more web servers than DNS than email? Or similar numbers of each? 2. Go through the 10 highest and make sure they follow secure practies like libsafe. Personally I think a BIG disclaimer in the installer, `look, if you will run these things, on your head be it' for every daemon that gets installed would be in order. [snip] I apoligize to all the people reading this list for filling it with rants. Will stop now. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
Colin Phipps [EMAIL PROTECTED] writes: On Wed, Jan 16, 2002 at 01:42:50AM +1300, Adam Warner wrote: ...it took the Debian Security Team an average of 35 days to fix security-related vulnerabilites. An average based upon a very long tail is highly misleading. Please quote the median time to fix a vulnerability instead. It is not misleading in this case, the tail is the _most_ important part of the data. It doesn't matter if we patch every other hole in 10 minutes if we leave one open for months. Yes it does, if that remaining hole is merely a local non-root potential vulnerability with no known exploit that's a PITA to fix - you *must* weight the average accordingly. Much as I hate stats, I can see that what you want to measure is how much lethargy there is in Debian, which means excluding other influences, and instead of wondering about means modes and medians, you've got to weight the whole thing. Bah, complicated. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Tue, Jan 15, 2002 at 01:52:47PM +, Colin Phipps wrote: [...] Furthermore I think the mean is exactly the right measure of this: from the user point of view, the important figure is total exposure time, i.e. sum of time between vulnerability discovery and patch (for installed packages) for all vulns. For someone who installs every Debian package, this is equal to (# of vulnerabilities)x(mean time to patch). The former measures how well packages are audited in advance, the latter measures how quickly vulnerabilities are corrected. It's the right statistic. Are there any stats available on the number of people who have each package installed? (I think not, but better ask). If such stats were available, then security flaws in popular packages could be weighted higher than flaws in the not-so-popular packages. tangentSuch numbers may also be useful for guestimating the impact of non-security related bugs... I feel a debian package coming along... (mutters as he walk off into the sunset)/tangent -- Colin Phipps PGP 0x689E463E http://www.netcraft.com/ -- Karl E. Jørgensen [EMAIL PROTECTED] www.karl.jorgensen.com One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh msg05289/pgp0.pgp Description: PGP signature
Re: Following security issues found upstream
Previously Jean-Marc Boursot wrote: Like the last postfix DoS? Am I wrong or there wasn't any bugtraq report for that? There was, Wietse announced it to bugtraq. Wichert. -- _ [EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Tue, Jan 15, 2002 at 02:04:38PM +, Tim Haynes wrote: Colin Phipps [EMAIL PROTECTED] writes: It is not misleading in this case, the tail is the _most_ important part of the data. It doesn't matter if we patch every other hole in 10 minutes if we leave one open for months. Yes it does, if that remaining hole is merely a local non-root potential vulnerability with no known exploit that's a PITA to fix - you *must* weight the average accordingly. Agreed, weighted mean (by severity of vulnerability and popularity of package) would be better, if suitable weighting could be devised. On Tue, Jan 15, 2002 at 01:55:18PM +, Karl E. Jorgensen wrote: Are there any stats available on the number of people who have each package installed? Relative popularity of packages can be got from the popularity-contest results (although this will tend to reflect workstations more than servers, since people running a secure server aren't likely to run something that sends their package list to anyone). http://people.debian.org/~apenwarr//popcon/ -- Colin Phipps PGP 0x689E463E http://www.netcraft.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[] .
Title: °Ë»ö¿£Áø ¾ÆÀ̵ûµûµû
ÀÎÅͳݿ¡´Â ¸¹Àº Á¤º¸¿Í ±× Á¤º¸¸¦ ã¾ÆÁÖ´Â °Ë»ö¿£ÁøÀÌ ÀÖ½À´Ï´Ù.
ÇÏÁö¸¸ °Ë»ö¿£ÁøµéÀÌ ³Ê¹«³ª ¸¹Àº Á¤º¸¸¦ Á¦°øÇØ ÁÖ´Â °á°ú ¿ÀÈ÷·Á Á¤º¸¸¦ ã´Âµ¥ ¸¹Àº ³ë·Â°ú ½Ã°£À»
ÇãºñÇÏ´Â °á°ú¸¦ ÃÊ·¡ÇÏ°í ÀÖ½À´Ï´Ù.
ÀÌÁ¦´Â ¾òÀ» ¼ö ¾ø´Â ¸¹Àº ¾çÀÇ °Ë»ö°á°úº¸´Ù´Â ½Å·Ú¼º ÀÖ´Â Á¤º¸¸¦ ¿ä±¸ÇÏ´Â ½Ã´ë°¡ µÇ¾ú½À´Ï´Ù.
ÀÎÅͳݿ¡ »êÀçÇØ ÀÖ´Â »çÀÌÆ® Áß¿¡´Â ¿ì¸®°¡ ²À ÇÊ¿äÇÑ Á¤º¸µéÀ» ´ã°í ÀÖ´Â »çÀÌÆ®°¡ ¸¹ÀÌ Àִµ¥,
ÀÌ »çÀÌÆ® µéÀ» ±¸ºÐÇϸé Æ÷Å»,º¸Å»,Çãºê »çÀÌÆ®¶ó°í ÇÕ´Ï´Ù.
¾ÆÀ̵ûµûµû´Â ÀÌ·± »çÀÌÆ®¸¦ ã¾ÆÁÖ´Â Ä«Å×°í¸® ¹× Å°¿öµå °Ë»ö¿£ÁøÀÔ´Ï´Ù.
°¢ Ä«Å×°í¸® º°·Î ½Å·Ú¼º ÀÖ´Â ¾ö¼±µÈ »çÀÌÆ®¸¸ ³×ƼÁðÀÇ ¾ç½ÉÀ¸·Î
µî·Ï°ü¸®ÇÏ´Â °Ë»ö¿£ÁøÀ̸ç
±ÍÇϲ²¼µµ Ä«Å×°í¸® ´ã´çÀÚ°¡ µÇ½Ç ¼ö ÀÖ½À´Ï´Ù.
Ä«Å×°í¸® ´ã´çÀÌ µÇ½Ã¸é ¢ß¾ÆÀÌ¿£À¥ÀÇ ÁÖ½Ä 1ÁÖ¸¦ ¹«»óÀ¸·Î µå¸®¸ç pop3 e-mail °èÁ¤À» µå¸³´Ï´Ù.
("¿¹" [EMAIL PROTECTED]")
¶ÇÇÑ,±× Ä«Å×°í¸®¸¦ °ü¸®ÇÒ ¼ö ÀÖ´Â ±ÇÇÑ°ú ÇØ´ç Ä«Å×°í¸®¿¡ ´ã´çÀÚ ¾ÆÀ̵𸦠µî·ÏÇÕ´Ï´Ù.
(µî·Ï½ÅûÀ» ÇϽÅÈÄ ´ã´ç°ü¸®ÀÚ·Î login ÇϽøé Ä«Å×°í¸®¸¦ Á÷Á¢ °ü¸®ÇÏ½Ç ¼ö ÀÖ½À´Ï´Ù.)
ȸ¿ø°¡ÀÔÀ» ÇϽðí ȸ¿øÀÌ µÇ½Ã¸é ¢ß ¾ÆÀÌ¿£À¥ÀÇ ÁÖ½Ä 1ÁÖ¸¦ ¹«»óÀ¸·Î µå¸³´Ï´Ù.
ÀÎÅͳÝÀº ³×ƼÁðÀÌ ÁÖÀÎÀÌ°í ¾ÆÀ̵ûµûµû´Â ³×ƼÁðÀÇ °ÍÀ̱⠶§¹®ÀÔ´Ï´Ù!
http://iwww.net (¾ÆÀ̵ûµûµû)·Î ¹æ¹®ÇØ ÁÖ¼¼¿ä
¾ÆÀ̵ûµûµûÀÇ À̳äÀº ¿ì¸® ³×ƼÁðÀÌ °®°íÀÖ´Â À¯ÀÍÇÑ Á¤º¸¸¦ ¼·Î °øÀ¯ÇÏ°í »õ·Î¿î ³×ƼÁð¹®È¸¦
âÃâÇϴ°ÍÀÔ´Ï´Ù. ±ÍÇϲ²¼µµ ¾ÆÀ̵ûµûµûÀÇ ÇÑ °¡Á·ÀÌ µÇ¾îÁÖ½Ã±æ ºÎŹµå¸³´Ï´Ù.
´Ã °Ç°ÇϽðí ÇູÇϼ¼¿ä~~~°¨»çÇÕ´Ï´Ù.
1ÀÏ Æò±Õ ¹æ¹®
774,500 hit(2002.01.13)
°¡ÀÔȸ¿ø
156,550 (2002.01.13)
³×ƼÁð ´ã´ç Ä«Å×°í¸®
785 °³
Á÷Á¢ ¹æ¹®Çϼż Æò°¡ÇØ ÁֽʽÿÀ! ==http://iwww.net
À¯ÀÍÇÑ »çÀÌÆ®¶ó°í Æò°¡µÇ½Ã¸é
ÁÖÀ§ºÐµé¿¡°Ô ¾Ë·ÁÁֽñæ¹Ù¶ø´Ï´Ù. ( ¾ÆÀ̵ûµûµû = iwww )
±ÍÇϲ² ºÒÆíÀ» ³¢ÃÄ µå·È´Ù¸é ¿ë¼¸¦ ¹Ù¶ø´Ï´Ù.
±ÍÇÏÀÇ ¸ÞÀÏÀº ÀÎÅͳݿ¡¼ À¥¼ÇÎÁß ÃëµæÇÏ¿´À¸¸ç ±ÍÇÏÀÇ ¾î¶°ÇÑ Á¤º¸µµ °®°íÀÖÁö ¾Ê½À´Ï´Ù.
´ÙÀ½ºÎÅÍ´Â ÀÎÅͳÝ,Á¤º¸Åë½Å,¹ÙÀÌ·¯½º¹é½Å µî À¯ÀÍÇÑ Á¤º¸¸¸À» º¸³»µå¸³´Ï´Ù.
¾ÆÀ̵ûµûµûÀÇ °¡Á·ÀÌ µÇ½Ã¸é Àüü°¡Á· ¸ÞÀÏÀ» ÅëÇÏ¿© À¯ÀÍÇÑ Á¤º¸¸¦ ¹Þ¾Æº¸½Ç ¼ö ÀÖ½À´Ï´Ù.
°øÁö»çÇ×À» Âü°íÇÏ½Ã¸é ¾ÆÀ̵ûµûµû ³»ºÎ»çÁ¤À» ¾Æ½Ç ¼ö ÀÖ½À´Ï´Ù.
¹Ù·Î°¡¼ º¸±â
³×ƼÁðÀÇ °í°ßÀ» ¼ö·ÅÇÏ´Â °ø°³°Ô½ÃÆÇÀ» ¿î¿µÁßÀÔ´Ï´Ù.
¹Ù·Î°¡¼ º¸±â
±×·¡µµ ¼ö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ç °æ¿ì ¼ö½Å°ÅºÎ¸¦ Ŭ¸¯ÇϽʽÿÀ!
¼ö½Å°ÅºÎ
Detecting break-ins
Hi, Recently I've installed some IP logging deamons (snort, ippl along with logcheck) and I was amazed how many break-in attempts there are each day on my simple home box which isn't even adverised anywhere, as I only run a few services intended for friends and family (apache, wu-ftpd, exim). I can see a lot of IIS related attempts, which obviously do not work, as well as some refused anonymous FTP connection attempts. For these I don't worry to much as they have failed. (I hope. I'm no expert, though.) Then there are more exotic stuff. High port UDP attampts, connection to port 113 etc. Now the logs provided by the above packages often say something like 'connection attempt to ..' whichever port/service. The question is whether there is a way to know whether any of those attempts succeded. Or to put it more simply, how could one distinguish a failed attempt and a successful break-in? (I know this is probably a very complex topic, but I would greatly appreciate some advise!) Many thanks for your help in advance! best regards, Balazs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Detecting break-ins
On Tue, Jan 15, 2002 at 09:04:07PM +0100, Balazs Javor wrote: Then there are more exotic stuff. High port UDP attampts, connection to port 113 etc. High port UDP stuff is often just traceroutes. 113 is normal, as many servers will attempt an auth lookup when you access them. Now the logs provided by the above packages often say something like 'connection attempt to ..' whichever port/service. The question is whether there is a way to know whether any of those attempts succeded. Or to put it more simply, how could one distinguish a failed attempt and a successful break-in? Well, the first thing to as is is there anything even listening on that port? You can feel pretty safe about (for example) connection attempts to your telnet daemon if you're not actually running a telling daemon to begin with. You should already have a pretty good idea about what services are listening on various ports on your machine. But just to be sure, try running 'netstat -ulp' and 'netstat -tlp' as root to show which PIDs are listening on which UDP and TCP ports, respectively. Turn off what you don't need by removing its entry from inetd.conf or by prevending init from starting it from /etc/rc?.d (I know this is probably a very complex topic, but I would greatly appreciate some advise!) Most of stuff that you see, really, is harmless. A lot of it, as I said above, isn't even necessarily a breakin attempt. Assuming you're up to date on the fixes from security.debian.org, you're safe from the worms and script kiddies, which are the only things stupid enough to do something that will show up in your logs. It's always good to set up a host based intrusion detection system like tripwire (preferably the version in sid, rather than the ancient slow version from potato). And look in to something like LIDS or something else that can verify the integrity of the in-memory kernel image. Kernel based rootkits are very hard to detect. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg05294/pgp0.pgp Description: PGP signature
[Deb-SEC]oddball ssh remote passwd question
Hello all, This is far from as serious an issue as some of the items on the list right now, but I thought I'd see if anyone has some input. I'm running some synchronized machines, and I only want users to change passwords on the master. So, I thought of writing a script to replace password that just uses ssh to remotely call password on the master machine and let them change it there... Well, here's the rub. if you do: ssh [EMAIL PROTECTED] password ssh will have you authenticate to host, and then bring up the password change prompt (current) UNIX password: on the remote machine. BUT when you start typing, the characters show up on screen- not hashed or unprinted. What is it that is striping this functionality from passwd? Failing finding a way to get ssh to not express these characters, I could swear there is a simple way of turning off echoing input to the screen, but for the life of me I can't remember the command or variable in bash. Anyone feeling charitable and want to help out since my memory is failing? Thanks, David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Deb-SEC]oddball ssh remote passwd question
David Ehle [EMAIL PROTECTED] writes: Hello all, if you do: ssh [EMAIL PROTECTED] password What is `password'? ssh will have you authenticate to host, and then bring up the password change prompt (current) UNIX password: on the remote machine. BUT when you start typing, the characters show up on screen- not hashed or unprinted. What is it that is striping this functionality from passwd? Failing finding a way to get ssh to not express these characters, I could swear there is a simple way of turning off echoing input to the screen, but for the life of me I can't remember the command or variable in bash. ssh(1): | -t Force pseudo-tty allocation. This can be used to execute arbi | trary screen-based programs on a remote machine, which can be | very useful, e.g., when implementing menu services. Multiple | -t options force tty allocation, even if ssh has no local tty. That any use? ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Deb-SEC]oddball ssh remote passwd question
Tim, Yep that does it :) Thanks mucho! I knew it was something VERY simple but my brain is just stir-fried today and I couldn't think of it. Thanks again. David. Tim Haynes wrote: David Ehle [EMAIL PROTECTED] writes: Hello all, if you do: ssh [EMAIL PROTECTED] password What is `password'? ssh will have you authenticate to host, and then bring up the password change prompt (current) UNIX password: on the remote machine. BUT when you start typing, the characters show up on screen- not hashed or unprinted. What is it that is striping this functionality from passwd? Failing finding a way to get ssh to not express these characters, I could swear there is a simple way of turning off echoing input to the screen, but for the life of me I can't remember the command or variable in bash. ssh(1): | -t Force pseudo-tty allocation. This can be used to execute arbi | trary screen-based programs on a remote machine, which can be | very useful, e.g., when implementing menu services. Multiple | -t options force tty allocation, even if ssh has no local tty. That any use? ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Detecting break-ins
hi balaz how much time and energy do you want to spend ??? - 1st passs.. - update your box regularly per debians security patches - read debians security howto http://www.debian.org/doc/manuals/securing-debian-howto - 2nd pass... - you;'re doing w/ snot/ippl/logcheck - logcheck already tells you whether it was successful attempts or not and how they tried it... - 3rd pass... - add host and network IDS ( tripwire, aide, etc... - if you wanna watch for network activity randomly... - run tcpdump, showtraf, trafshow, ncat, etc..etc.. - 4th pass... ( aka should be 1st pass ) - clean up permissions and remove unused services etc..etc.. ( things might break..but than yu know to fix it ) - lots of time can be spent here... - 5th pass... - if you find hackers in your box.. do you want to chase them down ??? - you need to have logs saves everywhere... - you have to be prepared to interact live with them - read your log files religiously...and understand what its says... - backup your system - make a cd image of your whole system if you're paranoid BEFORE you go online -- if a hacker gets in its too too late... -- i try to spend my time at the prevention end... not trying to detect them... but there is only so much to do before somebody else ( anotehr boss ) wants yo to do something else instead - if you only use tripwire ... it typicaly runs once a day a [cr/h]acker can do miracles to your machine until tripwire runs - i want to know that the [cr/h]acker got into my systems with a few seconds - and similarly... in a few seconds... i want a program to tell me what was changed ... - dont count on the eyes to tell you something is awry - than decide what to do with the box... watch them play with the box... or unplug it... and report it... http://www.Linux-Sec.net - see the IDS section... have fun alvin On Tue, 15 Jan 2002, Balazs Javor wrote: Hi, Recently I've installed some IP logging deamons (snort, ippl along with logcheck) and I was amazed how many break-in attempts there are each day on my simple home box which isn't even adverised anywhere, as I only run a few services intended for friends and family (apache, wu-ftpd, exim). I can see a lot of IIS related attempts, which obviously do not work, as well as some refused anonymous FTP connection attempts. For these I don't worry to much as they have failed. (I hope. I'm no expert, though.) Then there are more exotic stuff. High port UDP attampts, connection to port 113 etc. Now the logs provided by the above packages often say something like 'connection attempt to ..' whichever port/service. The question is whether there is a way to know whether any of those attempts succeded. Or to put it more simply, how could one distinguish a failed attempt and a successful break-in? (I know this is probably a very complex topic, but I would greatly appreciate some advise!) Many thanks for your help in advance! best regards, Balazs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
udp 32768
-BEGIN PGP SIGNED MESSAGE- When I do a 'netstat -l' I get (among a bunch of stuff that looks OK): mail:# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign AddressState udp0 0 *:32768 *:* What is this, and should I be worried? Jeff Teitel - -- Those who would give up essential liberty, to purchase a little temporary safety, deserve neither liberty nor safety. -Benjamin Franklin -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 Comment: See www.teitel.net for my Public Key iQEVAwUBPESxE0f9CJPZzjMvAQHPCwf8CIRI/pDNOZnVWoTwnIRs/owPWh3cO3ar pLgXM5qewDDzAvIXXazj2DGpt0p0j9K9QhpDERFWlrhATqpDE8zb526r/pdyIL60 YNeSDO00A9VOO/pvL5CcW+8T1av0MOSlUcwhHPR9uLPSGFg4kIbJ/Wb9r0Y6kgNc 9QiJirfPZ736Ia8/6Swn1/qmLR9rYvkSENrCZbBRHJC4kojXLiOegNoFy9VvhCQB OMYo5GYpVzxKROzBPA17rbJVZ80QMiI8QJH7Kngdg0/TuhuesuKkUyw+0JGIroUW e7eXpdTwpj8ooe6ZY84y40U8U2IyKVnx/SkICeiM+WtqONkNXkJ9RA== =ckem -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udp 32768
Jeff Teitel [EMAIL PROTECTED] writes: When I do a 'netstat -l' I get (among a bunch of stuff that looks OK): mail:# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign AddressState udp0 0 *:32768 *:* What is this, and should I be worried? You tell us. netstat(8): | -p, --program | Show the PID and name of the program to which each socket | belongs. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udp 32768
On Tue, Jan 15, 2002 at 03:45:59PM -0600, Jeff Teitel wrote: mail:# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign AddressState udp0 0 *:32768 *:* What is this, and should I be worried? Add the '-p' flag to netstat, which will give you the pid of the process listening on that port. Or use fuser. Then you can use ps to figure out which program is actually doing the listening. Once you figured that out, then you can decide if you should be worried. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg05301/pgp0.pgp Description: PGP signature
Re: udp 32768
-BEGIN PGP SIGNED MESSAGE- Noah L. Meyerhans wrote: On Tue, Jan 15, 2002 at 03:45:59PM -0600, Jeff Teitel wrote: mail:# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign AddressState udp0 0 *:32768 *:* What is this, and should I be worried? Add the '-p' flag to netstat, which will give you the pid of the process listening on that port. Or use fuser. Then you can use ps to figure out which program is actually doing the listening. Once you figured that out, then you can decide if you should be worried. noah mail:~# netstat -lp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp0 0 *:32768 *:* 135/named Aha! Nothing to worry about. Thanks to all who replied. Jeff - -- Those who would give up essential liberty, to purchase a little temporary safety, deserve neither liberty nor safety. -Benjamin Franklin -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 Comment: See www.teitel.net for my Public Key iQEVAwUBPES6pEf9CJPZzjMvAQHOHQgAj/JfxGt2wARsH+zrNx2u+Y4K1bB75VAT I2+VUN73HCVHuZiKEd4nLkYeG0JIAeUMADilXrfNnCI3oPtV523o98A2mkNWzCDP Vcl7VKoCBuVU2zRyJXx4Mct3mCq1r5B3XYKN2Z9X7YxiRxVRuokUE7VjR48ZqFDr 67pvXMuzmUmrL/xIaJigmc4g6/V8OWaopGvqqdkTcrdAvTZFgeFUlvn1E0MSen51 XLLEawZDVW/34AMQeT+jHpTJakRMXPxg57oxJ6/fmnBz3iWbSOE5TXPt+ZdN99RM xiyITyydLm8qHWj2KKVN7z6CMQ34pr/gG2p9FQZCB7Djub+cqKtaNQ== =jN5s -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
(Á¤º¸) ¡Ú Å·Ä«,ÄýÄ«¸¦ ãÀ¸¼¼¿ä????????????????????
(ȨÆäÀÌÁö ±¸°æÇϱâ) -- http://www.searchcorea.com ¡Ú`Å·Ä«,ÄýÄ«` ÀÚ½ÅÀÌ ¿øÇϽô ÀÌ»óÇüÀ» ã¾Æµå¸³´Ï´Ù¡Ú ¾È³çÇϼ¼¿ä.Á¦°¡ Á¤¸» ¿©¼ººÐ°ú ³²¼ººÐ²² ÁÁÀº¼Ò½Ä ¾Ë·Áµå¸±²²¿ä^^ ³²¼ººÐÀ̳ª ¿©¼ººÐÀ̳ª ¿äÁò Å·Ä« ÄýÄ«¸¦ ¸¸³ª½Ã±â Èûµå½ÃÁÒ? Á¦°¡ ÃßõÇØ µå¸®´Â »çÀÌÆ®¿¡ Çѹø °¡º¸¼¼¿ä. ÀÌ È¸»ç´Â ÂøÇÑ ³²ÀÚ,À̻ۿ©ÀÚ,´É·ÂÀִ³²ÀÚ,Çк°ÁÁÀº¿©ÀÚ,¸Å³ÊÁÁÀº³²ÀÚ µîÀ¸·Î °¢ÀÚÀÇ ¿øÇϽô ÀÌ»óÇüÀ» ã¾Æ¼ ¿¬°áÇØ Áִ ȸ»ç±¸¿ä, ¹°·Ð °¡ÀÔºñ´Â ¾ø½À´Ï´Ù. ±×¸®°í »çÁøÀ¸·Î »ó´ë¹æÀÇ ¾ó±¼À» È®ÀÎÇÒ¼ö ÀÖ¾î¼, ÀÚ½ÅÀÇ ¿øÇϽô ÀÌ»óÇüÀ» ²À ãÀ¸½Ç¼ö ÀÖÀ¸½Ç²¨¿¹¿ä,^^* ±×¸®°í ÀÚ¼¼ÇÑ ³»¿ëÀ» º¸°í½ÍÀ¸½Ã¸é ȨÆäÀÌÁö µé¾î¼Å¼ ±¸°æÇÏ½Ã¸é µÇ±¸¿ä, ÁÁÀº Á¤º¸°¡ µÇ¼ËÀ¸¸é ÁÁ°Ú³×¿ä, Áñ°Å¿î ÇÏ·ç µÇ¼¼¿ä. (ȨÆäÀÌÁö ±¸°æÇϱâ) -- http://www.searchcorea.com ps. Çã¶ô¾øÀÌ À̸ÞÀÏÀ» º¸³»¼ Á˼ÛÇÕ´Ï´Ù. À̸ÞÀÏÁּҴ Ÿ»çÀÌÆ® °Ô½ÃÆÇ¿¡¼ ã¾Æ À̸ÞÀÏÀ» º¸³»°Ô µÇ¾ú½À´Ï´Ù. À̸ÞÀÏ ¹Þ±â¸¦ ¿øÇϽÃÁö ¾ÊÀ»°æ¿ì,¼ö½Å°ÅºÎ¸¦ ÇØÁֽʽÿä. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Tue, Jan 15, 2002 at 02:34:47PM +, Colin Phipps wrote: On Tue, Jan 15, 2002 at 02:04:38PM +, Tim Haynes wrote: Colin Phipps [EMAIL PROTECTED] writes: It is not misleading in this case, the tail is the _most_ important part of the data. It doesn't matter if we patch every other hole in 10 minutes if we leave one open for months. Yes it does, if that remaining hole is merely a local non-root potential vulnerability with no known exploit that's a PITA to fix - you *must* weight the average accordingly. Agreed, weighted mean (by severity of vulnerability and popularity of package) would be better, if suitable weighting could be devised. Separate graphs would be more useful to more people. (not everybody's weighting would be the same as the weighting that would take a year of debate to not be settled anyway...) One graph for remote exploits, one for local priviledge escalation, one for remote holes in Important (according to pkg system), etc. Make a graph for anything someone might be interested in. Or even generate them on the fly with input from a set of checkboxes for which package to include; if someone wanted to write the code, it wouldn't be hard. (assuming there's a good way to see which package falls into which category... Hmm, that's probably not so easy with the data that is kept now.) Anyway, the most useful thing would be multiple graphs according to a few interesting criteria. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Tuesday, 2002-01-15 at 13:07:12 +0100, Javier Fernández-Sanguino Peña wrote: On Tue, Jan 15, 2002 at 09:23:20AM +0100, Lupe Christoph wrote: I still think a table and graph would be a god addition to the security FAQ, as an answer to the question How long does Debian take to fix known vulnerabilities. Tne table could go in the FAQ, and the graph could be linked. (Dunno how the FAQ gets set up, but I guess there will be an ASCII-only version.) Already did it yesterday (except for th column with the data). See http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.3 Thank you. But I can't parse An published in the debian-security mailinglist showed that in the year 2001, An email? Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: [??] ???? ?? ???? ????????.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 15. januar 2002 19:05 To: [EMAIL PROTECTED] Subject: [??] ?? . I tried to mail a report to [EMAIL PROTECTED], but there was no such recipient. I suggest that action is taken to get rid of all mail from this domain. -- Jan Arne Fagertun [EMAIL PROTECTED], Powel ASA, Norway Phone: +47 73804500 Fax: +47 73804501Direct phone: +47 73804568 NTNU = NT, Not Unix... http://www.nvg.ntnu.no/ntnu/ - better use Linux ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
On Tue, Jan 15, 2002 at 01:16:12PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: [snip] Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) [snip] The above link contains the following: FIXME (jfs): I'm not sure about this, shouldn't bind files be chown'ed to the groups created? Some files might need rw permissions in order for bind to work correctly; for example: if the name server is being used as a cache the cache files need to be written on hard disk. Also, if the DNS server is secondary, it might need to transfer zones from the primary and write them on hard disk too. This should be clarified. My opinion is that things that need to be writable should be owned by the user that runs named, but everything else should be owned by root. i.e. secondary zones etc., should be owned by the user that runs named. If you're doing dynamic DNS, the primary zones will also need to be writable. named.conf (and primary zones if you're not doing dynamic DNS) should be owned by root and not writable by named. This way, if there's a bind exploit, an attacker can't corrupt your zone files or config file (except for the secondary zones.) Of course, they may still be able to make the DNS server serve incorrect information, but at least it's another hurdle for them to jump over. -- Michael Wood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Monday, 2002-01-14 at 23:20:21 -0400, Peter Cordes wrote: On Mon, Jan 14, 2002 at 01:25:11PM -0500, Jeremy L. Gaddis wrote: I recompressed it as a real PNG, and attached it to this mail, for your viewing pleasure :) PNG gets 3.5 times better compression, probably because this image only uses 8 bits of colour, and the xwd was 24bit. I hadn't tried to view it when it first came around. As a graph, it is not very impressive. Hard to judge x and y for any point on the curve. This would probably be better done as a histogram. Someone else mentioned that this graph should go up on a website, but someone else shot them down. I think the suggestion was just for this image in particular, not that this should be done for every image-attachment on all lists. Anyway, I agree that it would be cool to have this graph and the data available on a web site. (With the data in a two-column ascii list, rather than a spreadsheet or something that needs to be downloaded and dealt with separately.) Of course, then we might need to make up excuses, or preferably find solutions, for the exceptionally long bugs. I still think a table and graph would be a god addition to the security FAQ, as an answer to the question How long does Debian take to fix known vulnerabilities. Tne table could go in the FAQ, and the graph could be linked. (Dunno how the FAQ gets set up, but I guess there will be an ASCII-only version.) I believe the most useful format would be linear for the number of bugs fixed, and log for the time. Like this Time (days) No of fixes 1 ? 2-3 ? 4-7 ? 8-15? 16-31 ? etc. I'd be *really* interested in seeing that kind of table for more OSes. Not only Linux distributions, but also Solaris, *BSD, and Windowses. My gut feeling is that Debian would shine in such a comparison. Initially, I came to Debian because I had the feeling that it was the Linux dustribution with the fastest reaction to the discovery of vulnerabilities. Judging from BUGTRAQ. Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm|
Re: Debian security being trashed in Linux Today comments
On Tue, 2002-01-15 at 09:44, Florian Weimer wrote: Adam Warner [EMAIL PROTECTED] writes: http://www.linuxtoday.com/news_story.php3?ltsn=2002-01-14-002-20-SC-DB Someone with better knowledge of all the facts might want to comment on the claim that Debian is always the last to fix security holes and the tag team follow up I've been fighting for months now to try to convince them to release an advisory or fix for ftpd... Of course, libc problems are a bit unfair for comparison. Red Hat runs the official CVS repository, and they probably knew about the problem by mid-November or something like that (the fix was committed on 2001-11-29, IIRC). I've just found that some anonymous poster promoted the Linux Today comments on Debian Planet: http://www.debianplanet.org//article.php?sid=568 At this rate Slashdot isn't far off ;-) Regards, Adam
Re: Debian security being trashed in Linux Today comments
On Mon, Jan 14, 2002 at 09:53:15AM -0500, Noah L. Meyerhans wrote: On Mon, Jan 14, 2002 at 01:37:50PM +, Simon Huggins wrote: So perhaps Debian security is only as good as the package maintainers? I'm sure most maintainers do care and do investigate bugs I probably just had a bad experience. That is the case in unstable and testing, but not stable. You seem to be implying I was talking about woody or sid yet the bug in the BTS says potato. That is why you're encouraged to run stable on any machine connected to the internet. In its case, there is a group within Debian who is responsible for providing security updates in a timely manner with or without assistance from the package maintainer. I should probably have emailed security-team instead of security when I found the bug. Ho hum. -- --( Lefinnois[away] huggie: dans ton troupeau de )-- Simon ( clef public c'est la quelle la bonne ? ) Nomis Htag.pl 0.0.19
Re: Debian security being trashed in Linux Today comments
On Tue, Jan 15, 2002 at 09:23:20AM +0100, Lupe Christoph wrote: On Monday, 2002-01-14 at 23:20:21 -0400, Peter Cordes wrote: On Mon, Jan 14, 2002 at 01:25:11PM -0500, Jeremy L. Gaddis wrote: I recompressed it as a real PNG, and attached it to this mail, for your viewing pleasure :) PNG gets 3.5 times better compression, probably because this image only uses 8 bits of colour, and the xwd was 24bit. I hadn't tried to view it when it first came around. As a graph, it is not very impressive. Hard to judge x and y for any point on the curve. This would probably be better done as a histogram. Well. Take in account it was done somewhat in a hurry... IIRC x = number of days taken to fix bug y = number of bugs fixed Someone else mentioned that this graph should go up on a website, but someone else shot them down. I think the suggestion was just for this image I did not shot him down just said I did not think it would be possible. Problem is, debiandoc-sgml has no support for inline images. I still think a table and graph would be a god addition to the security FAQ, as an answer to the question How long does Debian take to fix known vulnerabilities. Tne table could go in the FAQ, and the graph could be linked. (Dunno how the FAQ gets set up, but I guess there will be an ASCII-only version.) Already did it yesterday (except for th column with the data). See http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.3 Regards Javi
J.T. Sterlings Daily Special - January 15, 2002
Title: Welcome to J.T. Sterlings J.T. Sterlings Daily Specials - January 15, 2002Our Daily Specials change once every day at Midnight, Eastern Time. You are subscribed to J.T. Sterlings Daily Special mailings. Visit us at www.jtsterlings.com or click below to place your order. Item 21531 Rose bush with a butterfly that flutters by. Tune: "Rose Garden." 12" high. $21.95 Regular Price. Regular Price $21.95 Sale Price $16.02 Today's Special Price $14.42 You save 10% Click Here To Order! Item 21564 Delicate pink shell vase with flowers and parrot are the designs on this lacquered wood screen. 9 3/4" x 1" x 28" high. $29.95 Regular Price. Regular Price $29.95 Sale Price $21.86 Today's Special Price $19.67 You save 10% Click Here To Order! Item 21565 Lacquered wood screen with peach and blue birds with yellow and green shell leaves and flowers. 9 3/4" x 1" x 28" high. $29.95 Regular Price. Regular Price $29.95 Sale Price $21.86 Today's Special Price $19.67 You save 10% Click Here To Order! Item 21566 Blue, yellow and pink birds with pink and green leaves and flowers bedeck this lacquered wood screen. 9 3/4" x 1" x 28" high. $29.95 Regular Price. Regular Price $29.95 Sale Price $21.86 Today's Special Price $19.67 You save 10% Click Here To Order! You are receiving this special offer because you have provided permission to receive third party email communications regarding special online promotions or offers. Any third-party offers contained in this email are the sole responsibility of the offer originator. Copyright © 2001 J.T. Sterlings - 5700 Memorial Highway Suite 206, Tampa FL 33615. All Rights Reserved. J.T. Sterlings does not condone the use of unsolicited email (spam). If you do not wish to receive any further messages from J.T. Sterlings, please follow the instructions below to unsubscribe. --- You are currently subscribed to dailyspecial as: debian-security@lists.debian.org To unsubscribe send a blank email to: [EMAIL PROTECTED]
Re: Asking for documentation help (Re: IPSec questions...)
On Mon, Jan 14, 2002 at 07:52:59AM -0700, Stefan Srdic wrote: I don't have any pratical experience with FreeSWAN at all, however, I have statically compiled BIND 9 and placed it in a chroot jail on Debian. I wonder if it would hard to packge a chroot'ed setup of BIND9 once it completely configured? As already said, documentation is a *Very* important part of a distribution. IMHO the Securing Debian HOWTO (might change it to Manual sometime in the future) does tackle an important issue. I would be very grateful if you reviewed and improved the (incomplete) information I wrote regarding Bind security in Debian (IMHO it's better placed here than in a separate HOWTO). Please read: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind SGML sources are available through CVS (check http://www.debian.org/doc/ddp), patches for the CVS sources are prefered but I will also accept any other suggestions. Regards Javi
Re: default security
On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. Agreed. Feel free to point to better security measures in the Default installation and document them, once done it is a major point of pressure to change Debian policy. I know this would take some time to implement, but I think it would help the image of debian and linux over time. I'm often frustrated that the big distros (rh, mandrake) doesn't do more to harden their distros. For example the default install of ssh in RH still provides both ssh1 and ssh2 root login. Debian, unlike RedHat or Mandrake provides and gives support for Bastille Linux. Even if the default setup is quite good (security-wise) it can easily be made even better. I know this is a rant, but maybe it would be wise to think of a way to implement this. At least, put more deamons in chroot jails and get libsafe compiled into every package. Debian could provide, with only some effort from package maintainers versions of daemons chrooted to given environments. This however, might break Policy (IMHO). BTW, Bastille does have modules for chrooting services (it has one for Bind) that can be selected when hardening the system. You could also help having Bastille's module (for Bind) adapted to Debian (I have not had time to do so myself) Regards Javi
Re: Asking for documentation help (Re: IPSec questions...)
That would be great. I will accept patches anytime. Please don't forget about writting it! (I will keep this mail, just as a reminder :) Javi On Mon, Jan 14, 2002 at 10:46:48AM -0500, Noah L. Meyerhans wrote: I'd happily volunteer to write the whole chapter, but I don't forsee having enough free time for that until sometime in mid March. If anybody wants to work on it, though, let me know, and I'll lend a hand. --
Re: Debian security being trashed in Linux Today comments
On Wed, 2002-01-16 at 01:07, Javier Fernández-Sanguino Peña wrote: Already did it yesterday (except for th column with the data). See http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.3 Please consider removing any reference to the average amount of time in the FAQ: ...it took the Debian Security Team an average of 35 days to fix security-related vulnerabilites. An average based upon a very long tail is highly misleading. Please quote the median time to fix a vulnerability instead. This will will be less than or equal to 10 days given this statistic: over 50% of the vulnerabilities where fixed in a 10-days time Because of this research it looks like Debian's security information page will have to be changed: http://www.debian.org/security/ Debian takes security very seriously. Most security problems brought to our attention are corrected within 48 hours. That's just not an honest description of what's occurred. It appears from the research that most (i.e. 50%) of security problems are corrected within 10 days, not 48 hours. I still need to be able to download that spreadsheet. I have viewed the PNG picture. Regards, Adam
Re: default security
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) | Regarding limiting BIND's privileges you must be aware that if a | non-root user runs BIND, then BIND cannot detect new interfaces | automatically. For example, if you stick a PCMCIA card into your laptop. Like anyone would really want to run bind automatically on all transient interfaces... It's a *service*, to be run on *serv-ers*! If you want a named listening on such an interface, the due pain is deserved, IMHO. (I've been meaning to get that off my chest for a few months :8) The above URL links to a bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no\bug=50013, which seems to imply that chroot()ed behaviour will be expected ere long. Have I missed it, or shall I carry on hoping? :) [snip] ~Tim -- http://spodzone.org.uk/
Re: default security
also sprach Javier Fernández-Sanguino Peña [EMAIL PROTECTED] [2002.01.15.1316 +0100]: Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) well, first of all, this document refers to a bug, #50013 (to which this is CCd). in the bug, the argument comes up that opinions differ from running bind non-root. but a chroot jail is advised. i'd love to know just why you'd ever run bind as root, even in a jail. if i have root rights in a jail, i'll break out of the jail within minutes (e.g. [1]). second, why would you *need* bind running as root? and thirdly, please check the threads at [2] and [3] if you are interested in a discussion on bind9 and chroot. One thing that might be a good idea, would be a security review of the main debian packages. It's probably beeing done for some already, but I would guess a lot of debian packages could benefit from even stricter default setups. For example, maybe libsafe should be default inn all installs. Agreed. Feel free to point to better security measures in the Default installation and document them, once done it is a major point of pressure to change Debian policy. running non-root *and* chrooting. Debian could provide, with only some effort from package maintainers versions of daemons chrooted to given environments. This however, might break Policy (IMHO). how would it break policy? 1. http://www.bpfh.net/simes/computing/chroot-break.html 2. http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg01393.html 3. http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg01001.html -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] above all, we should not wish to divest our existence of its rich ambiguity. -- nietzsche pgpPhGfngiiHZ.pgp Description: PGP signature
Re: faster -- Re: Debian security being trashed in Linux Today comments
Previously Alvin Oga wrote: i did an dist-upgrade update upgrade today... and saw sudo get update before fixes to sudo was posted to bugtraq Actually it was posted to bugtraq about 15 minutes before but you only saw it later due to moderation :) Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: faster -- Re: Debian security being trashed in Linux Today comments
hi ya wichert true... i probably should have been clearer... that i'm on the way end of the bugtraq list... keep up the good work all ... have fun alvin http://www.Linux-Sec.net ... hardening howtos ... On Tue, 15 Jan 2002, Wichert Akkerman wrote: Previously Alvin Oga wrote: i did an dist-upgrade update upgrade today... and saw sudo get update before fixes to sudo was posted to bugtraq Actually it was posted to bugtraq about 15 minutes before but you only saw it later due to moderation :)
Re: default security
Hmm. Here's a suggestion. - This idea is based on the asumtion that espesially serversystems need good security. 1. Make a votingpage and anounce it on debian-users asking what are the main servers people are running on their debian systems. 2. Go through the 10 highest and make sure they follow secure practies like libsafe. 3. Support security in these servers also for testing and unstable. rant I think it would be worthwhile to rethink the philosophy of debian-stable. Instead of saying the next version of debian is stable when all it's packages are stable, how about defining a stable version of each package, and saying that stable is a dynamic target. In the age of highspeed conections, most most people could then install debian over the 'net instead of the install cd's. /rant I apoligize to all the people reading this list for filling it with rants. Will stop now. Tarjei
Re: Debian security being trashed in Linux Today comments
On Wed, Jan 16, 2002 at 01:42:50AM +1300, Adam Warner wrote: ...it took the Debian Security Team an average of 35 days to fix security-related vulnerabilites. An average based upon a very long tail is highly misleading. Please quote the median time to fix a vulnerability instead. It is not misleading in this case, the tail is the _most_ important part of the data. It doesn't matter if we patch every other hole in 10 minutes if we leave one open for months. Furthermore I think the mean is exactly the right measure of this: from the user point of view, the important figure is total exposure time, i.e. sum of time between vulnerability discovery and patch (for installed packages) for all vulns. For someone who installs every Debian package, this is equal to (# of vulnerabilities)x(mean time to patch). The former measures how well packages are audited in advance, the latter measures how quickly vulnerabilities are corrected. It's the right statistic. -- Colin Phipps PGP 0x689E463E http://www.netcraft.com/
Re: Debian security being trashed in Linux Today comments
Previously Colin Phipps wrote: It is not misleading in this case, the tail is the _most_ important part of the data. It doesn't matter if we patch every other hole in 10 minutes if we leave one open for months. Both are interesting though. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: default security
Tarjei [EMAIL PROTECTED] writes: Hmm. Here's a suggestion. - This idea is based on the asumtion that espesially serversystems need good security. *All* installed boxes need adequate securing. Linux worms would not propagate if it weren't for a critical mass of idiots running unpatched daemons packages; scanning by IP# is no respector of `this is a server' or `this is a workstation'; it just happens that servers *have* to be secure while workstations tend not to be. 1. Make a votingpage and anounce it on debian-users asking what are the main servers people are running on their debian systems. You'd want a control poll e.g. on slashdot or somewhere as well because the Internet as a whole will run different servers in different amounts - more web servers than DNS than email? Or similar numbers of each? 2. Go through the 10 highest and make sure they follow secure practies like libsafe. Personally I think a BIG disclaimer in the installer, `look, if you will run these things, on your head be it' for every daemon that gets installed would be in order. [snip] I apoligize to all the people reading this list for filling it with rants. Will stop now. ~Tim -- http://spodzone.org.uk/
Re: Debian security being trashed in Linux Today comments
Colin Phipps [EMAIL PROTECTED] writes: On Wed, Jan 16, 2002 at 01:42:50AM +1300, Adam Warner wrote: ...it took the Debian Security Team an average of 35 days to fix security-related vulnerabilites. An average based upon a very long tail is highly misleading. Please quote the median time to fix a vulnerability instead. It is not misleading in this case, the tail is the _most_ important part of the data. It doesn't matter if we patch every other hole in 10 minutes if we leave one open for months. Yes it does, if that remaining hole is merely a local non-root potential vulnerability with no known exploit that's a PITA to fix - you *must* weight the average accordingly. Much as I hate stats, I can see that what you want to measure is how much lethargy there is in Debian, which means excluding other influences, and instead of wondering about means modes and medians, you've got to weight the whole thing. Bah, complicated. ~Tim -- http://spodzone.org.uk/
[홍보] 네티즌이 만든 검색엔진 아이따따따입니다.
Title: 검색엔진 아이따따따
인터넷에는 많은 정보와 그 정보를 찾아주는 검색엔진이 있습니다.
하지만 검색엔진들이 너무나 많은 정보를 제공해 주는 결과 오히려 정보를 찾는데 많은 노력과 시간을
허비하는 결과를 초래하고 있습니다.
이제는 얻을 수 없는 많은 양의 검색결과보다는 신뢰성 있는 정보를 요구하는 시대가 되었습니다.
인터넷에 산재해 있는 사이트 중에는 우리가 꼭 필요한 정보들을 담고 있는 사이트가 많이 있는데,
이 사이트 들을 구분하면 포탈,보탈,허브 사이트라고 합니다.
아이따따따는 이런 사이트를 찾아주는 카테고리 및 키워드 검색엔진입니다.
각 카테고리 별로 신뢰성 있는 엄선된 사이트만 네티즌의 양심으로
등록관리하는 검색엔진이며
귀하께서도 카테고리 담당자가 되실 수 있습니다.
카테고리 담당이 되시면 ㈜아이엔웹의 주식 1주를 무상으로 드리며 pop3 e-mail 계정을 드립니다.
("예" [EMAIL PROTECTED]")
또한,그 카테고리를 관리할 수 있는 권한과 해당 카테고리에 담당자 아이디를 등록합니다.
(등록신청을 하신후 담당관리자로 login 하시면 카테고리를 직접 관리하실 수 있습니다.)
회원가입을 하시고 회원이 되시면 ㈜ 아이엔웹의 주식 1주를 무상으로 드립니다.
인터넷은 네티즌이 주인이고 아이따따따는 네티즌의 것이기 때문입니다!
http://iwww.net (아이따따따)로 방문해 주세요
아이따따따의 이념은 우리 네티즌이 갖고있는 유익한 정보를 서로 공유하고 새로운 네티즌문화를
창출하는것입니다. 귀하께서도 아이따따따의 한 가족이 되어주시길 부탁드립니다.
늘 건강하시고 행복하세요~~~감사합니다.
1일 평균 방문
774,500 hit(2002.01.13)
가입회원
156,550 (2002.01.13)
네티즌 담당 카테고리
785 개
직접 방문하셔서 평가해 주십시오! ==http://iwww.net
유익한 사이트라고 평가되시면
주위분들에게 알려주시길바랍니다. ( 아이따따따 = iwww )
귀하께 불편을 끼쳐 드렸다면 용서를 바랍니다.
귀하의 메일은 인터넷에서 웹서핑중 취득하였으며 귀하의 어떠한 정보도 갖고있지 않습니다.
다음부터는 인터넷,정보통신,바이러스백신 등 유익한 정보만을 보내드립니다.
아이따따따의 가족이 되시면 전체가족 메일을 통하여 유익한 정보를 받아보실 수 있습니다.
공지사항을 참고하시면 아이따따따 내부사정을 아실 수 있습니다.
바로가서 보기
네티즌의 고견을 수렴하는 공개게시판을 운영중입니다.
바로가서 보기
그래도 수신을 원치 않으실 경우 수신거부를 클릭하십시오!
수신거부
Detecting break-ins
Hi, Recently I've installed some IP logging deamons (snort, ippl along with logcheck) and I was amazed how many break-in attempts there are each day on my simple home box which isn't even adverised anywhere, as I only run a few services intended for friends and family (apache, wu-ftpd, exim). I can see a lot of IIS related attempts, which obviously do not work, as well as some refused anonymous FTP connection attempts. For these I don't worry to much as they have failed. (I hope. I'm no expert, though.) Then there are more exotic stuff. High port UDP attampts, connection to port 113 etc. Now the logs provided by the above packages often say something like 'connection attempt to ..' whichever port/service. The question is whether there is a way to know whether any of those attempts succeded. Or to put it more simply, how could one distinguish a failed attempt and a successful break-in? (I know this is probably a very complex topic, but I would greatly appreciate some advise!) Many thanks for your help in advance! best regards, Balazs
Re: Detecting break-ins
On Tue, Jan 15, 2002 at 09:04:07PM +0100, Balazs Javor wrote: Then there are more exotic stuff. High port UDP attampts, connection to port 113 etc. High port UDP stuff is often just traceroutes. 113 is normal, as many servers will attempt an auth lookup when you access them. Now the logs provided by the above packages often say something like 'connection attempt to ..' whichever port/service. The question is whether there is a way to know whether any of those attempts succeded. Or to put it more simply, how could one distinguish a failed attempt and a successful break-in? Well, the first thing to as is is there anything even listening on that port? You can feel pretty safe about (for example) connection attempts to your telnet daemon if you're not actually running a telling daemon to begin with. You should already have a pretty good idea about what services are listening on various ports on your machine. But just to be sure, try running 'netstat -ulp' and 'netstat -tlp' as root to show which PIDs are listening on which UDP and TCP ports, respectively. Turn off what you don't need by removing its entry from inetd.conf or by prevending init from starting it from /etc/rc?.d (I know this is probably a very complex topic, but I would greatly appreciate some advise!) Most of stuff that you see, really, is harmless. A lot of it, as I said above, isn't even necessarily a breakin attempt. Assuming you're up to date on the fixes from security.debian.org, you're safe from the worms and script kiddies, which are the only things stupid enough to do something that will show up in your logs. It's always good to set up a host based intrusion detection system like tripwire (preferably the version in sid, rather than the ancient slow version from potato). And look in to something like LIDS or something else that can verify the integrity of the in-memory kernel image. Kernel based rootkits are very hard to detect. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpXE8kw0X3A4.pgp Description: PGP signature
[Deb-SEC]oddball ssh remote passwd question
Hello all, This is far from as serious an issue as some of the items on the list right now, but I thought I'd see if anyone has some input. I'm running some synchronized machines, and I only want users to change passwords on the master. So, I thought of writing a script to replace password that just uses ssh to remotely call password on the master machine and let them change it there... Well, here's the rub. if you do: ssh [EMAIL PROTECTED] password ssh will have you authenticate to host, and then bring up the password change prompt (current) UNIX password: on the remote machine. BUT when you start typing, the characters show up on screen- not hashed or unprinted. What is it that is striping this functionality from passwd? Failing finding a way to get ssh to not express these characters, I could swear there is a simple way of turning off echoing input to the screen, but for the life of me I can't remember the command or variable in bash. Anyone feeling charitable and want to help out since my memory is failing? Thanks, David.
Re: [Deb-SEC]oddball ssh remote passwd question
Tim, Yep that does it :) Thanks mucho! I knew it was something VERY simple but my brain is just stir-fried today and I couldn't think of it. Thanks again. David. Tim Haynes wrote: David Ehle [EMAIL PROTECTED] writes: Hello all, if you do: ssh [EMAIL PROTECTED] password What is `password'? ssh will have you authenticate to host, and then bring up the password change prompt (current) UNIX password: on the remote machine. BUT when you start typing, the characters show up on screen- not hashed or unprinted. What is it that is striping this functionality from passwd? Failing finding a way to get ssh to not express these characters, I could swear there is a simple way of turning off echoing input to the screen, but for the life of me I can't remember the command or variable in bash. ssh(1): | -t Force pseudo-tty allocation. This can be used to execute arbi | trary screen-based programs on a remote machine, which can be | very useful, e.g., when implementing menu services. Multiple | -t options force tty allocation, even if ssh has no local tty. That any use? ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Detecting break-ins
hi balaz how much time and energy do you want to spend ??? - 1st passs.. - update your box regularly per debians security patches - read debians security howto http://www.debian.org/doc/manuals/securing-debian-howto - 2nd pass... - you;'re doing w/ snot/ippl/logcheck - logcheck already tells you whether it was successful attempts or not and how they tried it... - 3rd pass... - add host and network IDS ( tripwire, aide, etc... - if you wanna watch for network activity randomly... - run tcpdump, showtraf, trafshow, ncat, etc..etc.. - 4th pass... ( aka should be 1st pass ) - clean up permissions and remove unused services etc..etc.. ( things might break..but than yu know to fix it ) - lots of time can be spent here... - 5th pass... - if you find hackers in your box.. do you want to chase them down ??? - you need to have logs saves everywhere... - you have to be prepared to interact live with them - read your log files religiously...and understand what its says... - backup your system - make a cd image of your whole system if you're paranoid BEFORE you go online -- if a hacker gets in its too too late... -- i try to spend my time at the prevention end... not trying to detect them... but there is only so much to do before somebody else ( anotehr boss ) wants yo to do something else instead - if you only use tripwire ... it typicaly runs once a day a [cr/h]acker can do miracles to your machine until tripwire runs - i want to know that the [cr/h]acker got into my systems with a few seconds - and similarly... in a few seconds... i want a program to tell me what was changed ... - dont count on the eyes to tell you something is awry - than decide what to do with the box... watch them play with the box... or unplug it... and report it... http://www.Linux-Sec.net - see the IDS section... have fun alvin On Tue, 15 Jan 2002, Balazs Javor wrote: Hi, Recently I've installed some IP logging deamons (snort, ippl along with logcheck) and I was amazed how many break-in attempts there are each day on my simple home box which isn't even adverised anywhere, as I only run a few services intended for friends and family (apache, wu-ftpd, exim). I can see a lot of IIS related attempts, which obviously do not work, as well as some refused anonymous FTP connection attempts. For these I don't worry to much as they have failed. (I hope. I'm no expert, though.) Then there are more exotic stuff. High port UDP attampts, connection to port 113 etc. Now the logs provided by the above packages often say something like 'connection attempt to ..' whichever port/service. The question is whether there is a way to know whether any of those attempts succeded. Or to put it more simply, how could one distinguish a failed attempt and a successful break-in? (I know this is probably a very complex topic, but I would greatly appreciate some advise!) Many thanks for your help in advance! best regards, Balazs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
udp 32768
-BEGIN PGP SIGNED MESSAGE- When I do a 'netstat -l' I get (among a bunch of stuff that looks OK): mail:# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign AddressState udp0 0 *:32768 *:* What is this, and should I be worried? Jeff Teitel - -- Those who would give up essential liberty, to purchase a little temporary safety, deserve neither liberty nor safety. -Benjamin Franklin -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 Comment: See www.teitel.net for my Public Key iQEVAwUBPESxE0f9CJPZzjMvAQHPCwf8CIRI/pDNOZnVWoTwnIRs/owPWh3cO3ar pLgXM5qewDDzAvIXXazj2DGpt0p0j9K9QhpDERFWlrhATqpDE8zb526r/pdyIL60 YNeSDO00A9VOO/pvL5CcW+8T1av0MOSlUcwhHPR9uLPSGFg4kIbJ/Wb9r0Y6kgNc 9QiJirfPZ736Ia8/6Swn1/qmLR9rYvkSENrCZbBRHJC4kojXLiOegNoFy9VvhCQB OMYo5GYpVzxKROzBPA17rbJVZ80QMiI8QJH7Kngdg0/TuhuesuKkUyw+0JGIroUW e7eXpdTwpj8ooe6ZY84y40U8U2IyKVnx/SkICeiM+WtqONkNXkJ9RA== =ckem -END PGP SIGNATURE-
Re: udp 32768
Jeff Teitel [EMAIL PROTECTED] writes: When I do a 'netstat -l' I get (among a bunch of stuff that looks OK): mail:# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign AddressState udp0 0 *:32768 *:* What is this, and should I be worried? You tell us. netstat(8): | -p, --program | Show the PID and name of the program to which each socket | belongs. ~Tim -- http://spodzone.org.uk/
