Re: inuring FreeBSD to the apache bug without upgrading apache ?
On Thu, 20 Jun 2002 19:59:20 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Patrick Thomas wrote: Is it possible to patch/recompile FreeBSD 4.5 in such a way that your system is no longer vulnerable to the chunking attack, even if you are still running a vulnerable apache ? Why not upgrade Apache...?? Both the 1 and 2 series have been updated I think. (I'm a newbie at server stuff, so bear with me if I made a faux pas.) The way you would deal with this would be to tell Apache that it was an HTTP 1.0 server, since chunking is an HTTP 1.1 feature. The only place this is an issue is if you need to reuse an HTTP connection, and that only occurs in HTTP 1.1 when you are doing pipelining. Everywhere else, you can indicate an end of data Mozilla has an option to enable http pipelining as a performance option. I regularly used this, maybe I shouldn't? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
I think that libsafe would protect against this bug to at least prevent against any possible malicious code execution. I think it still leaves the DoS possibility open though... Even some kind of non-exec stack protection patched into FBSD would only generate a SEGV if it got triggered[*]. Very hard to stop the DoS. [*] and yes does nothing to prevent against malicious code execution attacks on x86 architecture either, only obscures... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Thu, 20 Jun 2002, Terry Lambert wrote: Lamont Granquist wrote: Cyrus imapd is a real pain in the ass to administer local user accounts with though. You mean that it doesn't integrate well with the UNIX credentials system. THe issue here is that Cyrus needs to be able to hook create/delete actions on accounts, and UNIX fails to provide a means of doing this. I look at this as a UNIX deficiency. You can actually get around it by using pw and utilizing the script hooks it has. Well, that's trying to place blame on how it should get fixed. From my perspective I don't care, it is just more difficult to use. The easiest real fix for this would be to write a PAM module to cause the UNIX users to authenticate against the Cyrus database. Creating mailboxes is also a PITA, I like procmail to be able to do this and not have a 2nd configuration step... The cyradm program is extremely deficient. Not a big issue, I think. Writing scripts to encapsulate it and be less deficient is really very trivial. Yeah, these days I don't have that much time to script... If I did have more scripting time, I'd be fixing more shit at work to help me sleep through the night when I'm on call... Its great if you want to offer people imap e-mail without offering them shell access. For local access, though, there's a higher administrative overhead. I'm back to using the UW imapd even though I know it is a poorer codebase... I recommend you do not publicize the IP addresses of the servers, if they are net accessible outside your organization. 8-). Nope. Well protected by firewall in one case, and I'll be updating my ipf rules when I convert scriptkiddie... I never use remote IMAP anyways... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Limiting clients per source IP address (ftpd, inetd, etc.)
Luigi Rizzo wrote: On Thu, Jun 20, 2002 at 08:25:28PM -0700, Terry Lambert wrote: Giorgos Keramidas wrote: I've been thinking for quite some time to add per-client-IP limiting to ftpd, and I had almost decided upon something like the following, ... Someone just did something similar for inetd (per IP per port). The more I think about this, and the fact that there is code growing to do basically the same thing in every program, the more I think that the code to do this needs to be centralized. in fact there is an ipfw rule which does just this: ipfw add allow ip from any to any limit src-addr 5 and here you go... Can this be done per port? THis is what both the FTP and the inetd modification movements have been about... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Limiting clients per source IP address (ftpd, inetd, etc.)
On Thu, Jun 20, 2002 at 11:58:10PM -0700, Terry Lambert wrote: ... in fact there is an ipfw rule which does just this: ipfw add allow ip from any to any limit src-addr 5 and here you go... Can this be done per port? THis is what both the FTP and the inetd modification movements have been about... ipfw add allow ip from any to any limit src-addr src-port 5 (you can select a subset of the src-addr src-port dst-addr dst-port as the match mask to determine if connections belong to the same group. With the new ipfw code that i have posted it should be trivial to extend the match mask to use real bitmasks (so you can limit per-subnet, per port ranges, etc etc.) BTW in terms of implementation efficiency: this limit thing uses the same hash table used by dynamic ipfw rules. There is currently an (arbitrary) limit of a total of 1000 dynamic entries in the table, but no reason not to raise it much higher if you have memory. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: multiple gateways
Peter J. Blok writes: I know this topic has been brought up numerous times. I have 4 IP4 internal networks (sf0 .. sf3) I have a cable modem connection ep0 and a DSL ep1 connection too. I'd like to route all traffic from sf0 and sf1 to the DSL connection and the others to the cable modem. At the same time I'd like to offer the protection of ipfilter. Traffic on sf0 should not see traffic on sf1 etc. Since this seems not possible with the both stable and current, I would like to make a solution for it, inside the kernel. I am thinking of creating a routing table based on source address and designate the right gateway. Source interface instead of source address. source address can be spoofed Or better some thing for routes as jail for processes? Different routing tables in one kernel And assign interfaces to tables. Thoughts and opinions are very welcome. Where do you suggest I start? Peter P.S. If this functionality exists (without bridging) I'd like to know as well -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
On Thu, Jun 20, 2002 at 07:33:54PM -0700, Frank Mayhar wrote: Kris Kennaway wrote: Surely it's easier to just upgrade the apache port, instead of recompiling your kernel and the entire OS. Not always. (I'm running an old version of Covalent Raven SSL and I'm loathe to upgrade. If it works, don't fix it and there are only so many hours in a day.) The exact same argument can be made for not upgrading the OS, which is a much larger endeavour and can potentially screw things up much worse. Kris msg35140/pgp0.pgp Description: PGP signature
Re: inuring FreeBSD to the apache bug without upgrading apache ?
Joshua Lee wrote: The way you would deal with this would be to tell Apache that it was an HTTP 1.0 server, since chunking is an HTTP 1.1 feature. The only place this is an issue is if you need to reuse an HTTP connection, and that only occurs in HTTP 1.1 when you are doing pipelining. Everywhere else, you can indicate an end of data Mozilla has an option to enable http pipelining as a performance option. I regularly used this, maybe I shouldn't? It depends. Does it still use 4 outstanding connections to the server on the other end, or does it serialize all your picture download requests through a single pipe? If the latter, what is the measured latency between the end of one response and the beginning of another? Basically, this is going to boild down to how the web server on the back end is written, and what's between you and it, in the way of smart hardware. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: projects?
On Thu, Jun 20, 2002 at 01:21:30PM -0700, Julian Elischer wrote: I've been considereing this as a fun project. The difficult comes at the interface/IP boundary.. we'd need am ng_route node to multiplex the packets to the correct output nodes... Would it be needed to duplicate the whole stack in the netgraph node or would it be relatively easy to hook it up to the existing ip and tcp code? Just wondering. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Lamont Granquist wrote: Cyrus imapd is a real pain in the ass to administer local user accounts with though. You mean that it doesn't integrate well with the UNIX credentials system. THe issue here is that Cyrus needs to be able to hook create/delete actions on accounts, and UNIX fails to provide a means of doing this. I look at this as a UNIX deficiency. You can actually get around it by using pw and utilizing the script hooks it has. Well, that's trying to place blame on how it should get fixed. From my perspective I don't care, it is just more difficult to use. It has functionality that can not be implemented without adding to how UNIX does things. Basically, it needs to be able to hook the account constructor/destructor. I think that it you are running shell acounts on your mail server, you are in trouble anyway. The easiest real fix for this would be to write a PAM module to cause the UNIX users to authenticate against the Cyrus database. Creating mailboxes is also a PITA, I like procmail to be able to do this and not have a 2nd configuration step... You mean new mailboxes. THat's an issue of a client program that you could run from procmail on a user's behalf, based on a credential correspondance. You have to establish that correspondance first. Actually, there are patches that let you auto-create mailboxes, but, like your procmail fix, they are subject to denial of service attacks from people who know the process is automatic. Probably if you have particular problems with Cyrus, you should take them up with the Cyrus mailing lists. This has really gotten away from the request for a recommendation of which IMAP server to run on a FreeBSD system. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
On Fri, 21 Jun 2002, Kris Kennaway wrote: On Thu, Jun 20, 2002 at 07:33:54PM -0700, Frank Mayhar wrote: Kris Kennaway wrote: Surely it's easier to just upgrade the apache port, instead of recompiling your kernel and the entire OS. Not always. (I'm running an old version of Covalent Raven SSL and I'm loathe to upgrade. If it works, don't fix it and there are only so many hours in a day.) The exact same argument can be made for not upgrading the OS, which is a much larger endeavour and can potentially screw things up much worse. That's a very valid point. I'm certainly not recommending that Frank upgrade his OS, but I must note that I trust ugprading the entire FreeBSD operating system to be a smoother operation than upgrading one single, solitary commercial closed source package. At least if I'm gonna go about installing a new world I /know/ what I'm getting myself into and that if my box gets screwed up: a) It's probably my fault. b) I can go reading the error messages and Makefiles and figure out what I botched. I have the source. However, I would ask Frank if there's a particular reason he needs to use Covalent Raven SSL. OpenSSL is free, works like gangbusters, and comes with FreeBSD. I have a feeling he'd be much happier with it if there's not some other reason he cannot move to it. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[++-][++-].[+-][+-]+.+++..++ +.+[++-]++.+++..+++.--..+. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
On Fri, 21 Jun 2002, Kris Kennaway wrote: On Thu, Jun 20, 2002 at 07:33:54PM -0700, Frank Mayhar wrote: Kris Kennaway wrote: Surely it's easier to just upgrade the apache port, instead of recompiling your kernel and the entire OS. Not always. (I'm running an old version of Covalent Raven SSL and I'm loathe to upgrade. If it works, don't fix it and there are only so many hours in a day.) The exact same argument can be made for not upgrading the OS, which is a much larger endeavour and can potentially screw things up much worse. You can just patch the running version of apache with the diffs that fix the security hole. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
On Fri, Jun 21, 2002 at 02:29:30AM -0400, Joshua Lee wrote: On Thu, 20 Jun 2002 19:59:20 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Patrick Thomas wrote: Is it possible to patch/recompile FreeBSD 4.5 in such a way that your system is no longer vulnerable to the chunking attack, even if you are still running a vulnerable apache ? Why not upgrade Apache...?? Both the 1 and 2 series have been updated I think. (I'm a newbie at server stuff, so bear with me if I made a faux pas.) The apache13+ipv6 port has not, because the last ipv6 patchset is available for 1.13.22. The way you would deal with this would be to tell Apache that it was an HTTP 1.0 server, since chunking is an HTTP 1.1 feature. The only place this is an issue is if you need to reuse an HTTP connection, and that only occurs in HTTP 1.1 when you are doing pipelining. Everywhere else, you can indicate an end of data Mozilla has an option to enable http pipelining as a performance option. I regularly used this, maybe I shouldn't? It should fallback. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 8 floppy drive anyone ?
Poul-Henning Kamp wrote: I have a bunch of 8 floppies I need to try to recover contents from, is there anybody out there who has a 8 drive they'd be willing to part with for $$ ? If it comes with the magic SA800-PC cable it would be just perfect. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Try [EMAIL PROTECTED] of http://www.vcfe.org he's in Munich Germany, he collects weird stuff for a proto-not-yet-museum, probably he'll not be keen to sell, but offer to trade some other weird stuff you can dredge up in exchange, you may make his day. His associate Salam (email lost) of http://www.vintage.org also runs a museum in USA, might be able to help similarly, trading. Hypo Vereinsbank in Munich, Bavaria, Germany were still using 8 drives on computers in bank branches about 2 years ago, don't know if theyve been thrown out yet. PS I have a sector recovery tool I wrote for 5.25 on dos, but works on 3.25 on FreeBSD too, just that the recovery bit is better on DOS than BSD, on BSD it's vaguely dd'ish, on DOS it really recovers data. http://bim.bsn.com/~jhs/src/bsd/jhs/bin/public/valid/ Julian Stacey Munich Unix (FreeBSD, Linux etc) Independent Consultant [EMAIL PROTECTED] http://bim.bsn.com/~jhs/ Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Limiting clients per source IP address (ftpd, inetd, etc.)
On 2002-06-20 20:25 +, Terry Lambert wrote: Giorgos Keramidas wrote: I've been thinking for quite some time to add per-client-IP limiting to ftpd, and I had almost decided upon something like the following, where each child of ftpd has two numbers associated with it. Someone just did something similar for inetd (per IP per port). I know. I missed that post (probably deleted it accidentally), and a friend told me that this was being discussed. Since I had been giving the topic a big of thought, I thought I'd post what I had and ask for comments. The friend who notified me about this mentioned that a linear list was being used and what I had so far would probably be OK for inetd too. The more I think about this, and the fact that there is code growing to do basically the same thing in every program, the more I think that the code to do this needs to be centralized. A simple core reuse of ../../foo.c would probably be sufficient in this case, since the part that does the limiting only needs the following interface: find_client_addr(); find_client_pid(); add_client(addr, pid); del_client(pid);/* called by reapchild() */ Putting this code into a seperate daemon, or even natd, makes a lot more sense to me than hacking up the kernel, or every network application ever written. Sound very general to me, and I can't say I don't like the idea. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Limiting clients per source IP address (ftpd, inetd, etc.)
On 2002-06-21 00:35 +, Luigi Rizzo wrote: On Thu, Jun 20, 2002 at 11:58:10PM -0700, Terry Lambert wrote: in fact there is an ipfw rule which does just this: ipfw add allow ip from any to any limit src-addr 5 and here you go... Can this be done per port? THis is what both the FTP and the inetd modification movements have been about... ipfw add allow ip from any to any limit src-addr src-port 5 ... BTW in terms of implementation efficiency: this limit thing uses the same hash table used by dynamic ipfw rules. There is currently an (arbitrary) limit of a total of 1000 dynamic entries in the table, but no reason not to raise it much higher if you have memory. The main reason I was looking for a userland implementation of this was that adding limiting to an FTP server that has an active number of a few thousand connections might be a little resource intensive to the kernel of the machine. It's probably OK to stay a bit to much within a userland function that searches a hash/list of addresses, but doing this in the kernel, is something I can't say I fully understand yet. I'm not familiar with the ipfw code. Would it be possible to limit the connections based on source address for a machine that has a few thousand connections and still not put a heavy load on the kernel? - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Limiting clients per source IP address (ftpd, inetd, etc.)
On Fri, Jun 21, 2002 at 04:36:26PM +0300, Giorgos Keramidas wrote: ... BTW in terms of implementation efficiency: this limit thing uses the same hash table used by dynamic ipfw rules. There is currently an (arbitrary) limit of a total of 1000 dynamic entries in the table, but no reason not to raise it much higher if you have memory. The main reason I was looking for a userland implementation of this was that adding limiting to an FTP server that has an active number of a few thousand connections might be a little resource intensive to the kernel of the machine. It's probably OK to stay a bit to much within a userland function that searches a hash/list of addresses, but doing this in the kernel, is something I can't say I fully understand yet. I'm not familiar with the ipfw code. Would it be possible to limit the connections based on source address for a machine that has a few thousand connections and still not put a heavy load on the kernel? i'd say yes, as long as you make the hash table size and number of buckets large enough. Both are configurable via sysctl variables: net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.dyn_max: 1000 cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Limiting clients per source IP address (ftpd, inetd, etc.)
Hello, The main reason I was looking for a userland implementation of this was that adding limiting to an FTP server that has an active number of a few thousand connections might be a little resource intensive to the kernel of the machine. It's probably OK to stay a bit to much within a userland function that searches a hash/list of addresses, but doing this in the kernel, is something I can't say I fully understand yet. Not only this. For example take the normal inetd behaviour for an FTP server. If the ftpd child processes grow above the limit, inetd simply won't spawn others. The users think that the service is dying (because it can be pinged, but the client can't log on) and begin to flame the operator (such a lame service :). Imagine this with the per IP address limit (this will hit more users, because of proxies, NAT boxes, etc). I think it is much better if the daemon can report this via a simple text message. The user limit thing is the last which is necessary to the FreeBSD ftpd for running an anonymous server. [ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]--- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD NFS server benchmarks vs. OpenBSD, NetBSD?
Terry makes some very excellent points that I've tested and documented in Real Life. Two years ago I did a bunch of extensive testing between three NFS servers (Sun, FreeBSD, NetApp) and one set of NFS clients (FreeBSD). Anyone that knows NFS really well would have predicted our test results that demonstrated the FreeBSD NFS server as being the best performer. The FreeBSD system was a home build with a GigE card, tuned MTU, large window, etc... running on a Cisco GigE switch. It solidly outperformed every other NFS server. If you were to have used Solaris clients, it's quite likely that one of the other two servers would have outperformed the FreeBSD server. Tuning the NFS server and the clients also has enormous potential for improvement. It took dozens of iterations to find the ideal combination of MTU size, nfsiod clients, nfsd servers, in the mail cluster I build. However, the engineering effort held large dividends. That mail system is still in use, seldom touched by human hands. It's withstood mail storms, DoS attacks, and many other network events that have been catastrophic to some of our other mail systems. Your best bet is to take a look at each of the platforms and determine which suits your needs best. Once you've etched that in stone, install your OS of choice and start tuning it to best suit your environment. The above is all unbiased. I personally have used quite a few NFS systems, a few more than I'd like to have. Many others will have opinions but here are mine: BSDI has, IMHO, one of the finest NFS implementations anywhere. I've used it extensively with NT, Mac OS, Mac OS X, BSDI, FreeBSD, Linux, and Solaris clients. As of BSDI 4.0/4.1 (IIRC) it supported NFS locking and worked VERY, VERY well with BSDI clients (as should be expected). I don't know how it's doing these days, I've dropped off the BSDI mailing lists and stopped using it in favor of FreeBSD. FreeBSD has very solid NFS code in addition to being a very robust, versatile, and downright fun operating system. It's very easy to do everything I want to with FreeBSD. It's NFS is missing locking support but it's very fast and works very well with FreeBSD and Mac OS X clients. I haven't used it with anything else. OpenBSD and NetBSD both fall into the same category in my book. Both OS's attack a niche that is too narrow for my purposes. I've installed NetBSD on a HP 9000, Mac IIci, and Intel hardware and, it works, but I couldn't ever easily do anything useful with them. OpenBSD is OpenBSD and life is too short to fight some battles. Sun wrote the book on NFS. They also missed the boat. NFS on Sun is reliable and works well with Sun NFS clients. Good luck with anything else. Performance has never been a feature of Sun's NFS implementation so keep shopping if you care about it. Linux NFS sucks. Some will point out that it's made LOTs of progress. They should also note there's a long ways to go. Linux NFS interaction with NetApp, FreeBSD, and Sun NFS servers is very problematic and never achieves good performance. Matt On Thursday, June 20, 2002, at 11:15 PM, Terry Lambert wrote: Dan Ellard wrote: Has anyone done a side-by-side benchmark of the FreeBSD, OpenBSD, and NetBSD NFS servers on the same hardware? Note that I'm interested in server performance, not client performance. I'm particularly interested in read performance, but anything would be interesting. In lieu of actual data, which system do people think makes the best NFS server for heavily-loaded systems? I don't think anyone has benchmarked this; if they had, color me astonished. Your best bet would be to compare them yourself, since it's not that hard to install them. FWIW, You can't seperate server and client performance. If you have two clients and two servers, the first client caches operation X, and the second client does not, and you have two servers, one where operation X is very fast, and reads are OK, and the other where operation X is very slow, but reads are slightly faster than just OK, which one shows up as being better is going to depend in the client you use in the benchmarks. If you're asking about a server and not a client, then you would be better of asking about the particular client by name vs. each of the possible server choices. PS: Your answers are going to differ based on UDP vs. TCP and rsize/wsize. In particular, if you need to have an rsize/wsize larger than the MTU, make sure you are using TCP, not UDP, or you will be shooting yourself in the foot (most Linux clients wonder why when they use UDP, their nubers go to hell; that's why). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message `` Matt Simerson [EMAIL PROTECTED] Unix Systems Engineer Interland, Inc. -- I drive too
Re: inuring FreeBSD to the apache bug without upgrading apache ?
Kris Kennaway wrote: On Thu, Jun 20, 2002 at 07:33:54PM -0700, Frank Mayhar wrote: Kris Kennaway wrote: Surely it's easier to just upgrade the apache port, instead of recompiling your kernel and the entire OS. Not always. (I'm running an old version of Covalent Raven SSL and I'm loathe to upgrade. If it works, don't fix it and there are only so many hours in a day.) The exact same argument can be made for not upgrading the OS, which is a much larger endeavour and can potentially screw things up much worse. Yep. Which is why the only times I've upgraded the kernel on my production boxes have been when there is a critical fix that I _had_ to install, usually a security fix. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
Brandon D. Valentine wrote: However, I would ask Frank if there's a particular reason he needs to use Covalent Raven SSL. OpenSSL is free, works like gangbusters, and comes with FreeBSD. I have a feeling he'd be much happier with it if there's not some other reason he cannot move to it. As I mentioned, the two reasons are (1) it hasn't been broken (at least up to now) and (2) I haven't had time. These are colocated production boxes; I don't have easy physical access to them to fix things if they go seriously wrong, and having them be down for any length of time is a Bad Thing. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I Volunteer
Brandon D. Valentine wrote: On Thu, 20 Jun 2002, Darren Pilgrim wrote: Personally I'm all for courier-imap. IMAP and POP3, Maildirs, SSL, and the ability to access both real and virtual mailboxes. See my other recent message about the security implications of running courier-imap. Also, maildirs are a mediocre idea for general use, and a horrible idea for high volume mail spools. The whole idea behind IMAP is for the mail to reside on the mail server, not a user's workstation. Maildirs eat inodes like nobody's business. If you're using FFS to host a fairly high traffic mail spool you'll probably need to newfs your filesystem with a /ton/ of inodes. The only solution is to use a filesystem which dynamically allocates inodes like XFS. Cyrus uses a much more efficient storage mechanism. That's exactly where the difficulties come from. Cyrus is a royal PITA to convince to run on a machine that also has shells. For instance: in my case my local mail provider doesn't support IMAP (and their mailserver is quite a long way away from me and behind some rather laggy and slow pipes). I wanted to be able to run Sylpheed when I'm on the X console and pine when I'm remotely logged in. The only option (given that they use different mail formats) seemed to be to dump all of my mail into a local IMAP server (it's not a ton of mail either) so both programs could see it. While the uw-imap can do this with a bit of prodding (you have to change a variable in a dependancy to get it to no spew your imap directories all throughout your home directory), it works OK. I originally tried Cyrus IMAP (because it was supposedly better), but nearly pulled my head off trying to get all of the authentication/permission/configuration/login/etc issues worked out. I never actually did successfully create a subdirectory on the Cyrus server, and after poring over the tons of not-very-helpful docs, I eventually gave up and went to the uw solution. UW might not be the best technically, but I wasn't going to have to spend 6 weeks learning the intricacies of the permissions system on my IMAP server to get it working. -- \ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED] |\/ | ||/ _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: projects?
On Thu, 20 Jun 2002, Terry Lambert wrote: Basically, that's my short list. There are actually a lot more things that could be done in the networking area; there are things to do in the routing area, and things to do with RED queueing, and things to do with resource tuning, etc., and, of course, there's the bugs that you normally see in the BSD stack only when you try to dothings like open more than 65535 outbound connections from a single box, etc.. Personally, I'm tired of solving the same problems over and over again, so I'd like to see the code in FreeBSD proper, so that it becomes part of the intellectual commons. SO which project are you going to do terry? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: projects?
On Fri, 21 Jun 2002, Mark Santcroos wrote: On Thu, Jun 20, 2002 at 01:21:30PM -0700, Julian Elischer wrote: I've been considereing this as a fun project. The difficult comes at the interface/IP boundary.. we'd need am ng_route node to multiplex the packets to the correct output nodes... Would it be needed to duplicate the whole stack in the netgraph node or would it be relatively easy to hook it up to the existing ip and tcp code? I'd try start with a second copy of the existing code and see what needs to be hacked.. If it were easy enough you could retrofit th changes to th current code but I suspect that it woudl diverge... Just wondering. Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
What none of you has mentioned is the thought I had in mind when I asked this question, and that is, I have a rd machine with 16 jails on it, each running apache. Therefore in a situation like this it would be _much_ easier to just tune a sysctl or rebuild the kernel, vs. rebuilding 16 differently configured, different versions of apache. YMMV. --PT On Fri, 21 Jun 2002, Frank Mayhar wrote: Brandon D. Valentine wrote: However, I would ask Frank if there's a particular reason he needs to use Covalent Raven SSL. OpenSSL is free, works like gangbusters, and comes with FreeBSD. I have a feeling he'd be much happier with it if there's not some other reason he cannot move to it. As I mentioned, the two reasons are (1) it hasn't been broken (at least up to now) and (2) I haven't had time. These are colocated production boxes; I don't have easy physical access to them to fix things if they go seriously wrong, and having them be down for any length of time is a Bad Thing. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: projects?
On Fri, Jun 21, 2002 at 08:37:15AM +0200, Mark Santcroos wrote: On Thu, Jun 20, 2002 at 01:21:30PM -0700, Julian Elischer wrote: I've been considereing this as a fun project. The difficult comes at the interface/IP boundary.. we'd need am ng_route node to multiplex the packets to the correct output nodes... Would it be needed to duplicate the whole stack in the netgraph node or would it be relatively easy to hook it up to the existing ip and tcp code? For my purposes, it would need to be seperate so you could copy the module and hack in a new TCP without changing the existing one. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg35162/pgp0.pgp Description: PGP signature
Re: midi on FreeBSD 4.5: good progress! i now have a midi.ko bas
Hello Conrad; On Fri, 21 Jun 2002, Conrad Sabatier wrote: John, Please keep us informed as to your progress. I'm sure I'm not the only one who would be *very* happy to see your work come to fruition! it will be very nice to have this work. i am pretty excited about it. i've wanted to work on it since the very beginning, but i lacked the skills and time. I'm able to do this now because i own a laptop with midi on it and i have an hour+ bus ride each way back and forth between home and work. but i have to be careful, i dont want to disappear under mysterious circumstance. or explode. working on freebsd midi support seems to have a lot in common with being the drummer in 'Spinal Tap'. :-) If I can help in any way (testing or whatever), let me know. thankyou very much! i'll pop something out as soon as it works. -- John L. Utz III [EMAIL PROTECTED] Idiocy is the Impulse Function in the Convolution of Life To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
On Fri, 21 Jun 2002 10:38:21 +0200 Bernd Walter [EMAIL PROTECTED] wrote: On Fri, Jun 21, 2002 at 02:29:30AM -0400, Joshua Lee wrote: On Thu, 20 Jun 2002 19:59:20 -0700 Terry Lambert [EMAIL PROTECTED] wrote: The way you would deal with this would be to tell Apache that it was an HTTP 1.0 server, since chunking is an HTTP 1.1 feature. The only place this is an issue is if you need to reuse an HTTP connection, and that only occurs in HTTP 1.1 when you are doing pipelining. Everywhere else, you can indicate an end of data Mozilla has an option to enable http pipelining as a performance option. I regularly used this, maybe I shouldn't? It should fallback. Considering that there's a warning concerning it's use with some servers maybe it doesn't... Luckily it's not on by default. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Fri, 21 Jun 2002, Terry Lambert wrote: It has functionality that can not be implemented without adding to how UNIX does things. Basically, it needs to be able to hook the account constructor/destructor. It's quite simple to integrate Cyrus IMAP with the local system. Cyrus will by default use the system password database for its authentication, all that is left is to write up a script to your liking to manage the IMAP folders (I wrote one in PERL using the IMAP::Admin and Mail::IMAPClient modules, but please don't ask me for them, I'm not that proud of them :-). You can hook that script in to whatever you're using to create the system user accounts. In the near future, however, I plan to move the authentication database into LDAP and have Cyrus use that so that I can get rid of all of the local system accounts which are there for nothing other than authentication (the shells are just /sbin/nologin). All in all, I love the Cyrus design, and it hasn't given me a bit of trouble in over 6 years. It makes doing a secure black-box mail server very easy. -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Limiting clients per source IP address (ftpd, inetd, etc.)
Wouter Van Hemel wrote: I agree with this... but I think that the reason many people like to do it by implementing the limitation in the daemon, is that they can send back some kind of reply, stating the reason of the refusal (which is a nice thing to do, since so many people are behind proxies, sharing the same ip). In that case, you need to speak the protocol of the specific service, even though most of it is plain text anyway. If not, the ipfw method works just fine. Just a thought. Attila Nagy makes a similar point. I think maybe the place for such a message is in a proxy server. The problem here is the point is to limit the number of connections by one IP address. The obvious reason for this constraint is to prevent a trivial denial of service attack occurring from a single IP address, so that clients from other IP address can get in. If you allow the connection to go through so that you can present a user with a capacity limitation message, then you are in much deeper trouble. You've already allowed your attacker to consume a connection resource, and enough of the protocol state engine has to be there for the inital connection negotiation, such that a failure message can be delivered down the protocol encapsulated channel (in the FTP case, the command channel, as a greetings message failure). After that happens, then you close the connection to the client. However, an attacking client can delay the handshake negotiation mechanism, thus consuming the per connection state information without a full connection. Alternately, for other protocols, immediately upon being connected to the server which is about to reject the connection, the client can wait for the server to do the connection close as part of the reject. This sends the socket into TIME-WAIT on the server, tying up the server resources for a full 2MSL. I think that permitting the connection to go through so that you can have a protocol rejection followed by a protocol close defeats much of the purpose of rate limiting based on IPs. If the patch were simply to set an overall connection limit, then it might make sense to allow the connection. Even so, you are then subject to attack. The ftp.cdrom.com server does a connection rejection based on protocol negotiation and a failure handshake message (Too many users; maximum of 5000 or whatever). Technically, you could DOS attack this server: it's relying on pool retention in order to not run out of connections. In other words, it's assuming that the people connecting to it are legitimate. So a connection followed by a protocol rejection is for people who are playing nice. A connection reject outright is for people who are attacking you. In other words, it's a circuit breaker, not door security. Someone made the comment about people sitting behind a NAT, so that the number of connections from a given IP is actually legitimate traffic. This rate limitation is targetted at an attacker. One would expect that the number of connections would be set high enough that it would not trigger for these people, and low enough to catch an attacker. Really, if you get to this point in dropping connections, you are pretty much screwed anyway. It's not going to protect you from partial connection attempts, which are one of the most common attach types these days (e.g. SYN-flooding), since by the time you get through the protocol state machine, the resources that you should be worrying about protecting have already been compromised. If the idea is to prevent an attack, then you should not even queue the SYN requests from an IP after you hit the connection limit -- you should drop them. The network card DMA'ing them into memory in the first place is where you want to squelch the problem. That's probably a firmware issue, where you give the card a list of squelch IP addresses, and it ignores packets from there for timeout. In any case, there's really little justification for accepting a connection and then immediately rejecting it with a protocol reject, since all of your overhead for protocol state, connection, etc., has already been consumed, if your intent is to guard against an attack. So I guess what needs to happen is a strict definition of what it is people expect to actually accomplish with this class of patches. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD on a MaxAttach?
I noticed that the SNAP Servers are far better in performance than the MaxAttach. WinNT/2000 embedded was a nice idea, but its so bloated I think they screwed it up a bit in its efficiency. BSDI v4.3 and FreeBSD kernels are more up to the task (I have BSDI whick rocks in its own right). The mini iso does wonders for me for custom solutions. I wonder if Solaris 9 can hold a few candles to BSDI v4.3 or FreeBSD v4.6. We need a few articles to compare these notes!!! ;o Ken _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: projects?
On Fri, Jun 21, 2002 at 11:04:36AM -0700, Brooks Davis wrote: For my purposes, it would need to be seperate so you could copy the module and hack in a new TCP without changing the existing one. I understand, but you won't need to do that for the IP layer in your case. Other people might have a reverse situation, so some hooks to both these layers would come in handy, that was my point. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
Joshua Lee wrote: Mozilla has an option to enable http pipelining as a performance option. I regularly used this, maybe I shouldn't? It should fallback. Considering that there's a warning concerning it's use with some servers maybe it doesn't... Luckily it's not on by default. THat's not the issue. The issue is that some servers claim to be 1.1 servers, but do not implement pipelining. Older Apache servers fall into this category. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Chris Dillon wrote: On Fri, 21 Jun 2002, Terry Lambert wrote: It has functionality that can not be implemented without adding to how UNIX does things. Basically, it needs to be able to hook the account constructor/destructor. It's quite simple to integrate Cyrus IMAP with the local system. Cyrus will by default use the system password database for its authentication, While I appreciate the positive support of Cyrus, I guess I need to point out that this approach only works if you are willing to send passwords over the wire in plaintext. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD on a MaxAttach?
Chris Dillon wrote: We have some Quantum SNAP Servers which are exactly the same thing as the older MaxAttach boxes except with bigger IDE drives, and they're still running the custom version of FreeBSD on them. They actually perform better than our much heftier Windows NT 4 servers. They even perform better than the newer MaxAttach boxes which are now running a form of Win2K and have much heftier hardware. Uh... the version of FreeBSD on the Quantum boxes is probably the same version of FreeBSD that was on the InterJets... *cough*. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
On Fri, 21 Jun 2002, Terry Lambert wrote: THat's not the issue. The issue is that some servers claim to be 1.1 servers, but do not implement pipelining. Older Apache servers fall into this category. I have been using pipelining in Mozilla for many months now without encountering a single, solitary server which caused me problems. I would guage that the number of servers out there which exhibit this problem is few. Netcraft could probably provide some fairly authoritative data in this regard, provided someone has a list of known buggy HTTP 1.1 implementations. It would probably be a much appreciated public service to the network if someone were resourceful enough to construct such a list, run it through netcraft, inform the admins of any and all known websites running buggy HTTP 1.1 implementations of the issue and recommend an upgrade path based on their currently installed HTTP server. This would be fairly simple to automate I would imagine with some help from the folks at netcraft. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[++-][++-].[+-][+-]+.+++..++ +.+[++-]++.+++..+++.--..+. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Limiting clients per source IP address (ftpd, inetd, etc.)
On 2002-06-21 15:12 +, Terry Lambert wrote: Someone made the comment about people sitting behind a NAT, so that the number of connections from a given IP is actually legitimate traffic. This rate limitation is targetted at an attacker. Actually I was thinking more of ReGet and Godzilla-style software used by some users to play unfair and suck more bandwidth out of an FTP server, by opening a zillion sockets and downloading a single file in chunks. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Limiting clients per source IP address (ftpd, inetd, etc.)
Giorgos Keramidas wrote: On 2002-06-21 15:12 +, Terry Lambert wrote: Someone made the comment about people sitting behind a NAT, so that the number of connections from a given IP is actually legitimate traffic. This rate limitation is targetted at an attacker. Actually I was thinking more of ReGet and Godzilla-style software used by some users to play unfair and suck more bandwidth out of an FTP server, by opening a zillion sockets and downloading a single file in chunks. What a clever hack! I don't know if I should revise my argument to include per-IP-per-file, which would of necessity be user space, or just admire it and say they *deserve* more bandwidth for being smart... I guess I'll argue that it's a different problem space, and limiting the number of connections for that reason is really easy to get around: 1) Open as many connections as you can 2) Divide the download between the connections In other words, your workaround only works if you take the file into account, or if you set your per IP connection limit to 1 connection per IP. The former is a totally different problem, while the latter can be done with ipfw or one of the other approaches already discussed. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Terry Lambert wrote: Chris Dillon wrote: It's quite simple to integrate Cyrus IMAP with the local system. Cyrus will by default use the system password database for its authentication, While I appreciate the positive support of Cyrus, I guess I need to point out that this approach only works if you are willing to send passwords over the wire in plaintext. There's no support for SSL in Cyrus? What about secure authentication? Speaking of which, what does it take to get secure authentication to work on FreeBSD? Courier supports it, but the port compiles with options to disable the secure authentication methods. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: projects?
On Sat, Jun 22, 2002 at 01:03:34AM +0200, Mark Santcroos wrote: On Fri, Jun 21, 2002 at 11:04:36AM -0700, Brooks Davis wrote: For my purposes, it would need to be seperate so you could copy the module and hack in a new TCP without changing the existing one. I understand, but you won't need to do that for the IP layer in your case. Other people might have a reverse situation, so some hooks to both these layers would come in handy, that was my point. It depends on what you're trying to do. If all you want to do is mess with in-kernel TCP implementations then just hooking into the existing IP layer is sufficent. I'm also thinking that the ability to run netgraph code in a hybrid userland/kernel environment for development would be useful in which case it would be useful to be able to implement the whole network stack in netgraph nodes. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg35179/pgp0.pgp Description: PGP signature
kernel file creation query...
Hi,
This might be a lame query...but ...
I am trying to create a file from kernel space given
the vnode of the parent directory using VOP_CREATE.
The code is as below.
int make_file(struct vnode *dvp, struct vnode **vpp, struct proc *p, char
*name)
{
struct componentname cnp;
struct vattr va, *vap = va;
/* set component name */
cnp.cn_nameiop = CREATE;
cnp.cn_flags = LOCKLEAF;
cnp.cn_proc = p;
cnp.cn_cred = p-p_ucred;
cnp.cn_pnbuf = cnp.cn_nameptr = name;
cnp.cn_namelen = cnp.cn_consume = strlen(name);
/* set attributes */
VATTR_NULL(vap);
vap-va_type = VREG;
return VOP_CREATE(dvp, vpp, cnp, vap);
}
Now the file is getting created, but if I do an ls on its parent
directory, I get something like;
foo: Bad file descriptor.
I am sure I am doing something wrong or missing something. I tried looking
at the nfs and kern code, but couldn't figure out much.
Can you experts just correct me..
thanks in advance
nitin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Fri, 21 Jun 2002, Terry Lambert wrote: Chris Dillon wrote: On Fri, 21 Jun 2002, Terry Lambert wrote: It has functionality that can not be implemented without adding to how UNIX does things. Basically, it needs to be able to hook the account constructor/destructor. It's quite simple to integrate Cyrus IMAP with the local system. Cyrus will by default use the system password database for its authentication, While I appreciate the positive support of Cyrus, I guess I need to point out that this approach only works if you are willing to send passwords over the wire in plaintext. Yes, but this is the case with any IMAP server and doesn't really have anything to do with Cyrus in particular. Unlike other IMAP servers, however, Cyrus supports SASL which offers plenty of non-plain-text authentication options, unfortunately none of which work with a local FreeBSD password database that I know of. There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD on a MaxAttach?
On Fri, 21 Jun 2002, Terry Lambert wrote: Uh... the version of FreeBSD on the Quantum boxes is probably the same version of FreeBSD that was on the InterJets... *cough*. 2.2.something? :-) Whatever version it is, I'm impressed with how well it works. The only problem I have with the Quantum SNAP boxes is the total lack of being able to script any kind of setting of file ownerships or ACLs. You have to set those entirely through the web interface, which is entirely unacceptable when you want to do it for 2000 user home directories. The NT command-line ACL tools don't work, which is how I script that kind of thing on NT servers, and I've tried in vain to write a PERL script that actually accessed and parsed the web interface and sent back the appropriate POSTs. It almost works, but I gave up for the time being. The only other option would be to write something to run in the JVM that is on them, and I can't find any API documentation on setting file ownership or ACLs, not to mention I don't know Java well enough to write such a thing in the first place. :-) -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
