Re: [Fwd: security]
Luis M wrote: (snip) 6. use the AllowUsers option in sshd_config and put a comma separated list of users that are allowed to login remotely. All other users will simply be denied access. 7. Use tcp_wrappers to allow only a handful of IPs to login remotely to your box. If you don't have a static IP that you use yourself to login to your computer remotely, you might want to allow IPs coming from ISPs in your own country/region. That way you limit attacks to a very limitted subset of IPs that can be tracked (and possibly sued) :-) Use whois to determine the IP blocks for major ISPs. I have one final twist on the concept, pertaining to #7. I was going to completely lock down a network I administer (no root SSH, only DSA key based SSH2, etc...) but can't quite make that leap, due to the remote possibility of needing to ssh in as root from somewhere, possibly when I don't have a DSA key handy. My solution was to default deny SSH access to the network, selectively enabling friendly IP ranges (exactly the concept Luis had, based on the idea that I'll be able to find a real person to contact). The key addition I have is I also allow SSH access from any IP address to one specific box that's hardened more than normal, and watched more closely than the others. That way, in an emergency, I'd be able to ssh in there, and bounce to another box (or update my access list on the router). A more advanced concept would automatically close that hole to anyone trying to hit port 22 on one of the protected servers, but that's overkill for my needs. Also, in my case, I'm dropping the packets right at the edge router. That's easier for me to maintain, especially since I had a set of rules for blocking various bad things already. Another good idea would be to supplement my router-based solution with iptables on every box, but I figure I'll start with the low hanging fruit. --Rich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Update of security-critical outdated packages
Kjetil Kjernsmo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, It is an issue that's been bugging me for some time, and while I have tried to find good reasons, I have not, so I might as well write them down. I have a lot of respect for the security team, and I don't think I have anything to contribute other than my thoughts, but I'll try to share them. Many packages in stable are really outdated. After first installing Woody, I first thought that looking at the prospect of waiting one-and-a-half year for the next release would scare me away from Debian. Now that I've grown up a bit more, it doesn't. I'm perfectly fine with using backports for things like KDE. Also, if I was a sysadmin for a lot of boxes, supporting many not-too-savvy users, the release cycle is perfectly reasonable. For a stable system, pinning is not option, because you'll quite soon have to update things like libc6 if you do. It's not about that. Backports are fine for most purposes, and I'm fine with the release cycle. Depending on what you're doing, pinning actually can work quite well. But you're correct in that upgrading too many pakages quickly leads to an explosion of dependancies. It's about a small handful of security-critical packages, like for example Snort. In the case of Snort, the security team has explicitly discouraged people from using the packages available in Woody, see DSA-297. I find it very hard to understand that in the cases where the security team strongly advises an upgrade, that the backported packages are not included in e.g. a point release. This has nothing to do with the security team and security issues as far as software vulnerabilities. If there's a security issue with a package, the security team will fix the problem in the stable release. Problem solved (as in DSA-297). Snort is related to you overall system security, yes, but new releases of Snort have to do with your desire to run the latest and greatest releast of a package, not with security issues. So, this is just about the very few packages the security team feels are so outdated, one advice people not to use them. For those packages, the question is: What is the advantage of keeping so outdated packages in the archive? If the package is outdated, you have other options, including apt-get source and other options mentioned in your email. It just doesn't have to do with the security team. In the case of snort, an old version could still be useful in the archive. Picture a machine that must run stable (for various reasons), sitting behind a decent firewall. It may use snort as a last line of defense, it may use snort just because it's handy for detecting strange patters which could indicate other network problems, etc. It could even have some locally-grown programs that use some snort tools. This is somewhat relevant to the point Ryan just raised in his recent post about better apt security with 3rd-party sites, since having outdated packages in the archive makes people use backports from 3rd-party sites, and you don't know the validity of these packages. True, but security issues aren't forcing people to use backports. If they are, they don't understand how Debian handles security. It seems to me to be a perfect way to trojan a newbie's machines: The newbie hears on debian-user that he must update some of these packages: So, there is a malicious cracker who put a site up with official updates, and the newbie adds it to his sources.list. Instantly, he gets a version of Snort that ignores attacks and chkrootkit with a rootkit... Even if you could use debsigs, a newbie probably couldn't verify the package anyway, due to the lack of personal WOT. I think it is a rather bad situation. It's kind of off the topic, but if you're concerned about tools like snort, et. al., you should be at the experience level where verifying signatures of untrusted packages, upgrading to testing|unstable, doing apt-get source, or simply building from a tarball are viable options for you. If a newbie believes a posting that he must update from site: http://whatever.not.a.debian.site:1234/my/evil/files;, there's not much to be done about it, aside from better education of end users. As you stated, this does get more into the points raised in the other topic. Again, I'm fine with backports for many packages, and I'm fine with the general release cycle, it's just the small number of critical security-related packages that I feel needs some discussion. What's the difference if someone downloads a backport of snort or a backport of a window manager? Either way, if the backport is evil, you're screwed. It's probably worse to have a malicious backport of more mundane software, since the effects may be less noticeable, and the software may be more widespread. IMHO, it's been discussed to death already. Whether you want a brand new version of snort or a new version of KDE is
Re: Update of security-critical outdated packages
Kjetil Kjernsmo wrote: On Thursday 15 January 2004 17:33, Rich Puhek wrote: Depending on what you're doing, pinning actually can work quite well. Yup, and I do it on my workstation (not that I understand it, it is rather magic to me). Snort is related to you overall system security, yes, but new releases of Snort have to do with your desire to run the latest and greatest releast of a package, not with security issues. Well, that's not how I read DSA-297. I have no desire to run the latest and greatest release of a package on my production server, to the contrary, with the notable exception of SpamAssassin. I would argue that it is only because of security issues I would ever consider upgrading a package on a production server (and mine isn't even in production yet! :-) ). it may use snort just because it's handy for detecting strange patters which could indicate other network problems, etc. It could even have some locally-grown programs that use some snort tools. OK, valid argument, still, wouldn't it be rather rare compared to actually using it for what it is intended for? True, but security issues aren't forcing people to use backports. If they are, they don't understand how Debian handles security. Again, that's not how I read DSA-297. They advise using newer versions of snort because it recognizes newer attacks. Any security holes in snort will continue to be patched. In other words, if someone discovered today that woody's snort version has a buffer overflow, you can bet that snort will be updated in security within a few days. The key difference here is in the use of the term security issues. The security release is used to patch holes in a server. The version of snort in stable has no security issues in the sense that installing it does not open you up to attack. It's kind of off the topic, but if you're concerned about tools like snort, et. al., you should be at the experience level where verifying signatures of untrusted packages, It has nothing to do with experience. Sometimes, you just don't have the WOT needed to verify a package. Most probably, only those who have at some point attended a Debian keysigning party have a WOT suitable for that, and perhaps people who live in an area with many Debian users. In sparsely populated areas like Norway, a good WOT is a real luxury, and one of past year's most luxurious evenings was the Debian keysigning party... :-) upgrading to testing|unstable, You don't want to do that on a production system. On a general production server, no. Now think about why: you might have to upgrade lots of dependancies, you might get stuck with incompletely tested software, it's more difficult to maintain security updates. Those are also the arguements used for not arbitrarily upgrading packages in stable! You may find that upgrading to unstable (or a hibrid of unstable packages) is just about ideal for something like an IDS or an antispam server. Machines like that tend to need bleeding-edge software, so almost by definition, they end up runing unstable. doing apt-get source, or simply building from a tarball are viable options for you. Yep, but it is still besides the point: Really good reason for keeping outdated packages in the archive (ok, you provided one above)? Is the arguement that old packages like snort should be removed altogether, or that packages I really find important should be upgraded more aggressively? If it's the former, I'd argue that unless you can present a hugely compelling arguement for removal (like a sudden discovery of a licensing issue, with an accompanying lawsuit), it would be a bad idea to suddely have packages disappear from stable. If it's the latter, well, we're back to the initial arguements about release cycles, package updates, etc. Also, how do we decide what's important enought to be upgraded immediately? should SpamAssassin be upgraded because I don't want to receive spam that's been catchable for a year? Should PHP be upgraded because I want to be able to serve pages that have been written in a language version supported for the last year (like $_FILES['userfile']['error'] ). Should perl be upgraded because it's a very important language? Eventually, you'd discover you come up with the package list for Debian/unstable. Again, I'm fine with backports for many packages, and I'm fine with the general release cycle, it's just the small number of critical security-related packages that I feel needs some discussion. What's the difference if someone downloads a backport of snort or a backport of a window manager? Big difference: If the WM is a bit unstable, or it has a bit weird performance at times, I don't care. It's the cost of running unstable software. But if the NIDS fails to recognize an attack that's been known for two years, it is pretty serious. It sounded like your main objection to backports was that someone could trojan
Re: Update of security-critical outdated packages
Kjetil Kjernsmo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, It is an issue that's been bugging me for some time, and while I have tried to find good reasons, I have not, so I might as well write them down. I have a lot of respect for the security team, and I don't think I have anything to contribute other than my thoughts, but I'll try to share them. Many packages in stable are really outdated. After first installing Woody, I first thought that looking at the prospect of waiting one-and-a-half year for the next release would scare me away from Debian. Now that I've grown up a bit more, it doesn't. I'm perfectly fine with using backports for things like KDE. Also, if I was a sysadmin for a lot of boxes, supporting many not-too-savvy users, the release cycle is perfectly reasonable. For a stable system, pinning is not option, because you'll quite soon have to update things like libc6 if you do. It's not about that. Backports are fine for most purposes, and I'm fine with the release cycle. Depending on what you're doing, pinning actually can work quite well. But you're correct in that upgrading too many pakages quickly leads to an explosion of dependancies. It's about a small handful of security-critical packages, like for example Snort. In the case of Snort, the security team has explicitly discouraged people from using the packages available in Woody, see DSA-297. I find it very hard to understand that in the cases where the security team strongly advises an upgrade, that the backported packages are not included in e.g. a point release. This has nothing to do with the security team and security issues as far as software vulnerabilities. If there's a security issue with a package, the security team will fix the problem in the stable release. Problem solved (as in DSA-297). Snort is related to you overall system security, yes, but new releases of Snort have to do with your desire to run the latest and greatest releast of a package, not with security issues. So, this is just about the very few packages the security team feels are so outdated, one advice people not to use them. For those packages, the question is: What is the advantage of keeping so outdated packages in the archive? If the package is outdated, you have other options, including apt-get source and other options mentioned in your email. It just doesn't have to do with the security team. In the case of snort, an old version could still be useful in the archive. Picture a machine that must run stable (for various reasons), sitting behind a decent firewall. It may use snort as a last line of defense, it may use snort just because it's handy for detecting strange patters which could indicate other network problems, etc. It could even have some locally-grown programs that use some snort tools. This is somewhat relevant to the point Ryan just raised in his recent post about better apt security with 3rd-party sites, since having outdated packages in the archive makes people use backports from 3rd-party sites, and you don't know the validity of these packages. True, but security issues aren't forcing people to use backports. If they are, they don't understand how Debian handles security. It seems to me to be a perfect way to trojan a newbie's machines: The newbie hears on debian-user that he must update some of these packages: So, there is a malicious cracker who put a site up with official updates, and the newbie adds it to his sources.list. Instantly, he gets a version of Snort that ignores attacks and chkrootkit with a rootkit... Even if you could use debsigs, a newbie probably couldn't verify the package anyway, due to the lack of personal WOT. I think it is a rather bad situation. It's kind of off the topic, but if you're concerned about tools like snort, et. al., you should be at the experience level where verifying signatures of untrusted packages, upgrading to testing|unstable, doing apt-get source, or simply building from a tarball are viable options for you. If a newbie believes a posting that he must update from site: http://whatever.not.a.debian.site:1234/my/evil/files;, there's not much to be done about it, aside from better education of end users. As you stated, this does get more into the points raised in the other topic. Again, I'm fine with backports for many packages, and I'm fine with the general release cycle, it's just the small number of critical security-related packages that I feel needs some discussion. What's the difference if someone downloads a backport of snort or a backport of a window manager? Either way, if the backport is evil, you're screwed. It's probably worse to have a malicious backport of more mundane software, since the effects may be less noticeable, and the software may be more widespread. IMHO, it's been discussed to death already. Whether you want a brand new version of snort or a new
Re: Update of security-critical outdated packages
Kjetil Kjernsmo wrote: On Thursday 15 January 2004 17:33, Rich Puhek wrote: Depending on what you're doing, pinning actually can work quite well. Yup, and I do it on my workstation (not that I understand it, it is rather magic to me). Snort is related to you overall system security, yes, but new releases of Snort have to do with your desire to run the latest and greatest releast of a package, not with security issues. Well, that's not how I read DSA-297. I have no desire to run the latest and greatest release of a package on my production server, to the contrary, with the notable exception of SpamAssassin. I would argue that it is only because of security issues I would ever consider upgrading a package on a production server (and mine isn't even in production yet! :-) ). it may use snort just because it's handy for detecting strange patters which could indicate other network problems, etc. It could even have some locally-grown programs that use some snort tools. OK, valid argument, still, wouldn't it be rather rare compared to actually using it for what it is intended for? True, but security issues aren't forcing people to use backports. If they are, they don't understand how Debian handles security. Again, that's not how I read DSA-297. They advise using newer versions of snort because it recognizes newer attacks. Any security holes in snort will continue to be patched. In other words, if someone discovered today that woody's snort version has a buffer overflow, you can bet that snort will be updated in security within a few days. The key difference here is in the use of the term security issues. The security release is used to patch holes in a server. The version of snort in stable has no security issues in the sense that installing it does not open you up to attack. It's kind of off the topic, but if you're concerned about tools like snort, et. al., you should be at the experience level where verifying signatures of untrusted packages, It has nothing to do with experience. Sometimes, you just don't have the WOT needed to verify a package. Most probably, only those who have at some point attended a Debian keysigning party have a WOT suitable for that, and perhaps people who live in an area with many Debian users. In sparsely populated areas like Norway, a good WOT is a real luxury, and one of past year's most luxurious evenings was the Debian keysigning party... :-) upgrading to testing|unstable, You don't want to do that on a production system. On a general production server, no. Now think about why: you might have to upgrade lots of dependancies, you might get stuck with incompletely tested software, it's more difficult to maintain security updates. Those are also the arguements used for not arbitrarily upgrading packages in stable! You may find that upgrading to unstable (or a hibrid of unstable packages) is just about ideal for something like an IDS or an antispam server. Machines like that tend to need bleeding-edge software, so almost by definition, they end up runing unstable. doing apt-get source, or simply building from a tarball are viable options for you. Yep, but it is still besides the point: Really good reason for keeping outdated packages in the archive (ok, you provided one above)? Is the arguement that old packages like snort should be removed altogether, or that packages I really find important should be upgraded more aggressively? If it's the former, I'd argue that unless you can present a hugely compelling arguement for removal (like a sudden discovery of a licensing issue, with an accompanying lawsuit), it would be a bad idea to suddely have packages disappear from stable. If it's the latter, well, we're back to the initial arguements about release cycles, package updates, etc. Also, how do we decide what's important enought to be upgraded immediately? should SpamAssassin be upgraded because I don't want to receive spam that's been catchable for a year? Should PHP be upgraded because I want to be able to serve pages that have been written in a language version supported for the last year (like $_FILES['userfile']['error'] ). Should perl be upgraded because it's a very important language? Eventually, you'd discover you come up with the package list for Debian/unstable. Again, I'm fine with backports for many packages, and I'm fine with the general release cycle, it's just the small number of critical security-related packages that I feel needs some discussion. What's the difference if someone downloads a backport of snort or a backport of a window manager? Big difference: If the WM is a bit unstable, or it has a bit weird performance at times, I don't care. It's the cost of running unstable software. But if the NIDS fails to recognize an attack that's been known for two years, it is pretty serious. It sounded like your main objection to backports
Re: MS BS
Ted Roby wrote: My secalert account for these lists is being drenched with 40 to 70 of these fake Microsoft Update emails per day. My filters on my client dump them to a Junk folder, but I would prefer it if my Exim filter would do the job at the server level instead. I am running Nigel Metheringham's system_filter.exim. The single part MIME filter doesn't seem to catch it though. What are others on this list using or doing to blatently block this stuff? There is no valid .exe I could receive, ever. Amavis. If you're just running Linux boxes, you can skip the anti-virus programs, and just use the banned_filenames. If you have users who are on Windoze machines, add in clamav, and you've got a free AV solution that's pretty good. There's others that should work fine to... look into MIMEDefang, (I think that's what it's called). --- The human race is a race of cowards; and I am not only marching in that procession but carrying a banner. -- Mark Twain --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MS BS
Ted Roby wrote: My secalert account for these lists is being drenched with 40 to 70 of these fake Microsoft Update emails per day. My filters on my client dump them to a Junk folder, but I would prefer it if my Exim filter would do the job at the server level instead. I am running Nigel Metheringham's system_filter.exim. The single part MIME filter doesn't seem to catch it though. What are others on this list using or doing to blatently block this stuff? There is no valid .exe I could receive, ever. Amavis. If you're just running Linux boxes, you can skip the anti-virus programs, and just use the banned_filenames. If you have users who are on Windoze machines, add in clamav, and you've got a free AV solution that's pretty good. There's others that should work fine to... look into MIMEDefang, (I think that's what it's called). --- The human race is a race of cowards; and I am not only marching in that procession but carrying a banner. -- Mark Twain --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: [d-security] Re: ssh vulnerability in the wild
Adrian von Bidder wrote: On Tuesday 16 September 2003 22:30, Rich Puhek wrote: [mix stable/testing/unstable] This is what I usually do - and usually, it works quite fine. Right now, though, I've been pulling in more and more from testing/unstable since some things depend on the new glibc, and some other things randomly break when used with the new glibc, so I've had to upgrade those things, which in turn depend on foo, which... Ahh, when it starts to want to download a lot of libraries I don't know much about, that's when I lean towards apt-get source. reduces the exploding dependancies/conflicts problem... --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
Adrian von Bidder wrote: On Tuesday 16 September 2003 22:30, Rich Puhek wrote: [mix stable/testing/unstable] This is what I usually do - and usually, it works quite fine. Right now, though, I've been pulling in more and more from testing/unstable since some things depend on the new glibc, and some other things randomly break when used with the new glibc, so I've had to upgrade those things, which in turn depend on foo, which... Ahh, when it starts to want to download a lot of libraries I don't know much about, that's when I lean towards apt-get source. reduces the exploding dependancies/conflicts problem... --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: [d-security] Re: ssh vulnerability in the wild
Dossy wrote: On 2003.09.16, Stephen Frost [EMAIL PROTECTED] wrote: Is 3.6.1p2-3 vulnerable? For those of us who want security, must we downgrade to 3.4p1-1.1 or build from source after patching by hand? Or will this security fix be applied to sarge as well? There's at least a version on incoming.debian.org which has the version for unstable. I don't know what to tell you about testing/sarge. I'm sure it will be in before release but beyond that I've no idea when it will make it into testing. Eek. So, if we want to run secure systems, we either have to run unstable (and all the troubles that comes with) or stable? I find that testing is a good middle ground for a reasonably stable system but with reasonably up-to-date packages, so that's why I run it. Running stable involves hand-managing way too many packages that I do need more recent versions, and unstable involves way too many troubles if I apt-get update without carefully inspecting what's being updated, which I don't have the time for. :-( poop. Guess I'll go the deb-src route and hand-patch, I guess. Not what I wanted to do today ... ;-) -- Dossy Or (to get a reasonably up to date system): * Set your default release to stable (I actually prefer to use distribution names, so that if I'm asleep at the switch when a new version is released I don't accidentally 'apt-get upgrade' when I should 'apt-get dist-upgrade') * Include testing and unstable in sources.conf * Include apt-src for testing and/or unstable. * Install a stable system, then for special needs, try 'apt-get install foo/testing' (or foo/unstable). If you can live with the dependancies, great. If things turn ugly, then apt-get source instead. This way, you'll have stable (with the corresponding security updates) for just about everything. For the few packages that need to be from unstable or testing, either patch them yourself, or watch incoming, or watch for others to contribute .debs. Plus, you can apt-get update upgrade without having your system blow up. I've found fairly few cases where I actually *need* a more recent version, so this approach works great for me. In most cases, the only perceved need for a more recent version has been for security updates, which, of course, are backported in Debian stable. Of course, YMMV. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: ssh vulnerability in the wild
Dossy wrote: On 2003.09.16, Stephen Frost [EMAIL PROTECTED] wrote: Is 3.6.1p2-3 vulnerable? For those of us who want security, must we downgrade to 3.4p1-1.1 or build from source after patching by hand? Or will this security fix be applied to sarge as well? There's at least a version on incoming.debian.org which has the version for unstable. I don't know what to tell you about testing/sarge. I'm sure it will be in before release but beyond that I've no idea when it will make it into testing. Eek. So, if we want to run secure systems, we either have to run unstable (and all the troubles that comes with) or stable? I find that testing is a good middle ground for a reasonably stable system but with reasonably up-to-date packages, so that's why I run it. Running stable involves hand-managing way too many packages that I do need more recent versions, and unstable involves way too many troubles if I apt-get update without carefully inspecting what's being updated, which I don't have the time for. :-( poop. Guess I'll go the deb-src route and hand-patch, I guess. Not what I wanted to do today ... ;-) -- Dossy Or (to get a reasonably up to date system): * Set your default release to stable (I actually prefer to use distribution names, so that if I'm asleep at the switch when a new version is released I don't accidentally 'apt-get upgrade' when I should 'apt-get dist-upgrade') * Include testing and unstable in sources.conf * Include apt-src for testing and/or unstable. * Install a stable system, then for special needs, try 'apt-get install foo/testing' (or foo/unstable). If you can live with the dependancies, great. If things turn ugly, then apt-get source instead. This way, you'll have stable (with the corresponding security updates) for just about everything. For the few packages that need to be from unstable or testing, either patch them yourself, or watch incoming, or watch for others to contribute .debs. Plus, you can apt-get update upgrade without having your system blow up. I've found fairly few cases where I actually *need* a more recent version, so this approach works great for me. In most cases, the only perceved need for a more recent version has been for security updates, which, of course, are backported in Debian stable. Of course, YMMV. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: Simple e-mail virus scanner
Kjetil Kjernsmo wrote: Dear all, I guess I'm not really looking for a security solution, but I guess you folks are the most likely to know, so I try here... In the last couple of hours, I've got about 25 100KB of the recent Sobig.f M$ virus, along with about the same number of bogus there was a virus in an e-mail you sent. It would be really great to be able to filter those out so that I don't need to see them, that is, get them in a folder I can clean out now and then. But I don't want to run a full-scale virus scanner, because for the time being, I really don't need any, as no e-mail is read on an MS machine here. I figured, most viruses should be able to detect by using simple regexs, right? So, a simple scanner that looks for a number of regexs available from a repository could do the trick...? Or perhaps use something like Vipul's Razor for this kind of stuff...? So, I'm wondering, does anybody know about any such approach? Cheers, Kjetil You may just want to bite the bullet and install amavisd-new. Even though you're not really worried about the viruses per se, it will filter out the crap. If Sobig.F is any indication, this may become more desirable. You may even just want to install amavis without a virus scanner (and just searching for banned filenames), if an AV program imposes too much of a load on your system. Amavis also is nice for catching executable files that are so common with current worms (our install actually was catching Sobig.F this way before the AV signatures were updated). If you're not reading email on an MS machine, I'm guessing it's fairly rare for you to recieve legit emails with .pif, .exe, or .bat attachments. The nice thing is, amavis will do a better job at catching the attachments then some of the ad hoc methods discussed earlier (see the config section on banned filenames). Another plus is that it can be configured to SMTP reject the message, instead of accepting and then bouncing. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple e-mail virus scanner
Kjetil Kjernsmo wrote: Dear all, I guess I'm not really looking for a security solution, but I guess you folks are the most likely to know, so I try here... In the last couple of hours, I've got about 25 100KB of the recent Sobig.f M$ virus, along with about the same number of bogus there was a virus in an e-mail you sent. It would be really great to be able to filter those out so that I don't need to see them, that is, get them in a folder I can clean out now and then. But I don't want to run a full-scale virus scanner, because for the time being, I really don't need any, as no e-mail is read on an MS machine here. I figured, most viruses should be able to detect by using simple regexs, right? So, a simple scanner that looks for a number of regexs available from a repository could do the trick...? Or perhaps use something like Vipul's Razor for this kind of stuff...? So, I'm wondering, does anybody know about any such approach? Cheers, Kjetil You may just want to bite the bullet and install amavisd-new. Even though you're not really worried about the viruses per se, it will filter out the crap. If Sobig.F is any indication, this may become more desirable. You may even just want to install amavis without a virus scanner (and just searching for banned filenames), if an AV program imposes too much of a load on your system. Amavis also is nice for catching executable files that are so common with current worms (our install actually was catching Sobig.F this way before the AV signatures were updated). If you're not reading email on an MS machine, I'm guessing it's fairly rare for you to recieve legit emails with .pif, .exe, or .bat attachments. The nice thing is, amavis will do a better job at catching the attachments then some of the ad hoc methods discussed earlier (see the config section on banned filenames). Another plus is that it can be configured to SMTP reject the message, instead of accepting and then bouncing. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: Debian Stable server hacked
A few thoughts on potenital problems: Thijs Welman wrote: Unfortunately i don't have the resources to get an IDS system up and running... A bare-bones IDS isn't all thet extreme to build, especially if you are only interested in a single network. Debian stable + snort source package from unstable might be your best bet... regards and tia, Thijs Welman Delft University of Technology the Netherlands - [0] My server is running Debian stable with: - linux-2.4.21-ac4 custom compiled kernel without LKM-support - sshd - apache - apache-ssl - php4 - smbd/nmbd (firewalled at the university network border) NOTE: Ok, firewalled at the network border, but could poorly-secured internal windows machines have been used as a springboard for an attack? The same goes for the below services, are you sure that all the machines and people on the same side of the firewall are completely trustworthy? This is a big hole if you're only firewalling at the border of your campus network, and have a wide variety of machines out there... - postfix (not accessible from outside) - bind9 (not accessible from outside) - mysql (firewalled) - proftpd (firewalled) - snmpd (firewalled) - amanda-client from inetd (firewalled) All packages are unmodified releases from Debian stable and, yes, i do update packes from security.debian.org as soon as there are any updates. :) Was anyone else logged in at the time? Perhaps one of your admins had a weak or compromised password? --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: SPAMMED ONCE AGIN !!! (Was: Re: Under 10 bucks, cell phone antenna boosters. qmnh coxehywqphhnsg)
Michelle Konzack wrote: Because I use [EMAIL PROTECTED] only to get mails, there was someone which had made a lookup on the Mailing-List-Server to get this Address... Well, no. If you look carefully, you have managed to leak that address to the list before. On March 17, 2003, for instance (Message-Id: [EMAIL PROTECTED]) you posted a reply to a question. Although you set your From address to be the linux4michelle address, you also ended up with the following line: X-Sender: [EMAIL PROTECTED] (Unverified) So, your MUA or MTA has leaked that address, without anyone needing to do a lookup on the Debian servers. That is a nice approach to handling the spam problem, but as you can see, one must be very careful to prevent leaking the subscribed to address. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: Traffic monitoring
Nils wrote: Hello everybody! I have small but complicated problem. How do you monitor what network traffic you have and how much? I want to be able to see the origin and destination, type and volume. We have two computer labs, with its respective ISP-connections, both with volume based rates. These two sites are also connected to each other through a VPN. The volume between the two sites should really be marginal. Due to what we get charge by the ISP, we suspect a lot of non-sanctioned material (mp3..) being transported over smb. I would like to at least be able to monitor the volume from respective computer going through the firewall (and the VPN). If you can install a machine as a sniffer (hubs only in the network, or a switch that supports port mirroring), iptraf may really help here. I don't find it very usefull over long trends, but I use iptraf on my network whenever I see an unexplained jump in traffic and need to track down the source. It's able to show traffic by port, by packet size, or a running display of source IP:port and destination IP:port pairs. Also supports packet filtering (which is really nice to filter out the port 22 connection from my workstation, so the continual screen updates don't distract me with increasing packet counts). It's also packaged for Debian. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Traffic monitoring
Nils wrote: Hello everybody! I have small but complicated problem. How do you monitor what network traffic you have and how much? I want to be able to see the origin and destination, type and volume. We have two computer labs, with its respective ISP-connections, both with volume based rates. These two sites are also connected to each other through a VPN. The volume between the two sites should really be marginal. Due to what we get charge by the ISP, we suspect a lot of non-sanctioned material (mp3..) being transported over smb. I would like to at least be able to monitor the volume from respective computer going through the firewall (and the VPN). If you can install a machine as a sniffer (hubs only in the network, or a switch that supports port mirroring), iptraf may really help here. I don't find it very usefull over long trends, but I use iptraf on my network whenever I see an unexplained jump in traffic and need to track down the source. It's able to show traffic by port, by packet size, or a running display of source IP:port and destination IP:port pairs. Also supports packet filtering (which is really nice to filter out the port 22 connection from my workstation, so the continual screen updates don't distract me with increasing packet counts). It's also packaged for Debian. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: Protection against http tunneling (was: HTTP tunnel with linuxserver and windows client)
Vassilii Khachaturov wrote: The question is... is there any way to protect against this? I mean, how would you differenciate on for example, a squid, the traffic of one of this tunnels from the real traffic you want to allow? There is a way to protect any particular form of tunnelling (i.e., if you know that a particular tunnel is there, you'll find a way to disrupt it). But there is no practical way to prevent covert communications of an inside user to the outside world, if any reasonable connectivity, through whatever firewall or whatever, exists. You can minimize the risk by monitoring everyone's activity 24hours, but even then you don't have 100% guarantee. And if you close the network, the person can smuggle diskettes in and out, creating a high-latency link. Or use the state of his office lighting (on or off) at every 17th minutes to signify whether the next bit of the message is 0 or 1. Not too good to transmit a picture, but enough to eventually relay a secret encryption key to someone out there watching. You've got the idea... Reminds me of a rumor I heard that someone was working on an NFS over SMTP gateway. Would have pretty crappy latency, but the point was to prove that a firewall is not a guarrantee of security. Also worth considering in your examples is RFC2549 (IP over Avian Carriers with QoS). --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Protection against http tunneling (was: HTTP tunnel with linux server and windows client)
Vassilii Khachaturov wrote: The question is... is there any way to protect against this? I mean, how would you differenciate on for example, a squid, the traffic of one of this tunnels from the real traffic you want to allow? There is a way to protect any particular form of tunnelling (i.e., if you know that a particular tunnel is there, you'll find a way to disrupt it). But there is no practical way to prevent covert communications of an inside user to the outside world, if any reasonable connectivity, through whatever firewall or whatever, exists. You can minimize the risk by monitoring everyone's activity 24hours, but even then you don't have 100% guarantee. And if you close the network, the person can smuggle diskettes in and out, creating a high-latency link. Or use the state of his office lighting (on or off) at every 17th minutes to signify whether the next bit of the message is 0 or 1. Not too good to transmit a picture, but enough to eventually relay a secret encryption key to someone out there watching. You've got the idea... Reminds me of a rumor I heard that someone was working on an NFS over SMTP gateway. Would have pretty crappy latency, but the point was to prove that a firewall is not a guarrantee of security. Also worth considering in your examples is RFC2549 (IP over Avian Carriers with QoS). --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: [work] Integrity of Debian packages
Gary MacDougall wrote: Yes, the American Empire is certainly on the move... and the World is their oyster. Be afraid, be very afraid. Ted Maybe you should talk to the family of the 3300 people in the WTC that died because the FBI, CIA or Special Services didn't have or couldn't intercept the many mail, fax and cell phone communications that went between the cowards that flew planes into the buildings. You know, I feel safer now than I did on 9-11. The price of freedom is costly. Ummm, interception wasn't the problem. Interpretation was the problem. Harvesting more email isn't going to solve much (and will possibly compound the problem) if intelligence agencies lack enough manpower to translate and interpret the messages. Your comment seems to lay blame for 9/11 on the intelligence community. It's fair to say that they had major flaws at that time (and possibly now as well). You could argue that this specific incident could have been prevented if certain measures were in place. Keep in mind, the perpetrators were a determined group that was willing to accept death in the pursuit of their goal. That's a combination that is nearly unstoppable. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [work] Integrity of Debian packages
Ted Parvu wrote: On Fri, Mar 07, 2003 at 01:10:29PM -0500, Gary MacDougall wrote: Maybe you should talk to the family of the 3300 people in the WTC that died because the FBI, CIA or Special Services didn't have or couldn't intercept the many mail, fax and cell phone communications that went between the cowards that flew planes into the buildings. You know, I feel safer now than I did on 9-11. The price of freedom is costly. Hmm, the price of freedom is costly They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Ben Franklin Perhaps you would do well to consider that the US military should never have allowed those planes to hit anything. http://www.dtic.mil/doctrine/jel/cjcsd/cjcsi/3610_01a.pdf Umm, according to that document, the military could *not* take any action against the aircraft. They do have authority to destroy Derelict Airborne Objects, but the definition of such an object does not include any form of manned craft. The document goes on to specify what assistance the military will provide to civil authorities in piracy of civil aircraft: Military personnel will provide the following types of support: intercept, surveillance, lift, equipment, and communications. Military personnel may not participate in a search, seizure, arrest, or other similar activity. This restriction would include the apprehension of aircraft hijackers or use of military aircraft (fixed-wing or helicopter) or other vehicles as platforms for gunfire or the use of other weapons against suspected hijackers. So it would seem that as of Sept. 11th, 2001 (the order you reference was issued June 1st, 2001), the military could not do anything besides escort the planes. Note the specific restriction against the use of weapons against suspected hijackers. Why don't you google what the standing intercept orders are for aircraft that stray off course or that lose communications. Then ask yourself why only the plane that was headed for the Whitehouse was downed. The Washington propaganda machine is in full force in this country. Use the Net to understand what is really going on here. Ted Yes, of course the Net is even more reliable than the government propaganda :-) Granted, there's bound to be plenty of slant from the official line, but keep in mind the fact that any yahoo with a modem can generate a different view that's even less credible. Let's also take a good look at the reality of the situation. Life isn't a movie, there's a finite time involved to do something as basic as getting an aircraft off the ground, plus transit time to fly from an airbase to intercept the suspect craft. Also, after the cold war ended, we kinda stepped down the alert level at airbases around the US, so I doubt there were any pilots sitting around in a ready room just waiting for a siren to go off, planes might not have been fuled up, planes were most likely not armed, etc. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [work] Integrity of Debian packages
Gary MacDougall wrote: Yes, the American Empire is certainly on the move... and the World is their oyster. Be afraid, be very afraid. Ted Maybe you should talk to the family of the 3300 people in the WTC that died because the FBI, CIA or Special Services didn't have or couldn't intercept the many mail, fax and cell phone communications that went between the cowards that flew planes into the buildings. You know, I feel safer now than I did on 9-11. The price of freedom is costly. Ummm, interception wasn't the problem. Interpretation was the problem. Harvesting more email isn't going to solve much (and will possibly compound the problem) if intelligence agencies lack enough manpower to translate and interpret the messages. Your comment seems to lay blame for 9/11 on the intelligence community. It's fair to say that they had major flaws at that time (and possibly now as well). You could argue that this specific incident could have been prevented if certain measures were in place. Keep in mind, the perpetrators were a determined group that was willing to accept death in the pursuit of their goal. That's a combination that is nearly unstoppable. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: [work] Integrity of Debian packages
Ted Parvu wrote: On Fri, Mar 07, 2003 at 01:10:29PM -0500, Gary MacDougall wrote: Maybe you should talk to the family of the 3300 people in the WTC that died because the FBI, CIA or Special Services didn't have or couldn't intercept the many mail, fax and cell phone communications that went between the cowards that flew planes into the buildings. You know, I feel safer now than I did on 9-11. The price of freedom is costly. Hmm, the price of freedom is costly They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Ben Franklin Perhaps you would do well to consider that the US military should never have allowed those planes to hit anything. http://www.dtic.mil/doctrine/jel/cjcsd/cjcsi/3610_01a.pdf Umm, according to that document, the military could *not* take any action against the aircraft. They do have authority to destroy Derelict Airborne Objects, but the definition of such an object does not include any form of manned craft. The document goes on to specify what assistance the military will provide to civil authorities in piracy of civil aircraft: Military personnel will provide the following types of support: intercept, surveillance, lift, equipment, and communications. Military personnel may not participate in a search, seizure, arrest, or other similar activity. This restriction would include the apprehension of aircraft hijackers or use of military aircraft (fixed-wing or helicopter) or other vehicles as platforms for gunfire or the use of other weapons against suspected hijackers. So it would seem that as of Sept. 11th, 2001 (the order you reference was issued June 1st, 2001), the military could not do anything besides escort the planes. Note the specific restriction against the use of weapons against suspected hijackers. Why don't you google what the standing intercept orders are for aircraft that stray off course or that lose communications. Then ask yourself why only the plane that was headed for the Whitehouse was downed. The Washington propaganda machine is in full force in this country. Use the Net to understand what is really going on here. Ted Yes, of course the Net is even more reliable than the government propaganda :-) Granted, there's bound to be plenty of slant from the official line, but keep in mind the fact that any yahoo with a modem can generate a different view that's even less credible. Let's also take a good look at the reality of the situation. Life isn't a movie, there's a finite time involved to do something as basic as getting an aircraft off the ground, plus transit time to fly from an airbase to intercept the suspect craft. Also, after the cold war ended, we kinda stepped down the alert level at airbases around the US, so I doubt there were any pilots sitting around in a ready room just waiting for a siren to go off, planes might not have been fuled up, planes were most likely not armed, etc. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: Sendmail vulnerability : is Debian falling behind?
Jeremy T. Bouse wrote: It's been discussed plenty on the Debian mailing lists as well as having the package maintainer give an update on the status of the packages that are being prepared/ready at this time... Might suggest checking a bit further before making such a rash judgement on issues arelady being dealt with... RedHat and SuSe have commerical money to throw at it... Debian is run by volunteers... As well RedHat and SuSe do not support nearly as many platforms as Debian, so it sometimes takes a bit to get all the packages compiled on all the platforms prior to making an annonouncement so they are all available... Jeremy On Mon, Mar 03, 2003 at 03:17:16PM -0600, Jor-el wrote: Woah... easy on Jor-el, everyone. He wasn't slamming Debian's schedule on security updates so much as being concerned about whether Debian was being given the same early notification of vulnerabilities as RedHat, SuSe, and other vendors. As mentioned in another thread, Debian didn't appear to be on the list of vendors notified by CERT (see http://www.cert.org/advisories/CA-2003-07.html). -- Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sendmail vulnerability : is Debian falling behind?
Jeremy T. Bouse wrote: It's been discussed plenty on the Debian mailing lists as well as having the package maintainer give an update on the status of the packages that are being prepared/ready at this time... Might suggest checking a bit further before making such a rash judgement on issues arelady being dealt with... RedHat and SuSe have commerical money to throw at it... Debian is run by volunteers... As well RedHat and SuSe do not support nearly as many platforms as Debian, so it sometimes takes a bit to get all the packages compiled on all the platforms prior to making an annonouncement so they are all available... Jeremy On Mon, Mar 03, 2003 at 03:17:16PM -0600, Jor-el wrote: Woah... easy on Jor-el, everyone. He wasn't slamming Debian's schedule on security updates so much as being concerned about whether Debian was being given the same early notification of vulnerabilities as RedHat, SuSe, and other vendors. As mentioned in another thread, Debian didn't appear to be on the list of vendors notified by CERT (see http://www.cert.org/advisories/CA-2003-07.html). -- Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail (fwd)
Vassilii Khachaturov wrote: (See also the bugs from the CC). I believe that Debian should be somehow put on the CERT vendor list: they give the vendors more advance warning on the security issues before they issue an advisory, allowing to issue an emergency patch. Does anybody on this list (debian-security) have any ties with CERT to do it? - Original Message - From: Ramon Kagan [EMAIL PROTECTED] To: debian-security@lists.debian.org Sent: Monday, March 03, 2003 4:00 PM Subject: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail (fwd) HI, I don't see Debian listed in the notification list at the bottom of the CERT Advisory. Is there any estimate on the release of patched sendmail packages? Ramon Kagan [snip] I'm guessing that Debian is notified by CERT, since I have seen Debian listed in CERT advisories before. The last CERT Advisory I noticed that applied to Debian was the CA-2003-02 Double-Free Bug in CVS Server. The email announcement did include Debian. The key is that the vendor responses are those recieved by CERT, so if Debian was notified (I assume that means CERT emailed someone on the security team, or some other semi-official Debian person) and didn't return a response yet, you won't see Debian in the Advisory email. According to the advisories, CERT keeps updating the vendor portion of the advisory (http://www.cert.org/advisories/CA-2003-07.html) for this advisory), so I'd assume we'll see Debian listed there eventually. --Rich _ Rich Puhek ETN Systems Inc. 2125 1st Ave East Hibbing MN 55746 tel: 218.262.1130 email: [EMAIL PROTECTED] _
Re: Questions on Sysloging with a DMZ
Mike Dresser wrote: I was thinking of using a digiboard on the syslog machine, and connecting a serial link to each server. However, that doesn't help me on stuff like cisco's and jetdirect boxes that can only output syslog over ethernet. logging console level should get what you need on a cisco. Might have to set that serial port to no password, which brings up an additional home if physical security is a concern. --Rich _ Rich Puhek ETN Systems Inc. _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh ip address
Try just doing an `echo $SSH_CLIENT`. Depending on your version, you may need split the output up a bit... --Rich Eduardo J. Gargiulo wrote: Hi all. Is there any way to obtain the IP address of a ssh client and use it on a shell script? I want to put a crontab like ssh server script but I need the IP address i'm connecting from in the shell script and the address is assigned dynamically. thanks ~ejg -- _ Rich Puhek ETN Systems Inc. _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh ip address
Try just doing an `echo $SSH_CLIENT`. Depending on your version, you may need split the output up a bit... --Rich Eduardo J. Gargiulo wrote: Hi all. Is there any way to obtain the IP address of a ssh client and use it on a shell script? I want to put a crontab like ssh server script but I need the IP address i'm connecting from in the shell script and the address is assigned dynamically. thanks ~ejg -- _ Rich Puhek ETN Systems Inc. _
Re: Security Feedback - Backup Process?
Security input aside... have you considered using rsync instead of building a bunch of huge tarballs? I use a similar method, but my backup machine pulls data in with rsync. I don't build ISOs, I just tar from the backup machine to tape. By using rsync, I beat up my network much less, and I speed up the operation. Also, with the method I have, I maintain everything on my backup server... no configuration goes on the clients. Just something else to consider. --Rich Kenneth Pronovici wrote: The batch backup process is divided into four pieces: o collect [each machine]: builds tarballs based on configuration o stage [backup machine]: stages all collected data from other machines o store [backup machine]: builds ISO image and writes staged data to disc o purge [each machine]: purges old archived tarballs and/or ISO disc images ... Other than the problem with the saved-off files, is it safe to say that this process is as reasonably secure as any batch process which relies on ssh can be, or are there other things I can change to make the whole thing more secure? I really appreciate any feedback any of you might provide. I read the list, or you can send email privately to [EMAIL PROTECTED]. Thanks! -- _ Rich Puhek ETN Systems Inc. _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Got root?
Ummm.. you got it a bit backwards... UNIX does not *give* root access to daemons below 1024... The program (not necessasarily a daemon) must HAVE root access before it can bind to a port below 1024. That said, you may be on to something. It sounds like a good idea to me... but that doesn't necessarily mean anything. --Rich Sunny Dubey wrote: Hi I know that this might sound like a stupid question, but its one that has been bugging me. Why does UNIX continue to give root access to all deamons below port 1024? I know that UNIX does it so that normal users can't seem like legit and important services, but there surely must be some better way of delegating a port below 1024 to a deamon. A while ago, I remember reading on slashdot about how TrustedBSD and OpenBSD were different from each other. One of the differences was the fact that TrustedBSD used ACLs to give acccess to whatever for whomever. Couldn't you essentially do the same for ports? (Instead of giving access to files, you would give acces to ports) It would be like having a file called /etc/acl.ports (or something) and within the file, would be a list which binaries are allowed to bind to what ports. (an example is provided below) # /etc/acl.ports # Port Numbers binary 80 /usr/local/apache/bin/httpd 22 /usr/local/openssh/sshd 21 /usr/local/anonftpd/ftpd This way, not only would root have control over all ports below 1024, but the deamons themselves don't need to be running as root. (I also think that it would be very odd for a deamon _needing_ root access to run in the first place ...) Thanks for hearing me out. I could be very wrong on all of this. (Sorry if I am) I would just like to know why this hasn't been implemented in UNIX. (Actually, I did once hear about some patch to the LInux kernel that did something similar, but I have yet to find the patch) Sunny Dubey insert funny-witty comment here -- _ Rich Puhek ETN Systems Inc. _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Got root?
Ummm.. you got it a bit backwards... UNIX does not *give* root access to daemons below 1024... The program (not necessasarily a daemon) must HAVE root access before it can bind to a port below 1024. That said, you may be on to something. It sounds like a good idea to me... but that doesn't necessarily mean anything. --Rich Sunny Dubey wrote: Hi I know that this might sound like a stupid question, but its one that has been bugging me. Why does UNIX continue to give root access to all deamons below port 1024? I know that UNIX does it so that normal users can't seem like legit and important services, but there surely must be some better way of delegating a port below 1024 to a deamon. A while ago, I remember reading on slashdot about how TrustedBSD and OpenBSD were different from each other. One of the differences was the fact that TrustedBSD used ACLs to give acccess to whatever for whomever. Couldn't you essentially do the same for ports? (Instead of giving access to files, you would give acces to ports) It would be like having a file called /etc/acl.ports (or something) and within the file, would be a list which binaries are allowed to bind to what ports. (an example is provided below) # /etc/acl.ports # Port Numbers binary 80 /usr/local/apache/bin/httpd 22 /usr/local/openssh/sshd 21 /usr/local/anonftpd/ftpd This way, not only would root have control over all ports below 1024, but the deamons themselves don't need to be running as root. (I also think that it would be very odd for a deamon _needing_ root access to run in the first place ...) Thanks for hearing me out. I could be very wrong on all of this. (Sorry if I am) I would just like to know why this hasn't been implemented in UNIX. (Actually, I did once hear about some patch to the LInux kernel that did something similar, but I have yet to find the patch) Sunny Dubey insert funny-witty comment here -- _ Rich Puhek ETN Systems Inc. _
