Re: encrrypting messages to security team
On Sat, Jun 21, 2003 at 01:12:02AM -0700, Blars Blarson wrote: Shouldn't the security team have a gpg key available so confidential messages to [EMAIL PROTECTED] can be sent encrypted? That's probably why the Debian Security Team FAQ says: [from http://www.debian.org/security/faq] Q: How can I reach the security team? A: Security information can be sent to [EMAIL PROTECTED], which is supposed to be read by all Debian developers. If you have sensitive information please use [EMAIL PROTECTED] which only the members of the security team read. If desired email can be encrypted with the Debian Security Contact key (key ID 0x363CCD95). This FAQ was two links off of the www.debian.org home page. j -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgp0.pgp Description: PGP signature
Re: CAN-2003-0794: a local DoS
On Wed, Oct 22, 2003 at 05:36:42PM +0200, Sebastien Bacher wrote: Package: gdm Version: 2.4.1.6-2 Severity: important Tags: security A second security bug that need to be closed, fixed in gdm 2.4.4.4 upstream for about one week (and on others distribs too, is the GDM maintainer taking care of this package ?) : From the Security FAQ: Q: What is the policy for a fixed package to appear in security.debian.org? A: Security breakage in the stable distribution warrants a package on security.debian.org. Anything else does not Q: How is security handled for testing and unstable? A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those I know that my answer is not really a great 'practical' answer, it is, in fact, the best answer. For extra coverage, I'll cc: the package maintainer (according to packages.debian.org) for this package. HTH j -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Uhm, so, what happened...?
On Wed, Nov 26, 2003 at 04:46:32PM +0100, Kjetil Kjernsmo wrote: On Tuesday 25 November 2003 13:29, Alan James wrote: On Tue, 25 Nov 2003 12:09:11 +0100, Kjetil Kjernsmo [EMAIL PROTECTED] wrote: I bet there are a lot of users running around scared, not knowing what to do really... Any advices for us?? Keep your eye on http://www.wiggy.net/debian/status/ Expect more details to appear there in a day or two. Yeah, nice summary, but it really doesn't address the issue: am I vulnerable to the same attack as was used to break in? Even if the answer is we don't know, it would be nice to hear somebody say that, and then say something more elaborate of what the unknowns are. For those that are only reading this on the mailing list and haven't been following up to the link mentioned above, the important bit of when will we know that's noted in the wiggy.net link is as follows: We expect to need until Wednesday and ask for your patience until then. Afterwards when we have all the facts we will explain what exactly happened and how we hope to prevent this from happening again in the future. We've still got many hours of Wednesday left and if the people in charge of this are like many hackers I know, it'll be near the end of the day before anything would be posted. Please Kjetil, don't take my email as a RTFM type dismissive answer as I mean no disrespect at all to you, but wanted to inform others on the list that this update info is expected sometime today... j -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgp0.pgp Description: PGP signature
Re: Will 2.4.20 Source be patched for the latest kernel vulnerability?
On Mon, Dec 01, 2003 at 05:52:27PM -0800, peace bwitchu wrote: Will 2.4.20 Source be patched for the latest kernel local root vulnerability? From the announcement we see: This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and 2.6.0-test6 kernel tree. For Debian it has been fixed in version 2.4.18-12 of the kernel source packages, version 2.4.18-14 of the i386 kernel images and version 2.4.18-11 of the alpha kernel images. It's been my experience that aside from this, don't expect any further patches aside from continuing inclusion in subsequent kernels (2.4.24 and later). I could be wrong ;) j -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgp0.pgp Description: PGP signature
Re: Dsniff/mailsnarf
On Tue, Feb 24, 2004 at 06:11:20PM -0500, [EMAIL PROTECTED] wrote: I've been asked to place a sniffer on a network that handles HIPPA data, and watch for e-mail containing certain strings. I figured that mailsnarf would be the best way to do this. Aside from any of hte technical details of this, I'm kind of wondering how this fits into HIPPA and it's policies. I'd be sure that if I were you, I'd have written evidence of someone (a boss/supervisor/etc) ordering this kind of behaviour and also my objection to sniffing data that might be confidential under HIPPA. This just sounds wrong all around. I'd suggest significant amount of C.Y.A. activity on your part. Good luck. *shakes head* Sorry I can't be more helpful otherwise. -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgp0.pgp Description: PGP signature
Re: Dsniff/mailsnarf
On Tue, Feb 24, 2004 at 06:45:50PM -0500, [EMAIL PROTECTED] wrote: On Tue, Feb 24, 2004 at 06:19:48PM -0500, John Keimel wrote: On Tue, Feb 24, 2004 at 06:11:20PM -0500, [EMAIL PROTECTED] wrote: I've been asked to place a sniffer on a network that handles HIPPA data, and watch for e-mail containing certain strings. I figured that mailsnarf would be the best way to do this. Aside from any of hte technical details of this, I'm kind of wondering how this fits into HIPPA and it's policies. Certain info has to be protected. Like, all of it. I've dealt with HIPPA, so I know. My befuddlement was over the idea of sniffing for that info and the assumptions that one has to make in doing such a thing. skip down I'd be sure that if I were you, I'd have written evidence of someone (a boss/supervisor/etc) ordering this kind of behaviour and also my objection to sniffing data that might be confidential under HIPPA. I have a very nice contract, complete with a very detailed scope of work, which my lawyer has OKed. -snip- There's no CYA. I'm being asked to verify that there is no HIPPA information that is leaving the site, accidentally or otherwise. There is a nice defined set of keywords that would be used in any of the documentation (it's a testing Lab). If the capture file size *ever* goes above 0 bytes, they have a problem. That's all I'm involved with. I want *nothing* to do with the actual data. I'm just setting up a system that will notify certain people if there is a 'leak', and they can go in and figure out what happened. Well, you've already done your CYA [1] activities, so that's good. If your scope is well defined and you've a good contract, excellent. I hope you're charging more than enough for the priviledge of them having YOU sniff their traffic :) hehe. Good luck with it, hope it works out for all parties. j [1] someone defined HIPPA in the thread earlier, but didn't define cover your ass :) -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgp0.pgp Description: PGP signature
Re: grsec patch over debian 2.4.20 kernel
On Tue, Apr 22, 2003 at 03:17:56PM +0300, Ted Bukov wrote: Hi folks, I got the last 2.4.20 kernel with apt-get install. I want to patch it with grsec, but I met many times the follow message: Reversed (or previously applied) patch detected! Assume -R? [n] When I answered yes to all questions, the kernel compilation had failed. I think grsec patch have conficts with already patched debian kernel source, so is there any debian kernel sources with grsec applied? I don't want to use plain (vanilla) kernel, because of its ptrace vulnerability. Thanks in advance. I know that I had some issues when I put together my kernel, but I got them resolved. Turned out that my kernel, at the time, wasn't proved to be supported by grsec, yet. Looking at the downloads section of grsecurity's website, www.grsecurity.net and notice their latest version was published only two days ago, grsecurity-1.9.9g-2.4.20.patch . I'd suggest that you might consider checking on the mailing list over there, as I'm sure that any quirks of the patch would be well known there. Their mailing list info is at http://www.grsecurity.net/mailinglist.php and the archives of the list are at http://wws.grsecurity.net/wws/arc/grsecurity . Personally, I'm happy with my current kernel and it's current patch and having recently experienced a spate of downtime due to a SCSI drive (I tried EVERYTHING before I finally replaced the drive - to my detriment) I'm not looking to make a reboot until I absolutely have to. So I've not touched the kernel lately. However, looking at some of the new admin features of grsecurity, I think I'll add it to my so-called development box. HTH j -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgp5EGzqmIPuC.pgp Description: PGP signature
Re: kernel+grsecurity
On Mon, May 19, 2003 at 08:38:56AM +, Andr?s Rold?n wrote: Hi list. I am the CSO of a company and I am going to install several Debian woody machines with a kernel patched with grsecurity. Theses servers will be critical production-ready machines. The question is, what should I have to be aware of by compiling this kernel and what should I do to ensure a stability in those servers? I believe there was a recent thread on grsecurity, although it may have been over on Debian-isp instead. Anywho... Your asking the question of 'what should I have to be aware of by compiling this kernel and' leads me to ask 'Well, what exactly are you doing with the servers and what do you need protection from?' Some of the major questions that spring to my mind are: - Will there be other 'users' on the systems? Or are they just servers to be used by 'trusted' employees? - If $USERS=1, then what are the users allowed to do? Why are they on the system in the first place? Just to update web files? Compile programs? - IF $USERS=0, then you have less to worry about, unless you're planning to run your daemons as restricted users. And if you will do that, you need to be aware that some of those daemon/users will not have access to some of the things they might WANT or NEED in order to run as they normally do. You may have to recompile those daemons from source in order to make them behave properly in this new environment. - Will the server be on the Internet? Behind a firewall? With ipchains? You can go from the simple only run what services/daemons are necessary and keep up on security patches all the way up to EVERYONE IS OUT TO GET ME AND HACK ME! AND THE PEOPLE ON THE MAILING LIST ARE DOING IT NOW! level of paranoia (sorry for the yelling, but it's needed for the effect of insane raving). You really need to define your goals of what the servers will be used for and who will be using the servers in order to decide how to best use grsecurity. Just looking at the number of lines in my kernel config that have GRK in them indicates that there's 47 options available for grsecurity. Each one of those options needs to be examined and you'd need to know what it does and decide whether you really need it, whether you simply want it and mostly (on multiuser server) whether those adjustments would be received by your user base as acceptable to how they do things. I hope that I've given some direction as to the questions I'd be asking myself under similar circumstances and that my reply doesn't sound simply as though it's a 'non-answer linux support answer' which we all sometimes receive or send. I've been running grsecurity for a while now, previously having used it when it was simply 'openwall' - or was it 'smoothwall' , I get em confused. I think openwall. Without taunting the server pixies, I've had good luck with it and haven't had an outage due to kernel issues at all. A wayward SCSI drive cause my last troubles and have resulted in the number 140 as indicated below instead of something like 440. $ uptime 17:33:17 up 140 days, 18:32, 4 users, load average: 0.87, 0.88, 0.96 Some other servers running similar bits of patched kernels for security, mostly from multiuser systems that might have prying eyes: 1:33pm up 199 days, 18:19, 1 user, load average: 0.28, 0.22, 0.18 13:35:15 up 171 days, 4:19, 1 user, load average: 0.01, 0.00, 0.00 1:35pm up 171 days, 4:22, 1 user, load average: 0.08, 0.02, 0.01 13:35:52 up 171 days, 4:25, 4 users, load average: 0.08, 0.05, 0.01 Hope this helps... -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + ==
Re: encrrypting messages to security team
On Sat, Jun 21, 2003 at 01:12:02AM -0700, Blars Blarson wrote: Shouldn't the security team have a gpg key available so confidential messages to [EMAIL PROTECTED] can be sent encrypted? That's probably why the Debian Security Team FAQ says: [from http://www.debian.org/security/faq] Q: How can I reach the security team? A: Security information can be sent to [EMAIL PROTECTED], which is supposed to be read by all Debian developers. If you have sensitive information please use [EMAIL PROTECTED] which only the members of the security team read. If desired email can be encrypted with the Debian Security Contact key (key ID 0x363CCD95). This FAQ was two links off of the www.debian.org home page. j -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgpCP7fw3QcdK.pgp Description: PGP signature
Re: CAN-2003-0794: a local DoS
On Wed, Oct 22, 2003 at 05:36:42PM +0200, Sebastien Bacher wrote: Package: gdm Version: 2.4.1.6-2 Severity: important Tags: security A second security bug that need to be closed, fixed in gdm 2.4.4.4 upstream for about one week (and on others distribs too, is the GDM maintainer taking care of this package ?) : From the Security FAQ: Q: What is the policy for a fixed package to appear in security.debian.org? A: Security breakage in the stable distribution warrants a package on security.debian.org. Anything else does not Q: How is security handled for testing and unstable? A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those I know that my answer is not really a great 'practical' answer, it is, in fact, the best answer. For extra coverage, I'll cc: the package maintainer (according to packages.debian.org) for this package. HTH j -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + ==
Re: Uhm, so, what happened...?
On Wed, Nov 26, 2003 at 04:46:32PM +0100, Kjetil Kjernsmo wrote: On Tuesday 25 November 2003 13:29, Alan James wrote: On Tue, 25 Nov 2003 12:09:11 +0100, Kjetil Kjernsmo [EMAIL PROTECTED] wrote: I bet there are a lot of users running around scared, not knowing what to do really... Any advices for us?? Keep your eye on http://www.wiggy.net/debian/status/ Expect more details to appear there in a day or two. Yeah, nice summary, but it really doesn't address the issue: am I vulnerable to the same attack as was used to break in? Even if the answer is we don't know, it would be nice to hear somebody say that, and then say something more elaborate of what the unknowns are. For those that are only reading this on the mailing list and haven't been following up to the link mentioned above, the important bit of when will we know that's noted in the wiggy.net link is as follows: We expect to need until Wednesday and ask for your patience until then. Afterwards when we have all the facts we will explain what exactly happened and how we hope to prevent this from happening again in the future. We've still got many hours of Wednesday left and if the people in charge of this are like many hackers I know, it'll be near the end of the day before anything would be posted. Please Kjetil, don't take my email as a RTFM type dismissive answer as I mean no disrespect at all to you, but wanted to inform others on the list that this update info is expected sometime today... j -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgpU0yajGEFVx.pgp Description: PGP signature
Re: Will 2.4.20 Source be patched for the latest kernel vulnerability?
On Mon, Dec 01, 2003 at 05:52:27PM -0800, peace bwitchu wrote: Will 2.4.20 Source be patched for the latest kernel local root vulnerability? From the announcement we see: This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and 2.6.0-test6 kernel tree. For Debian it has been fixed in version 2.4.18-12 of the kernel source packages, version 2.4.18-14 of the i386 kernel images and version 2.4.18-11 of the alpha kernel images. It's been my experience that aside from this, don't expect any further patches aside from continuing inclusion in subsequent kernels (2.4.24 and later). I could be wrong ;) j -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgphhZRc6ByqF.pgp Description: PGP signature
Re: Dsniff/mailsnarf
On Tue, Feb 24, 2004 at 06:11:20PM -0500, [EMAIL PROTECTED] wrote: I've been asked to place a sniffer on a network that handles HIPPA data, and watch for e-mail containing certain strings. I figured that mailsnarf would be the best way to do this. Aside from any of hte technical details of this, I'm kind of wondering how this fits into HIPPA and it's policies. I'd be sure that if I were you, I'd have written evidence of someone (a boss/supervisor/etc) ordering this kind of behaviour and also my objection to sniffing data that might be confidential under HIPPA. This just sounds wrong all around. I'd suggest significant amount of C.Y.A. activity on your part. Good luck. *shakes head* Sorry I can't be more helpful otherwise. -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgprNQ3CFiE0q.pgp Description: PGP signature
Re: Dsniff/mailsnarf
On Tue, Feb 24, 2004 at 06:45:50PM -0500, [EMAIL PROTECTED] wrote: On Tue, Feb 24, 2004 at 06:19:48PM -0500, John Keimel wrote: On Tue, Feb 24, 2004 at 06:11:20PM -0500, [EMAIL PROTECTED] wrote: I've been asked to place a sniffer on a network that handles HIPPA data, and watch for e-mail containing certain strings. I figured that mailsnarf would be the best way to do this. Aside from any of hte technical details of this, I'm kind of wondering how this fits into HIPPA and it's policies. Certain info has to be protected. Like, all of it. I've dealt with HIPPA, so I know. My befuddlement was over the idea of sniffing for that info and the assumptions that one has to make in doing such a thing. skip down I'd be sure that if I were you, I'd have written evidence of someone (a boss/supervisor/etc) ordering this kind of behaviour and also my objection to sniffing data that might be confidential under HIPPA. I have a very nice contract, complete with a very detailed scope of work, which my lawyer has OKed. -snip- There's no CYA. I'm being asked to verify that there is no HIPPA information that is leaving the site, accidentally or otherwise. There is a nice defined set of keywords that would be used in any of the documentation (it's a testing Lab). If the capture file size *ever* goes above 0 bytes, they have a problem. That's all I'm involved with. I want *nothing* to do with the actual data. I'm just setting up a system that will notify certain people if there is a 'leak', and they can go in and figure out what happened. Well, you've already done your CYA [1] activities, so that's good. If your scope is well defined and you've a good contract, excellent. I hope you're charging more than enough for the priviledge of them having YOU sniff their traffic :) hehe. Good luck with it, hope it works out for all parties. j [1] someone defined HIPPA in the thread earlier, but didn't define cover your ass :) -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgpWZOcC6bqmn.pgp Description: PGP signature
Re: named: 'error sending response: unexpected error'
On Wed, Jul 13, 2005 at 08:25:37AM +0200, Adrian von Bidder wrote: | Jul 12 18:41:07 zbasel named[5317]: client 24.93.40.63#38829: error sending response: unexpected error I've never received any complaints about DNS problems nor did I see any stability problems. IP addresses seem completely random. The DNS records served are round robin DNS RR with no more then 15 entries - so perhaps the problem only occurs when the packet size approaches the maximum for UDP DNS packets? (OTOH, it's not even clear that it's an UDP request from the log...) Anybody seen this can confirm it's harmless / a known issue? I see this error when a particular server of mine cannot confirm that it sent an answer to a query, most often due to a network problem. See, my server occasionally loses its network, so while BIND is still trying to send replies, no network is available. It prints the error just like you're seeing in the logs. I'd imagine that a misconfigured firewall (allow DNS queries, but not answers) might also show the same error. So, I've seen it and under my circumstances, I consider it harmless. j pgpahzgiiqZMU.pgp Description: PGP signature
Re: secure installation
On 8/15/07, Pat [EMAIL PROTECTED] wrote: 1) What if someone (and I am sure it happens more often than you may realize) who is clueless about computers decides to download Debian, installs it, get hacked, trojaned horsed, their credit cards numbers stolen, etc. It is called responsibility, and we cannot blame it on them for knowing nothing, we can't all be computer security experts. In addition you have the option within lokkit to select no firewall if that is what you really want, so it seem to leave freedon of choice as to how to use your computer enabled, along with the option to uninstall it completely. But who is the ultimate responsible party? The clueless computer user that tries to use some 'new fancy operating system' or the volunteer developer of that system? Put your own political opinion onto that question - rhetorically. No, if someone WANTS to use lokkit, then they certainly can, yes? Am I assuming enough that they can 'apt-get install lokkit' and then configure it? Make up a web page on how _you_ think you should harden a Debian install with Lokkit as the cornerstone of your how-to and post it. As several others have pointed out, and as we have seen in the world of more popular operating systems from Redmond, installing a Firewall that defaults 'on' provides you no real extra protection if you don't know what in the hell you're doing with it. (You are coming to a sad realization, cancel or allow?). AFAIAC, if some clueless person installs an operating system they don't know and get themselves into some trouble, it's THEIR fault. It's not Debian's fault, it's not Linus' fault, it's not Deb or Ian's fault. It's not the kernel developer, it's not the CD distributor, it's not the mirror host. You're responsible for your own stupidity when it comes to linux, I think that's a well established aspect of the community already; for good or ill. Very few Linux experts suffer fools elegantly. If someone is looking for a more stupid proof distro, perhaps Ubuntu or SUSE would serve them better. Let's not dumb down Debian for the rest of the world because a clueless user _might_ compromise their own credit card numbers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CISP Compliance
On 8/20/07, Jonathan Wilson [EMAIL PROTECTED] wrote: Sorry if this is the wrong place for this, but: Does anyone know of a place I can get information on setting up CISP (VISA credit card) compliant Debian systems - or Linux in general, if there's no Debian-specific info. I've been searching the web for a couple hours and I don't know if I'm searching for the wrong phrases or what, but I'm not finding anything at all. What I'm looking for is, essentially, what software needs to be installed to make a system storing and processing CC info CISP compliant, and what settings need to be configured to match. I'm just sure there's folks out there who's secured Debian systems and installed configured the necessary software for logging, auditing, monitoring, etc. I just can't find anything about it - maybe I'm blind today. CISP, or PCI, as I hear it referred to more often (as PCI covers more than just Visa), is pretty expensive and tough. There are some products out there that are built on linux that are portions of the PCI compliance checklists, but there isn't, AFAIK in recent research, a one stop shop for PCI compliant servers. As a matter of fact, for PCI level 1 compliance, you're looking at the preference of PCI to have many common services (DHCP, DNS, etc) on separate servers. The real pain in the ass with PCI and linux is the logging and accountability of access to those logs. Making your shopping cart PCI compliant is pretty easy, there are plenty of things that do THAT part, but for a whole system, rather network, of servers to be PCI compliant is rough. I know of a consultant that has some spare cycles to help someone gain compliance if you're interested. He just went through a lot of research, learning, investigation and meetings with some PCI level 1 compliance stuff, so he's got it all on the top of his brain. If you're interested, email me off list. And really, it's not me, it is a friend and colleague. I'm not pushing the consultant cart around the village right now. If you're not at level one, few are, you can likely do a bunch of stuff without TOO much effort and expense, but it will mean a lot of work and thought on security. And it's a lot of pedantic stuff. Heck, even some of the stuff I see in actual banks is scary compared to what I've seen the Level 1 PCI people wanting. But that's another rant, eh? Good luck. j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator
On Tue, May 13, 2008 at 3:52 PM, Jan Luehr [EMAIL PROTECTED] wrote: For the last question, I see several solutions: - the user has to read the DSA and handle it himself Since some keys are generated automatically, (e.g. ssh host keys) users will have to regenerate keys,they haven't generated in the first place and might not be aware of their existens. That's bad. The only instructions I've seen for regenerating host keys include shutting down the sshd server. This is impossible in some servers I have, so is there another way? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator
On Tue, May 13, 2008 at 4:31 PM, Vincent Bernat [EMAIL PROTECTED] wrote: OoO En cette soirée bien amorcée du mardi 13 mai 2008, vers 22:21, John Keimel [EMAIL PROTECTED] disait: Since some keys are generated automatically, (e.g. ssh host keys) users will have to regenerate keys,they haven't generated in the first place and might not be aware of their existens. That's bad. The only instructions I've seen for regenerating host keys include shutting down the sshd server. This is impossible in some servers I have, so is there another way? Restarting OpenSSH do not close existing connections. Yes, that's correct. I agree. But the instructions I saw were for 'shutting down the SSHD server' - not just 'restarting it'. That's why I asked. I think Ian's suggestion will work just fine for me though, so I'll give that a go. Thanks folks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What to do about SSH brute force attempts?
On Thu, Aug 21, 2008 at 10:33 AM, Michael Tautschnig [EMAIL PROTECTED] wrote: Hi all, since two days (approx.) I'm seeing an extremely high number of apparently coordinated (well, at least they are trying the same list of usernames) brute force attempts from IP addresses spread all over the world. I've got denyhosts and an additional iptables based firewall solution in place to mitigate these since quite some time already and this seems to do the trick in terms of blocking them fairly quickly. Personally, I am letting Denyhosts do my legwork and checking the reports to look for patterns. I gave up on emailing people reports. A large portion of the emails are bounced with 'make sure you email this information to us... don't reply to this... ' and another bunch simply bounce. I have no faith in any asian IP admin receiving and properly reacting to an email. If I see a domestic (US) host that looks like a human might answer, I'll try and send a report, but I do nothing automated. I realize that I might be a better citizen to respond to all of them and report bad hosts, but since I've been using denyhosts, I've never received any positive response about a host being shut down. I think the vast majority of admins simply don't care or don't even see my email reports. Other than that, I have only tightened up my 'number of failed logins' in denyhosts in response to the recent spate of attacks. I've also double checked all my role accounts to make sure they're needed and/or secured. j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Securing my PC at a Wireless Hotspot?
On Sun, Feb 8, 2009 at 3:56 AM, Chip Panarchy forumanar...@gmail.com wrote: So, how do I secure my PC at a Wireless Hotspot? This is on the borderline of debian-user and debian-security. People will argue both ways on that. Use a VPN or an SSH tunnel to a trusted source. I use one of my servers, either a VPS I rent for about $10/mo or a server I own and maintain that's on the Internet in a data center. My trust level of those servers is much higher than any other method. I know that my traffic is secure from my point to my server, then off the to the internet. As far as securing my own laptop while on the hotspot, I will make sure I do not have unnecessary ports open. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lenny version info
On Wed, Dec 15, 2010 at 6:49 AM, Ashley Taylor ash...@getdarker.com wrote: Hi, Does anyone have any decent filter rules for Gmail so I can stop receiving this nonsense without unsubscribing? Thanks. http://tinyurl.com/2b3g2l4 Also, since you need it: http://tinyurl.com/ybpctcz Please particularly note items on jeopardy reply or Top posting and trimming. j -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim+h69ffj8dmzziur9mrvcj_kqv9ait3qwce...@mail.gmail.com
Re: Lenny version info
On Wed, Dec 15, 2010 at 7:10 AM, Ashley Taylor ash...@getdarker.com wrote: Sorry, this is the way Gmail handles replies. No, it's the way YOU handle replies. Gmail happens to place the cursor at the top of the email, setting you up for a jeopardy reply. It's trivial to scroll down a little and type within the message in the proper location and avoid top-posting. I know this is the case because I'm doing it right now. And I even managed to delete the extraneous text that doesn't pertain to the conversation. Don't blame gmail for your laziness. I hope it's annoying for you like these pointless e-peen stroking bitch replies are agitating me (and yes, this is one of those replies). I don't do it because it's annoying to you, that's just an added bonus. Since the thread has already devolved and because anyone with a decent email client who doesn't want to see the thread continue has marked it dead, I thought that it wouldn't matter too much to reply and add to it. Match on a bonfire, as it were. I'd much rather see security discussions on this list, rather than having to educate people in the ways of how the intarwebs works, how to google and how to write a proper reply on a technical mailing list. Cheers! j -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=2fumv6b4lykdz5-zn8yt=-wbt7x=uiwry7...@mail.gmail.com
Re: Lenny version info
On Wed, Dec 15, 2010 at 11:17 AM, Ashley Taylor ash...@getdarker.com wrote: stfu and stop replying to this chain. This is debian-security, not debian-childish-trolling. It's called a thread not a chain. Chain e-mails are also frowned upon. Thanks. j -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=efowwkqn85degpjk-mw+cnk+uwehlahrpj...@mail.gmail.com
