Re: PAM support on potato
Philippe BARNETCHE wrote: > It looks like xdm doesn't support pam. http://people.debian.org/~branden/ take a look at the "Looking Ahead" section > I can't get pam_ldap working (either with login or gdm or kdm) while it's > running great on other distributions. depending on your needs this will cover gdm or not, here's what I use: auth requisite pam_nologin.so auth required pam_env.so auth required pam_ldap.so account required pam_ldap.so session required pam_unix.so password required pam_ldap.so It should be noted that I don't use a pam_unix failover for auth or session because on my workstation there are no valid shell accounts in the password file, outside of root ofcourse who shouldn't be loging in via gdm ever anyway. I haven't had any luck getting the pam_ldap password stuff to work, ymmv. login is more complicated and you should really understand fully what you're doing before you construct a login pam config. But suffice it to say that pam_ldap does work atleast for auth and account. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PAM support on potato
Wichert Akkerman wrote:
> Shouldn't the auth bit be:
> auth required pam_nologin.so
> auth required pam_env.so
> auth sufficient pam_ldap.so
> auth required pam_unix.so
>
> Otherwise you won't be able to login using local accounts.
Well it would be if I had local accounts, but I don't. Thats what I was
trying to explain when I was talking about why I didn't have a pam_unix
failover. (lousy word I know, I just couldn't think of a better one)
> The current version might be broken; the vesion in potato should work
> just fine.
I'm using the one from potato, everytime I try to get password working it
ends up either asking my password too many times, or simply ignores the
cracklib requirements I've tried to pair it with. Another part of the
problem is also openldap's mandate that the password be encrypted by the
pam module, which while I understand why they did that, is a pain because
now we have to deal with buggy hashing mechanisms in every program that
comes along and wants to change passwords. IIRC pam_ldap fails to put the
{md5} token in front of a generated md5 hash, this is probably fixed in the
more recent versions, I haven't checked. Anyway, I wanted to use salted
SHA and that wasn't supported at all.
If anyone has a working pam_ldap married to cracklib pam configuration for
potato, I'd be interested in seeing it.
--
Jamie Heilman http://audible.transient.net/~jamie/
"I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's
not for you." She was cheap, she was stupid and she wouldn't load
-- well, not for me, anyway." -Holly
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nss-ldap security bug
Don't race to install 110-3, it has unresolved symbols. See bug #76018 -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nss-ldap security bug
The libnns-ldap 122-1 update made it into r1 without ever having an official Security Alert announcement, I dunno how big of a deal this is, but I figured I should dredge it up incase it needed be addressed officially. Anyone? -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nss-ldap security bug
> I know, it's on the list of things to do. Since it's already in there it > has a lower priority then fixing things that don't have a fix yet > though. Thats cool, it hasn't been compiled for alpha yet either so I guess there's still work to be done. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SmartList sucks was Re: [OT] unsubscribe
> Mailman already has a config option for that, seem not to be switched > on by the admins. Debian mailing lists are managed using the ironically named "SmartList" software. Transitioning to better software probably isn't a high priority due the significant number of lists already deployed. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
Re: unknown udp port
> What I figured out is that the server uses an unpriviliged random udp > port when originating queries to other name servers and that named binds > that udp port a priori and listens on that port waiting for replies to > questions it will make. I hope I got it right, could someone please > confirm that? Yeah, that sounds like BIND. http://cr.yp.to/djbdns/forgery.html -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
Re: Removing stupid HTTP methods from Apache
Anne Carasik wrote: > I'm running Apache on a Woody machine, and I can't figure > out for the life of me how to disable certain insecure HTTP > methods like PROPFIND and PUT. Don't run software that answers requests with these methods if you don't want them enabled, nothing in apache (1.3 anyway) will service those by default. Otherwise, yeah, Limit and LimitExcept are the directives you're interested in. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
Re: Where to install the firewall scripts
> networking goes down. Can anybody point us to the relevant > documentation? last I knew there wasn't any, it was a todo item I wrote a quicky stub logger that logs its environment and how it was called, this is what I found: called as "/etc/network/if-pre-up.d/pre-up" (no arguments), nothing passed in to stdin, id: uid=0(root) gid=0(root) groups=0(root) environment: ADDRFAM=inet IFACE=eth0 IF_ADDRESS=192.168.2.42 IF_BROADCAST=192.168.2.255 IF_GATEWAY=192.168.2.1 IF_NETMASK=255.255.255.0 IF_NETWORK=192.168.2.0 METHOD=static MODE=start PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/tmp SHLVL=1 _=/bin/run-parts obviously your IPs may differ, looks like run-parts is used to call everything in that script for every interface being taken down. I wouldn't count on PWD being /tmp I think that may have been an artifact of my script (which I wrote a long time ago and don't have anymore). Anyway, you get the idea. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: NIS(Client && Server) + Security
> I have 3 machines, A, B and C. Machine A is my gateway,B my NIS, > mail and SMB server and machine C is my WorkStation. My doubt is if > is secure to have a NIS client on machine A or simple re-direct my > connections to machine B? Unless there's something you've not told us there's no reason to have A provide your NIS service, so why even consider it? If you did put NIS on machine A, for whatever reason, you would need to ensure hosts external to your local network couldn't access the NIS service, which could be done using the usual packet filtering techniques. In general NIS should never be exposed to untrusted access because its far too vulnerable to attack. I say this assuming A, B, C are all on a single local network, if machine B is external to the network machine C is on, well then, its a different story, and perhaps NIS isn't the best tool for the job. (IMO, NIS is almost never the best tool in homogenous linux environments.) -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
Re: NIS(Client && Server) + Security
> One last thing: What links do you sugest to read about this matter (NIS) and > what better tools exist for this kind of job? I don't really have any links, I'm just going by what my experience has been. The NIS security issues are well known, I'm sure a google search will turn up scads of information. NIS is almost the only option though if you require on-the-fly user replication between multiple different kinds of unix hosts. None of the BSDs that I know of have implemented a flexible SYSV-like name service switch yet, (there was a FreeBSD guy who was promising to do it but last I heard there was no public code, I haven't looked at 5.0 yet though) which is pretty much required to start stitching things like LDAP directly to your libc routines. Glibc supports this so its a given for environments that use it. Solaris >= 2.7 supports it *I think* ... its been a while since I dealt with that. Padl software makes both NSS and PAM hooks for LDAP, freely available to the linux community. (Not the best security record sadly, but I'm unaware of any competition.) OS X supports pluggable name services via netinfo (yuck) which work OK in my experience, though NFS was fugly at the time. Generally if you've got an environment that supports it, and you really need unified management[1] of your name services[2] I'd suggest using LDAP, openldap w/TLS provides significantly more security than NIS. [1] unified environments come at a high reliability cost, you've got to provide redundancy fallover services or your network can become unusable in the blink of an eye if something fails. I'd never consider using something like LDAP on a network with less than 5 machines, not for name services anyway. Small tasks can be handled well enough with rsync and ssh and some routine scripts. [2] note when I say name services, I'm not talking about DNS, though the facilities exist to incorporate that into a unified configuration. Personally I'd never use a unified environment for DNS management because doing so tends to create some annoying chicken-or-egg scenarios that newbie admins can easily trip over and cause a mess. I'm not fond of fragile services, which incidently is why I don't run BIND and why I think anyone who does is a fool. There are plenty of good replacements, djbdns, maradns (for those of you who tend and nurture your myopic little hatred of djb like its some kind of 100 year old bonsai), etc. And they don't crash every few days for no reason. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: BCC fields shown
Csillag Krist?f wrote: > > Soren Boll Overgaard pointed out that deleting the BCC fields from the > mails sent to other recipients is not the mail client's responsibility. > It should be done by the MTA. Soren isn't entirely right. In practice its more sane for the MUA to process, then remove, the Bcc field before sending the message, especially if the MUA will be speaking SMTP to send the message. > Evolution is configured to use /usr/sbin/sendmail for sending > out mails. Local injection adheres by no standard accross MTAs, but a reasonable thing for an injection program to do is to process and remove the Bcc field atleast in the case where the program is called without any arguments (the arguments being, traditionally, the addresses of the intended recipients). In many injection programs, the behavior that dictates how recipients are chosen is configurable. > If I configure it to use the SMTP server at localhost, it is working > properly. I wouldn't rely on that, if its not your MUA removing the Bcc you should be aware not all SMTP servers are going to remove that field for you. > So I guess this is a bug in the sendmail program in exim ?? Maybe, or maybe the proper flags simply aren't being passed to your local injection program to tell it to abide by the behavior you expect. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
Re: Cross site tracing and apache
Emmanuel Lacour wrote: > Is there someone having information about this web vulnerability, goals > and risks and how to disable it? google There's plenty of discussion out there on why this "vulnerability" isn't. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: Bug severity for substantial DoS vulnerability
Florian Weimer wrote: > What's the correct severity for substantial DoS vulnerabilities? I'd gauge it a little based on how popular the software is in the vulnerable configuration (which is something of a crapshoot). Sounds like you're talking about remotely exploitable as well, which I guess earns it a bonus point. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: Secure remote syslogging?
Litzler Mihaly wrote: > How do you think switching a separate VLAN for this would be also secure > enough? Is it a must to use a dedicated device? Switching is done for speed, not security.
Re: OpenSSH and debian?
Phillip Hofmeister wrote: > The same information can be gathered from your MTA (if you are > running one) by doing an RCPT TO: and then an RSET. This is not universally true and is generally a matter of how the MTA is configured. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
Re: rpc.mountd
Baran YURDAGUL wrote: > I have to questions firts one how can I configure mount.d on linux > use reserved ports ? man rpc.mountd -p or --port Force rpc.mountd to bind to the specified port, instead of using the random port number assigned by the portmapper. > and the second is about the apache sever, how can i disable http > trace ? thanks.. use google http://www.apacheweek.com/issues/03-01-24 Neither of these provide any additional security, why exactly do you think they are necessary? -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
Re: rpc.mountd
Baran YURDAGUL wrote: > Is there any problem occurs If I bind mountd to just one port under > 1024 ? Cause mount.d bind to 4 different port when it is started via > automatically ? these are the Medium marked ISS scan results .. Just to make sure I follow, an ISS scanner complained about finding those high ports... But, just pushing the port numbers down below 1024 won't solve anything. You're much better off filtering traffic to those ports with ipfilter and backing that up with a good tcp_wrappers configuration. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
Re: apache
Martynas Domarkas wrote: > Hi. I would like to use date string in apache log file names. Is there a > way to use some directive in httpd.conf to be parsed as shell command > like `date +%Y%m%d` or some other way to solve the problem? I will use > logrotate mechanism of debian, and this date string could be used only > for file creation after apache process receives SIGUSR1. Grab the cronolog package, its easier and less intrusive. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz
Re: apache
Martynas Domarkas wrote: > > Thanks, but I realy do not like instalation of another packages. There > must be a way to do this with apache configuration. Martynas Domarkas wrote: > > Thanks a lot. This is nice solution, but I still like apache do the job, > and let logrotate simpy rotate /var/log/apache/*.log. I feel like I have > seen somewhere some piece of shell command in httpd.conf. Martynas Domarkas wrote: > > Yes, of course. But in this case I will invoke rotatelogs... I don't > like it. As, you've exhausted the other possibilites, why not read the fine manual: http://httpd.apache.org/docs/logs.html -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
Re: pam doesn't see nis
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204711
Re: Known vulnerabilities left open in Debian?
Matt Zimmerman wrote: > > If you have concrete information about unfixed bugs, bring it forth. > Otherwise this is just more FUD. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196590 Now. To be fair, these bugs probably aren't the end of the world as long as you understand what all of them are and how to protect yourself, and I don't expect a great number of people are even using the Debian Zope packages. But as more time goes on these bugs are getting harder and harder to keep on top of because there are so many of them and they go so deep that backporting to this version of Zope becomes incredibly non-trivial. Frankly I wish Zope would just be dropped from stable, but I am glad Debian has the sensibilities to air their security bugs openly and not hide them obscurity (like say... the Zope project itself). It gives people the ability to remain informed, and thats ever so important. Still there are times when the project tends to let known holes fester. I find it tends to be worst around a new release. Take for example the mysql crash bug #131921 which was given up for a lost cause. Thankfully I've never seen this happen with a vulnerability that can cause a system compromise in a popular package. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
SmartList sucks was Re: [OT] unsubscribe
> Mailman already has a config option for that, seem not to be switched > on by the admins. Debian mailing lists are managed using the ironically named "SmartList" software. Transitioning to better software probably isn't a high priority due the significant number of lists already deployed. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unknown udp port
> What I figured out is that the server uses an unpriviliged random udp > port when originating queries to other name servers and that named binds > that udp port a priori and listens on that port waiting for replies to > questions it will make. I hope I got it right, could someone please > confirm that? Yeah, that sounds like BIND. http://cr.yp.to/djbdns/forgery.html -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing stupid HTTP methods from Apache
Anne Carasik wrote: > I'm running Apache on a Woody machine, and I can't figure > out for the life of me how to disable certain insecure HTTP > methods like PROPFIND and PUT. Don't run software that answers requests with these methods if you don't want them enabled, nothing in apache (1.3 anyway) will service those by default. Otherwise, yeah, Limit and LimitExcept are the directives you're interested in. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where to install the firewall scripts
> networking goes down. Can anybody point us to the relevant > documentation? last I knew there wasn't any, it was a todo item I wrote a quicky stub logger that logs its environment and how it was called, this is what I found: called as "/etc/network/if-pre-up.d/pre-up" (no arguments), nothing passed in to stdin, id: uid=0(root) gid=0(root) groups=0(root) environment: ADDRFAM=inet IFACE=eth0 IF_ADDRESS=192.168.2.42 IF_BROADCAST=192.168.2.255 IF_GATEWAY=192.168.2.1 IF_NETMASK=255.255.255.0 IF_NETWORK=192.168.2.0 METHOD=static MODE=start PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/tmp SHLVL=1 _=/bin/run-parts obviously your IPs may differ, looks like run-parts is used to call everything in that script for every interface being taken down. I wouldn't count on PWD being /tmp I think that may have been an artifact of my script (which I wrote a long time ago and don't have anymore). Anyway, you get the idea. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NIS(Client && Server) + Security
> I have 3 machines, A, B and C. Machine A is my gateway,B my NIS, > mail and SMB server and machine C is my WorkStation. My doubt is if > is secure to have a NIS client on machine A or simple re-direct my > connections to machine B? Unless there's something you've not told us there's no reason to have A provide your NIS service, so why even consider it? If you did put NIS on machine A, for whatever reason, you would need to ensure hosts external to your local network couldn't access the NIS service, which could be done using the usual packet filtering techniques. In general NIS should never be exposed to untrusted access because its far too vulnerable to attack. I say this assuming A, B, C are all on a single local network, if machine B is external to the network machine C is on, well then, its a different story, and perhaps NIS isn't the best tool for the job. (IMO, NIS is almost never the best tool in homogenous linux environments.) -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NIS(Client && Server) + Security
> One last thing: What links do you sugest to read about this matter (NIS) and > what better tools exist for this kind of job? I don't really have any links, I'm just going by what my experience has been. The NIS security issues are well known, I'm sure a google search will turn up scads of information. NIS is almost the only option though if you require on-the-fly user replication between multiple different kinds of unix hosts. None of the BSDs that I know of have implemented a flexible SYSV-like name service switch yet, (there was a FreeBSD guy who was promising to do it but last I heard there was no public code, I haven't looked at 5.0 yet though) which is pretty much required to start stitching things like LDAP directly to your libc routines. Glibc supports this so its a given for environments that use it. Solaris >= 2.7 supports it *I think* ... its been a while since I dealt with that. Padl software makes both NSS and PAM hooks for LDAP, freely available to the linux community. (Not the best security record sadly, but I'm unaware of any competition.) OS X supports pluggable name services via netinfo (yuck) which work OK in my experience, though NFS was fugly at the time. Generally if you've got an environment that supports it, and you really need unified management[1] of your name services[2] I'd suggest using LDAP, openldap w/TLS provides significantly more security than NIS. [1] unified environments come at a high reliability cost, you've got to provide redundancy fallover services or your network can become unusable in the blink of an eye if something fails. I'd never consider using something like LDAP on a network with less than 5 machines, not for name services anyway. Small tasks can be handled well enough with rsync and ssh and some routine scripts. [2] note when I say name services, I'm not talking about DNS, though the facilities exist to incorporate that into a unified configuration. Personally I'd never use a unified environment for DNS management because doing so tends to create some annoying chicken-or-egg scenarios that newbie admins can easily trip over and cause a mess. I'm not fond of fragile services, which incidently is why I don't run BIND and why I think anyone who does is a fool. There are plenty of good replacements, djbdns, maradns (for those of you who tend and nurture your myopic little hatred of djb like its some kind of 100 year old bonsai), etc. And they don't crash every few days for no reason. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BCC fields shown
Csillag Krist?f wrote: > > Soren Boll Overgaard pointed out that deleting the BCC fields from the > mails sent to other recipients is not the mail client's responsibility. > It should be done by the MTA. Soren isn't entirely right. In practice its more sane for the MUA to process, then remove, the Bcc field before sending the message, especially if the MUA will be speaking SMTP to send the message. > Evolution is configured to use /usr/sbin/sendmail for sending > out mails. Local injection adheres by no standard accross MTAs, but a reasonable thing for an injection program to do is to process and remove the Bcc field atleast in the case where the program is called without any arguments (the arguments being, traditionally, the addresses of the intended recipients). In many injection programs, the behavior that dictates how recipients are chosen is configurable. > If I configure it to use the SMTP server at localhost, it is working > properly. I wouldn't rely on that, if its not your MUA removing the Bcc you should be aware not all SMTP servers are going to remove that field for you. > So I guess this is a bug in the sendmail program in exim ?? Maybe, or maybe the proper flags simply aren't being passed to your local injection program to tell it to abide by the behavior you expect. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cross site tracing and apache
Emmanuel Lacour wrote: > Is there someone having information about this web vulnerability, goals > and risks and how to disable it? google There's plenty of discussion out there on why this "vulnerability" isn't. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apache
Martynas Domarkas wrote: > Hi. I would like to use date string in apache log file names. Is there a > way to use some directive in httpd.conf to be parsed as shell command > like `date +%Y%m%d` or some other way to solve the problem? I will use > logrotate mechanism of debian, and this date string could be used only > for file creation after apache process receives SIGUSR1. Grab the cronolog package, its easier and less intrusive. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apache
Martynas Domarkas wrote: > > Thanks, but I realy do not like instalation of another packages. There > must be a way to do this with apache configuration. Martynas Domarkas wrote: > > Thanks a lot. This is nice solution, but I still like apache do the job, > and let logrotate simpy rotate /var/log/apache/*.log. I feel like I have > seen somewhere some piece of shell command in httpd.conf. Martynas Domarkas wrote: > > Yes, of course. But in this case I will invoke rotatelogs... I don't > like it. As, you've exhausted the other possibilites, why not read the fine manual: http://httpd.apache.org/docs/logs.html -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pam doesn't see nis
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204711 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Known vulnerabilities left open in Debian?
Matt Zimmerman wrote: > > If you have concrete information about unfixed bugs, bring it forth. > Otherwise this is just more FUD. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196590 Now. To be fair, these bugs probably aren't the end of the world as long as you understand what all of them are and how to protect yourself, and I don't expect a great number of people are even using the Debian Zope packages. But as more time goes on these bugs are getting harder and harder to keep on top of because there are so many of them and they go so deep that backporting to this version of Zope becomes incredibly non-trivial. Frankly I wish Zope would just be dropped from stable, but I am glad Debian has the sensibilities to air their security bugs openly and not hide them obscurity (like say... the Zope project itself). It gives people the ability to remain informed, and thats ever so important. Still there are times when the project tends to let known holes fester. I find it tends to be worst around a new release. Take for example the mysql crash bug #131921 which was given up for a lost cause. Thankfully I've never seen this happen with a vulnerability that can cause a system compromise in a popular package. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PAM support on potato
Philippe BARNETCHE wrote: > It looks like xdm doesn't support pam. http://people.debian.org/~branden/ take a look at the "Looking Ahead" section > I can't get pam_ldap working (either with login or gdm or kdm) while it's > running great on other distributions. depending on your needs this will cover gdm or not, here's what I use: auth requisite pam_nologin.so auth required pam_env.so auth required pam_ldap.so account required pam_ldap.so session required pam_unix.so password required pam_ldap.so It should be noted that I don't use a pam_unix failover for auth or session because on my workstation there are no valid shell accounts in the password file, outside of root ofcourse who shouldn't be loging in via gdm ever anyway. I haven't had any luck getting the pam_ldap password stuff to work, ymmv. login is more complicated and you should really understand fully what you're doing before you construct a login pam config. But suffice it to say that pam_ldap does work atleast for auth and account. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
Re: PAM support on potato
Wichert Akkerman wrote:
> Shouldn't the auth bit be:
> auth required pam_nologin.so
> auth required pam_env.so
> auth sufficient pam_ldap.so
> auth required pam_unix.so
>
> Otherwise you won't be able to login using local accounts.
Well it would be if I had local accounts, but I don't. Thats what I was
trying to explain when I was talking about why I didn't have a pam_unix
failover. (lousy word I know, I just couldn't think of a better one)
> The current version might be broken; the vesion in potato should work
> just fine.
I'm using the one from potato, everytime I try to get password working it
ends up either asking my password too many times, or simply ignores the
cracklib requirements I've tried to pair it with. Another part of the
problem is also openldap's mandate that the password be encrypted by the
pam module, which while I understand why they did that, is a pain because
now we have to deal with buggy hashing mechanisms in every program that
comes along and wants to change passwords. IIRC pam_ldap fails to put the
{md5} token in front of a generated md5 hash, this is probably fixed in the
more recent versions, I haven't checked. Anyway, I wanted to use salted
SHA and that wasn't supported at all.
If anyone has a working pam_ldap married to cracklib pam configuration for
potato, I'd be interested in seeing it.
--
Jamie Heilman http://audible.transient.net/~jamie/
"I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's
not for you." She was cheap, she was stupid and she wouldn't load
-- well, not for me, anyway." -Holly
Re: nss-ldap security bug
Don't race to install 110-3, it has unresolved symbols. See bug #76018 -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: nss-ldap security bug
The libnns-ldap 122-1 update made it into r1 without ever having an official Security Alert announcement, I dunno how big of a deal this is, but I figured I should dredge it up incase it needed be addressed officially. Anyone? -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: nss-ldap security bug
> I know, it's on the list of things to do. Since it's already in there it > has a lower priority then fixing things that don't have a fix yet > though. Thats cool, it hasn't been compiled for alpha yet either so I guess there's still work to be done. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz
Re: Strange logs for connection
Fran?ois Conza wrote: > I receive this log by mail from my server but dont understand > In my /etc/hosts.deny i have : > > > ALL:ALL:spawn (safe_finger -l @%h | mail -s %u-%c root) &:banners > /usr/local/etc/banners/deny > portmap: ALL you're portmap: ALL rule will never be reached, the first line makes it redundant > This is a mail from my serveur : > > > [212.184.103.11] > Login: operator Name: operator > Directory: /rootShell: /bin/sh > On since Mon Jan 22 08:56 (CET) on pts/0 from 212.93.151.66 > 41 minutes 26 seconds idle > No mail. > No Plan. > > > > That this mean ? I have a back door in my serveur ? > That can i do ? No, this is what safe_finger returned, its part of the output you asked for in your hosts.deny. Some fool at 212.184.103.11 has a finger daemon running, beyond that the information isn't horribly usefull, we don't know that finger daemon is telling you the truth. If you ask me spawning safe_finger is a waste of time, it provides no trustworthy information and generally only alerts a would-be attacker to the fact you have automata that returns a probe when tickled. If you really want to use tcp_wrappers to notify of abnormal access attempts I suggest using something more like this: ALL: ALL: spawn (mail -s "%s access attempt from %h" This is an nmap on my serveur If you don't need it, don't run it. Try identifying all the processes which are using those ports using "lsof" and "netstat -taup" anything you don't need you should disable. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
Re: glibc LD_PRELOAD
Ethan Benson wrote: > is potato vulnerable to the LD_PRELOAD file overwriting vulnerability > discussed at http://www.securityfocus.com/vdb/bottom.html?vid=2223 > > there was an unexplained libc6 update on Jan 10 for i386 (but not > powerpc, not sure about other archs) to security.debian.org, all the > changelog mentions is `Add backported security patch from glibc 2.2' > > current version of libc6 on powerpc is: 2.1.3-13 > current version of libc6 on i386 is: 2.1.3-15 I believe there have been attempts to fix this, atleast in 2.1.3-16 and later. From the 2.1.3-16 changelog: * Ok, include Solar Designers nifty patch for more security issues. Thanks to Solar again for making me do a double release :) -- Ben Collins <[EMAIL PROTECTED]> Sun, 14 Jan 2001 00:30:17 -0500 However 2.1.3-17 exhibits odd behavior which I mentioned to Ben in a private email, though he hasn't got back to me on if its now deemed "normal" or whatever. Basically ldd doesn't work as expected anymore, as illustrated by: [60]polyphony<~/>ls -l /usr/bin/wall -rwxr-sr-x1 root tty 9276 Jul 27 2000 /usr/bin/wall [61]polyphony<~/>ldd /usr/bin/wall y0 wall: /dev/:0: No such file or directory Broadcast Message from [EMAIL PROTECTED] (/dev/pts/4) at 13:20 ... y0 [62]polyphony<~/>sudo su - polyphony:~# ldd /usr/bin/wall hrmmm wall: /dev/:0: No such file or directory Broadcast Message from [EMAIL PROTECTED] (/dev/pts/4) at 13:21 ... hrmmm polyphony:~# I have no idea if this has further reaching consequences, but ldd didn't used to actually execute the programs you ran it on. This seems to only affect sgid applications. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
Re: Send a mail
> Well, I can't tell you how to change the 'from' entry in your MTA. man qmail-inject at any rate none of this is security related -jamie
Re: Debian or Linux 7???
> Just how much more secure is Debian than redhat? Security comes from knowing how to use and administrate Unix, it doesn't just fall into your lap at the press of a button. If you want a secure OS you have to work for it and understand what you're doing. Debian is no more secure than Redhat is no more secure than Solaris is no more secure than OpenBSD. We could make a lot of vague generalizations about default setup and what-not but its really just a waste of time. If you don't want to be hacked, learn how to prevent it. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
Re: OpenSSH and CVS
Matthew H. Ray wrote: > I'm running Debian on a CVS server and have Debian clients. We're using > OpenSSH to replace the rsh calls in CVS. The problem is that every time > a cvs user makes a CVS call (like cvs diff file), they have to enter my > password. I know there's a way around this, but I can't find clear > documentation. If you don't want to enter passwords then you could use RSA keys. (man ssh) However you say - "enter my password" - that smacks of misconfiguration as they should be entering *their* passwords, not yours. Don't expect any system which uses a single account shared among many users to be secure. Also, if you have any wincvs users be sure you set your CVSROOT to something that a) includes the :ext: protocol hint, and b) doesn't include the username. I have found through experience that wincvs is pretty picky about those things, where unix clients aren't. For example a good CVSROOT is :ext:mycvsserver:/mycvs/root/path where as a bad one which will almost certainly make wincvs choke (these get stored in the CVS control files remember) is [EMAIL PROTECTED]:/mycvs/root/path. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: Wrong DNS configuration. Which?
Romanenko M.A. wrote: > Am I right, that sendmail's check_mail rejects connection because there > are no A-record for tgngu.tyumen.ru in other side DNS configuration? Yes, now if you believe this is a desirable configuration or not is another matter, but that is probably what is happening. It might be spam, it might be a misconfiguration on their end. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz
Re: NTP security
Piotr Tarnowski wrote: > If not can I limit allowed clients somehow ? (I noticed that DENY on > ipchains to others than my reference external server limits ntptrace > usage). To the best of my knowledge you can't natively (in the application) control access at the transport level, which is unfortunate. You can at the protocol level however. Get the NTP documentation and read about the authentication options and the access control options. To control access at the transport level you will have to use firewalling rules. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
Re: NTP security
Rishi L Khan wrote: > Maybe use tcp wrappers? That's how I'd do it. Nope, ntpd doesn't link against libwrap and can't be run out of inetd. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
Re: NTP security
> So what is the most secure way of syncing time on a server ? Coupling your server directly to an atomic clock, or some other source of "hard" time, yeilds no network reliance at all, and is the most secure way. Using bug free software is the most secure way to synchronize over a network. ntpd could probably benefit from a good auditing as it is a reference implmentation and those tend to get a rather unwieldy code-base. (BIND being a prime example) > I noticed that /etc/services has a tcp entry for ntp. Is there any way > (short of changing the code) to coax ntp to use tcp instead of udp ? No, UDP is intrinsic to how NTP works. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
Re: NTP security
> See Ultra-Link, http://www.ulio.com/ for a low cost battery powerable > atomic clock radio receiver. It has a 3V inverted TTL RS-232 link > that runs at 2400 or 9600 baud. Power draw is +3.5V to 15V at 600uA. Thats pretty snazzy. > Actually it isn't. A bi-directional link is usually needed, but it Ah I was making my observation based on that NTP seems to be designed around a connectionless protocol that structures itself in a tree-ish format, kinda like DNS, and that a connection based protocol would make the structure too unwieldy. Granted DNS does do some data transfer over TCP but its not generally needed during normal operation. At any rate, it couldn't be done without modifiing the code, and finding somebody else to peer with who also had a modified server. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Re: NTP security
On one of my multihomed machines together with authentication I tend to use something like: restrict default ignore restrict ntpserver1 nomodify restrict ntpserver2 nomodify restrict ntpserver3 nomodify restrict network1 mask netmask1 notrust nomodify restrict network2 mask netmask2 notrust nomodify restrict network3 mask netmask3 restrict 127.0.0.1 Basically this synchronizes time using the 3 server sources and then via a broadcast server config it advertises the time to network1, network2, and network3. network3 however is the only network which administrative requests may be honored from, or localhost. See the other popular thread right now for locking down your interfaces on a ip forwarding machine. Combined with a packet filter this should offer pretty good protection, though it will be somthing you have to watch as your server addresses can change with little warning. On the subject of securing NTP, has anyone gotten the autokey stuff to work the version of ntpd in stable? -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Re: Ports to block?
Nate Duehr wrote: > On Thu, Apr 05, 2001 at 09:38:46PM +0100, Steve Ball wrote: > > If you run a web server then open port 80 tcp, if you have SMTP inbound > > email then open port 25 tcp, if you run your own DNS for your domain > > then open port 53 udp. > > You're going to be upset the first time you hit a site that has enough > information in the DNS response to break the UDP size limit. BIND > will switch to TCP and you will drop the packets. Thats resolving, which uses non-privelged ports. Don't filter on remote ports, its only going to get you in trouble. Back on the server side: If you run a dns server you should know if you need to provide TCP DNS service or not as you know what content your DNS server contains. Most people don't have DNS record sets large enough to trigger a TCP lookup. BIND's zone transfer protocol works over TCP however, so if you're acting as a master you may have to open the tcp port to your slaves. Ofcourse if you're running BIND and you're concerned about security ... There are better servers than BIND and there are better ways to transfer zone information. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Re: Logging practices (and why does it suck in Debian?)
Kenneth Vestergaard Schmidt wrote: > Before I start this, however, I would really like to know if this is just > going to be something I'll do for myself, or if there's anybody else > interested in it? Maybe even design it for inclusion in Debian? I personally > think this should be done, since the default now sucks (to put it mildly). Personally I always redo the standard syslog.conf, but I find it can only be done well if you know what role your machine is going to generally play ahead of time. For example on my workstations I remove the uucp, lpr, and cron entries, because of the programs I traditionaly use those entries never see enough use to justify seperate log files, I just let them get put into the syslog. I also remove the mail logs that are sorted by priority because a) on my workstations I use nullmailers and hence don't generate many logs, and b) on my servers I use qmail w/multilogger. Finally on my servers I always remove the xconsole dump as X has no place on a secure server and hence nobody is going to be looking at that pipe anyway. But then I can do all this because I already know what kind of logs to expect during normal usage and I can "budget" for it. I wouldn't say that my configuration is going to work for everybody. Actually the default debian syslog config is better than many other default configs in that the split is fairly intuitive. OTOH there's something to be said for shipping a lousy a default configuration as it makes people sit down and become more familiar with the software they are using. Syslog and other facility based loggers just generally suck. Thats not really Debian's fault and I'm not really sure what you're going to do about it. Unfortunately facility based logging has become the standard in Unix, even though most of the time its not very usefull. Worse yet syslog just isn't reliable. I run syslog-ng on a few machines but its not much better, though it is an improvement. I think this is mostly because syslog-ng tries too hard to be all things to all people in all situations. Dan Bernstein's multilog program is the only logger I've seen that offers various reliability guarentees and actually delivers on them, but it has some prerequisites for usage that can frequently be difficult to meet. What I'd really like to see is a facility logger that could collect logs like traditional syslog but then would let me hand them to something like multilog to be stored on disk. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz
Re: Logging practices (and why does it suck in Debian?)
Jim Breton wrote: > Some such solutions are intermittently discussed, designed, etc. on the > [EMAIL PROTECTED] list. Suggest you subscribe and hang out for a while. > :) > > http://cr.yp.to/lists.html Really? See now I've just been browsing archives and I didn't see anything so I figured subscribing would be yet another list where I'd watch the same old folks flame the same old newbies... not that I don't find it amusing, I just figured why add another. ;) But hey if somebody's gonna write the glue to stitch facilites and multilog together I'm all for it, especially if somebody else can figure out how to make logger that does reliable and perhaps secure network transport. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Re: psuedonymity and apache
> I am interested in finding a way to make apache be pseudo-anonymous in its > logging. Personally I use the SetEnvIf and CustomLog directives to achieve areas of anonymity on my web site. (not to mention the possible performance savings) Details how to do that are in the apache docs. If you wanted to get relatively anonymous session-ids placed into your log files you could use the mod_usertrack's cookies in your CustomLog delcaration. (again its in the docs) The downside is that cookies are well, cookies, and aren't reliable. There may be a better module out there that places a user-tracker token into the environment, that would be something to look for. The assumption you're making is that an IP can be traced back to a person, I'm not going to argue that this assumption is flawed, but what you're asking for is a way to have your cake (be able to track down abuse to the source) and eat it too (not store the connection info). If its accountability you're trying to avoid no matter what, if you store the IP anywhere, be it encrypted/seperated or not, you've already lost. If you don't want to be able to say 1.2.3.4 connected to /myphatmp3archive/ then don't log it. Even then you're probably screwed as your upstream could conceivably log the activity. If, on the other hand, you just want to display your log files to the world sans the detailed connection information, just post-process them and remove the IP. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
Re: Lprng version question
Wolftales wrote: > Am I running a version that has the fix for the syslog() exploit? Learn how to read a changelog, it will save you a lot of time and worry, from /usr/share/doc/lprng/changelog.Debian.gz: lprng (3.6.12-8) stable; urgency=high * Apparently the upstream lprng 3.6.15 which the setuid test code was * taken from was buggy itself giving lots of false positives!! This code is from 3.6.24 which does work. Closes: #74942, #74946 -- Craig Small <> Tue, 17 Oct 2000 16:35:43 -0500 lprng (3.6.12-7) stable; urgency=high * SECURITY FIXES!! * syslog() overflow bug fixed * getttext NLSPATH security bug fixed. * spool_file_perms security bug fixed. * Added setuid Linux bug work-around. -- Craig Small <> Sun, 15 Oct 2000 15:42:02 -0500 -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz
Re: proftpd exploit??
Zak Kipling wrote: > On Thu, 24 May 2001, Andres Herrera wrote: > > > I've tried to exploit it by login and sending: > > ls ../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../ > > and suddenly it began eating memory and getting slow all the system. > ... > > Any solution?? > > Resource limits on the ftp server process? Or a DenyFilter of \*.*/ as is recommended on the proftpd.org web site. http://www.proftpd.org/critbugs.html -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Re: Bind stop working right.
> It is the bind 1:8.2.3-0.potato.1 > Is there any fixes/know problems to this version? http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=bind >From a security standpoint there are always problems with bind, but no matter, there are much better DNS servers out there. I believe I saw maradns enter unstable a few days ago and you can always snag djbdns from http://cr.yp.to/djbdns.html -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: rlinetd security
> > I do care. I often disable inetd completely, if the server in question > > doesn't need any of what it offers. > > Interesting thought... I wonder if I can get away with that easily? No, you can't if you're plan is to uninstall inetd, the package structure is broken and won't allow it due to $@)!ed up dependancies. I've been trying to do it for ages. Then, when I found equivs I danced a jig. Its pretty much impossible to do in potato, I think you can pull it off in sid/woody though with the help of equivs - I haven't tried as my only unstable box actually needed inetd, and was only accessible from an internal network so I wasn't worried about inetd's underlying flaws wrt DoSability and lack of concurency limiting. If you use inetd on untrusted interface you are asking for pain, I thought that was fairly well understood by now. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
Re: rlinetd security
> >Can't it just be removed with update-rc.d? > > Sure, of course. You just can't delete it from the system entirely, which is > what I would prefer. Exactly, you can do all kinds of things to make sure it isn't enabled, (I usually add exit 0 to the top of the init script) but not having the software isntalled that you don't use is one of the biggest advantages to a binary based distro like Debian. Its the inability to do this at a sufficiently granular level in *BSD that makes me want to punch through walls sometimes. One of the biggest reasons I still evangelize binary distro's and linux. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
Re: rlinetd security
Tim Haynes wrote: > FWIW I heard recently[i] that djbdns never needs TCP. Maybe this is by Not exactly. tinydns only uses port 53 udp axfrdns only uses port 53 tcp - you run this if you a) need to allow zone transfers to legacy systems, b) need to serve large queries, otherwise, you don't need it dnscache uses port 53 both tcp and udp - its the caching resolver -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
Re: rlinetd security
Ted Cabeen wrote: > In other news, the maintainer of netbase is against removing the netbase > dependency on netkit-inetd, but I can't really seem to tell why. I've looked > at his posts on debian-devel and in the BTS, but I haven't found a good > justification for the dependency yet. If anyone does know Anthony's reasons, > I'd like to hear them. I thought about asking why a few months ago, but after reading his responses in the BTS I decided I'd save my breath. There is no good reason afaik, and I'd even go out on a limb and say there is no good reason *period* as I've been running several machines without a working inetd for a year or so now, simply don't have the need for it on most workstations in my situation. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: Strange logs for connection
Fran?ois Conza wrote: > I receive this log by mail from my server but dont understand > In my /etc/hosts.deny i have : > > > ALL:ALL:spawn (safe_finger -l @%h | mail -s %u-%c root) &:banners >/usr/local/etc/banners/deny > portmap: ALL you're portmap: ALL rule will never be reached, the first line makes it redundant > This is a mail from my serveur : > > > [212.184.103.11] > Login: operator Name: operator > Directory: /rootShell: /bin/sh > On since Mon Jan 22 08:56 (CET) on pts/0 from 212.93.151.66 > 41 minutes 26 seconds idle > No mail. > No Plan. > > > > That this mean ? I have a back door in my serveur ? > That can i do ? No, this is what safe_finger returned, its part of the output you asked for in your hosts.deny. Some fool at 212.184.103.11 has a finger daemon running, beyond that the information isn't horribly usefull, we don't know that finger daemon is telling you the truth. If you ask me spawning safe_finger is a waste of time, it provides no trustworthy information and generally only alerts a would-be attacker to the fact you have automata that returns a probe when tickled. If you really want to use tcp_wrappers to notify of abnormal access attempts I suggest using something more like this: ALL: ALL: spawn (mail -s "%s access attempt from %h" This is an nmap on my serveur If you don't need it, don't run it. Try identifying all the processes which are using those ports using "lsof" and "netstat -taup" anything you don't need you should disable. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc LD_PRELOAD
Ethan Benson wrote: > is potato vulnerable to the LD_PRELOAD file overwriting vulnerability > discussed at http://www.securityfocus.com/vdb/bottom.html?vid=2223 > > there was an unexplained libc6 update on Jan 10 for i386 (but not > powerpc, not sure about other archs) to security.debian.org, all the > changelog mentions is `Add backported security patch from glibc 2.2' > > current version of libc6 on powerpc is: 2.1.3-13 > current version of libc6 on i386 is: 2.1.3-15 I believe there have been attempts to fix this, atleast in 2.1.3-16 and later. From the 2.1.3-16 changelog: * Ok, include Solar Designers nifty patch for more security issues. Thanks to Solar again for making me do a double release :) -- Ben Collins <[EMAIL PROTECTED]> Sun, 14 Jan 2001 00:30:17 -0500 However 2.1.3-17 exhibits odd behavior which I mentioned to Ben in a private email, though he hasn't got back to me on if its now deemed "normal" or whatever. Basically ldd doesn't work as expected anymore, as illustrated by: [60]polyphony<~/>ls -l /usr/bin/wall -rwxr-sr-x1 root tty 9276 Jul 27 2000 /usr/bin/wall [61]polyphony<~/>ldd /usr/bin/wall y0 wall: /dev/:0: No such file or directory Broadcast Message from jamie@polyphony (/dev/pts/4) at 13:20 ... y0 [62]polyphony<~/>sudo su - polyphony:~# ldd /usr/bin/wall hrmmm wall: /dev/:0: No such file or directory Broadcast Message from jamie@polyphony (/dev/pts/4) at 13:21 ... hrmmm polyphony:~# I have no idea if this has further reaching consequences, but ldd didn't used to actually execute the programs you ran it on. This seems to only affect sgid applications. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Send a mail
> Well, I can't tell you how to change the 'from' entry in your MTA. man qmail-inject at any rate none of this is security related -jamie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian or Linux 7???
> Just how much more secure is Debian than redhat? Security comes from knowing how to use and administrate Unix, it doesn't just fall into your lap at the press of a button. If you want a secure OS you have to work for it and understand what you're doing. Debian is no more secure than Redhat is no more secure than Solaris is no more secure than OpenBSD. We could make a lot of vague generalizations about default setup and what-not but its really just a waste of time. If you don't want to be hacked, learn how to prevent it. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenSSH and CVS
Matthew H. Ray wrote: > I'm running Debian on a CVS server and have Debian clients. We're using > OpenSSH to replace the rsh calls in CVS. The problem is that every time > a cvs user makes a CVS call (like cvs diff file), they have to enter my > password. I know there's a way around this, but I can't find clear > documentation. If you don't want to enter passwords then you could use RSA keys. (man ssh) However you say - "enter my password" - that smacks of misconfiguration as they should be entering *their* passwords, not yours. Don't expect any system which uses a single account shared among many users to be secure. Also, if you have any wincvs users be sure you set your CVSROOT to something that a) includes the :ext: protocol hint, and b) doesn't include the username. I have found through experience that wincvs is pretty picky about those things, where unix clients aren't. For example a good CVSROOT is :ext:mycvsserver:/mycvs/root/path where as a bad one which will almost certainly make wincvs choke (these get stored in the CVS control files remember) is user@mycvsserver:/mycvs/root/path. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wrong DNS configuration. Which?
Romanenko M.A. wrote: > Am I right, that sendmail's check_mail rejects connection because there > are no A-record for tgngu.tyumen.ru in other side DNS configuration? Yes, now if you believe this is a desirable configuration or not is another matter, but that is probably what is happening. It might be spam, it might be a misconfiguration on their end. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NTP security
Piotr Tarnowski wrote: > If not can I limit allowed clients somehow ? (I noticed that DENY on > ipchains to others than my reference external server limits ntptrace > usage). To the best of my knowledge you can't natively (in the application) control access at the transport level, which is unfortunate. You can at the protocol level however. Get the NTP documentation and read about the authentication options and the access control options. To control access at the transport level you will have to use firewalling rules. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NTP security
Rishi L Khan wrote: > Maybe use tcp wrappers? That's how I'd do it. Nope, ntpd doesn't link against libwrap and can't be run out of inetd. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NTP security
> So what is the most secure way of syncing time on a server ? Coupling your server directly to an atomic clock, or some other source of "hard" time, yeilds no network reliance at all, and is the most secure way. Using bug free software is the most secure way to synchronize over a network. ntpd could probably benefit from a good auditing as it is a reference implmentation and those tend to get a rather unwieldy code-base. (BIND being a prime example) > I noticed that /etc/services has a tcp entry for ntp. Is there any way > (short of changing the code) to coax ntp to use tcp instead of udp ? No, UDP is intrinsic to how NTP works. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NTP security
> See Ultra-Link, http://www.ulio.com/ for a low cost battery powerable > atomic clock radio receiver. It has a 3V inverted TTL RS-232 link > that runs at 2400 or 9600 baud. Power draw is +3.5V to 15V at 600uA. Thats pretty snazzy. > Actually it isn't. A bi-directional link is usually needed, but it Ah I was making my observation based on that NTP seems to be designed around a connectionless protocol that structures itself in a tree-ish format, kinda like DNS, and that a connection based protocol would make the structure too unwieldy. Granted DNS does do some data transfer over TCP but its not generally needed during normal operation. At any rate, it couldn't be done without modifiing the code, and finding somebody else to peer with who also had a modified server. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NTP security
On one of my multihomed machines together with authentication I tend to use something like: restrict default ignore restrict ntpserver1 nomodify restrict ntpserver2 nomodify restrict ntpserver3 nomodify restrict network1 mask netmask1 notrust nomodify restrict network2 mask netmask2 notrust nomodify restrict network3 mask netmask3 restrict 127.0.0.1 Basically this synchronizes time using the 3 server sources and then via a broadcast server config it advertises the time to network1, network2, and network3. network3 however is the only network which administrative requests may be honored from, or localhost. See the other popular thread right now for locking down your interfaces on a ip forwarding machine. Combined with a packet filter this should offer pretty good protection, though it will be somthing you have to watch as your server addresses can change with little warning. On the subject of securing NTP, has anyone gotten the autokey stuff to work the version of ntpd in stable? -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ports to block?
Nate Duehr wrote: > On Thu, Apr 05, 2001 at 09:38:46PM +0100, Steve Ball wrote: > > If you run a web server then open port 80 tcp, if you have SMTP inbound > > email then open port 25 tcp, if you run your own DNS for your domain > > then open port 53 udp. > > You're going to be upset the first time you hit a site that has enough > information in the DNS response to break the UDP size limit. BIND > will switch to TCP and you will drop the packets. Thats resolving, which uses non-privelged ports. Don't filter on remote ports, its only going to get you in trouble. Back on the server side: If you run a dns server you should know if you need to provide TCP DNS service or not as you know what content your DNS server contains. Most people don't have DNS record sets large enough to trigger a TCP lookup. BIND's zone transfer protocol works over TCP however, so if you're acting as a master you may have to open the tcp port to your slaves. Ofcourse if you're running BIND and you're concerned about security ... There are better servers than BIND and there are better ways to transfer zone information. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logging practices (and why does it suck in Debian?)
Kenneth Vestergaard Schmidt wrote: > Before I start this, however, I would really like to know if this is just > going to be something I'll do for myself, or if there's anybody else > interested in it? Maybe even design it for inclusion in Debian? I personally > think this should be done, since the default now sucks (to put it mildly). Personally I always redo the standard syslog.conf, but I find it can only be done well if you know what role your machine is going to generally play ahead of time. For example on my workstations I remove the uucp, lpr, and cron entries, because of the programs I traditionaly use those entries never see enough use to justify seperate log files, I just let them get put into the syslog. I also remove the mail logs that are sorted by priority because a) on my workstations I use nullmailers and hence don't generate many logs, and b) on my servers I use qmail w/multilogger. Finally on my servers I always remove the xconsole dump as X has no place on a secure server and hence nobody is going to be looking at that pipe anyway. But then I can do all this because I already know what kind of logs to expect during normal usage and I can "budget" for it. I wouldn't say that my configuration is going to work for everybody. Actually the default debian syslog config is better than many other default configs in that the split is fairly intuitive. OTOH there's something to be said for shipping a lousy a default configuration as it makes people sit down and become more familiar with the software they are using. Syslog and other facility based loggers just generally suck. Thats not really Debian's fault and I'm not really sure what you're going to do about it. Unfortunately facility based logging has become the standard in Unix, even though most of the time its not very usefull. Worse yet syslog just isn't reliable. I run syslog-ng on a few machines but its not much better, though it is an improvement. I think this is mostly because syslog-ng tries too hard to be all things to all people in all situations. Dan Bernstein's multilog program is the only logger I've seen that offers various reliability guarentees and actually delivers on them, but it has some prerequisites for usage that can frequently be difficult to meet. What I'd really like to see is a facility logger that could collect logs like traditional syslog but then would let me hand them to something like multilog to be stored on disk. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logging practices (and why does it suck in Debian?)
Jim Breton wrote: > Some such solutions are intermittently discussed, designed, etc. on the > [EMAIL PROTECTED] list. Suggest you subscribe and hang out for a while. > :) > > http://cr.yp.to/lists.html Really? See now I've just been browsing archives and I didn't see anything so I figured subscribing would be yet another list where I'd watch the same old folks flame the same old newbies... not that I don't find it amusing, I just figured why add another. ;) But hey if somebody's gonna write the glue to stitch facilites and multilog together I'm all for it, especially if somebody else can figure out how to make logger that does reliable and perhaps secure network transport. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: psuedonymity and apache
> I am interested in finding a way to make apache be pseudo-anonymous in its > logging. Personally I use the SetEnvIf and CustomLog directives to achieve areas of anonymity on my web site. (not to mention the possible performance savings) Details how to do that are in the apache docs. If you wanted to get relatively anonymous session-ids placed into your log files you could use the mod_usertrack's cookies in your CustomLog delcaration. (again its in the docs) The downside is that cookies are well, cookies, and aren't reliable. There may be a better module out there that places a user-tracker token into the environment, that would be something to look for. The assumption you're making is that an IP can be traced back to a person, I'm not going to argue that this assumption is flawed, but what you're asking for is a way to have your cake (be able to track down abuse to the source) and eat it too (not store the connection info). If its accountability you're trying to avoid no matter what, if you store the IP anywhere, be it encrypted/seperated or not, you've already lost. If you don't want to be able to say 1.2.3.4 connected to /myphatmp3archive/ then don't log it. Even then you're probably screwed as your upstream could conceivably log the activity. If, on the other hand, you just want to display your log files to the world sans the detailed connection information, just post-process them and remove the IP. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lprng version question
Wolftales wrote: > Am I running a version that has the fix for the syslog() exploit? Learn how to read a changelog, it will save you a lot of time and worry, from /usr/share/doc/lprng/changelog.Debian.gz: lprng (3.6.12-8) stable; urgency=high * Apparently the upstream lprng 3.6.15 which the setuid test code was * taken from was buggy itself giving lots of false positives!! This code is from 3.6.24 which does work. Closes: #74942, #74946 -- Craig Small <> Tue, 17 Oct 2000 16:35:43 -0500 lprng (3.6.12-7) stable; urgency=high * SECURITY FIXES!! * syslog() overflow bug fixed * getttext NLSPATH security bug fixed. * spool_file_perms security bug fixed. * Added setuid Linux bug work-around. -- Craig Small <> Sun, 15 Oct 2000 15:42:02 -0500 -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bind stop working right.
> It is the bind 1:8.2.3-0.potato.1 > Is there any fixes/know problems to this version? http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=bind >From a security standpoint there are always problems with bind, but no matter, there are much better DNS servers out there. I believe I saw maradns enter unstable a few days ago and you can always snag djbdns from http://cr.yp.to/djbdns.html -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
> > I do care. I often disable inetd completely, if the server in question > > doesn't need any of what it offers. > > Interesting thought... I wonder if I can get away with that easily? No, you can't if you're plan is to uninstall inetd, the package structure is broken and won't allow it due to $@)!ed up dependancies. I've been trying to do it for ages. Then, when I found equivs I danced a jig. Its pretty much impossible to do in potato, I think you can pull it off in sid/woody though with the help of equivs - I haven't tried as my only unstable box actually needed inetd, and was only accessible from an internal network so I wasn't worried about inetd's underlying flaws wrt DoSability and lack of concurency limiting. If you use inetd on untrusted interface you are asking for pain, I thought that was fairly well understood by now. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
Tim Haynes wrote: > FWIW I heard recently[i] that djbdns never needs TCP. Maybe this is by Not exactly. tinydns only uses port 53 udp axfrdns only uses port 53 tcp - you run this if you a) need to allow zone transfers to legacy systems, b) need to serve large queries, otherwise, you don't need it dnscache uses port 53 both tcp and udp - its the caching resolver -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
Ted Cabeen wrote: > In other news, the maintainer of netbase is against removing the netbase > dependency on netkit-inetd, but I can't really seem to tell why. I've looked > at his posts on debian-devel and in the BTS, but I haven't found a good > justification for the dependency yet. If anyone does know Anthony's reasons, > I'd like to hear them. I thought about asking why a few months ago, but after reading his responses in the BTS I decided I'd save my breath. There is no good reason afaik, and I'd even go out on a limb and say there is no good reason *period* as I've been running several machines without a working inetd for a year or so now, simply don't have the need for it on most workstations in my situation. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using BIND in a chroot enviro?
I'm not sure its even worth mentioning this, but its a thread on security and BIND, so here's the ob. plug for Something Better(tm): http://cr.yp.to/djbdns.html In this case the only thing needed is a single instance of dnscache listening on an internal interface, no need to open up your network further at all. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using BIND in a chroot enviro?
> forget it. > 1. non-free Certainly, that is something to consider, if your prejudice is that way bent. I tend to judge software more on its technical merit than on its distribution policies. At any rate, maradns is of similar design, and it is DFSG compliant, if you want yet another alternative. > 2. author write like "alle shit then my" Uh, sure. > it can't resolv over tcp witch is need if payload break a spezified > length limit > > also bind9 can make this also You clearly don't understand what this person was asking for, or what dnscache is capable of. There seem to be a lot of people waving the 53/tcp flag lately like its some kind of huge bogon that you have to watch out for when you're building your firewall rules. I assure you, its not, its really quite simple. If, like the person who started the thread, you are simply trying to utilize a local caching resolver to speed up your DNS queries, you don't need to worry about port 53 on your external interface AT ALL and you can completely firewall it off. If your upstream ISP only accepts queries from source port 53, they are stupid and you'd be best off finding a better ISP, or just doing all the resolving yourself (probably more secure that way anyhow depending on how much you trust your upstream's DNS cache configuration). If, on the other hand, you are serving DNS records to the world at large, you already know perfectly well if you have records over 512 bytes that will require tcp transport or not, or if you need to allow zone transfers to outside parties, so the question of if you need to allow 53/tcp is already decided, all you have to do is recognise that fact. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using BIND in a chroot enviro?
Tim Haynes wrote: > H. I dislike the word `prejudice' there, even if it does sum my > approach to non-free up very well. I understand that feeling, I have it myself, its why I used the term. I'm not gonna let myself off the hook anymore than anyone else, I get on my soapbox regularly and rant against having any NT machines at my place of employment for much the same reason. And I have total knee-jerk reactions when people talk about using this or that proprietary solution. We all have prejudices, I feel its usefull to recognise and be comfortable with that fact, so I can take it into account when I'm trying to be impartial about something. > Technical merits are of stuff-all use if the software can't be > redistributed freely in sensible packages. "Well thats just like, your opinion, man." ;) (here's to hoping you've seen The Big Lebowski) > > > 2. author write like "alle shit then my" > > > > Uh, sure. > > Whatever the quote means, I don't need *another* DJB-war barely a fortnight > after the last one. Aww, but they contain the same addictive chemical found in the Colonel's chicken! Yeah anyway, I just didn't understand the quote either. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Apache, mod_auth_pam, pam_krb4, and you
> I'm going slowly insane trying to convince Apache to pass a user/pass to > pam_krb4, thereby validating a user for entrance into a secure directory. Is > it too much to hope for that it's this simple? I haven't used that module before, but I would suggest making sure you have a /etc/pam.d/other ruleset that looks similar to: auth required pam_deny.so auth required pam_warn.so account required pam_deny.so account required pam_warn.so password required pam_deny.so password required pam_warn.so session required pam_deny.so session required pam_warn.so This will make things which fall through other pam rules complain loudly in the logs and reject any [auth/account/password/session] attempts without explicit rules. Its not only handy for debugging but its also probably not a bad default configuration, I rather wish pam was distributed this way as a stock config, but I gather its not "traditional." Anyway, it may help you figure out whats wrong, it may not - I tend to find looking at the source code for pam modules mandatory when debugging problems like that, many times there is a squirled away debug option which can bring more things to light. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: snort 's logs go to /var/log/auth.log for some reason?
Dmitriy wrote: > How can I change this? man snort, note -s option man syslog.conf -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why do people do this? [Was fishingboat in root]
Jason Thomas wrote: > maybe ask the maintainer of the package to change it to something > meaningful! better yet, uninstall the package and boycott stupid behavior -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: crc32 compensation attack
Micah Anderson wrote: > Got what appears to be a "crc32 compensation attack in my logs today, > about 10 minutes worth of these types of messages should I be > worried? Should I laugh at this feable attempt to break in? Should I > gnaw my fingernails with my shotgun on my lap? heh, http://www.plif.com/archive/wc055.gif I would be worried that somebody is interested in your ssh sessions. I would be less worried that they were able to successfully compromise the session, but check the source code for that message so you can find out where it was generated and what the attacker may have been trying to do. (I would have closed the session as soon as I saw this myself though just to be on the safe side.) There was a theoretical attack against the crc32 compensation attack detector itself a while back, this might be what you saw. http://razor.bindview.com/publish/advisories/adv_ssh1crc.html -jamie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Exim mail
Daniel Rychlik wrote: > How do I stop this from happening. Apparently my bud telented to port 25 > and somehow sent mail from my root account. Any suggestions, white papers > or links? Id would like to block the telnet application all together, but I > dont think thats possible. He didn't use your root account, he used the nature of SMTP to trick you. http://rfc821.x42.com/ And no, you can't block telnet, unless you choose to not run a mail server at all. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [2] Mailserver HDD organization
[EMAIL PROTECTED] wrote: > now i have tried postfix and exim and i like both. > But wich is more secure? any body some knowledge about that? postfix has a better, more security concious, design -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Un-installing inetd on Woody.
Stefan Srdic wrote: > Hi, > > I'm running Woody at home and have no use for the inetd deamon. I > have tried to un-install the package which provides inetd > (netkit-inetd), but it depends on package netbase so if I remove > nekit-inetd I lose netbase. > > How can I circumvent this problem? apt-get install equivs -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using BIND in a chroot enviro?
I'm not sure its even worth mentioning this, but its a thread on security and BIND, so here's the ob. plug for Something Better(tm): http://cr.yp.to/djbdns.html In this case the only thing needed is a single instance of dnscache listening on an internal interface, no need to open up your network further at all. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: Using BIND in a chroot enviro?
> forget it. > 1. non-free Certainly, that is something to consider, if your prejudice is that way bent. I tend to judge software more on its technical merit than on its distribution policies. At any rate, maradns is of similar design, and it is DFSG compliant, if you want yet another alternative. > 2. author write like "alle shit then my" Uh, sure. > it can't resolv over tcp witch is need if payload break a spezified > length limit > > also bind9 can make this also You clearly don't understand what this person was asking for, or what dnscache is capable of. There seem to be a lot of people waving the 53/tcp flag lately like its some kind of huge bogon that you have to watch out for when you're building your firewall rules. I assure you, its not, its really quite simple. If, like the person who started the thread, you are simply trying to utilize a local caching resolver to speed up your DNS queries, you don't need to worry about port 53 on your external interface AT ALL and you can completely firewall it off. If your upstream ISP only accepts queries from source port 53, they are stupid and you'd be best off finding a better ISP, or just doing all the resolving yourself (probably more secure that way anyhow depending on how much you trust your upstream's DNS cache configuration). If, on the other hand, you are serving DNS records to the world at large, you already know perfectly well if you have records over 512 bytes that will require tcp transport or not, or if you need to allow zone transfers to outside parties, so the question of if you need to allow 53/tcp is already decided, all you have to do is recognise that fact. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
Re: Using BIND in a chroot enviro?
Tim Haynes wrote: > H. I dislike the word `prejudice' there, even if it does sum my > approach to non-free up very well. I understand that feeling, I have it myself, its why I used the term. I'm not gonna let myself off the hook anymore than anyone else, I get on my soapbox regularly and rant against having any NT machines at my place of employment for much the same reason. And I have total knee-jerk reactions when people talk about using this or that proprietary solution. We all have prejudices, I feel its usefull to recognise and be comfortable with that fact, so I can take it into account when I'm trying to be impartial about something. > Technical merits are of stuff-all use if the software can't be > redistributed freely in sensible packages. "Well thats just like, your opinion, man." ;) (here's to hoping you've seen The Big Lebowski) > > > 2. author write like "alle shit then my" > > > > Uh, sure. > > Whatever the quote means, I don't need *another* DJB-war barely a fortnight > after the last one. Aww, but they contain the same addictive chemical found in the Colonel's chicken! Yeah anyway, I just didn't understand the quote either. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
Re: Apache, mod_auth_pam, pam_krb4, and you
> I'm going slowly insane trying to convince Apache to pass a user/pass to > pam_krb4, thereby validating a user for entrance into a secure directory. Is > it too much to hope for that it's this simple? I haven't used that module before, but I would suggest making sure you have a /etc/pam.d/other ruleset that looks similar to: auth required pam_deny.so auth required pam_warn.so account required pam_deny.so account required pam_warn.so password required pam_deny.so password required pam_warn.so session required pam_deny.so session required pam_warn.so This will make things which fall through other pam rules complain loudly in the logs and reject any [auth/account/password/session] attempts without explicit rules. Its not only handy for debugging but its also probably not a bad default configuration, I rather wish pam was distributed this way as a stock config, but I gather its not "traditional." Anyway, it may help you figure out whats wrong, it may not - I tend to find looking at the source code for pam modules mandatory when debugging problems like that, many times there is a squirled away debug option which can bring more things to light. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way way without saying squat and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Re: snort 's logs go to /var/log/auth.log for some reason?
Dmitriy wrote: > How can I change this? man snort, note -s option man syslog.conf -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Re: Why do people do this? [Was fishingboat in root]
Jason Thomas wrote: > maybe ask the maintainer of the package to change it to something > meaningful! better yet, uninstall the package and boycott stupid behavior -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
Re: crc32 compensation attack
Micah Anderson wrote: > Got what appears to be a "crc32 compensation attack in my logs today, > about 10 minutes worth of these types of messages should I be > worried? Should I laugh at this feable attempt to break in? Should I > gnaw my fingernails with my shotgun on my lap? heh, http://www.plif.com/archive/wc055.gif I would be worried that somebody is interested in your ssh sessions. I would be less worried that they were able to successfully compromise the session, but check the source code for that message so you can find out where it was generated and what the attacker may have been trying to do. (I would have closed the session as soon as I saw this myself though just to be on the safe side.) There was a theoretical attack against the crc32 compensation attack detector itself a while back, this might be what you saw. http://razor.bindview.com/publish/advisories/adv_ssh1crc.html -jamie
Re: Exim mail
Daniel Rychlik wrote: > How do I stop this from happening. Apparently my bud telented to port 25 > and somehow sent mail from my root account. Any suggestions, white papers > or links? Id would like to block the telnet application all together, but I > dont think thats possible. He didn't use your root account, he used the nature of SMTP to trick you. http://rfc821.x42.com/ And no, you can't block telnet, unless you choose to not run a mail server at all. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
Re: [2] Mailserver HDD organization
[EMAIL PROTECTED] wrote: > now i have tried postfix and exim and i like both. > But wich is more secure? any body some knowledge about that? postfix has a better, more security concious, design
