Mailbox for Sysadmin
Good day Administrator, Please forgive me that small advertisement but this place is probably one of just few where I can find you. Here is what I want to show you: Every self-respecting Admin should have a mailbox in worthy domain. Do you have it already? If no - go to https://nox11.com choose one and start new life ;) If you aren't interested accept apology for spam. --- Cheers ad...@nox11.com
Re: Exploit in Upgrade Chain?
600 on /etc is technically more secure than the default 755 with normal POSIX systems, not less. If this is an exploit, it's one that locks things down tighter than they should normally be. :) Giacomo is correct that these incorrect perms can cause other issues, though not security related ones that I can think of. Are there a different set of perms you had set on /etc manually? Any other indication that you've been exploited, or just a hunch based on circumstantial weirdness based on unexpected /etc privs and bastille? Best regards, -Chris Boyd Stephen Smith Jr. wrote: On Wednesday 11 February 2009 23:26:45 Stan Katz wrote: I updated/upgraded both my AMD64 and AMD k6 Etch machines between Feb 10-11, 2009 using Lenny test. Both picked up a symptom I haven't seen since the lpd exploit of the 1990's. This symptom manifests itself as either a random escalation of the etc directory mode up to 600, or a consistent escalation to mode 600 upon reboot. My /etc is mode 755. Why would that be a problem? Some user/programs may need to read data out of the directory and root (the owner of my /etc) certainly needs write permissions. I don't remember why the lpd exploit did this. If this is an exploit, it shakes my confidence in debian online updating. I don't see how a 600 /etc can be exploited. Do you have any other records that would indicate you are exploited, or is this just fear-mongering? Also, the Bastille firewall on the AMD64 began locking down port 80 after about 10min of operation. Adding 80 to all interfaces didn't help. Only shutting down Bastille cleared the block. Sounds like a bug in Bastille. Can you reproduce reliably? Have you checked your configuration? If both, has you filed a bug yet? I fear this is another indication of the exploit. How/Why would these be related? Has anyone else experienced this misbehavior after an upgrade? Not here. I've been running Lenny for a number of months. Any suggestions, other than a complete disk wipe on both machines? In any case, where would I go for a trusted rebuild, if there truly is a sabateur in the ranks of the Debian maintainers? I'm forwarding to debian-security; perhaps they will have suggestions. This topic is more appropriate for that list than debian-user anyway. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: antivirus for webserver
Laura Arjona Reina wrote: My question is if it is needed to install an antivirus for keeping the webserver safe. And if it is needed, which antivirus could I use? I thought about clamav but I read about problems keeping up-to-date the software shipped with etch-stable. I wouldn't think so. Generally, anti-virus software on Linux and other Unix-like systems is to protect Windows clients from spreading viruses amongst themselves, not protecting a Linux server itself. If you're not doing mail or Samba on that box, don't really think it'd be very useful. On the other hand, you might look into more applicable things to Linux security like rkhunter and fail2ban, mod_security, etc. A quick audit with nikto and/or nessus wouldn't hurt. And also, keep things as up to date as possible. Best of luck! :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[MailServer Notification]Attachment Blocking Notification
Warning to Recipient: Action taken by attachment blocking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Secure 2.4.x kernel
Well hello list, it could be, that i'm overstepping my knowledge (and my english). If i have well understood, one of the problems of bufferoverruns is the follwing: The assembly statement jsr (jump to subroutine) puts the return address on the same stack, where space for local variables is reserved. So one solution is to seperate these stacks. So it's more a problem of the C-Compiler (and the number of Address-Register of the CPU and memory). So my questions are : 1) Is my problem description right ? 2) On other plattforms (for example on the newer plattforms like ia64) are there seperate stacks ? 3) Why is this not done on the 0x86-Plattform ? (Historical Reasons ? No chance of a step by step migration because of the interplay between programms and libarys ?) On Fri, 21 Dec 2001, Kelly Martin wrote: Hmmm I don't buy that this *couldn't* be done on the Intel. I might be overstepping my knowledge, but I'm sure there *must* be a way. Going back to my 68k days, it would have been fairly easy to write this. Hey, I'm not an Intel assembly/opcode expert, but it seems to me, I think that you could sit something right in on an interrupt that would alert when a fork/exec call was being made -- it wouldn't take a rocket scientist to figure out that if you could take an interrupt/event on this type of sig, you could certainly redirect the behavior or outcome. You've misunderstood. I was stating that it would be hard to _protect the stack against overruns_ on the Intel platform. What you're talking about has nothing to do stack protection. Fork and exec (being syscalls) are already handled as software interrupts, so what you're talking about doing is what the kernel already does. The examples pointed out (electric fence, st. james etc.) are fine workarounds, but they all look a little too patch-like for it to be something that is industrial strength. I just think that intercepting the syscalls like fork and exec at the kernel level for anything that is not privy should be a feature of the kernel. Statements like this lead me to question whether you really know what you're talking about. Electric Fence is a tool for debugging heap overruns and has nothing to do with access control in the kernel. St. Jude is _exactly_ what you're claiming is necessary: it's a tool for intercepting syscalls at the kernel level. And, to be honest, where the hell else would you intercept a syscall? Kelly -- 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: Secure 2.4.x kernel
Well hello list, it could be, that i'm overstepping my knowledge (and my english). If i have well understood, one of the problems of bufferoverruns is the follwing: The assembly statement jsr (jump to subroutine) puts the return address on the same stack, where space for local variables is reserved. So one solution is to seperate these stacks. So it's more a problem of the C-Compiler (and the number of Address-Register of the CPU and memory). So my questions are : 1) Is my problem description right ? 2) On other plattforms (for example on the newer plattforms like ia64) are there seperate stacks ? 3) Why is this not done on the 0x86-Plattform ? (Historical Reasons ? No chance of a step by step migration because of the interplay between programms and libarys ?) On Fri, 21 Dec 2001, Kelly Martin wrote: Hmmm I don't buy that this *couldn't* be done on the Intel. I might be overstepping my knowledge, but I'm sure there *must* be a way. Going back to my 68k days, it would have been fairly easy to write this. Hey, I'm not an Intel assembly/opcode expert, but it seems to me, I think that you could sit something right in on an interrupt that would alert when a fork/exec call was being made -- it wouldn't take a rocket scientist to figure out that if you could take an interrupt/event on this type of sig, you could certainly redirect the behavior or outcome. You've misunderstood. I was stating that it would be hard to _protect the stack against overruns_ on the Intel platform. What you're talking about has nothing to do stack protection. Fork and exec (being syscalls) are already handled as software interrupts, so what you're talking about doing is what the kernel already does. The examples pointed out (electric fence, st. james etc.) are fine workarounds, but they all look a little too patch-like for it to be something that is industrial strength. I just think that intercepting the syscalls like fork and exec at the kernel level for anything that is not privy should be a feature of the kernel. Statements like this lead me to question whether you really know what you're talking about. Electric Fence is a tool for debugging heap overruns and has nothing to do with access control in the kernel. St. Jude is _exactly_ what you're claiming is necessary: it's a tool for intercepting syscalls at the kernel level. And, to be honest, where the hell else would you intercept a syscall? Kelly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IDS
Hi, Try this: http://www.lids.org/ - Original Message - From: Osvaldo Mundim Junior [EMAIL PROTECTED] To: debian-security@lists.debian.org Sent: Monday, November 05, 2001 6:45 PM Subject: IDS Hi, does anybody can tell me where can I get a Instrusion Detection System's base? I need the signatures of attack... tks a lot... -- ___ Osvaldo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IDS
Hi, Try this: http://www.lids.org/ - Original Message - From: Osvaldo Mundim Junior [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 05, 2001 6:45 PM Subject: IDS Hi, does anybody can tell me where can I get a Instrusion Detection System's base? I need the signatures of attack... tks a lot... -- ___ Osvaldo -- 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]
