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]
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: 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: 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
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
Re: sources.list for potato
Wichert Akkerman wrote: > Previously Olaf Meeuwissen wrote: > > For a truly stable Debian system, drop > > deb http://http.us.debian.org/debian dists/potato-proposed-updates/ > > I wouldn't recommend that, on occasion a package makes it into > proposed-updates that really should not be installed on a potato reason > for some reason. Yeah, I second that. If you're going to poke around in prosposed-updates you should do it on a machine that isn't in production, sometimes things like bug #121305 happen. Speaking of which, Wichert, as OpenLDAP is your baby now, you wanna close that old bug out? Ben never did and its pretty much moot now as that bad package never made it into primetime. -- 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 chunk handling vulnerability and Apache 1.3.24-3
> Can someone clarify for me, please (not directly debian related, I know, > but...) - the patches appear to only be to the chunk-encoding functions > in mod_proxy. If mod_proxy isn't loaded, is apache still vulnerable? its not just mod_proxy, apache was vulnerable regardless -- 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: [d-security] Re: Apache chunk handling vulnerability and Apache 1.3.24-3
Christian Hammers wrote: > On Sat, Jun 22, 2002 at 11:50:10PM -0700, Jamie Heilman wrote: > > its not just mod_proxy, apache was vulnerable regardless > BTW: in the case that mod_proxy is not loaded: is it enough to just > backport the get_chunk_size function from http_protocol.c (like in the > file debian/patches/cert_vucert944335) to earlier versions to fix the > vulnerability or is there more? I would say yes, in the case where mod_proxy isn't loaded. -- 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: Permissions Required On hosts.allow ?
> So I've opened perms up to 644 again, but this seems the wrong thing > to do. I realise I was only gaining a minor layer of > security-thru-obscurity, but every little helps - surely we don't > want this file to be world-readable ? > > I note from inetd.conf that in.telnetd runs as uid.gid > telnetd.telnetd, whereas hosts.allow has uid.gid root.root, which I > guess is the cause of this. correct > Can I change this around a bit to achieve my goal - maybe make a new > group called "foo" (say) and give that gid to in.telnetd and > hosts.allow ... ? Obscuring your libwrap/tcpd configuration from your local users, at the expense of allowing services to run as seperate, non-privileged users is a bad idea. Privilege seperation provides a very tangible benefit, obfuscated config files do not. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
Re: Permissions Required On hosts.allow ?
Nick Boyce wrote: > Yep - that's just the sort of thing I had in mind - I can't see a > problem with it if all the new GID does is grant read access to the > tcp wrappers config files. [ I just realized one more ingredient > required is to make the relevant service daemons sgid tcpwrap as well > as members of it. ] Add water, makes its own sauce. > But I realize this stuff is tricky, and there may be some unforeseen > consequence that only a thorough knowledge of the source code (which I > don't have) can elicit - that's why I sought comments :) Its not that tricky, but its also not that broken. There are several approaches to system hardening. You can keep going down the path of absolutely minimal access rights, and eventually you'll end up with some sort of ACL system, and thats just fine, for the things that need it. There are several projects that do this, they all help make your system hard to crack/use/maintain, depending on your perspective. Wirex has something I that may or may not be called SubDomain, SELinux has some access control I believe, and there's probably others out there. And if you need to enforce a strict security model, these are probably the most apropos approach. What you're doing by creating a new supplementary group, is unnecessarily opening up a can of worms wrt the maintenance of your server. I would suggest that if you plan on participating in the active maintenance of your machine you should consider the value of simplicity over sheer paranoia. Lets assume you ignore me (which is just fine) and implement the supplementary group access control. Now to use tcpd, libwrap, tcpdchk, tcpdmatch, etc., a program's runtime privileges must include your supplementary group, or be those of the superuser. Obviously we can throw out programs that have superuser privs as having problems with this scheme. So you're left with the implication of a call to setgroups(2) or possibly initgroups(3), or it could mean the program is running with your new group as its primary group. Well running all your services with the new group as the primary one is going to be problematic. As you postulated not every service will work if you change its primary group, and perhaps more concerning is the amount of custom configuration you're going to have to maintain to set up a new primary group for a bunch of various daemons. On to the supplementary groups; both setgroups and initgroups require superuser privileges. Thus all services which want to use tcp wrappers must be started by a process with superuser privileges. Depending on which services you want to use this may or may not be an immediate issue. Services which require a privileged port usually already start as superuser so they probably won't be affected, provided they actually bother to call setgroups. I checked, and netkit-inetd does, so that clears you for everything that wants to use tcpd from netkit-inetd. (As an aside, the netkit-inetd shipped with Debian doesn't bother to check the !#$%ing return code though, which is lame, and incidentally, was reported over a year ago in bug #100186. If the OpenBSD inetd actually makes its way in as a replacement this issue, not to mention a host of other inadequacies, would hopefully be resolved.) Are there initially-privileged daemons which don't call setgroups? As I recall python didn't even support that syscall until recently, I'd say its possible this could bite you, though perhaps unlikely. As for programs which aren't initially privileged and want to use libwrap - they just won't work. (You may be surprised how many of those there are, use apt-cache to browse the reverse depends on libwrap0.) Keeping all this mind while you modify and update your server configuration over time, I mean hey, thats what makes this fun right? All that aside, if you run a fairly modest server without too many oddball requirements, you can probably make the supplementary groups hack work with relatively low pain. You've bought yourself a bit more maintenance overhead, and you haven't altered your fundamental vulnerability to compromise at all (by which I mean if the services you run and the configurations you run them with actually have exploitable bugs in them or not), but hey, at least your users won't be able to read those files. And thats, um, something. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
Re: Permissions Required On hosts.allow ?
> He can probably reduce the pain somewhat by using cfengine to > rewrite protections and ownerships. That way if he updates the > next cfengine run will set everything to spec. Otherwise his > life will be an eternal priv violation chase. Thats an idea, increased security vis-a-vis increased infrastructure. -- 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: Permissions Required On hosts.allow ?
Joe Moore wrote: > As to your later message: > setgroups() and initgroups() are not necessary. Already UID telnetd is able > to write to /var/run/utmp because of its membership in GID utmp. Huh? > If they run as a user not listed for tcpwrap (such as an interactive > user), they will not be able to read /etc/hosts.allow. This may be a very > good thing: > > If /etc/hosts.allow is unreadable, and /etc/hosts.deny has ALL:ALL, tcpwrap > will prevent all connections. This is desirable if you want a more secure > system. This means that if you have not added telnetd to the tcpwrap group, > in.telnetd will not accept connections from anywhere, even if it's > accidentally (or intentionally) started (by a malicious? user) !!! Talk about a convoluted approach. If you want services which happen to use tcp wrappers and which happen to have been started without your knowledge to reject connections by default just don't use wildcards (ALL:) in hosts.allow. List every daemon explicitly. Don't rely on the side effects of misconfiguration to do something that the framework already allows. I'll say this one more time: the system isn't that broken, stop trying to fix it. There is no legitimate reason to jump through all these hoops just to hide your tcp wrappers configuration from your local users. If the requirements for your host dictate minimal access rights use an access control system thats been designed to achieve it without creating a huge mess. -- 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: Permissions Required On hosts.allow ?
Joe Moore wrote: > Jamie Heilman wrote: > > Joe Moore wrote: > >> As to your later message: > >> setgroups() and initgroups() are not necessary. Already UID telnetd > >> is able to write to /var/run/utmp because of its membership in GID > >> utmp. > > > > Huh? > > Telnetd does not run as root. However, it needs to write login entries into > /var/run/utmp. How does it do this? The UID telnetd is listed as a group > member of group "utmp". The /var/run/utmp file is owned root:utmp, and is > group-writable. in.telnetd can write utmp entries. OK, but this in no way makes setgroups() unnecessary, which is why I was confused by your earlier statement. telnetd's privileges are bestowed by the inetd process, using, amongst other things, setgroups(). > >> If /etc/hosts.allow is unreadable, and /etc/hosts.deny has > >> ALL:ALL, tcpwrap will prevent all connections. This is desirable > >> if you want a more secure system. > > > > List every daemon explicitly. Don't rely on the side effects of > > misconfiguration to do something that the framework already > > allows. > > This side-effect is not a primary purpose. I'm not debating if its primary or not, I'm mearly pointing out you aren't adding extra security to the system that wasn't already present in the stock configuration. > It would be just as easy for the malicious user to not link > libtcpwrap.so into their executable. This malicious user scenario is a strawman, there is no need to discuss it. Accidental daemon starting is, unfortunately, a bit more relevant given Debian's policy to run whatever has been installed by default. (Note, I'm not challenging this policy, it is what it is.) -- 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: Permissions Required On hosts.allow ?
> I come to the Land Of Unix from mainframes, where I used to earn my > crust. The mainframes had a tight security lockdown from out of the > box (or truck, as the case usually was of course :). I kind of guessed as much. Yours is not an usual desire. > I'd be very interested to hear about any such options in the Linux > world. AFAIK, Linux ACL facilities are still experimental > (http://packages.debian.org/testing/admin/kernel-patch-acl.html) Most things in the realm of tighter access control are experimental, and tend to stay that way for a long time due, probably, to the lack of cohesion behind the various movements. But as I mentioned before, you'll probably want to examine subdomain from Wirex, SELinux, maybe LIDS, RSBAC, and doubtless there are others, but I'd start with those. -- 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: "suspicious" apache log entries
> [Sat Aug 31 21:03:49 2002] [error] [client 64.152.12.2] request failed: > erroneous characters after protocol string: CONNECT > mailb.microsoft.com:25 / HTTP/1.0 open proxy probe, standard Internet crapola, http://www.monkeys.com/security/proxies/
Re: "suspicious" apache log entries
Jamie Heilman wrote: > > [Sat Aug 31 21:03:49 2002] [error] [client 64.152.12.2] request failed: > > erroneous characters after protocol string: CONNECT > > mailb.microsoft.com:25 / HTTP/1.0 > > open proxy probe, standard Internet crapola, > http://www.monkeys.com/security/proxies/ Hmm, ok it appears all the links off that page are 404s, guess I should have checked that before I replied, anyway, I think you're guess was right, just somebody trying to abuse a hole in a weak proxy. -- 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
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
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]
