Unpacking Debian packages on FreeBSD
I'd like to grope around inside a .deb file, which has been created on a debian Linux box. Do we have any nifty tools for this, like rpm2cpio? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: FibreChannel support ?
Support exists for the Qlogic 2100 and 2200 FC-AL cards. On Tue, 27 Jul 1999, Papezik Milon wrote: > Hi all, > > only simple question :-) > > Does FreeBSD support any FibreChannel controller > or does body somebody writing a drive? > For which card card? > > Thanks in advance. > Milon > -- > [EMAIL PROTECTED] > > > 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: Which /etc-files do I need until vinum is initialized?
On Tuesday, 27 July 1999 at 9:32:51 +0200, Alexander Maret wrote: > Hi, > > I configured vinum (RAID 1) on a 3.2S System. As I want to mirror > as much as I need to keep the system running (in case of a drive 1 > failure) I mirrored /etc as well. At boot time (until vinum is > initialized) the system only has the following files: > > /etc/defaults/rc.conf > /etc/rc.conf > /etc/rc > /etc/fstab > /etc/gettytab > /etc/login.conf > /etc/ttys > > Do I need all of these files or can I put some of them away > (for example /etc/ttys or /etc/gettytab)? The files > would of course be available as soon as vinum is initialized > and /etc mounted. Interesting question. In view of the fact that I intend to make the root file system bootable One Of These Days, I don't think you should go to too much trouble here: after all, they're only a few kilobytes each. But I think you could eliminate these ones: > /etc/gettytab > /etc/login.conf > /etc/ttys You might find it advantageous to modify /etc/rc to mount /etc (and anything else you want) immediately after starting Vinum: if [ X$start_vinum = XYES ]; then vinum start mount /etc elif [ -n "$vinum_drives" ]; then vinum read $vinum_drives mount /etc fi Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FibreChannel support ?
Hi all, only simple question :-) Does FreeBSD support any FibreChannel controller or does body somebody writing a drive? For which card card? Thanks in advance. Milon -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Which /etc-files do I need until vinum is initialized?
Hi, I configured vinum (RAID 1) on a 3.2S System. As I want to mirror as much as I need to keep the system running (in case of a drive 1 failure) I mirrored /etc as well. At boot time (until vinum is initialized) the system only has the following files: /etc/defaults/rc.conf /etc/rc.conf /etc/rc /etc/fstab /etc/gettytab /etc/login.conf /etc/ttys Do I need all of these files or can I put some of them away (for example /etc/ttys or /etc/gettytab)? The files would of course be available as soon as vinum is initialized and /etc mounted. Regards, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: hot-swapping ata disks
It seems Iani Brankov wrote: [Charset koi8-r unsupported, filtering to ASCII...] > Hi, > I tried 'camcontrol rescan' and I found it works when I add a SCSI device while > the system is on. I find it useful for adding/removing devices w/o restarting > the box. (Maybe it's risky, but useful. I supposed that's the idea of the > 'rescan' command in camcontrol) > > Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI > anyway). I have some experimental code that enables one to do this, but it is not without risk as the IDE channels are not designed for this. You also need to put the disk in a drawer that is able to shut off power etc so you dont burn any electronics while changing the drive. Once I get a little time I'll celan this up and make it available... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare plug/quickie tests.
Is there anyone in particular to whom we should write at VMWare? I agree with his sentiments. -Kip On Mon, 26 Jul 1999, Jordan K. Hubbard wrote: > > I just wish that it was the other way around. I'd actually run > > NT if I could get it in a VMWare compartment under FreeBSD. > > You would do well to pass these sentiments on to vmware; they're > currently counting noses in FreeBSD-land to see if it makes > market sense. All the techs there appear to be sold on the idea, > but it takes more than tech buy-in to get a project approved. :) > > - Jordan > > > 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: Unpacking Debian packages on FreeBSD
On Tue, 27 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > I'd like to grope around inside a .deb file, which has been created on a > debian Linux box. Do we have any nifty tools for this, like rpm2cpio? You can use ar ar x package.deb Milan Kopacka To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Unpacking Debian packages on FreeBSD
I'd like to grope around inside a .deb file, which has been created on a debian Linux box. Do we have any nifty tools for this, like rpm2cpio? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
Sheldon Hearn wrote: > > On Mon, 26 Jul 1999 22:41:24 MST, Doug wrote: > > > However right after 3.2-R came out there was a flurry of -questions > > mail about broken pkg dependencies because sysinstall wasn't properly > > registering the X install. > > Is this a different problem from the broken compat22 installation? Yes. > > If the port depending on the existence of /var/db/pkg/X* is actually > > an error I'll report what I find to the -ports list. > > I'm pretty sure it constitutes "non-conformant" behaviour and I'd be > happy to look at it. Hrrmm... come to think of it, I think that the problem actually amounted to the ports not being able to register after installation was done. In other words, (IIRC) after they were built and installed ports that depended on X were unable to insert their +REQUIRED_BY entries, so this would not constitute "broken." However, I'm a bit fuzzy on it, and I'm very tired so I'm not sure. If I find anything odd I'll report it. Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, 26 Jul 1999 22:41:24 MST, Doug wrote: > However right after 3.2-R came out there was a flurry of -questions > mail about broken pkg dependencies because sysinstall wasn't properly > registering the X install. Is this a different problem from the broken compat22 installation? > If the port depending on the existence of /var/db/pkg/X* is actually > an error I'll report what I find to the -ports list. I'm pretty sure it constitutes "non-conformant" behaviour and I'd be happy to look at it. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
Sheldon Hearn wrote: > > On Mon, 26 Jul 1999 21:09:50 -0400, Tim Vanderhoek wrote: > > > I seem to remember that you can get away with a simple "mkdir > > /var/db/pkg/xxx" to fake it. > > Can you think of any ports that test for the existance of XFree86 using > the package system? They use USE_X_PREFIX or USE_X_LIB, both of which > test for libX11, no? Well, in an ideal world the ports that need parts of X would only test for the parts that they need. However right after 3.2-R came out there was a flurry of -questions mail about broken pkg dependencies because sysinstall wasn't properly registering the X install. If the port depending on the existence of /var/db/pkg/X* is actually an error I'll report what I find to the -ports list. Thanks, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
securelevel too course-grained?
On Mon, 26 Jul 1999 20:48:28 MST, Matthew Dillon wrote: > Subject: Re: securelevel and ipfw zero > > However, it does not allow you to do it if you are sitting at secure > level 3. You don't think that this discussion highlights the growing inadequacy of the securelevel mechanism's lack of granularity? I have a feeling it'll be time soon enough for us to make each of the decisions that is normally affected by securelevel dependant on the value of sysctl knobs. Presumeably one or more of them would be "write-once" knobs. :-) How much existing software tests for kern.securelevel? And could we make its value dependant on the new knobs? I can't see it being too big a problem. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, 26 Jul 1999 21:09:50 -0400, Tim Vanderhoek wrote: > I seem to remember that you can get away with a simple "mkdir > /var/db/pkg/xxx" to fake it. Can you think of any ports that test for the existance of XFree86 using the package system? They use USE_X_PREFIX or USE_X_LIB, both of which test for libX11, no? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
Sheldon Hearn wrote: > > On Mon, 26 Jul 1999 22:41:24 MST, Doug wrote: > > > However right after 3.2-R came out there was a flurry of -questions > > mail about broken pkg dependencies because sysinstall wasn't properly > > registering the X install. > > Is this a different problem from the broken compat22 installation? Yes. > > If the port depending on the existence of /var/db/pkg/X* is actually > > an error I'll report what I find to the -ports list. > > I'm pretty sure it constitutes "non-conformant" behaviour and I'd be > happy to look at it. Hrrmm... come to think of it, I think that the problem actually amounted to the ports not being able to register after installation was done. In other words, (IIRC) after they were built and installed ports that depended on X were unable to insert their +REQUIRED_BY entries, so this would not constitute "broken." However, I'm a bit fuzzy on it, and I'm very tired so I'm not sure. If I find anything odd I'll report it. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, 26 Jul 1999 22:41:24 MST, Doug wrote: > However right after 3.2-R came out there was a flurry of -questions > mail about broken pkg dependencies because sysinstall wasn't properly > registering the X install. Is this a different problem from the broken compat22 installation? > If the port depending on the existence of /var/db/pkg/X* is actually > an error I'll report what I find to the -ports list. I'm pretty sure it constitutes "non-conformant" behaviour and I'd be happy to look at it. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
Sheldon Hearn wrote: > > On Mon, 26 Jul 1999 21:09:50 -0400, Tim Vanderhoek wrote: > > > I seem to remember that you can get away with a simple "mkdir > > /var/db/pkg/xxx" to fake it. > > Can you think of any ports that test for the existance of XFree86 using > the package system? They use USE_X_PREFIX or USE_X_LIB, both of which > test for libX11, no? Well, in an ideal world the ports that need parts of X would only test for the parts that they need. However right after 3.2-R came out there was a flurry of -questions mail about broken pkg dependencies because sysinstall wasn't properly registering the X install. If the port depending on the existence of /var/db/pkg/X* is actually an error I'll report what I find to the -ports list. Thanks, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
securelevel too course-grained?
On Mon, 26 Jul 1999 20:48:28 MST, Matthew Dillon wrote: > Subject: Re: securelevel and ipfw zero > > However, it does not allow you to do it if you are sitting at secure > level 3. You don't think that this discussion highlights the growing inadequacy of the securelevel mechanism's lack of granularity? I have a feeling it'll be time soon enough for us to make each of the decisions that is normally affected by securelevel dependant on the value of sysctl knobs. Presumeably one or more of them would be "write-once" knobs. :-) How much existing software tests for kern.securelevel? And could we make its value dependant on the new knobs? I can't see it being too big a problem. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, 26 Jul 1999 21:09:50 -0400, Tim Vanderhoek wrote: > I seem to remember that you can get away with a simple "mkdir > /var/db/pkg/xxx" to fake it. Can you think of any ports that test for the existance of XFree86 using the package system? They use USE_X_PREFIX or USE_X_LIB, both of which test for libX11, no? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
I needed a new drinks coaster... ;-) -marc Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com 1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
In message "Brian F. Feldman" writes: : But we can install from a single downloaded boot floppy, over the : Internet, which is better. Is that still true? I thought we went back to two floppies to do this... Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
: :> :> :That doesn't mean we shouldn't allow people to have an unsophisticated setup, :> :just because a sophisticated one is available. It would be useful to have :> :a per-firewall-rule counter, decrement it on each match if logging and :> :set, and be able to reset to something higher. :> : :> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ :> :> There may be some confusion here. I am advocating that we *allow* the :> zeroing of counters at secure level 3. : :Which is what I am advocating against. Let me put it a different way: ipfw allows you to clear counters. It is a feature that already exists. However, it does not allow you to do it if you are sitting at secure level 3. Why not? I can't think of any good reason why clearing the counters should be disallowed when sitting at a higher secure level. The counters are nothing more then statistics. Clearing statistics is not a security threat. The discussion should simply be about that. Not all this garbage about adding new features. There's a feature that does not seem to impact security, secure level disallows it, why? -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
I like the ability at secure level 3 to only reset the counters forward.. It fits in with such things as the "append only" flag. Maybe a new keyword. "advance" julian On Mon, 26 Jul 1999, Brian F. Feldman wrote: > On Mon, 26 Jul 1999, Matthew Dillon wrote: > > > > > :That doesn't mean we shouldn't allow people to have an unsophisticated > > setup, > > :just because a sophisticated one is available. It would be useful to have > > :a per-firewall-rule counter, decrement it on each match if logging and > > :set, and be able to reset to something higher. > > : > > : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > > > > There may be some confusion here. I am advocating that we *allow* the > > zeroing of counters at secure level 3. > > Which is what I am advocating against. > > > > > -Matt > > Matthew Dillon > > > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > > with "unsubscribe freebsd-ipfw" in the body of the message > > > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > gr...@freebsd.org _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | >http://www.FreeBSD.org/ _ |___/___/___/ > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Mon, 26 Jul 1999, Matthew Dillon wrote: > > :That doesn't mean we shouldn't allow people to have an unsophisticated setup, > :just because a sophisticated one is available. It would be useful to have > :a per-firewall-rule counter, decrement it on each match if logging and > :set, and be able to reset to something higher. > : > : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > > There may be some confusion here. I am advocating that we *allow* the > zeroing of counters at secure level 3. Which is what I am advocating against. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-ipfw" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
On Mon, 26 Jul 1999, Rayson Ho wrote: > Hi, > > I am not sure whether this is known to this list or > not, but here is the URL for ordering: > > http://www.bsdi.com/products/evalcd/ > But we can install from a single downloaded boot floppy, over the Internet, which is better. > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:That doesn't mean we shouldn't allow people to have an unsophisticated setup, :just because a sophisticated one is available. It would be useful to have :a per-firewall-rule counter, decrement it on each match if logging and :set, and be able to reset to something higher. : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ There may be some confusion here. I am advocating that we *allow* the zeroing of counters at secure level 3. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999, Sheldon Hearn wrote: > > > On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > > > You could start with "WinEXE". > > Save game file formats, not game executables. You think WinEXE tops my > pcgames suggestion? No. How about "savegames"? The Quake 2 format in there would be nice, to distinguish between Q2 Windows version X.XX and Linux glibc, Linux libc5, etc... > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
I needed a new drinks coaster... ;-) -marc Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com 1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Mon, 26 Jul 1999, Matthew Dillon wrote: > > :Instead of zeroing it, how about raising the logging limit to (current + > :whatever the limit was) > : > : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > : gr...@freebsd.org _ __ ___ | _ ) __| \ > > The way I see it either some piece of software is monitor the counters, > in which case the sysad does not need to clear them and does not need to > look at log messages, or the sysad is monitoring the stuff manually and > using the log messages. In the one case the counters don't need to be > cleared (and, indeed, should not be), in the other case the sysad may > want to clear them due to the manual monitoring. > > What we are really discussing here is the use of ipfw's counters in an > unsophisticated setup. The sophisticated setup is already handled. That doesn't mean we shouldn't allow people to have an unsophisticated setup, just because a sophisticated one is available. It would be useful to have a per-firewall-rule counter, decrement it on each match if logging and set, and be able to reset to something higher. > > -Matt > Matthew Dillon > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-ipfw" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
In message <[EMAIL PROTECTED]> "Brian F. Feldman" writes: : But we can install from a single downloaded boot floppy, over the : Internet, which is better. Is that still true? I thought we went back to two floppies to do this... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:Instead of zeroing it, how about raising the logging limit to (current + :whatever the limit was) : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : gr...@freebsd.org _ __ ___ | _ ) __| \ The way I see it either some piece of software is monitor the counters, in which case the sysad does not need to clear them and does not need to look at log messages, or the sysad is monitoring the stuff manually and using the log messages. In the one case the counters don't need to be cleared (and, indeed, should not be), in the other case the sysad may want to clear them due to the manual monitoring. What we are really discussing here is the use of ipfw's counters in an unsophisticated setup. The sophisticated setup is already handled. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
Instead of zeroing it, how about raising the logging limit to (current + whatever the limit was) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
: :> :> :That doesn't mean we shouldn't allow people to have an unsophisticated setup, :> :just because a sophisticated one is available. It would be useful to have :> :a per-firewall-rule counter, decrement it on each match if logging and :> :set, and be able to reset to something higher. :> : :> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ :> :> There may be some confusion here. I am advocating that we *allow* the :> zeroing of counters at secure level 3. : :Which is what I am advocating against. Let me put it a different way: ipfw allows you to clear counters. It is a feature that already exists. However, it does not allow you to do it if you are sitting at secure level 3. Why not? I can't think of any good reason why clearing the counters should be disallowed when sitting at a higher secure level. The counters are nothing more then statistics. Clearing statistics is not a security threat. The discussion should simply be about that. Not all this garbage about adding new features. There's a feature that does not seem to impact security, secure level disallows it, why? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
I like the ability at secure level 3 to only reset the counters forward.. It fits in with such things as the "append only" flag. Maybe a new keyword. "advance" julian On Mon, 26 Jul 1999, Brian F. Feldman wrote: > On Mon, 26 Jul 1999, Matthew Dillon wrote: > > > > > :That doesn't mean we shouldn't allow people to have an unsophisticated setup, > > :just because a sophisticated one is available. It would be useful to have > > :a per-firewall-rule counter, decrement it on each match if logging and > > :set, and be able to reset to something higher. > > : > > : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > > > > There may be some confusion here. I am advocating that we *allow* the > > zeroing of counters at secure level 3. > > Which is what I am advocating against. > > > > > -Matt > > Matthew Dillon > > <[EMAIL PROTECTED]> > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-ipfw" in the body of the message > > > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > [EMAIL PROTECTED] _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | >http://www.FreeBSD.org/ _ |___/___/___/ > > > > 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: securelevel and ipfw zero
On Mon, 26 Jul 1999, Matthew Dillon wrote: > > :That doesn't mean we shouldn't allow people to have an unsophisticated setup, > :just because a sophisticated one is available. It would be useful to have > :a per-firewall-rule counter, decrement it on each match if logging and > :set, and be able to reset to something higher. > : > : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > > There may be some confusion here. I am advocating that we *allow* the > zeroing of counters at secure level 3. Which is what I am advocating against. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-ipfw" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
On Mon, 26 Jul 1999, Rayson Ho wrote: > Hi, > > I am not sure whether this is known to this list or > not, but here is the URL for ordering: > > http://www.bsdi.com/products/evalcd/ > But we can install from a single downloaded boot floppy, over the Internet, which is better. > > > _ > 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 > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:That doesn't mean we shouldn't allow people to have an unsophisticated setup, :just because a sophisticated one is available. It would be useful to have :a per-firewall-rule counter, decrement it on each match if logging and :set, and be able to reset to something higher. : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ There may be some confusion here. I am advocating that we *allow* the zeroing of counters at secure level 3. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999, Sheldon Hearn wrote: > > > On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > > > You could start with "WinEXE". > > Save game file formats, not game executables. You think WinEXE tops my > pcgames suggestion? No. How about "savegames"? The Quake 2 format in there would be nice, to distinguish between Q2 Windows version X.XX and Linux glibc, Linux libc5, etc... > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
On Mon, 26 Jul 1999, Matthew Dillon wrote: > > :Instead of zeroing it, how about raising the logging limit to (current + > :whatever the limit was) > : > : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > : [EMAIL PROTECTED] _ __ ___ | _ ) __| \ > > The way I see it either some piece of software is monitor the counters, > in which case the sysad does not need to clear them and does not need to > look at log messages, or the sysad is monitoring the stuff manually and > using the log messages. In the one case the counters don't need to be > cleared (and, indeed, should not be), in the other case the sysad may > want to clear them due to the manual monitoring. > > What we are really discussing here is the use of ipfw's counters in an > unsophisticated setup. The sophisticated setup is already handled. That doesn't mean we shouldn't allow people to have an unsophisticated setup, just because a sophisticated one is available. It would be useful to have a per-firewall-rule counter, decrement it on each match if logging and set, and be able to reset to something higher. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-ipfw" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:Instead of zeroing it, how about raising the logging limit to (current + :whatever the limit was) : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : [EMAIL PROTECTED] _ __ ___ | _ ) __| \ The way I see it either some piece of software is monitor the counters, in which case the sysad does not need to clear them and does not need to look at log messages, or the sysad is monitoring the stuff manually and using the log messages. In the one case the counters don't need to be cleared (and, indeed, should not be), in the other case the sysad may want to clear them due to the manual monitoring. What we are really discussing here is the use of ipfw's counters in an unsophisticated setup. The sophisticated setup is already handled. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
Instead of zeroing it, how about raising the logging limit to (current + whatever the limit was) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Free BSDI CD!
Hi, I am not sure whether this is known to this list or not, but here is the URL for ordering: http://www.bsdi.com/products/evalcd/ _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, Jul 26, 1999 at 05:29:20PM -0700, Doug wrote: > > and installed it the "hard" way, however I know I'm going to run into > trouble down the road when ports start looking for the X stuff in > /var/db/pkg. I seem to remember that you can get away with a simple "mkdir /var/db/pkg/xxx" to fake it. Alternatively, $ cd /usr/ports/x11/XFree86 ; make generate-plist fake-pkg should be a little more correct. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare plug/quickie tests.
> I just wish that it was the other way around. I'd actually run > NT if I could get it in a VMWare compartment under FreeBSD. You would do well to pass these sentiments on to vmware; they're currently counting noses in FreeBSD-land to see if it makes market sense. All the techs there appear to be sold on the idea, but it takes more than tech buy-in to get a project approved. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
XFree 3.3.4 not on ftp.freebsd.org?
I was trying in vain today to get X 3.3.4 installed on my new system and couldn't seem to make it happen using sysinstall, even after I rebuilt it. AFAICS, there is no XFree 3.3.4 package available on ftp.freebsd.org/pub/FreeBSD, but I may have missed something. Fortunately it is on wcarchive, so I just pulled down all the bits and installed it the "hard" way, however I know I'm going to run into trouble down the road when ports start looking for the X stuff in /var/db/pkg. Any comments or suggestions welcome, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Free BSDI CD!
Hi, I am not sure whether this is known to this list or not, but here is the URL for ordering: http://www.bsdi.com/products/evalcd/ _ 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: XFree 3.3.4 not on ftp.freebsd.org?
On Mon, Jul 26, 1999 at 05:29:20PM -0700, Doug wrote: > > and installed it the "hard" way, however I know I'm going to run into > trouble down the road when ports start looking for the X stuff in > /var/db/pkg. I seem to remember that you can get away with a simple "mkdir /var/db/pkg/xxx" to fake it. Alternatively, $ cd /usr/ports/x11/XFree86 ; make generate-plist fake-pkg should be a little more correct. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare plug/quickie tests.
> I just wish that it was the other way around. I'd actually run > NT if I could get it in a VMWare compartment under FreeBSD. You would do well to pass these sentiments on to vmware; they're currently counting noses in FreeBSD-land to see if it makes market sense. All the techs there appear to be sold on the idea, but it takes more than tech buy-in to get a project approved. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
XFree 3.3.4 not on ftp.freebsd.org?
I was trying in vain today to get X 3.3.4 installed on my new system and couldn't seem to make it happen using sysinstall, even after I rebuilt it. AFAICS, there is no XFree 3.3.4 package available on ftp.freebsd.org/pub/FreeBSD, but I may have missed something. Fortunately it is on wcarchive, so I just pulled down all the bits and installed it the "hard" way, however I know I'm going to run into trouble down the road when ports start looking for the X stuff in /var/db/pkg. Any comments or suggestions welcome, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
At 05:02 PM 7/26/99 -0500, Dan Nelson wrote: In the last episode (Jul 26), Sheldon Hearn said: > On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > > You could start with "WinEXE". > > Save game file formats, not game executables. You think WinEXE tops > my pcgames suggestion? What about multi-OS games, like Quake? How about just calling it "games" ? How about the obvious: svgames --larry To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: hot-swapping ata disks
[ I don't know about the IDE code, but I can say something about the SCSI code. ] Iani Brankov wrote... > Hi, > I tried 'camcontrol rescan' and I found it works when I add a SCSI device > while > the system is on. I find it useful for adding/removing devices w/o restarting > the box. (Maybe it's risky, but useful. I supposed that's the idea of the > 'rescan' command in camcontrol) Hot-swapping SCSI devices may or may not be risky. It really depends on your bus topology and whether your setup was designed for it. In general, it's best to only do it in a hot-swap chassis. You can also do it with more conventional cable layouts, provided you don't end up disabling termination or taking something off the bus while I/O is going to it, etc. I wrote a fair bit of the hot swap code with an external CDROM drive in the middle of a terminated external chain. The drive stayed on the chain at all times, but I turned it off and on to make it go away and come back between rescans. > Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI > anyway). I dunno about the IDE code, although I'm sure Soren will have an answer. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
At 05:02 PM 7/26/99 -0500, Dan Nelson wrote: >In the last episode (Jul 26), Sheldon Hearn said: > > On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > > > You could start with "WinEXE". > > > > Save game file formats, not game executables. You think WinEXE tops > > my pcgames suggestion? > >What about multi-OS games, like Quake? How about just calling it >"games" ? How about the obvious: svgames --larry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
hot-swapping ata disks
Hi, I tried 'camcontrol rescan' and I found it works when I add a SCSI device while the system is on. I find it useful for adding/removing devices w/o restarting the box. (Maybe it's risky, but useful. I supposed that's the idea of the 'rescan' command in camcontrol) Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI anyway). Or maybe i'm walking on a wrong way? --iani To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: hot-swapping ata disks
[ I don't know about the IDE code, but I can say something about the SCSI code. ] Iani Brankov wrote... > Hi, > I tried 'camcontrol rescan' and I found it works when I add a SCSI device while > the system is on. I find it useful for adding/removing devices w/o restarting > the box. (Maybe it's risky, but useful. I supposed that's the idea of the > 'rescan' command in camcontrol) Hot-swapping SCSI devices may or may not be risky. It really depends on your bus topology and whether your setup was designed for it. In general, it's best to only do it in a hot-swap chassis. You can also do it with more conventional cable layouts, provided you don't end up disabling termination or taking something off the bus while I/O is going to it, etc. I wrote a fair bit of the hot swap code with an external CDROM drive in the middle of a terminated external chain. The drive stayed on the chain at all times, but I turned it off and on to make it go away and come back between rescans. > Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI > anyway). I dunno about the IDE code, although I'm sure Soren will have an answer. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
In the last episode (Jul 26), Sheldon Hearn said: > On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > > You could start with "WinEXE". > > Save game file formats, not game executables. You think WinEXE tops > my pcgames suggestion? What about multi-OS games, like Quake? How about just calling it "games" ? -- Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > > Having a per-rule limit means that you > > > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" > > > > limit > > > > (assuming an attacker exploits multiple rules) rather than a limit of > > > > "IPFW_VERBOSE_LIMIT". > > > > > > I disagree. I have *tons* of firewall rules, and I don't want to have > > > to recompile my kernel if I modify my script at a later point and make > > > the rules 'more verbose'. > > > > Huh? > > > > I think you completely missed what I said - or maybe the opposite. > > > > Right now, if you have ten "log" rules, I can make your system log up > > to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for > > each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - > > again assuming I can generate appropriate violations. > > > > This eats up a grossly variable amount of disk space, which seems contrary > > to the whole concept of IPFW_VERBOSE_LIMIT. > > If I'm getting attacked such that I'm logging data, I *want* as much > information on the attack as possible. I realize this when I setup my > IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. > > If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, > I'd like to see all of this. With a 'global' limit set to 100, I > wouldn't see these kinds of hits. > > Also, from analyzing attacks for years, most attacks have a pattern that > is *best* seen from seeing it hit a number of rules. By settin a > per-rule limit, you 'generally' can determine that an attack is going to > have a signature the same as the previous 'n' hits on that rule, but you > want to see the rest of the attack. > > I don't care to see a scan of the IMAP 1000 times when right after they > finish scanning it they also try to attack my POP3 port 1000 times. > Rather, I'd rather see the first 100 attempts on the IMAP port, then the > first 100 attempts on POP3, then the first 100 attempts on port 7, > etc... > > You get *better* information on per-rule limits than on a global limit. No, you simply get a finer-grained ability to select. > > If I'm an admin, I'm going to think "Well lets see, I want to store a > > month of bad packets in it. > > If you're an admin on today's internet, you'd realize that there is *NO* > way to get save a month worth of bad packets. Heck, at least once/week > I can't even store a day's worth of bad packets (I assume when we say > bad packets, we're talking about the If I'm an admin on today's internet (and I am), of course I realize that I'm not going to save a month worth of all bad packets, but I _can_ choose to hold onto a reasonable amount of logging information, which is what we are discussing. That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it allows you to sample the beginning of each 5 minute period, and you ought to be able to calculate the space required in a manner that allows you to guarantee that you have sufficient space. Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 10, and you reset the counter every 5 minutes, you still _ought_ to be able to determine that you require 2GB of disk space per day to keep those records. (And if you're getting 100K rejectable packets every 5 minutes, something is seriously wrong) > > I zero > > my counters every five minutes and there is a limit of 100 per five mins, > > and the average line length is 80 (or whatever) so therefore I need 80 * 100 > > * 12 * 24 * 30 or 70MB for my worst case scenario." > > Not. If the attack is the same, then the syslog error reporting will > same something like (this is a real message, with IP addresses change to > protect the guilty..): > > Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out > via ed0 > Jun 29 16:43:44 ns last message repeated 3 times > > If you've got seperate attacks, then you've got too much stuff you're > logging. > > > Now given 200 rules, I can fill his disk in substantially less than a day. > > If you're logging that much information, then you're logging too much > information. In any case, you've got information overload, so adding a > global limit on the rules means you're losing as much (or more) > information than you're logging, which is just as bad (or worse). No. You're not necessarily logging too much information. I do log a whole bunch of shouldn't-happen scenarios, because if they do happen, it means something is either horribly broken or somebody is doing something horribly wrong. I don't want an event such as an outbound source 10-net address to happen... in theory it can't because I filter at my borders and use no 10-net stuff internally. But I damn well want to know if it happens ANYWAYS. > If you're worried about logging too much information, then don't reset > your counters every 5 minutes. Besides, you're losing information if > you're max'd out every 5 minutes anyway, so it really doesn't matter > when you zero out your counters
hot-swapping ata disks
Hi, I tried 'camcontrol rescan' and I found it works when I add a SCSI device while the system is on. I find it useful for adding/removing devices w/o restarting the box. (Maybe it's risky, but useful. I supposed that's the idea of the 'rescan' command in camcontrol) Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI anyway). Or maybe i'm walking on a wrong way? --iani To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > You could start with "WinEXE". Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
> On Mon, 26 Jul 1999 22:17:20 +0200, Mark Murray wrote: > > > "Wintendo" is a bad name for anything official. Try to find MS's > > official name for the format(s). > > You're hoping for a standard name for file formats of games used on > Microsoft platformat? There are two words in that question that one > doesn't usually fine together in a sentence that doesn't contain the > word "bastardize". :-) You could start with "WinEXE". M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Etherboot 2.4 needs newer binutils
I need some wisdom on how to proceed. Since version 2 of Etherboot they are using the new data32 features of the Linux binutils. I know it works in binutils-2.9.1.0.25 which you can get from kernel.org or a mirror such as: http://kernel.stuph.org/pub/linux/devel/gcc I built it on -current after figuring the right host to pass to configure (it doesn't pick it up right without help). I installed the result as-new into /usr/local/bin and then modified the Etherboot Makefile to use it. Now I guess I have 2 questions: 1) When might this feature come into FreeBSD? Do we wait until this comes into the GNU release of binutils? 2) Do I make this a port so we can upgrade to the latest Etherboot release? Since they do a fair amount of active work I would like to track their latest stuff which currently we can't because our gas doesn't support "data32". Thanks, Doug A. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: wd0 DMA errors]
On Mon, 26 Jul 1999, Julian Elischer wrote: > I'm not convinced that this is the same error.. > the message is different.. *Nod* That's the other reason I wrote in about it. As soon as we get some other stuff cleared away I'm going to try building the world on those machines and see if the error resurfaces. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
In the last episode (Jul 26), Sheldon Hearn said: > On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > > You could start with "WinEXE". > > Save game file formats, not game executables. You think WinEXE tops > my pcgames suggestion? What about multi-OS games, like Quake? How about just calling it "games" ? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
new PPP printer for tcpdump
Hi, i've put a new PPP decode/print routine print-ppp.c for tcpdump into my home dir on freefall. It would be good if someone could verify/review it. hellmuth -- Hellmuth Michaelish...@kts.org Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 22:46:31 +0200, Sheldon Hearn wrote: > You're hoping for a standard name for file formats of games used on > Microsoft platformat? Duh, I'm being obtuse. Your question indicates that I've phrased my proposal in such a way as to suggest that this is for formats of Microsoft games. That's not what I meant. I meant games used on the Microsoft platforms. However, it occurs to me that this is stupid, since the same game may be available on multiple PC platforms, all using the same file format. So... how about pcgames as the name of the file? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Pasting data between terminals
On Mon, Jul 26, 1999 at 08:01:22PM +0200, Krzysztof Krawczyk wrote: > Maybe this is a wrong list, so tell me about it, but I think you can help > me :) > > I have small problem. I own two virtual terminals, eg. ttyp1 and ttyp2. > Under ttyp1 I run a program. Now I need to transport big count of datas > from terminal ttyp2 to ttyp1. > When I do: > echo "blah blah" >>/dev/ttyp1 > text "blah blah" appear in virtual terminal ttyp1, but only as a text of > "message". I need ttyp1 count those datas as a "command typed by hand", > not just a text displayed in this term as info. I must transport lots of > data between these terminals. Have you any ideas? 1) Try freebsd-questions in future. 2) Try expect. See http://expect.nist.gov/ . -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 22:17:20 +0200, Mark Murray wrote: > "Wintendo" is a bad name for anything official. Try to find MS's > official name for the format(s). You're hoping for a standard name for file formats of games used on Microsoft platformat? There are two words in that question that one doesn't usually fine together in a sentence that doesn't contain the word "bastardize". :-) I'll try... Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > Having a per-rule limit means that you > > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" > > > limit > > > (assuming an attacker exploits multiple rules) rather than a limit of > > > "IPFW_VERBOSE_LIMIT". > > > > I disagree. I have *tons* of firewall rules, and I don't want to have > > to recompile my kernel if I modify my script at a later point and make > > the rules 'more verbose'. > > Huh? > > I think you completely missed what I said - or maybe the opposite. > > Right now, if you have ten "log" rules, I can make your system log up > to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for > each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - > again assuming I can generate appropriate violations. > > This eats up a grossly variable amount of disk space, which seems contrary > to the whole concept of IPFW_VERBOSE_LIMIT. If I'm getting attacked such that I'm logging data, I *want* as much information on the attack as possible. I realize this when I setup my IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, I'd like to see all of this. With a 'global' limit set to 100, I wouldn't see these kinds of hits. Also, from analyzing attacks for years, most attacks have a pattern that is *best* seen from seeing it hit a number of rules. By settin a per-rule limit, you 'generally' can determine that an attack is going to have a signature the same as the previous 'n' hits on that rule, but you want to see the rest of the attack. I don't care to see a scan of the IMAP 1000 times when right after they finish scanning it they also try to attack my POP3 port 1000 times. Rather, I'd rather see the first 100 attempts on the IMAP port, then the first 100 attempts on POP3, then the first 100 attempts on port 7, etc... You get *better* information on per-rule limits than on a global limit. > If I'm an admin, I'm going to think "Well lets see, I want to store a > month of bad packets in it. If you're an admin on today's internet, you'd realize that there is *NO* way to get save a month worth of bad packets. Heck, at least once/week I can't even store a day's worth of bad packets (I assume when we say bad packets, we're talking about the > I zero > my counters every five minutes and there is a limit of 100 per five mins, > and the average line length is 80 (or whatever) so therefore I need 80 * 100 > * 12 * 24 * 30 or 70MB for my worst case scenario." Not. If the attack is the same, then the syslog error reporting will same something like (this is a real message, with IP addresses change to protect the guilty..): Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 Jun 29 16:43:44 ns last message repeated 3 times If you've got seperate attacks, then you've got too much stuff you're logging. > Now given 200 rules, I can fill his disk in substantially less than a day. If you're logging that much information, then you're logging too much information. In any case, you've got information overload, so adding a global limit on the rules means you're losing as much (or more) information than you're logging, which is just as bad (or worse). If you're worried about logging too much information, then don't reset your counters every 5 minutes. Besides, you're losing information if you're max'd out every 5 minutes anyway, so it really doesn't matter when you zero out your counters. > I don't know what you mean by "make the rules 'more verbose'" but what I > am advocating is not any change in what currently exists... I am talking > about limiting the number of entries possible in a manner that would seem > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most attacks don't hit the entire system on every rule in order to do a DoS attack. Even so, each rule with eventually 'limit-out' and the system will no longer log packets. This is a 'bad thing' from a security standpoint, since at that point we are losing information. The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still allowing *MAXIMUM* data collection when a DoS attack is not happening. It's not there to make your logfiles small. If you want small logfiles, turn of IPFW logging altogether. (I'm actually serious here.) > > Case in point, I may at one time want to 'log' all connections to a > > particular port, and then later ignore (no longer log) all the > > connections to that port *except* to a particular host. Or, the reverse > > may be true. In these cases, I don't want to have to recompile my > > kernel to allow 'more logging' of the information. > > Huh? Why would you have to recompile your kernel? Assuming securelevel < > 3, which is required regardless... you just delete the less restrictive > rule and replace it with a more restrictive rule. I want *
Re: securelevel and ipfw zero
> > > > Having a per-rule limit means that you > > > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > > > > (assuming an attacker exploits multiple rules) rather than a limit of > > > > "IPFW_VERBOSE_LIMIT". > > > > > > I disagree. I have *tons* of firewall rules, and I don't want to have > > > to recompile my kernel if I modify my script at a later point and make > > > the rules 'more verbose'. > > > > Huh? > > > > I think you completely missed what I said - or maybe the opposite. > > > > Right now, if you have ten "log" rules, I can make your system log up > > to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for > > each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - > > again assuming I can generate appropriate violations. > > > > This eats up a grossly variable amount of disk space, which seems contrary > > to the whole concept of IPFW_VERBOSE_LIMIT. > > If I'm getting attacked such that I'm logging data, I *want* as much > information on the attack as possible. I realize this when I setup my > IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. > > If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, > I'd like to see all of this. With a 'global' limit set to 100, I > wouldn't see these kinds of hits. > > Also, from analyzing attacks for years, most attacks have a pattern that > is *best* seen from seeing it hit a number of rules. By settin a > per-rule limit, you 'generally' can determine that an attack is going to > have a signature the same as the previous 'n' hits on that rule, but you > want to see the rest of the attack. > > I don't care to see a scan of the IMAP 1000 times when right after they > finish scanning it they also try to attack my POP3 port 1000 times. > Rather, I'd rather see the first 100 attempts on the IMAP port, then the > first 100 attempts on POP3, then the first 100 attempts on port 7, > etc... > > You get *better* information on per-rule limits than on a global limit. No, you simply get a finer-grained ability to select. > > If I'm an admin, I'm going to think "Well lets see, I want to store a > > month of bad packets in it. > > If you're an admin on today's internet, you'd realize that there is *NO* > way to get save a month worth of bad packets. Heck, at least once/week > I can't even store a day's worth of bad packets (I assume when we say > bad packets, we're talking about the If I'm an admin on today's internet (and I am), of course I realize that I'm not going to save a month worth of all bad packets, but I _can_ choose to hold onto a reasonable amount of logging information, which is what we are discussing. That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it allows you to sample the beginning of each 5 minute period, and you ought to be able to calculate the space required in a manner that allows you to guarantee that you have sufficient space. Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 10, and you reset the counter every 5 minutes, you still _ought_ to be able to determine that you require 2GB of disk space per day to keep those records. (And if you're getting 100K rejectable packets every 5 minutes, something is seriously wrong) > > I zero > > my counters every five minutes and there is a limit of 100 per five mins, > > and the average line length is 80 (or whatever) so therefore I need 80 * 100 > > * 12 * 24 * 30 or 70MB for my worst case scenario." > > Not. If the attack is the same, then the syslog error reporting will > same something like (this is a real message, with IP addresses change to > protect the guilty..): > > Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 > Jun 29 16:43:44 ns last message repeated 3 times > > If you've got seperate attacks, then you've got too much stuff you're > logging. > > > Now given 200 rules, I can fill his disk in substantially less than a day. > > If you're logging that much information, then you're logging too much > information. In any case, you've got information overload, so adding a > global limit on the rules means you're losing as much (or more) > information than you're logging, which is just as bad (or worse). No. You're not necessarily logging too much information. I do log a whole bunch of shouldn't-happen scenarios, because if they do happen, it means something is either horribly broken or somebody is doing something horribly wrong. I don't want an event such as an outbound source 10-net address to happen... in theory it can't because I filter at my borders and use no 10-net stuff internally. But I damn well want to know if it happens ANYWAYS. > If you're worried about logging too much information, then don't reset > your counters every 5 minutes. Besides, you're losing information if > you're max'd out every 5 minutes anyway, so it really doesn't matter > when you zero out your counters. You just
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > You could start with "WinEXE". Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
> On Mon, 26 Jul 1999 22:17:20 +0200, Mark Murray wrote: > > > "Wintendo" is a bad name for anything official. Try to find MS's > > official name for the format(s). > > You're hoping for a standard name for file formats of games used on > Microsoft platformat? There are two words in that question that one > doesn't usually fine together in a sentence that doesn't contain the > word "bastardize". :-) You could start with "WinEXE". M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Etherboot 2.4 needs newer binutils
I need some wisdom on how to proceed. Since version 2 of Etherboot they are using the new data32 features of the Linux binutils. I know it works in binutils-2.9.1.0.25 which you can get from kernel.org or a mirror such as: http://kernel.stuph.org/pub/linux/devel/gcc I built it on -current after figuring the right host to pass to configure (it doesn't pick it up right without help). I installed the result as-new into /usr/local/bin and then modified the Etherboot Makefile to use it. Now I guess I have 2 questions: 1) When might this feature come into FreeBSD? Do we wait until this comes into the GNU release of binutils? 2) Do I make this a port so we can upgrade to the latest Etherboot release? Since they do a fair amount of active work I would like to track their latest stuff which currently we can't because our gas doesn't support "data32". Thanks, Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: wd0 DMA errors]
On Mon, 26 Jul 1999, Julian Elischer wrote: > I'm not convinced that this is the same error.. > the message is different.. *Nod* That's the other reason I wrote in about it. As soon as we get some other stuff cleared away I'm going to try building the world on those machines and see if the error resurfaces. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
TCP/IP hardening
Attached are patches which implement four new sysctl variables: * net.inet.icmp.dropredirect: if set to 1, ignore ICMP REDIRECT packets. * net.inet.icmp.logredirect: if set to 1, log all ICMP REDIRECT packets (before optionally dropping them). * net.inet.tcp.restrict_rst: if set to 1, do not emit TCP RST packets. Conditional on the TCP_RESTRICT_RST kernel option, which defaults to off. * net.inet.tcp.drop_synfin: if set to 1, drop TCP packets with both the SYN and FIN options set. Conditional on the TCP_DROP_SYNFIN kernel option, which defaults to off. The logredirect code uses inet_ntoa, which is a bad idea. I'm open to suggestions for a better solution. Also, these sysctl variables should be described in a man page somewhere, but I'm not sure which one. These patches compile, but are not fully tested. DES -- Dag-Erling Smorgrav - d...@yes.no Index: etc/defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/26 19:11:51 @@ -48,6 +48,11 @@ tcp_extensions="NO"# Set to Yes to turn on RFC1323 extensions. log_in_vain="NO" # Disallow bad connection logging (or YES). tcp_keepalive="YES"# Kill dead TCP connections (or NO). +tcp_restrict_rst="NO" # Set to YES to restrict emission of RST +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +icmp_dropredirect="NO" # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect="NO" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias entry. Index: etc/rc.network === RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/26 19:11:51 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 >/dev/null fi + +if [ "X$icmp_dropredirect" = X"YES" ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 >/dev/null +fi + +if [ "X$icmp_logredirect" = X"YES" ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 >/dev/null +fi if [ "X$gateway_enable" = X"YES" ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,16 @@ if [ "X$tcp_keepalive" = X"YES" ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 >/dev/null +fi + +if [ "X$tcp_restrict_rst" = X"YES" ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 >/dev/null +fi + +if [ "X$tcp_drop_synfin" = X"YES" ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 >/dev/null fi if [ "X$ipxgateway_enable" = X"YES" ]; then Index: sys/conf/options === RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/26 19:11:51 @@ -222,6 +222,8 @@ PPP_FILTER opt_ppp.h TCP_COMPAT_42 opt_compat.h TCPDEBUG +TCP_RESTRICT_RST opt_tcp_input.h +TCP_DROP_SYNFINopt_tcp_input.h IPFILTER opt_ipfilter.h IPFILTER_LOG opt_ipfilter.h SLIP_IFF_OPTS opt_slip.h Index: sys/i386/conf/LINT === RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.620 diff -u -r1.620 LINT --- LINT1999/07/26 05:47:17 1.620 +++ LINT1999/07/26 19:11:51 @@ -465,9 +465,23 @@ optionsIPDIVERT#divert sockets optionsIPFILTER#kernel ipfilter support optionsIPFILTER_LOG#ipfilter logging -#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsIPSTEALTH #support for stealth forwarding +#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsTCPDEBUG + +# The following options add sysctl variables for controlling how certain +# TCP packets are handled. +# +# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. +# This is useful on systems which are exposed to SYN floods (e.g. IRC servers) +# or any system which one does not want to b
Re: file(1) Magdir candidate: wintendo
> So I propose a new file wintendo, for all gaming file formats used on > the MS Windows platform. "Wintendo" is a bad name for anything official. Try to find MS's official name for the format(s). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > :So, I've a box that I have an ipfw ruleset on. The firewall should not > > > be > > > :changeable during runtime, and the box runs at securelevel=3. > > > : > > > :In order to prevent DoS disk-fill attacks, I also have specified > > > :IPFW_VERBOSE_LIMIT. > > FWIW, as you pointed out below, this was put in specifically to avoid a > DoS attack. > > > > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > > > :so basically once you are up and running, you get to log > > > IPFW_VERBOSE_LIMIT > > > :events and then you lose logging (ideally I'd zero nonzero rules once > > > every > > > :N minutes). > > > : > > > :Comments? > > > > > > Playing devil's advocate, someone might be using those counters for > > > accounting purposes. That's about as worse a scenario as I can think > > > of, and I can't imagine this sort of situation would be prevalient. > > > > > > I'd say that the counters should be clearable at high secure level. > > > > Then there should be a separate counter for logging purposes...? I do not > > care if the accounting counters do not clear (ever), since things like MRTG > > are designed to deal with that situation. > > MRTG? multi-router traffic grapher. Put a SNMP interface between that and ipfw and wh instant traffic graphing. > > However, it seems bad that you > > would not be able to clear your counter for logging purposes, just in case > > you actually _did_ mean that you want bad packets to be logged. > > *grin* > > > I will also note that it would be acceptable, to me at least, to maintain a > > global (rather than per-rule) limit for the verbose limit. In general, I > > would think that someone who uses the limit facility is trying to avoid a > > DoS style disk-space attack. > > Agreed, see above. > > > Having a per-rule limit means that you > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > > (assuming an attacker exploits multiple rules) rather than a limit of > > "IPFW_VERBOSE_LIMIT". > > I disagree. I have *tons* of firewall rules, and I don't want to have > to recompile my kernel if I modify my script at a later point and make > the rules 'more verbose'. Huh? I think you completely missed what I said - or maybe the opposite. Right now, if you have ten "log" rules, I can make your system log up to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - again assuming I can generate appropriate violations. This eats up a grossly variable amount of disk space, which seems contrary to the whole concept of IPFW_VERBOSE_LIMIT. If I'm an admin, I'm going to think "Well lets see, I want to store a month of bad packets in it. I zero my counters every five minutes and there is a limit of 100 per five mins, and the average line length is 80 (or whatever) so therefore I need 80 * 100 * 12 * 24 * 30 or 70MB for my worst case scenario." Now given 200 rules, I can fill his disk in substantially less than a day. I don't know what you mean by "make the rules 'more verbose'" but what I am advocating is not any change in what currently exists... I am talking about limiting the number of entries possible in a manner that would seem to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. > Case in point, I may at one time want to 'log' all connections to a > particular port, and then later ignore (no longer log) all the > connections to that port *except* to a particular host. Or, the reverse > may be true. In these cases, I don't want to have to recompile my > kernel to allow 'more logging' of the information. Huh? Why would you have to recompile your kernel? Assuming securelevel < 3, which is required regardless... you just delete the less restrictive rule and replace it with a more restrictive rule. What I am discussing does not affect this at all. If you are afraid of hitting the VERBOSE_LIMIT, that is why you would have an additional command such as "ipfw zerolog". > I think a 'per-rule' limit works best, instead of a global limit. This > also works well in the case of rootkit attempt breakins, since they tend > to hit one rule multiple times, and then another multiple times, etc... > > With a 'global' limit, I may end up 'limiting out' on the first rule, > and then miss all the rules hit later on with the attack. Yes, you might. But you might miss them anyways, and I can run you out of disk space quicker. > > It also makes it more difficult to code in a bunch > > of "log" rules, since your periodic "zero" script has to know the number of > > each one, and if you just do an "ipfw zero rule1 rule2 rule3" then you > > get a bunch of > > > > /kernel: ipfw: Entry rule1 cleared. > > /kernel: ipfw: Entry rule2 cleared. > > /kernel: ipfw: Entry rule3 cleared. > > > > each time you do this. > > Or, you do like I do, and have a cronjob 'zero' out the entire log > ruleset everyn
new PPP printer for tcpdump
Hi, i've put a new PPP decode/print routine print-ppp.c for tcpdump into my home dir on freefall. It would be good if someone could verify/review it. hellmuth -- Hellmuth Michaelis[EMAIL PROTECTED] Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 22:46:31 +0200, Sheldon Hearn wrote: > You're hoping for a standard name for file formats of games used on > Microsoft platformat? Duh, I'm being obtuse. Your question indicates that I've phrased my proposal in such a way as to suggest that this is for formats of Microsoft games. That's not what I meant. I meant games used on the Microsoft platforms. However, it occurs to me that this is stupid, since the same game may be available on multiple PC platforms, all using the same file format. So... how about pcgames as the name of the file? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pasting data between terminals
On Mon, Jul 26, 1999 at 08:01:22PM +0200, Krzysztof Krawczyk wrote: > Maybe this is a wrong list, so tell me about it, but I think you can help > me :) > > I have small problem. I own two virtual terminals, eg. ttyp1 and ttyp2. > Under ttyp1 I run a program. Now I need to transport big count of datas > from terminal ttyp2 to ttyp1. > When I do: > echo "blah blah" >>/dev/ttyp1 > text "blah blah" appear in virtual terminal ttyp1, but only as a text of > "message". I need ttyp1 count those datas as a "command typed by hand", > not just a text displayed in this term as info. I must transport lots of > data between these terminals. Have you any ideas? 1) Try freebsd-questions in future. 2) Try expect. See http://expect.nist.gov/ . -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
On Mon, 26 Jul 1999 22:17:20 +0200, Mark Murray wrote: > "Wintendo" is a bad name for anything official. Try to find MS's > official name for the format(s). You're hoping for a standard name for file formats of games used on Microsoft platformat? There are two words in that question that one doesn't usually fine together in a sentence that doesn't contain the word "bastardize". :-) I'll try... Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > Having a per-rule limit means that you > > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > > > (assuming an attacker exploits multiple rules) rather than a limit of > > > "IPFW_VERBOSE_LIMIT". > > > > I disagree. I have *tons* of firewall rules, and I don't want to have > > to recompile my kernel if I modify my script at a later point and make > > the rules 'more verbose'. > > Huh? > > I think you completely missed what I said - or maybe the opposite. > > Right now, if you have ten "log" rules, I can make your system log up > to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for > each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - > again assuming I can generate appropriate violations. > > This eats up a grossly variable amount of disk space, which seems contrary > to the whole concept of IPFW_VERBOSE_LIMIT. If I'm getting attacked such that I'm logging data, I *want* as much information on the attack as possible. I realize this when I setup my IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, I'd like to see all of this. With a 'global' limit set to 100, I wouldn't see these kinds of hits. Also, from analyzing attacks for years, most attacks have a pattern that is *best* seen from seeing it hit a number of rules. By settin a per-rule limit, you 'generally' can determine that an attack is going to have a signature the same as the previous 'n' hits on that rule, but you want to see the rest of the attack. I don't care to see a scan of the IMAP 1000 times when right after they finish scanning it they also try to attack my POP3 port 1000 times. Rather, I'd rather see the first 100 attempts on the IMAP port, then the first 100 attempts on POP3, then the first 100 attempts on port 7, etc... You get *better* information on per-rule limits than on a global limit. > If I'm an admin, I'm going to think "Well lets see, I want to store a > month of bad packets in it. If you're an admin on today's internet, you'd realize that there is *NO* way to get save a month worth of bad packets. Heck, at least once/week I can't even store a day's worth of bad packets (I assume when we say bad packets, we're talking about the > I zero > my counters every five minutes and there is a limit of 100 per five mins, > and the average line length is 80 (or whatever) so therefore I need 80 * 100 > * 12 * 24 * 30 or 70MB for my worst case scenario." Not. If the attack is the same, then the syslog error reporting will same something like (this is a real message, with IP addresses change to protect the guilty..): Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 Jun 29 16:43:44 ns last message repeated 3 times If you've got seperate attacks, then you've got too much stuff you're logging. > Now given 200 rules, I can fill his disk in substantially less than a day. If you're logging that much information, then you're logging too much information. In any case, you've got information overload, so adding a global limit on the rules means you're losing as much (or more) information than you're logging, which is just as bad (or worse). If you're worried about logging too much information, then don't reset your counters every 5 minutes. Besides, you're losing information if you're max'd out every 5 minutes anyway, so it really doesn't matter when you zero out your counters. > I don't know what you mean by "make the rules 'more verbose'" but what I > am advocating is not any change in what currently exists... I am talking > about limiting the number of entries possible in a manner that would seem > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most attacks don't hit the entire system on every rule in order to do a DoS attack. Even so, each rule with eventually 'limit-out' and the system will no longer log packets. This is a 'bad thing' from a security standpoint, since at that point we are losing information. The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still allowing *MAXIMUM* data collection when a DoS attack is not happening. It's not there to make your logfiles small. If you want small logfiles, turn of IPFW logging altogether. (I'm actually serious here.) > > Case in point, I may at one time want to 'log' all connections to a > > particular port, and then later ignore (no longer log) all the > > connections to that port *except* to a particular host. Or, the reverse > > may be true. In these cases, I don't want to have to recompile my > > kernel to allow 'more logging' of the information. > > Huh? Why would you have to recompile your kernel? Assuming securelevel < > 3, which is required regardless... you just delete the less restrictive > rule and replace it with a more restrictive rule. I want *both* r
Re: securelevel and ipfw zero
> > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > > :changeable during runtime, and the box runs at securelevel=3. > > : > > :In order to prevent DoS disk-fill attacks, I also have specified > > :IPFW_VERBOSE_LIMIT. FWIW, as you pointed out below, this was put in specifically to avoid a DoS attack. > > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > > :events and then you lose logging (ideally I'd zero nonzero rules once every > > :N minutes). > > : > > :Comments? > > > > Playing devil's advocate, someone might be using those counters for > > accounting purposes. That's about as worse a scenario as I can think > > of, and I can't imagine this sort of situation would be prevalient. > > > > I'd say that the counters should be clearable at high secure level. > > Then there should be a separate counter for logging purposes...? I do not > care if the accounting counters do not clear (ever), since things like MRTG > are designed to deal with that situation. MRTG? > However, it seems bad that you > would not be able to clear your counter for logging purposes, just in case > you actually _did_ mean that you want bad packets to be logged. *grin* > I will also note that it would be acceptable, to me at least, to maintain a > global (rather than per-rule) limit for the verbose limit. In general, I > would think that someone who uses the limit facility is trying to avoid a > DoS style disk-space attack. Agreed, see above. > Having a per-rule limit means that you > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > (assuming an attacker exploits multiple rules) rather than a limit of > "IPFW_VERBOSE_LIMIT". I disagree. I have *tons* of firewall rules, and I don't want to have to recompile my kernel if I modify my script at a later point and make the rules 'more verbose'. Case in point, I may at one time want to 'log' all connections to a particular port, and then later ignore (no longer log) all the connections to that port *except* to a particular host. Or, the reverse may be true. In these cases, I don't want to have to recompile my kernel to allow 'more logging' of the information. I think a 'per-rule' limit works best, instead of a global limit. This also works well in the case of rootkit attempt breakins, since they tend to hit one rule multiple times, and then another multiple times, etc... With a 'global' limit, I may end up 'limiting out' on the first rule, and then miss all the rules hit later on with the attack. > It also makes it more difficult to code in a bunch > of "log" rules, since your periodic "zero" script has to know the number of > each one, and if you just do an "ipfw zero rule1 rule2 rule3" then you > get a bunch of > > /kernel: ipfw: Entry rule1 cleared. > /kernel: ipfw: Entry rule2 cleared. > /kernel: ipfw: Entry rule3 cleared. > > each time you do this. Or, you do like I do, and have a cronjob 'zero' out the entire log ruleset everynight right after it sends the results to me to analyze. However, at times (during breakins I happen to catch, or during ruleset debugging sessions) I still want to have control over individual rules. > I would rather see something like > > /kernel: ipfw: logging limit reached, suspending. > # /sbin/ipfw zerolog > /kernel: ipfw: logging limit reset, resuming. This is essentially what I do. But, you can do 'ipfw zero' which accomplishes the same thing. However, this is really a side-issue. The last thing I'll say is that I think a 'global' counter is a bad idea, and this is from using IPFW for years in a real/deployed FreeBSD firewall situation. It would cause me more trouble than it's worth, and provide 'less' flexibility than currently exists (which I use). The real issue from your first email is '*should* ipfw rules be 'zero-able' at securelevel 3'. I'm of two minds. The paranoid administrator can't think of any bad things that could occur, but I can imagine something bad happening if someone were allowed to do this, although it's not completely concrete. I don't have the brain-cells to dedicate to thinking about the full implications of a 'bad-guy' zeroing out my rules. On the other, the firewall administrator who actually has to use this darn system is less worried about breakins and such, thinking that if someone compromised my system at high securelevels, they could do more damage to my system in other ways than by zeroing out my firewall numbers. But, then again if we're in securelevel 3, we shouldn't let *anyone* do anything to the system, since we're paranoid about anything negative happening to my system. In other words, I'm not sure what is the 'right' thing to do here. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
DPT SmartRAID V (i2o) Status
Hi Y'll Several of you ask, so here is a generic answer; I am actively working on i2o subsystem for FreeBSD. The reference card for this work is the DPT 5th Generation controllers. Status: Much of the work, particularly IRT DPT controllers is complete. All the mechanics and kernel modifications to allow recognition of i2o card and in particular DPT cards is in place. I am able, routinely to: * Detect the cards * Negotiate setup and configuration * Initialize the IOP * Build a list of all devices known * Query device attributes and capabilities * Notify the kernel of known devices * Accept block I/O requests, send to the IOP, return results. * Accept character (raw) device I/O requests, translate to Block I/O requests, process and reply. * Still to be done: * Complete debugging disklabel code. * Add fdisk slice code * Mature and stabilize error handling * Complete port of dptutil (RAID management. Most Helpful Help: Fdisk Slice, disklabel, and devfs code completion. Personal Note; I am so swamped with work that I have little time, if any, for participation in mailing list activities. This is NOT to say that I am not active in FreeBSD, or the i2o project. If you need me, or like to chat, drop me a line! -- Sincerely Yours, Simon Shapiro Research FellowMindSpring Enterprises shapi...@mindspring.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
TCP/IP hardening
Attached are patches which implement four new sysctl variables: * net.inet.icmp.dropredirect: if set to 1, ignore ICMP REDIRECT packets. * net.inet.icmp.logredirect: if set to 1, log all ICMP REDIRECT packets (before optionally dropping them). * net.inet.tcp.restrict_rst: if set to 1, do not emit TCP RST packets. Conditional on the TCP_RESTRICT_RST kernel option, which defaults to off. * net.inet.tcp.drop_synfin: if set to 1, drop TCP packets with both the SYN and FIN options set. Conditional on the TCP_DROP_SYNFIN kernel option, which defaults to off. The logredirect code uses inet_ntoa, which is a bad idea. I'm open to suggestions for a better solution. Also, these sysctl variables should be described in a man page somewhere, but I'm not sure which one. These patches compile, but are not fully tested. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] Index: etc/defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/26 19:11:51 @@ -48,6 +48,11 @@ tcp_extensions="NO"# Set to Yes to turn on RFC1323 extensions. log_in_vain="NO" # Disallow bad connection logging (or YES). tcp_keepalive="YES"# Kill dead TCP connections (or NO). +tcp_restrict_rst="NO" # Set to YES to restrict emission of RST +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +icmp_dropredirect="NO" # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect="NO" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias entry. Index: etc/rc.network === RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/26 19:11:51 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 >/dev/null fi + +if [ "X$icmp_dropredirect" = X"YES" ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 >/dev/null +fi + +if [ "X$icmp_logredirect" = X"YES" ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 >/dev/null +fi if [ "X$gateway_enable" = X"YES" ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,16 @@ if [ "X$tcp_keepalive" = X"YES" ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 >/dev/null +fi + +if [ "X$tcp_restrict_rst" = X"YES" ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 >/dev/null +fi + +if [ "X$tcp_drop_synfin" = X"YES" ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 >/dev/null fi if [ "X$ipxgateway_enable" = X"YES" ]; then Index: sys/conf/options === RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/26 19:11:51 @@ -222,6 +222,8 @@ PPP_FILTER opt_ppp.h TCP_COMPAT_42 opt_compat.h TCPDEBUG +TCP_RESTRICT_RST opt_tcp_input.h +TCP_DROP_SYNFINopt_tcp_input.h IPFILTER opt_ipfilter.h IPFILTER_LOG opt_ipfilter.h SLIP_IFF_OPTS opt_slip.h Index: sys/i386/conf/LINT === RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.620 diff -u -r1.620 LINT --- LINT1999/07/26 05:47:17 1.620 +++ LINT1999/07/26 19:11:51 @@ -465,9 +465,23 @@ optionsIPDIVERT#divert sockets optionsIPFILTER#kernel ipfilter support optionsIPFILTER_LOG#ipfilter logging -#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsIPSTEALTH #support for stealth forwarding +#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsTCPDEBUG + +# The following options add sysctl variables for controlling how certain +# TCP packets are handled. +# +# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. +# This is useful on systems which are exposed to SYN floods (e.g. IRC servers) +# or any system which one does not wan
Re: file(1) Magdir candidate: wintendo
> So I propose a new file wintendo, for all gaming file formats used on > the MS Windows platform. "Wintendo" is a bad name for anything official. Try to find MS's official name for the format(s). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > > > :changeable during runtime, and the box runs at securelevel=3. > > > : > > > :In order to prevent DoS disk-fill attacks, I also have specified > > > :IPFW_VERBOSE_LIMIT. > > FWIW, as you pointed out below, this was put in specifically to avoid a > DoS attack. > > > > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > > > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > > > :events and then you lose logging (ideally I'd zero nonzero rules once every > > > :N minutes). > > > : > > > :Comments? > > > > > > Playing devil's advocate, someone might be using those counters for > > > accounting purposes. That's about as worse a scenario as I can think > > > of, and I can't imagine this sort of situation would be prevalient. > > > > > > I'd say that the counters should be clearable at high secure level. > > > > Then there should be a separate counter for logging purposes...? I do not > > care if the accounting counters do not clear (ever), since things like MRTG > > are designed to deal with that situation. > > MRTG? multi-router traffic grapher. Put a SNMP interface between that and ipfw and wh instant traffic graphing. > > However, it seems bad that you > > would not be able to clear your counter for logging purposes, just in case > > you actually _did_ mean that you want bad packets to be logged. > > *grin* > > > I will also note that it would be acceptable, to me at least, to maintain a > > global (rather than per-rule) limit for the verbose limit. In general, I > > would think that someone who uses the limit facility is trying to avoid a > > DoS style disk-space attack. > > Agreed, see above. > > > Having a per-rule limit means that you > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > > (assuming an attacker exploits multiple rules) rather than a limit of > > "IPFW_VERBOSE_LIMIT". > > I disagree. I have *tons* of firewall rules, and I don't want to have > to recompile my kernel if I modify my script at a later point and make > the rules 'more verbose'. Huh? I think you completely missed what I said - or maybe the opposite. Right now, if you have ten "log" rules, I can make your system log up to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - again assuming I can generate appropriate violations. This eats up a grossly variable amount of disk space, which seems contrary to the whole concept of IPFW_VERBOSE_LIMIT. If I'm an admin, I'm going to think "Well lets see, I want to store a month of bad packets in it. I zero my counters every five minutes and there is a limit of 100 per five mins, and the average line length is 80 (or whatever) so therefore I need 80 * 100 * 12 * 24 * 30 or 70MB for my worst case scenario." Now given 200 rules, I can fill his disk in substantially less than a day. I don't know what you mean by "make the rules 'more verbose'" but what I am advocating is not any change in what currently exists... I am talking about limiting the number of entries possible in a manner that would seem to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. > Case in point, I may at one time want to 'log' all connections to a > particular port, and then later ignore (no longer log) all the > connections to that port *except* to a particular host. Or, the reverse > may be true. In these cases, I don't want to have to recompile my > kernel to allow 'more logging' of the information. Huh? Why would you have to recompile your kernel? Assuming securelevel < 3, which is required regardless... you just delete the less restrictive rule and replace it with a more restrictive rule. What I am discussing does not affect this at all. If you are afraid of hitting the VERBOSE_LIMIT, that is why you would have an additional command such as "ipfw zerolog". > I think a 'per-rule' limit works best, instead of a global limit. This > also works well in the case of rootkit attempt breakins, since they tend > to hit one rule multiple times, and then another multiple times, etc... > > With a 'global' limit, I may end up 'limiting out' on the first rule, > and then miss all the rules hit later on with the attack. Yes, you might. But you might miss them anyways, and I can run you out of disk space quicker. > > It also makes it more difficult to code in a bunch > > of "log" rules, since your periodic "zero" script has to know the number of > > each one, and if you just do an "ipfw zero rule1 rule2 rule3" then you > > get a bunch of > > > > /kernel: ipfw: Entry rule1 cleared. > > /kernel: ipfw: Entry rule2 cleared. > > /kernel: ipfw: Entry rule3 cleared. > > > > each time you do this. > > Or, you do like I do, and have a cronjob 'zero' out the entire log > ruleset everynight right after it
Re: securelevel and ipfw zero
> :Hello, > : > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > :changeable during runtime, and the box runs at securelevel=3. > : > :In order to prevent DoS disk-fill attacks, I also have specified > :IPFW_VERBOSE_LIMIT. > : > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > :events and then you lose logging (ideally I'd zero nonzero rules once every > :N minutes). > : > :Comments? > > Playing devil's advocate, someone might be using those counters for > accounting purposes. That's about as worse a scenario as I can think > of, and I can't imagine this sort of situation would be prevalient. > > I'd say that the counters should be clearable at high secure level. Then there should be a separate counter for logging purposes...? I do not care if the accounting counters do not clear (ever), since things like MRTG are designed to deal with that situation. However, it seems bad that you would not be able to clear your counter for logging purposes, just in case you actually _did_ mean that you want bad packets to be logged. I will also note that it would be acceptable, to me at least, to maintain a global (rather than per-rule) limit for the verbose limit. In general, I would think that someone who uses the limit facility is trying to avoid a DoS style disk-space attack. Having a per-rule limit means that you actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit (assuming an attacker exploits multiple rules) rather than a limit of "IPFW_VERBOSE_LIMIT". It also makes it more difficult to code in a bunch of "log" rules, since your periodic "zero" script has to know the number of each one, and if you just do an "ipfw zero rule1 rule2 rule3" then you get a bunch of /kernel: ipfw: Entry rule1 cleared. /kernel: ipfw: Entry rule2 cleared. /kernel: ipfw: Entry rule3 cleared. each time you do this. I would rather see something like /kernel: ipfw: logging limit reached, suspending. # /sbin/ipfw zerolog /kernel: ipfw: logging limit reset, resuming. I can deal with it (in code) if there is a per-rule log counter as well, but what you are telling me makes it sound more attractive to have a global logging counter. Comments? ... Joe --- Joe Greco - Systems Administrator jgr...@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > > :changeable during runtime, and the box runs at securelevel=3. > > : > > :In order to prevent DoS disk-fill attacks, I also have specified > > :IPFW_VERBOSE_LIMIT. FWIW, as you pointed out below, this was put in specifically to avoid a DoS attack. > > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > > :events and then you lose logging (ideally I'd zero nonzero rules once every > > :N minutes). > > : > > :Comments? > > > > Playing devil's advocate, someone might be using those counters for > > accounting purposes. That's about as worse a scenario as I can think > > of, and I can't imagine this sort of situation would be prevalient. > > > > I'd say that the counters should be clearable at high secure level. > > Then there should be a separate counter for logging purposes...? I do not > care if the accounting counters do not clear (ever), since things like MRTG > are designed to deal with that situation. MRTG? > However, it seems bad that you > would not be able to clear your counter for logging purposes, just in case > you actually _did_ mean that you want bad packets to be logged. *grin* > I will also note that it would be acceptable, to me at least, to maintain a > global (rather than per-rule) limit for the verbose limit. In general, I > would think that someone who uses the limit facility is trying to avoid a > DoS style disk-space attack. Agreed, see above. > Having a per-rule limit means that you > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > (assuming an attacker exploits multiple rules) rather than a limit of > "IPFW_VERBOSE_LIMIT". I disagree. I have *tons* of firewall rules, and I don't want to have to recompile my kernel if I modify my script at a later point and make the rules 'more verbose'. Case in point, I may at one time want to 'log' all connections to a particular port, and then later ignore (no longer log) all the connections to that port *except* to a particular host. Or, the reverse may be true. In these cases, I don't want to have to recompile my kernel to allow 'more logging' of the information. I think a 'per-rule' limit works best, instead of a global limit. This also works well in the case of rootkit attempt breakins, since they tend to hit one rule multiple times, and then another multiple times, etc... With a 'global' limit, I may end up 'limiting out' on the first rule, and then miss all the rules hit later on with the attack. > It also makes it more difficult to code in a bunch > of "log" rules, since your periodic "zero" script has to know the number of > each one, and if you just do an "ipfw zero rule1 rule2 rule3" then you > get a bunch of > > /kernel: ipfw: Entry rule1 cleared. > /kernel: ipfw: Entry rule2 cleared. > /kernel: ipfw: Entry rule3 cleared. > > each time you do this. Or, you do like I do, and have a cronjob 'zero' out the entire log ruleset everynight right after it sends the results to me to analyze. However, at times (during breakins I happen to catch, or during ruleset debugging sessions) I still want to have control over individual rules. > I would rather see something like > > /kernel: ipfw: logging limit reached, suspending. > # /sbin/ipfw zerolog > /kernel: ipfw: logging limit reset, resuming. This is essentially what I do. But, you can do 'ipfw zero' which accomplishes the same thing. However, this is really a side-issue. The last thing I'll say is that I think a 'global' counter is a bad idea, and this is from using IPFW for years in a real/deployed FreeBSD firewall situation. It would cause me more trouble than it's worth, and provide 'less' flexibility than currently exists (which I use). The real issue from your first email is '*should* ipfw rules be 'zero-able' at securelevel 3'. I'm of two minds. The paranoid administrator can't think of any bad things that could occur, but I can imagine something bad happening if someone were allowed to do this, although it's not completely concrete. I don't have the brain-cells to dedicate to thinking about the full implications of a 'bad-guy' zeroing out my rules. On the other, the firewall administrator who actually has to use this darn system is less worried about breakins and such, thinking that if someone compromised my system at high securelevels, they could do more damage to my system in other ways than by zeroing out my firewall numbers. But, then again if we're in securelevel 3, we shouldn't let *anyone* do anything to the system, since we're paranoid about anything negative happening to my system. In other words, I'm not sure what is the 'right' thing to do here. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:Hello, : :So, I've a box that I have an ipfw ruleset on. The firewall should not be :changeable during runtime, and the box runs at securelevel=3. : :In order to prevent DoS disk-fill attacks, I also have specified :IPFW_VERBOSE_LIMIT. : :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT :events and then you lose logging (ideally I'd zero nonzero rules once every :N minutes). : :Comments? : :... Joe : :--- :Joe Greco - Systems Administratorjgr...@ns.sol.net Playing devil's advocate, someone might be using those counters for accounting purposes. That's about as worse a scenario as I can think of, and I can't imagine this sort of situation would be prevalient. I'd say that the counters should be clearable at high secure level. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
DPT SmartRAID V (i2o) Status
Hi Y'll Several of you ask, so here is a generic answer; I am actively working on i2o subsystem for FreeBSD. The reference card for this work is the DPT 5th Generation controllers. Status: Much of the work, particularly IRT DPT controllers is complete. All the mechanics and kernel modifications to allow recognition of i2o card and in particular DPT cards is in place. I am able, routinely to: * Detect the cards * Negotiate setup and configuration * Initialize the IOP * Build a list of all devices known * Query device attributes and capabilities * Notify the kernel of known devices * Accept block I/O requests, send to the IOP, return results. * Accept character (raw) device I/O requests, translate to Block I/O requests, process and reply. * Still to be done: * Complete debugging disklabel code. * Add fdisk slice code * Mature and stabilize error handling * Complete port of dptutil (RAID management. Most Helpful Help: Fdisk Slice, disklabel, and devfs code completion. Personal Note; I am so swamped with work that I have little time, if any, for participation in mailing list activities. This is NOT to say that I am not active in FreeBSD, or the i2o project. If you need me, or like to chat, drop me a line! -- Sincerely Yours, Simon Shapiro Research FellowMindSpring Enterprises [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
securelevel and ipfw zero
Hello, So, I've a box that I have an ipfw ruleset on. The firewall should not be changeable during runtime, and the box runs at securelevel=3. In order to prevent DoS disk-fill attacks, I also have specified IPFW_VERBOSE_LIMIT. Now, the problem is, in securelevel 3, you cannot zero a rule's counter, so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT events and then you lose logging (ideally I'd zero nonzero rules once every N minutes). Comments? ... Joe --- Joe Greco - Systems Administrator jgr...@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: wd0 DMA errors]
I'm not convinced that this is the same error.. the message is different.. On Sun, 25 Jul 1999, Doug wrote: > Sheldon Hearn wrote: > > > > On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: > > > > > No answer on -current, any help appreciated. > > > > We're probably all sitting here thinking "I'm sure this was asked and > > answered recently. He can read his CURRENT mail like the rest of us." > > I have indeed read my -current mail. Several bugs in the PCI and DMA > code > have been mentioned in the past week, but frankly I don't have enough > expertise in either to know for sure that the bugs mentioned would produce > the error messages I saw. A simple, "yes, those were the bugs fixed > recently" is all that was needed. > > Thank you, > > Doug > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
:Hello, : :So, I've a box that I have an ipfw ruleset on. The firewall should not be :changeable during runtime, and the box runs at securelevel=3. : :In order to prevent DoS disk-fill attacks, I also have specified :IPFW_VERBOSE_LIMIT. : :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT :events and then you lose logging (ideally I'd zero nonzero rules once every :N minutes). : :Comments? : :... Joe : :--- :Joe Greco - Systems Administrator[EMAIL PROTECTED] Playing devil's advocate, someone might be using those counters for accounting purposes. That's about as worse a scenario as I can think of, and I can't imagine this sort of situation would be prevalient. I'd say that the counters should be clearable at high secure level. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> :Hello, > : > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > :changeable during runtime, and the box runs at securelevel=3. > : > :In order to prevent DoS disk-fill attacks, I also have specified > :IPFW_VERBOSE_LIMIT. > : > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > :events and then you lose logging (ideally I'd zero nonzero rules once every > :N minutes). > : > :Comments? > > Playing devil's advocate, someone might be using those counters for > accounting purposes. That's about as worse a scenario as I can think > of, and I can't imagine this sort of situation would be prevalient. > > I'd say that the counters should be clearable at high secure level. Then there should be a separate counter for logging purposes...? I do not care if the accounting counters do not clear (ever), since things like MRTG are designed to deal with that situation. However, it seems bad that you would not be able to clear your counter for logging purposes, just in case you actually _did_ mean that you want bad packets to be logged. I will also note that it would be acceptable, to me at least, to maintain a global (rather than per-rule) limit for the verbose limit. In general, I would think that someone who uses the limit facility is trying to avoid a DoS style disk-space attack. Having a per-rule limit means that you actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit (assuming an attacker exploits multiple rules) rather than a limit of "IPFW_VERBOSE_LIMIT". It also makes it more difficult to code in a bunch of "log" rules, since your periodic "zero" script has to know the number of each one, and if you just do an "ipfw zero rule1 rule2 rule3" then you get a bunch of /kernel: ipfw: Entry rule1 cleared. /kernel: ipfw: Entry rule2 cleared. /kernel: ipfw: Entry rule3 cleared. each time you do this. I would rather see something like /kernel: ipfw: logging limit reached, suspending. # /sbin/ipfw zerolog /kernel: ipfw: logging limit reset, resuming. I can deal with it (in code) if there is a per-rule log counter as well, but what you are telling me makes it sound more attractive to have a global logging counter. Comments? ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Wavelan-WavepointII
Yes, we have had good success with WaveLAN/IEEE Turbo cards using the wi driver in both ad-hoc mode and infrastructure mode with a WavepointII. NAT will work on the wi interface, SKIP will not. While we run IP routing instead of bridging, the underlying concept is bridging if you really mean that. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Mon, 26 Jul 1999, Kirk McDonald wrote: > Hello, > > I am wondering if anyone has had success running bridging only between a > wavelan IEEE802.11 in a BSD machine and a WavepointII using an > IEEE802.11 card. I have had great succes using purely wavelan/BSD. > > Kirk McDonald > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Pasting data between terminals
hello Maybe this is a wrong list, so tell me about it, but I think you can help me :) I have small problem. I own two virtual terminals, eg. ttyp1 and ttyp2. Under ttyp1 I run a program. Now I need to transport big count of datas from terminal ttyp2 to ttyp1. When I do: echo "blah blah" >>/dev/ttyp1 text "blah blah" appear in virtual terminal ttyp1, but only as a text of "message". I need ttyp1 count those datas as a "command typed by hand", not just a text displayed in this term as info. I must transport lots of data between these terminals. Have you any ideas? Cys - Krzysztof Krawczyk IRC on DALnet: #polska #polcafe #wroclaw c...@for.lames.access.is.denied.cx -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "What sane person could live in this world and not be crazy?" -- Ursula K. LeGuin -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
securelevel and ipfw zero
Hello, So, I've a box that I have an ipfw ruleset on. The firewall should not be changeable during runtime, and the box runs at securelevel=3. In order to prevent DoS disk-fill attacks, I also have specified IPFW_VERBOSE_LIMIT. Now, the problem is, in securelevel 3, you cannot zero a rule's counter, so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT events and then you lose logging (ideally I'd zero nonzero rules once every N minutes). Comments? ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: wd0 DMA errors]
I'm not convinced that this is the same error.. the message is different.. On Sun, 25 Jul 1999, Doug wrote: > Sheldon Hearn wrote: > > > > On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: > > > > > No answer on -current, any help appreciated. > > > > We're probably all sitting here thinking "I'm sure this was asked and > > answered recently. He can read his CURRENT mail like the rest of us." > > I have indeed read my -current mail. Several bugs in the PCI and DMA code > have been mentioned in the past week, but frankly I don't have enough > expertise in either to know for sure that the bugs mentioned would produce > the error messages I saw. A simple, "yes, those were the bugs fixed > recently" is all that was needed. > > Thank you, > > Doug > > > 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: Wavelan-WavepointII
Yes, we have had good success with WaveLAN/IEEE Turbo cards using the wi driver in both ad-hoc mode and infrastructure mode with a WavepointII. NAT will work on the wi interface, SKIP will not. While we run IP routing instead of bridging, the underlying concept is bridging if you really mean that. Jim Flowers <[EMAIL PROTECTED]> #4 ISP on C|NET, #1 in Ohio On Mon, 26 Jul 1999, Kirk McDonald wrote: > Hello, > > I am wondering if anyone has had success running bridging only between a > wavelan IEEE802.11 in a BSD machine and a WavepointII using an > IEEE802.11 card. I have had great succes using purely wavelan/BSD. > > Kirk McDonald > > > 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: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
:On Mon, Jul 26, 1999, Nate Williams wrote: :> > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables :> > > in FreeBSD. :> > :> > But the point being made is that they are not ignored for executables :> > which have no read access. And from there, read access can be gained, :> > because at that point, you have code running in the process's address :> > space. :> :> That's right. In other words, there really is no way of protecting :> executable files from being read if someone is motivated enough. :> :> And, in an open-source OS like FreeBSD, it's not a viable solution in :> any case : : The only option, as I've mentined previously in this thread, :that I can think of, would be to have an option when building :various linker code to disable searching in $LD_LIBRARY_PATH if :the library being looked for is in the standard library paths. : :-- :|Chris Costello LD_LIBRARY_PATH was a huge security hole when it was first introduced and you know what? It STILL IS! We are opening up a can of worms here. It's one of those things where we either have to make the decision to try to protect the binary that the owner decided to make execute-only, or to give up. * LD_LIBRARY_PATH? * core dumps for execute-only binaries? * ktrace for execute-only binaries? If I were to put my foot down I would say off with their heads! i.e. disallow all three if the non-root-run binary is execute-only. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Pasting data between terminals
hello Maybe this is a wrong list, so tell me about it, but I think you can help me :) I have small problem. I own two virtual terminals, eg. ttyp1 and ttyp2. Under ttyp1 I run a program. Now I need to transport big count of datas from terminal ttyp2 to ttyp1. When I do: echo "blah blah" >>/dev/ttyp1 text "blah blah" appear in virtual terminal ttyp1, but only as a text of "message". I need ttyp1 count those datas as a "command typed by hand", not just a text displayed in this term as info. I must transport lots of data between these terminals. Have you any ideas? Cys - Krzysztof Krawczyk IRC on DALnet: #polska #polcafe #wroclaw [EMAIL PROTECTED] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "What sane person could live in this world and not be crazy?" -- Ursula K. LeGuin -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
