Re: kernel settings for pf default block
Hello Joachim, Sorry I could not get on internet the answer from Alexey. Can you please give the URL for this. Also please confirm that there is no kernel parameter to make pf block everything by default. Thanks in advance murthy Joachim Schipper wrote: > On Mon, Jul 03, 2006 at 05:30:44PM -0700, c.s.r.c.murthy wrote: > >>Hi, >>This seems to be widely discussed problem in openbsd pf. There is no >>kernel parameter that makes the pf to block all packets by default. I >>have searched on the internet and found some discussion taken place in >>2005 regarding this. The discussion concludes no such parameter in >>kernel. Are there any changes done in openbsd latest to have a kernel >>configurable parameter to make pf block packets by default? > > > Alexey already answered this, why do you repost it? > > Joachim [demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a name of murthy.4807DEFANGED-vcf]
MD5
Theo, Also the last I checked obsd still supports MD5 CU Chet Uber President and Principal Scientist SecurityPosture, Inc. 3718 N 113th Plaza, Omaha, NE 68164 vox +1 (402) 505-9684 | fax +1 (402) 932-2130 | cell (402) 813-3211 [EMAIL PROTECTED] | www.securityposture.com 'It is vain to do with more what can be done with fewer' -- This communication is confidential to the parties it was intended to serve --
Re: Preventing password reuse
On Tue, Jul 04, 2006 at 02:29:56AM -0400, Chet Uber wrote: > NP-complete problems are the most difficult complexity problems. No, NP-complete problems are the most difficult problems _in NP_.
Re: Preventing password reuse
Not to bicker, but the resources needed to use a database of all possible passwords even with alphanumerics and salted is very finite -- albeit large. OpenBSD's blowfish passwords have 128-bits of salt. A table of all 8 character (lower-case only) alphanumeric passwords would require 2^128 * (26+10)^8 ~= 9.6*10^50 entries. Being ``very finite'' is irrelevant at this order of magnitude. The term used earlier was nearly infinite, I used very finite because it is bounded -- which infinities are not. There are as you know multiple infinite sets that have no common members. Just don't want people to think that they are safe as is not an NP- complete problem. It is an NP-hard problem however. You are aware NP-complete problems are, by definition, reducible to NP-hard problems, right? In other words, NP-hard problems are ``harder'' than NP-complete ones. I should have properly stated that it is not an NP-complete problem but an NP one. NP-complete problems are the most difficult complexity problems. CU
Re: Preventing password reuse
Not to bicker, but the resources needed to use a database of all possible passwords even with alphanumerics and salted is very finite -- albeit large. OpenBSD blowfish hashes have 16 bytes of salt, so a database of these will not be feasible for a while. I agree that for all but those with the most powerful computing environments this is not something they are going to accomplish My point really was to clarify that infinite and finite should be used appropriately, and that intractable and uncomputable also are not the same. Sometimes these conversations get long and the words NP- complete, suffering the halting problem and an infinite search space should be used carefully. It makes our communications between ourselves that much more effective and accurate. You are right on that the feasibility of all but the most well funded adversaries can accomplish this, but it is not NP-complete, uncomputable, or subject to the halting problem. It is just very very difficult. I like the world feasible, the only improvement I would say is to state feasible for who. For any major corporation it is feasible, for drug cartels it is feasible, for foreign governments, the NSA, and few others it is feasible, but expensive. For any normal person, small company, hacker, cracker, activist, hoodlum, or deranged person it is not feasible or likely. I know that we are not going to attempt this in the next 3-5 years. We study hash collisions, but your problem above is above our financial capacity or need. We mainly deal with the issues related to login() and the use of MD5. If your adversary is the NSA I would not rest assured that it can't already happen. CU Chet Uber President and Principal Scientist SecurityPosture, Inc. 3718 N 113th Plaza, Omaha, NE 68164 vox +1 (402) 505-9684 | fax +1 (402) 932-2130 | cell (402) 813-3211 [EMAIL PROTECTED] | www.securityposture.com 'It is vain to do with more what can be done with fewer' -- This communication is confidential to the parties it was intended to serve --
Re: Preventing password reuse
On Tue, Jul 04, 2006 at 12:04:11AM -0400, Chet Uber wrote: > Not to bicker, but the resources needed to use a database of all > possible passwords even with alphanumerics and salted is very finite > -- albeit large. OpenBSD's blowfish passwords have 128-bits of salt. A table of all 8 character (lower-case only) alphanumeric passwords would require 2^128 * (26+10)^8 ~= 9.6*10^50 entries. Being ``very finite'' is irrelevant at this order of magnitude. > Just don't want people to think that they are safe as is not an NP- > complete problem. It is an NP-hard problem however. You are aware NP-complete problems are, by definition, reducible to NP-hard problems, right? In other words, NP-hard problems are ``harder'' than NP-complete ones.
Re: Preventing password reuse
On Tue, 4 Jul 2006, Chet Uber wrote: > Not to bicker, but the resources needed to use a database of all possible > passwords even with alphanumerics and salted is very finite -- albeit large. OpenBSD blowfish hashes have 16 bytes of salt, so a database of these will not be feasible for a while. -d
Re: Preventing password reuse
On Tue, Jul 04, 2006 at 02:15:09PM +1000, Rod.. Whitworth wrote:
| >Ahhh, .. that's what hash's are for; easily recreatable given duplicate
| >input strings, but creating the input string FROM the hash is just about
| >impossible [lacking near infinate resources].
| >
| >Storing hashes in a DB is just fine - that's how passwords are encrypted
| >in any case. Comparing the current to any others in the past 90 days
| >would work swinningly for a secure audit train.
| >
| > Lee
| >
| >
|
| So, you are suggesting using something other than the hash stored in
| OpenBSD's master.passwd then?
Why exactly would we need another hash ?
| If not try this:
| Add a user, nothing special.
| Record the hash from master.passwd
| Log in as the test user.
| Change "your" password.
| Change it back.
| Compare the hashes.
| Different eh?
How come these are different ? What happened ? It's still the same
password, right ? How can one string hash to two different outputs ?
It can not. From http://en.wikipedia.org/wiki/Hash_function : "A
fundamental property of all hash functions is that if two hashes
(according to the same function) are different, then the two inputs
are different in some way. This property is a consequence of hash
functions being deterministic."
| So you need to change to a less secure password hash method.
Why ?
How does the system know you've entered the correct password when you
log in ? It applies $magic_function to the text it receives ('the
password') and maybe some other data. Then it compares the output of
this $magic_function to whatever is stored in the password database.
If it matches, hey, you're authenticated and you may log in.
Now we repeat the above procedure using $magic_function on the "new"
password and compare the output with a list of old hashes. What is
different ? Why would this stop working ?
Think about it.
| Will that affect the security audit?
| Test with well known cracker tools and weep. I have (as root) fed a
| slice of master.passwd to John the Ripper with a few nologin users
| added using dictionary words of 7 or 8 chars as passwords and after 10
| days it had not cracked one of them. I bet it takes less time on lesser
| hashes to get some results.
Your password is not hashed as-is. A salt is added (for extra flavour)
before hashing. This salt it also stored in the database along with
the hash. Enter your password, the system takes the hash from the
database, computes the hash of the concatenation of said salt with
the password you entered. Then the system compares the hash with what
it found in the database.
Google 'password salt'
Cheers,
Paul 'WEiRD' de Weerd
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
[demime 1.01d removed an attachment of type application/pgp-signature]
Re: Preventing password reuse
Well, just to play the devil's advocate here ... One of the main functions of any password hygiene program 'should' be to prevent users from changing 'mypassword1' to 'mypassword2' and then 'mypassword3', etc. (Yes, we can force complex passwords, but the idea is the same.) It's fairly simple to compare 'newpassword' to 'existingpassword' and prevent this sort of behavior (I THINK that's what the -s option to passwdqc is for, but the man page is kind of ambiguous and I haven't had time to dive into the source yet - pam_passwdqc does it) but then the user can just do 'mypassword1', 'mydogsname1', 'mypassword2', mydogsname2', etc. and totally invalidate your carefully designed security policy. And hashes aren't gonna help. Don't get me wrong, I'm not knocking the idea completely. My assignment here is that I've been told that in order to get my client certified I have to avoid reuse of a password over a cycle of 4 90 day forced changes. My JOB is to assure that doing this doesn't open my client up to a whole new string of vulnerabilities. Mr. Rock, meet Mr. Hard Place. "In conclusion the main thing we did wrong ... was to worry about criminals being clever; we should rather have worried about our customers ... being stupid." Ross Anderson, "Security Engineering" On Monday 03 July 2006 20:25, L. V. Lammert wrote: > On Mon, 3 Jul 2006, STeve Andre' wrote: > > On Monday 03 July 2006 17:37, Jeff Simmons wrote: > > > > I can't resist pointing out that this is an AWFUL policy. You will be > > remembering peoples passwords, a history of them, which are > > very likely to be used on other systems. Thats really bad. I wonder > > (at least in the USA) what would happen to your company if that > > data was ever stolen? > > > > --STeve Andre' > > Ahhh, .. that's what hash's are for; easily recreatable given duplicate > input strings, but creating the input string FROM the hash is just about > impossible [lacking near infinate resources]. > > Storing hashes in a DB is just fine - that's how passwords are encrypted > in any case. Comparing the current to any others in the past 90 days > would work swinningly for a secure audit train. > > Lee -- Jeff Simmons [EMAIL PROTECTED] Simmons Consulting - Network Engineering, Administration, Security "You guys, I don't hear any noise. Are you sure you're doing it right?" --My Life With The Thrill Kill Kult
Re: Preventing password reuse
On Mon, 3 Jul 2006 22:25:53 -0500 (CDT), L. V. Lammert wrote: >On Mon, 3 Jul 2006, STeve Andre' wrote: > >> On Monday 03 July 2006 17:37, Jeff Simmons wrote: >> >> I can't resist pointing out that this is an AWFUL policy. You will be >> remembering peoples passwords, a history of them, which are >> very likely to be used on other systems. Thats really bad. I wonder >> (at least in the USA) what would happen to your company if that >> data was ever stolen? >> >> --STeve Andre' >> >Ahhh, .. that's what hash's are for; easily recreatable given duplicate >input strings, but creating the input string FROM the hash is just about >impossible [lacking near infinate resources]. > >Storing hashes in a DB is just fine - that's how passwords are encrypted >in any case. Comparing the current to any others in the past 90 days >would work swinningly for a secure audit train. > > Lee > > So, you are suggesting using something other than the hash stored in OpenBSD's master.passwd then? If not try this: Add a user, nothing special. Record the hash from master.passwd Log in as the test user. Change "your" password. Change it back. Compare the hashes. Different eh? So you need to change to a less secure password hash method. Will that affect the security audit? Test with well known cracker tools and weep. I have (as root) fed a slice of master.passwd to John the Ripper with a few nologin users added using dictionary words of 7 or 8 chars as passwords and after 10 days it had not cracked one of them. I bet it takes less time on lesser hashes to get some results. >From the land "down under": Australia. Do we look from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
Re: Preventing password reuse
I can't resist pointing out that this is an AWFUL policy. You will be remembering peoples passwords, a history of them, which are very likely to be used on other systems. Thats really bad. I wonder (at least in the USA) what would happen to your company if that data was ever stolen? --STeve Andre' Ahhh, .. that's what hash's are for; easily recreatable given duplicate input strings, but creating the input string FROM the hash is just about impossible [lacking near infinate resources]. Not to bicker, but the resources needed to use a database of all possible passwords even with alphanumerics and salted is very finite -- albeit large. If we are talking about login() that is. Our company maintains one for 8 characters and while requiring a large database still makes cracking passwords of finding collisions a trivial chore for 8 character passwords. We are currently working on one that will handle 13 character strings and hope to have it running by the end of the year. Just don't want people to think that they are safe as is not an NP- complete problem. It is an NP-hard problem however. CU Chet Uber President and Principal Scientist SecurityPosture, Inc. 3718 N 113th Plaza, Omaha, NE 68164 vox +1 (402) 505-9684 | fax +1 (402) 932-2130 | cell (402) 813-3211 [EMAIL PROTECTED] | www.securityposture.com 'It is vain to do with more what can be done with fewer' -- This communication is confidential to the parties it was intended to serve --
Re: Preventing password reuse
On Mon, 3 Jul 2006, STeve Andre' wrote: > On Monday 03 July 2006 17:37, Jeff Simmons wrote: > > I can't resist pointing out that this is an AWFUL policy. You will be > remembering peoples passwords, a history of them, which are > very likely to be used on other systems. Thats really bad. I wonder > (at least in the USA) what would happen to your company if that > data was ever stolen? > > --STeve Andre' > Ahhh, .. that's what hash's are for; easily recreatable given duplicate input strings, but creating the input string FROM the hash is just about impossible [lacking near infinate resources]. Storing hashes in a DB is just fine - that's how passwords are encrypted in any case. Comparing the current to any others in the past 90 days would work swinningly for a secure audit train. Lee
Re: starting Apache in SSL mode
L. V. Lammert wrote: Certificates have nothing to do with Apache, much less OpenBSD. If you want a signed certificate, you must create your own CA, or purchased a publically-signed cert from Verisign, Eqifax, Thawte, et al. That may be true, but mentioning "man 8 ssl" and referencing "GENERATING RSA SERVER CERTIFICATES FOR WEB SERVERS" would have been helpful. :) -ME -- Support OpenBSD: http://www.openbsd.org/orders.html
Re: Preventing password reuse
On Monday 03 July 2006 17:37, Jeff Simmons wrote: A client is setting up a password policy, and would like to prevent users from reusing a password for a period of time (four changes ninety days apart). Is there a way to do this, either within the OS or via a program in ports? I've been looking for quite a while and haven't found anything. I can't resist pointing out that this is an AWFUL policy. You will be remembering peoples passwords, a history of them, which are very likely to be used on other systems. Thats really bad. I wonder (at least in the USA) what would happen to your company if that data was ever stolen? The prevention of password reuse does not involve the storage of any passwords. You would properly store the hash. If you used MD5 there is an issue about collisions, but SHA1 would not have this problem. So the methodology would depend on the login. It is not normal for an OS to store the password, although application developers do do this. This is the same problem that you have in biometrics. Lots of people think you store the fingerprint, when really you only store data related to the fingerprint -- i.e. you cannot replay it to create a complete print. CU
Re: starting Apache in SSL mode
On Sun, 2 Jul 2006, FTP wrote: > On Tue, Jun 27, 2006 at 05:03:52PM +0200, FTP wrote: > > any chance to draw some attention to the above? > > Thanks > Certificates have nothing to do with Apache, much less OpenBSD. If you want a signed certificate, you must create your own CA, or purchased a publically-signed cert from Verisign, Eqifax, Thawte, et al. Lee
Re: Preventing password reuse
On Mon, 3 Jul 2006, Spruell, Darren-Perot wrote: > From: [EMAIL PROTECTED] > > A client is setting up a password policy, and would like to > > prevent users from > > reusing a password for a period of time (four changes ninety > > days apart). Is > > there a way to do this, either within the OS or via a program > > in ports? I've > > been looking for quite a while and haven't found anything. > > I haven't either, although I haven't looked really hard. I mention > http://www.mindrot.org/passwdqc.html not because I know it can do what > you're looking for but because it can offer a few steps up in password > quality which may also be in your policy. passwdqc doesn't keep a reuse history, but this is one of the things that I'd like to implement. > (http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html) approaches > this by storing password hashes in a history file - meaning you > have to basically have the equivalent of your shadow file (with > historically valuable information) hanging around somewhere else. This is the reason why I haven't implemented it in passwdqc yet :) This naive solution isn't very secure... -d
Re: Patent jeopardizes IETF syslog standard
On Tuesday 04 July 2006 05:05, Chris Cappuccio wrote: > Either way, this makes them look like the biggest fucking idiots ever. Most people who have ever had to use any of their devices knew this already. --- Lars Hansson
Re: Wireless Bridge...
On Monday 03 July 2006 23:29, Novak, Trevor SCIC wrote: > I'm trying to setup a wireless bridge with openbsd on a Toshiba > laptop. I'm using an SMC2532W-B (Prism 2.5) wireless card and a 3Com > 3C574-TX. Is the wi(4) in hostap mode? If not you cannot bridge...
Re: Preventing password reuse
Chris Zakelj <[EMAIL PROTECTED]> writes: > Date: Mon, 03 Jul 2006 21:09:32 -0400 > From: Chris Zakelj <[EMAIL PROTECTED]> > To: "STeve Andre'" <[EMAIL PROTECTED]> > CC: misc@openbsd.org > Subject: Re: Preventing password reuse > > STeve Andre' wrote: > > On Monday 03 July 2006 17:37, Jeff Simmons wrote: > > > >> A client is setting up a password policy, and would like to prevent users > >> from reusing a password for a period of time (four changes ninety days > >> apart). Is there a way to do this, either within the OS or via a program in > >> ports? I've been looking for quite a while and haven't found anything. > >> > > I can't resist pointing out that this is an AWFUL policy. You will be > > remembering peoples passwords, a history of them, which are > > very likely to be used on other systems. Thats really bad. I wonder > > (at least in the USA) what would happen to your company if that > > data was ever stolen? > > > > The same thing that happens whenever any other data (like, say, SSNs) > gets stolen. Absolutely nothing. > > Check out any good newspaper morgue before you believe that. There are too many counter-examples to your claim. The person who made this initial request claims to be working for medical doctors & credit card processors. There are specific horrible examples of the possible consequences of either. Of course, most of these are consequences to the person stealing the data, or the person whose data was lost -- but if too many data professionals start asserting it's not their responsibility at all, our politicians who art in will certainly create laws that say otherwise. HIPA for instance. Or think of the poor guy who lost a laptop at the VA recently. In any case, you don't need to store passwords. You can store a history of one-way hashes instead, get (nearly) the same benefit, and without nearly the security exposure. I think the more interesting security argument is that if you make people change passwords too often, they're much more likely to adopt other less secure policies in compensation, ones you can't control nearly so easily. For instance, they're much more likely to write them down. Or they may force you to adopt a less strigent password reset policy. Or they may just invent an obvious way to permute their password. -Marcus Watts
Re: Preventing password reuse
On Monday 03 July 2006 17:51, STeve Andre' wrote: > On Monday 03 July 2006 17:37, Jeff Simmons wrote: > > A client is setting up a password policy, and would like to prevent users > > from reusing a password for a period of time (four changes ninety days > > apart). Is there a way to do this, either within the OS or via a program > > in ports? I've been looking for quite a while and haven't found anything. > > I can't resist pointing out that this is an AWFUL policy. You will be > remembering peoples passwords, a history of them, which are > very likely to be used on other systems. Thats really bad. I wonder > (at least in the USA) what would happen to your company if that > data was ever stolen? > > --STeve Andre' As I mentioned in another post, these are requirements imposed by various security auditing firms. So from the company's (and my) standpoint, we've got some coverage, since we were required to retain the data. In general, I agree with most of what I've seen from these firms. I do question the basic assumptions, since if I have an audit preparation document, I've already got a pretty good basic blueprint of a certified firm's security setup and policies. And some of the policies I personally disagree with. But overall, it's probably a Good Thing (c), it's getting a lot of firms to improve what up till now have been weak 'security' arrangements. An employee of one of these firms claimed that no company that had passed one of their audits had ever been compromised. This will, of course, change. And the result will be modifications to the required security policies. After all, security isn't rocket science, it's chess. I might also add that all of the auditing firms I've dealt with look with favor on the deployment of OpenBSD as opposed to some other OSs. -- Jeff Simmons [EMAIL PROTECTED] Simmons Consulting - Network Engineering, Administration, Security "You guys, I don't hear any noise. Are you sure you're doing it right?" --My Life With The Thrill Kill Kult
Re: Preventing password reuse
STeve Andre' wrote: > On Monday 03 July 2006 17:37, Jeff Simmons wrote: > >> A client is setting up a password policy, and would like to prevent users >> from reusing a password for a period of time (four changes ninety days >> apart). Is there a way to do this, either within the OS or via a program in >> ports? I've been looking for quite a while and haven't found anything. >> > I can't resist pointing out that this is an AWFUL policy. You will be > remembering peoples passwords, a history of them, which are > very likely to be used on other systems. Thats really bad. I wonder > (at least in the USA) what would happen to your company if that > data was ever stolen? > The same thing that happens whenever any other data (like, say, SSNs) gets stolen. Absolutely nothing.
Re: Preventing password reuse
On Monday 03 July 2006 17:37, Jeff Simmons wrote: > A client is setting up a password policy, and would like to prevent users > from reusing a password for a period of time (four changes ninety days > apart). Is there a way to do this, either within the OS or via a program in > ports? I've been looking for quite a while and haven't found anything. I can't resist pointing out that this is an AWFUL policy. You will be remembering peoples passwords, a history of them, which are very likely to be used on other systems. Thats really bad. I wonder (at least in the USA) what would happen to your company if that data was ever stolen? --STeve Andre'
Re: set skip on interface rule doesn't show up in pfctl -sr
Henning Brauer wrote: > > skip steps and set skip have noting to do with each other. > set skip basically disables pf on a per-interface basis. > skip steps is an optimization in rule processing you can safely ignore. > it Just Works in the background and saves you CPU cycles :) > It does not have much to do with the topic but, if i do enable skip on an interface, if i send packets to the skipped interface with tags on them, these tags will be lost? I'm asking because i did some tagging and sent to the ftp-proxy running in the lo0 interface, and the tags were gone when the ftp-proxy did the connection on behalf of the user. I need this to do qos. My regards, -- Giancarlo Razzolini Linux User 172199 Moleque Sem Conteudo Numero #002 Slackware Current OpenBSD Stable Snike Tecnologia em Informatica 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: carp with hosts in different vlans
On Mon, Jul 03, 2006 at 04:58:09PM +0200, Sebastian Reitenbach wrote: > I can setup a tunnel between both hosts, and route the mulitcast > packets through the tunnel and then have the IP address shared between > the two hosts? No. CARP does not accept packets that have crossed a router, to prevent external spoofing of carp packets. Get your colo to change their switch/router config to put your boxes on the same ethernet segment, put both of the boxes on a switch that you manage that connects to one of your colo's switch port, or change colo providers.
Re: Preventing password reuse
On Monday 03 July 2006 16:19, Spruell, Darren-Perot wrote: > I mention > http://www.mindrot.org/passwdqc.html not because I know it can do what > you're looking for but because it can offer a few steps up in password > quality which may also be in your policy. Yes, it does everything I need very nicely except preventing password reuse. > Seems to me a better solution would be to take a one-way hash of the new > password hash out to some kind of a database ... Very much agree. I think we're going to need something like this (similar to some of the file integrity monitors) soon. I'm doing a lot of preparation for security audits these days (mainly doctor's offices and credit card processors right now) and that's something the auditing firms want to see. Thanks for the assistance. On Monday 03 July 2006 16:19, Spruell, Darren-Perot wrote: > From: [EMAIL PROTECTED] > > > A client is setting up a password policy, and would like to > > prevent users from > > reusing a password for a period of time (four changes ninety > > days apart). Is > > there a way to do this, either within the OS or via a program > > in ports? I've > > been looking for quite a while and haven't found anything. > > I haven't either, although I haven't looked really hard. I mention > http://www.mindrot.org/passwdqc.html not because I know it can do what > you're looking for but because it can offer a few steps up in password > quality which may also be in your policy. > > I notice Linux's pam_cracklib > (http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html) approaches this > by storing password hashes in a history file - meaning you have to > basically have the equivalent of your shadow file (with historically > valuable information) hanging around somewhere else. > > Seems to me a better solution would be to take a one-way hash of the new > password hash out to some kind of a database where a comparison could be > made against the last N password hash hashes that were used. Putting the > actual password hash out to storage for comparison seems more risky than > just a one-way hash of the hash (at least a little bit). A trigger on a > password change could easily tell if the new password hashes out to one on > record and records a hash of the hash if not. > > DS -- Jeff Simmons [EMAIL PROTECTED] Simmons Consulting - Network Engineering, Administration, Security "You guys, I don't hear any noise. Are you sure you're doing it right?" --My Life With The Thrill Kill Kult
Re: set skip on interface rule doesn't show up in pfctl -sr
* Nick Guenther <[EMAIL PROTECTED]> [2006-07-03 22:35]: > unfortunate. It also doesn't help that the manpage say, next to, -s > Rule: > "Note that the ``skip step'' optimization done automatically by the > kernel will skip evaluation of rules where possible." which seems to > imply that `-s rules` has something to do with `set skip`. skip steps and set skip have noting to do with each other. set skip basically disables pf on a per-interface basis. skip steps is an optimization in rule processing you can safely ignore. it Just Works in the background and saves you CPU cycles :) -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: Preventing password reuse
From: [EMAIL PROTECTED] > A client is setting up a password policy, and would like to > prevent users from > reusing a password for a period of time (four changes ninety > days apart). Is > there a way to do this, either within the OS or via a program > in ports? I've > been looking for quite a while and haven't found anything. I haven't either, although I haven't looked really hard. I mention http://www.mindrot.org/passwdqc.html not because I know it can do what you're looking for but because it can offer a few steps up in password quality which may also be in your policy. I notice Linux's pam_cracklib (http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html) approaches this by storing password hashes in a history file - meaning you have to basically have the equivalent of your shadow file (with historically valuable information) hanging around somewhere else. Seems to me a better solution would be to take a one-way hash of the new password hash out to some kind of a database where a comparison could be made against the last N password hash hashes that were used. Putting the actual password hash out to storage for comparison seems more risky than just a one-way hash of the hash (at least a little bit). A trigger on a password change could easily tell if the new password hashes out to one on record and records a hash of the hash if not. DS
Re: openwebmail with chrooted apache
On 2006/07/03 18:25, Nick Holland wrote: > OpenWebmail is very charming because of how very little it needs to > bring into base OpenBSD to get working. I set it up for a school of > about 200 students on a PII-450, worked well (once I set up MASSIVE > amounts of swap space...having 25 students change their PWs at the same > time burned through something like 600M of RAM+swap very > quickly...swap-to-file to the rescue!). I set IMP up once for a hosted email system for a bunch of schools, who insisted on using Lookout 97 for admin staff. The occasional uuencoded attachments (including a scanned letter pasted as a bitmap into an uncompressed Word document sent to something like 400 people) caused, shall we say, interesting things to happen as IMP tried to wordwrap it...
Re: set skip on interface rule doesn't show up in pfctl -sr
On 7/3/06, Nick Guenther <[EMAIL PROTECTED]> wrote:
On 7/3/06, Giancarlo Razzolini <[EMAIL PROTECTED]> wrote:
> pfctl -sI -vv shows you if an interface is skipped or not.
-w is not documented in pfctl(8). What does it do?
It most certainly is.
Try -vv ('v' 'v', as in 'victor' 'victor'), avoid typing your dmesg at
all costs! =)
Re: set skip on interface rule doesn't show up in pfctl -sr
Nick Guenther wrote: > -w is not documented in pfctl(8). What does it do? > It is not -w it is -v that stands for -v(erbose). If you use it twice (-vv) it increase the verbose level. It is in the pfctl man page. My regards, -- Giancarlo Razzolini Linux User 172199 Moleque Sem Conteudo Numero #002 Slackware Current OpenBSD Stable Snike Tecnologia em Informatica 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Wireless Bridge...
I'm trying to setup a wireless bridge with openbsd on a Toshiba laptop. I'm using an SMC2532W-B (Prism 2.5) wireless card and a 3Com 3C574-TX. I've created a bridgename.bridge0 file and added wi0 and ep1 to the file. The bridge is up and running. I can ping both on the wireless side and the ethernet side from the Obsd box, but I can't get any traffic to pass through it. I don't have PF running, in fact, I've stopped most of the services (hopefully not one I need). Anyway, any help would be appreciated.
Re: openwebmail with chrooted apache
FTP wrote: On Mon, Jul 03, 2006 at 08:49:03PM +0200, Sigfred Heversen wrote: Stuart Henderson wrote: On 2006/07/03 13:52, Nick Holland wrote: (contrast this to Squirrelmail, which does (amazingly) run in a chroot Same for Hastymail and Roundcube. I guess it's not too much of a stretch with IMP either (though I haven't actually used IMP recently enough to have checked chroot). In tree mail/imp depends on devel/horde that has exploit(s) in the wild. /Sigfred I had a look on IMP and looks fine to me cause you can have POP3 too as well. I actually dodn't intend to isntall an IMAP server. Using IMP to avoid an IMAP server is like cutting off your hands because you don't wish to trim your fingernails. A Bit Drastic, I do think. And similarly crippling, as IMP is less than 100% effective without IMAP, apparently: http://www.horde.org/imp/docs/?f=INSTALL.html "IMAP is recommended over POP3 in order to let users maintain mail folders other than INBOX and is required to allow messages to be flagged. IMAP is also much faster than POP3 in displaying a mailbox of messages. In short, do not use POP3 unless IMAP is not available." If you want IMP, IMAP is the least of your tasks. I think once you have IMP configured, you will forget that IMAP was even involved. As a result is IMP a good solution for a small e-mail server? I've never got IMP all the way running...but I very quickly came to the conclusion that "small" and IMP or any other Horde-based product have nothing to do with each other. That's not to say that IMP isn't a (potentially) cool product, and I'd like to come back to it, but the setup and config is much more "involved" than I'd find justified for a "small" e-mail server. OpenWebmail is very charming because of how very little it needs to bring into base OpenBSD to get working. I set it up for a school of about 200 students on a PII-450, worked well (once I set up MASSIVE amounts of swap space...having 25 students change their PWs at the same time burned through something like 600M of RAM+swap very quickly...swap-to-file to the rescue!). I must say, at this point, being not written in PHP is starting to look Really Nice, too. Nick.
Re: set skip on interface rule doesn't show up in pfctl -sr
On 7/3/06, Giancarlo Razzolini <[EMAIL PROTECTED]> wrote: > pfctl -sI -vv shows you if an interface is skipped or not. My 2 cents, -w is not documented in pfctl(8). What does it do? On 7/3/06, Clint Pachl <[EMAIL PROTECTED]> wrote: Henning Brauer wrote: > * Daniel Ouellet <[EMAIL PROTECTED]> [2006-07-03 21:44]: >> Is there a special reason why we couldn't see the >> >> set skip on interface >> >> in the display of the rules in pf with the regular: >> >> pfctl -sr > > it is not a rule. It is an option. Would it be beneficial to add an "Options" modifier to pfctl's -s arg in order to verify all options? # pfctl -s Options Options:Values: loginterfaceem0 optimizationnormal block-policydrop state-policyfloating skip on lo0 fxp1 ... -pachl That's what I and Stuart Henderson said. Methinks it is a good idea. -Nick
Preventing password reuse
A client is setting up a password policy, and would like to prevent users from reusing a password for a period of time (four changes ninety days apart). Is there a way to do this, either within the OS or via a program in ports? I've been looking for quite a while and haven't found anything. -- Jeff Simmons [EMAIL PROTECTED] Simmons Consulting - Network Engineering, Administration, Security "You guys, I don't hear any noise. Are you sure you're doing it right?" --My Life With The Thrill Kill Kult
Re: set skip on interface rule doesn't show up in pfctl -sr
Henning Brauer wrote: * Daniel Ouellet <[EMAIL PROTECTED]> [2006-07-03 21:44]: Is there a special reason why we couldn't see the set skip on interface in the display of the rules in pf with the regular: pfctl -sr it is not a rule. It is an option. Would it be beneficial to add an "Options" modifier to pfctl's -s arg in order to verify all options? # pfctl -s Options Options:Values: loginterfaceem0 optimizationnormal block-policydrop state-policyfloating skip on lo0 fxp1 ... -pachl
Re: set skip on interface rule doesn't show up in pfctl -sr
Daniel Ouellet wrote: >> If this was to be implemented, it might be more appropriate to show in >> the >> runtime state (pfctl -si) than the rule output. > > I don't know. May be may be not. But I got cut with this. I had a > sysadmin do changes in a pretty big multi interface box and he use the > set skip to test new rules on individual interface as I guess it started > to be to big, I can't explain. But in any case, I started to see pass > that some strange things that shouldn't be there and looking at the > pfctl -sr at work, I never saw anything that would explain it. > > After many hours of work, I thought that may be there might be a bug > somehow. Look in that directions and a few more days pass. > > Someone time the most obvious is not what jump at you and in the end, I > started to look in more details to the rules instead of the pfctl -sr > until I saw the set skip in there. > > So, in the end, it is very stupid that I agree with 100%! > > No one else to blame then the sysadmin and myself to assume that pfctl > -sr would show me what's active at the time. > > I felt into that trap and that's why I was asking if it wouldn't make > sense to see what's actually active when you are looking at the live > configuration running on the system. > > I took for granted that looking at the live rules was telling me that's > what is actively filter. Believe me, I will not felt into that trap > again, but I thought after a many hours that I could have saved, that > may be it might be very useful for someone else may be. > > I just thought that if you look at the live configuration, it should > show the life configuration. > > That was just my take on it after a real life trap that I don't have > anyone to blame then myself for not looking at the details configuration > line by line sooner. > > In any case, thanks for the feedback. That's a mistake I will not repeat > again! (;> > > Daniel > > pfctl -sI -vv shows you if an interface is skipped or not. My 2 cents, -- Giancarlo Razzolini Linux User 172199 Moleque Sem Conteudo Numero #002 Slackware Current OpenBSD Stable Snike Tecnologia em Informatica 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: set skip on interface rule doesn't show up in pfctl -sr
set skip on interface in the display of the rules in pf with the regular: pfctl -sr it is not a rule. I guess one could argue that: set block-policy option is not a rule either, but it does show up however: Example 1: In pf.conf set block-policy return block all pfctl -sr block return all Example 2: In pf.conf set block-policy drop block all pfctl -sr block drop all This set option does show up here. OK, it can be argue that it might be a rule as well, but it is enter as set option in the same section as set skip. Daniel
Re: Patent jeopardizes IETF syslog standard
J.C. Roberts [EMAIL PROTECTED] wrote: > > This sucks. It's no different than what Cisco did with their HSRP patent > to try to kill off VRRP. The Huawei IPR claim to the IETF is nearly > identical to the crap Cisco put out years ago in their IPR claim. > It's funny how these Chinese guys like to rip-off Cisco. First they rip off Cisco IOS, by virtue they rip off all of Cisco's bugs, and now they rip off Cisco's intellectual property stance. How do you rip off an intellectual property stance? It's counter-intuitive. Either way, this makes them look like the biggest fucking idiots ever. -- Quis custodiet ipsos custodes?
Re: openwebmail with chrooted apache
> > In tree mail/imp depends on devel/horde that has exploit(s) in the wild. This doesn't look very much fun, remote php execution and looks like it's being actively probed-for.
Re: set skip on interface rule doesn't show up in pfctl -sr
Indeed it does, but not by hacking up `-s rules`. pfctl(8) lists all the various things you can display with -s. 'options' (as per pf.conf(5)) do not seem to be among them, however, which I agree is unfortunate. It also doesn't help that the manpage say, next to, -s Rule: "Note that the ``skip step'' optimization done automatically by the kernel will skip evaluation of rules where possible." which seems to imply that `-s rules` has something to do with `set skip`. I don't know about all the options. I kind of think these are more operations limits or something. I am sure I don't use the right words here, but the options would be for optimization of efficiency of busy system. In low usage, the options wouldn't be in the way in any case. I see the set skip as all or nothing, oppose to options that are capacity related. I could be wrong, but I don't see that as the same thing at all. The show rules, or what ever it may be call should show the go/no go stuff and if you want optimization, then you can always looks else where for capacity related issues. I don't think the two should be at the same place here, but again, that's just my thinking. Look logical to me, but I am not saying I hold all the truth here either.
Re: openwebmail with chrooted apache
From: [EMAIL PROTECTED] > > In tree mail/imp depends on devel/horde that has exploit(s) > in the wild. > > > > /Sigfred > > > > I had a look on IMP and looks fine to me cause you can have > POP3 too as well. I actually dodn't intend to isntall an IMAP server. > > As a result is IMP a good solution for a small e-mail server? It works as well as anything and it's *pretty*. As pointed out though, IMP doesn't work without the rest of the Horde framework, and frankly I don't like introducing more code than neccesary (especially in the case of a PHP app) and if all you need is webmail, is bringing along all the rest of the Horde framework really prudent? DS
Re: set skip on interface rule doesn't show up in pfctl -sr
If this was to be implemented, it might be more appropriate to show in the runtime state (pfctl -si) than the rule output. I don't know. May be may be not. But I got cut with this. I had a sysadmin do changes in a pretty big multi interface box and he use the set skip to test new rules on individual interface as I guess it started to be to big, I can't explain. But in any case, I started to see pass that some strange things that shouldn't be there and looking at the pfctl -sr at work, I never saw anything that would explain it. After many hours of work, I thought that may be there might be a bug somehow. Look in that directions and a few more days pass. Someone time the most obvious is not what jump at you and in the end, I started to look in more details to the rules instead of the pfctl -sr until I saw the set skip in there. So, in the end, it is very stupid that I agree with 100%! No one else to blame then the sysadmin and myself to assume that pfctl -sr would show me what's active at the time. I felt into that trap and that's why I was asking if it wouldn't make sense to see what's actually active when you are looking at the live configuration running on the system. I took for granted that looking at the live rules was telling me that's what is actively filter. Believe me, I will not felt into that trap again, but I thought after a many hours that I could have saved, that may be it might be very useful for someone else may be. I just thought that if you look at the live configuration, it should show the life configuration. That was just my take on it after a real life trap that I don't have anyone to blame then myself for not looking at the details configuration line by line sooner. In any case, thanks for the feedback. That's a mistake I will not repeat again! (;> Daniel
Re: set skip on interface rule doesn't show up in pfctl -sr
On 2006/07/03 16:26, Nick Guenther wrote: > I don't know a lot about the architecture of pf (I plan to learn soon > though) so maybe this is completely stupid, but I suggest adding modes > for `pfctl -s` to match everything listed in pf.conf(5). `-s config' to produce a usable pf.conf from in-memory configuration would be quite appealing...
Re: openwebmail with chrooted apache
On Mon, Jul 03, 2006 at 08:49:03PM +0200, Sigfred Heversen wrote: > Stuart Henderson wrote: > >On 2006/07/03 13:52, Nick Holland wrote: > > > >>(contrast this to Squirrelmail, which does (amazingly) run in a chroot > > > > > >Same for Hastymail and Roundcube. I guess it's not too much of a > >stretch with IMP either (though I haven't actually used IMP recently > >enough to have checked chroot). > > > > In tree mail/imp depends on devel/horde that has exploit(s) in the wild. > > /Sigfred > I had a look on IMP and looks fine to me cause you can have POP3 too as well. I actually dodn't intend to isntall an IMAP server. As a result is IMP a good solution for a small e-mail server? Thanks George
Re: set skip on interface rule doesn't show up in pfctl -sr
On 7/3/06, Daniel Ouellet <[EMAIL PROTECTED]> wrote: > it is not a rule. OK, not a rule, but still shouldn't it be possible or useful to see that in effect? If you make changes for testing or what not and you use this temporary, etc on a box of 10+ interfaces, just my thinking, but I was expecting to see this in display of how the pf was working. Yes it might be stupid to forget to remove it or what ever, but if you do check the active rules to see what's in action and skip doesn't show up there, one might think all is good and don't check the details configuration to see if that would be there or not. Just a thought. Someone might put this in effect and then an other admin check the rules, don't see it and think all is good and look else where just to find out after many hours that this set skip is bypassing the configurations. May not be a rule, but still have effect in the working configuration. Doesn't it make sense to see it? Indeed it does, but not by hacking up `-s rules`. pfctl(8) lists all the various things you can display with -s. 'options' (as per pf.conf(5)) do not seem to be among them, however, which I agree is unfortunate. It also doesn't help that the manpage say, next to, -s Rule: "Note that the ``skip step'' optimization done automatically by the kernel will skip evaluation of rules where possible." which seems to imply that `-s rules` has something to do with `set skip`. I don't know a lot about the architecture of pf (I plan to learn soon though) so maybe this is completely stupid, but I suggest adding modes for `pfctl -s` to match everything listed in pf.conf(5). -Nick
Re: set skip on interface rule doesn't show up in pfctl -sr
it is not a rule. OK, not a rule, but still shouldn't it be possible or useful to see that in effect? If you make changes for testing or what not and you use this temporary, etc on a box of 10+ interfaces, just my thinking, but I was expecting to see this in display of how the pf was working. Yes it might be stupid to forget to remove it or what ever, but if you do check the active rules to see what's in action and skip doesn't show up there, one might think all is good and don't check the details configuration to see if that would be there or not. Just a thought. Someone might put this in effect and then an other admin check the rules, don't see it and think all is good and look else where just to find out after many hours that this set skip is bypassing the configurations. May not be a rule, but still have effect in the working configuration. Doesn't it make sense to see it?
Re: set skip on interface rule doesn't show up in pfctl -sr
From: [EMAIL PROTECTED] > Is there a special reason why we couldn't see the > > set skip on interface > > in the display of the rules in pf with the regular: > > pfctl -sr If this was to be implemented, it might be more appropriate to show in the runtime state (pfctl -si) than the rule output. DS
Network slowdown (DLINK DGE-530T card maxing out at 17.3Mb/sec) P4 2.4 512M ram 424M free
Really odd problem here:
I've set up a fairly simple firewall utilizing dual DGE-530T gigabit cards.
Isolating a windows rack from the rest of campus. Note that testing the
speed from a 100Mb linux host in the same office (plugged into the same
router as the firewall but of course outside the firewall's control) shows a
better then expected speed (94.2Mb/sec) connecting to the same test server
(100Mb) across campus.
First the Iperf (again note this is connecting to a 100Mb host) results
with both the linux host and the openbsd firewall running 2.0.2 (final note:
this speed is the same when the openbsd system is connected to a 1Gb host as
well)
(linux host running iperf -s)
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
[ 4] local x port 5001 connected with y port 36002 [ 4] 0.0-10.1 sec
20.8 MBytes 17.3 Mbits/sec
(openbsd host running iperf -s)
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
[ 6] local y port 5001 connected with x port 34081 [ 6] 0.0-10.1 sec
20.8 MBytes 17.3 Mbits/sec
Dmesg (yes, there's only 512M of ram, will upgrade it to 1G if needed, but
considering a top shows Free: 424M I don't think that's the problem) :
OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.40GHz ("GenuineIntel" 686-class) 2.40 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU
SH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF
real mem = 535871488 (523312K)
avail mem = 481947648 (470652K)
using 4278 buffers containing 26898432 bytes (26268K) of memory mainbus0
(root) bios0 at mainbus0: AT/286+(00) BIOS, date 04/28/03, BIOS32 rev. 0 @
0xffe90 apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfeae0/176 (9 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801BA LPC" rev 0x00)
pcibios0: PCI bus #2 is the last bus
bios0: ROM list: 0xc/0xc000 0xe/0x1800 cpu0 at mainbus0 pci0 at
mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function
0 "Intel 82845G/GL" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel
82845G/GL/GV/GE/PE AGP" rev 0x01
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon 7500 QW" rev 0x00 wsdisplay0 at
vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation) uhci0 at pci0 dev 29
function 0 "Intel 82801DB USB" rev 0x01: irq 11 usb0 at uhci0: USB revision
1.0 uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x01: irq 10
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x01: irq 9
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered ehci0 at pci0 dev 29 function
7 "Intel 82801DB USB" rev 0x01: irq 3
usb3 at ehci0: USB revision 2.0
uhub3 at usb3
uhub3: Intel EHCI root hub, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered
ppb1 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0x81
pci2 at ppb1 bus 2
skc0 at pci2 dev 9 function 0 "D-Link Systems DGE-530T" rev 0x11, Marvell
Yukon (0x1): irq 9 sk0 at skc0 port A, address 00:0d:88:70:c1:f7 eephy0 at
sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 3
skc1 at pci2 dev 10 function 0 "D-Link Systems DGE-530T" rev 0x11, Marvell
Yukon (0x1): irq 10
sk1 at skc1 port A, address 00:0f:3d:f4:8d:ce
eephy1 at sk1 phy 0: Marvell 88E1011 Gigabit PHY, rev. 3 ichpcib0 at pci0
dev 31 function 0 "Intel 82801DB LPC" rev 0x01 pciide0 at pci0 dev 31
function 1 "Intel 82801DB IDE" rev 0x01: DMA, channel 0 configured to
compatibility, channel 1 configured to compatibility wd0 at pciide0 channel
0 drive 0:
wd0: 16-sector PIO, LBA, 38146MB, 78125000 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0
channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0
lun 0: SCSI0 5/cdrom removable
atapiscsi1 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi1: 2 targets
cd1 at scsibus1 targ 0 lun 0: SCSI0
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
cd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2 ichiic0 at pci0 dev 31
function 3 "Intel 82801DB SMBus" rev 0x01: irq 11 iic0 at ichiic0 auich0 at
pci0 dev 31 function 5 "Intel 82801DB AC97" rev 0x01: irq 11, ICH4 AC97
ac97: codec id 0x41445374 (Analog Devices AD1981B)
ac97: codec features headphone, 20
Re: set skip on interface rule doesn't show up in pfctl -sr
* Daniel Ouellet <[EMAIL PROTECTED]> [2006-07-03 21:44]: > Is there a special reason why we couldn't see the > > set skip on interface > > in the display of the rules in pf with the regular: > > pfctl -sr it is not a rule. -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
set skip on interface rule doesn't show up in pfctl -sr
Is there a special reason why we couldn't see the set skip on interface in the display of the rules in pf with the regular: pfctl -sr That's on 3.9.
FTP / local logins and KerberosV
One question regarding Kerberos authentication in ftpd is whether the daemon supports only password authentication against the kerberos database, or if it can support authentication using a service ticket from a user who has already gotten a TGT (passwordless login). Also, what (if any) openbsd-compatible ftp client/server implementations are there that do support krb5/gssapi for passwordless auth? Ditto for sshd; I see that if the user's login class has one of the krb* authentication styles, the password provided at login is used to authenticate as a principle against the kerberos realm. Is the only way to enable seamless ticket authentication in sshd to enable GSSAPIAuthentication? Will a user that logs in remotely via SSH and authenticates against the kerberos database (krb5 / krb5-or-pwd) get a TGT in their credential cache? I know that this is the case with a local console login... DS
Re: openwebmail with chrooted apache
Stuart Henderson wrote: On 2006/07/03 13:52, Nick Holland wrote: (contrast this to Squirrelmail, which does (amazingly) run in a chroot Same for Hastymail and Roundcube. I guess it's not too much of a stretch with IMP either (though I haven't actually used IMP recently enough to have checked chroot). In tree mail/imp depends on devel/horde that has exploit(s) in the wild. /Sigfred
Re: openwebmail with chrooted apache
On Mon, 3 Jul 2006, Stuart Henderson wrote: Same for Hastymail and Roundcube. I guess it's not too much of a stretch with IMP either (though I haven't actually used IMP recently enough to have checked chroot). Horde/Imp works fine in chroot. -- Antoine
Re: openwebmail with chrooted apache
On 2006/07/03 13:52, Nick Holland wrote: > (contrast this to Squirrelmail, which does (amazingly) run in a chroot Same for Hastymail and Roundcube. I guess it's not too much of a stretch with IMP either (though I haven't actually used IMP recently enough to have checked chroot).
Re: openwebmail with chrooted apache
FTP wrote: I installed openwebmail from the ports and when trying to launch: http://your_server/cgi-bin/openwebmail/openwebmail.pl I get a 500 error. I suppose that this is due to the chrooted apache but how do I find the dependencies for a perl script? 1) you think really hard about what a program does and how it does it. * It runs as setuid root, so it can jump to any logged in user to fetch their mail. (hint: chrooting a suid root program is kinda pointless) * It accesses /var/mail (can't recall if directly or via pop3) * It accesses Sendmail binary directly (another setuid root program). * it accesses /home/* directly (that's from memory, from a few years back's version. I suspect there is a lot more. Some details may have changed, including my memory) 2) you think really hard about how much of the system you would have to pull into the chroot to do what you want. * Too much dangerous stuff...and much of the file system. The benefit of chrooting is mostly lost. 3) Decide if the effort is worth it. * No, it isn't IN THIS CASE. Give it up. See the last sentence in: http://www.openbsd.org/faq/faq10.html#httpdchroot OpenWebmail is one of these apps. Making it work in a chroot would require a major rewrite and restructure, not simply copying files over...then you STILL have to trust the mechanism used to do those root-like things. (contrast this to Squirrelmail, which does (amazingly) run in a chroot relatively easily...but then, Squirrelmail uses an IMAP server to move your mail data around...so instead of worrying about a "hole" in Apache or the web-app, you have to worry about a hole in your IMAP server) Nick.
Re: Patent jeopardizes IETF syslog standard
From: [EMAIL PROTECTED] > > useful implementation of a redundancy protocol. It's > technically better > > than HSRP or any of the versions of VRRP but the problems > till stands > > that it is not an "official" protocol, which simply means > adoption and > > inter operability will suffer to some degree. > > Adoption and interoperability are immaterial if everything is OBSD of > course. I wonder what percentage of people using OBSD face > interoperability issues? Isn't CARP so easy, and OBSD in > general, that > you just want to install it on all of your machines? That's one option, though we've already seen at least one other implementation of CARP pop up, the userland one for other *nix OSes (UCARP - http://www.ucarp.org/project/ucarp). What it would take is for other vendors who provide HA services via VRRP (countless) to learn of the availability of CARP and implement it in their own equipment. Once one or two do this, others should begin to jump on board, and someone may actually pop up and decide to throw it through the IETF for standardization so that the others can get their warm fuzzies and consider it "official" as JCR was saying. Because we know its not official until big American corporation say it is and monkey their customers into paying for its "officialness." Self-fulfilling prophecy: then we can get on target with the back and forth we've seen with OpenSSH already... Vendor: OpenSSH doesn't cost anything. Can we use it and just violate the GPL? Advisor: It's under the BSDL. You don't have to violate anything, just use it. You should donate to the project though. Vendor: Great. Take it, implement it, sell it, and don't make any donations. Screw those guys. OpenBSD: You guys using OpenSSH should donate money because we help you succeed. Vendor: Take off, we don't owe you anything, eh? Advisor: Oh look, they also have a CARP protocol that does everything VRRP does and more, and doesn't have that scary patent thing hanging over it. Vendor: Great. $$$ Ka-ching $$$ Advisor: Dontaions? OpenBSD: Donations? Vendor: Piss off. DS
Re: News From HiFn
On Jun 30, 2006, at 7:11 PM, Theo de Raadt wrote: > Why should we bleed our little hearts over a company who acted like > assholes towards us for years, and only changed their policy due to > public pressure? Because behavior modification requires rewarding in some fashion desired behavior? Because the stick doesn't work without the carrot? Because all the world longs to see a kinder, gentler Theo? :-) --- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
Re: 3.9 freeze
ok, I have the server on datacenter, when freeze I will try it. - Original Message - From: "mickey" <[EMAIL PROTECTED]> To: "diego" <[EMAIL PROTECTED]> Cc: "Pedro Martelletto" <[EMAIL PROTECTED]>; Sent: Monday, July 03, 2006 9:52 AM Subject: Re: 3.9 freeze On Mon, Jul 03, 2006 at 09:45:22AM -0300, diego wrote: no, I can only ping the server or change tty (ctrl alt fn), but I can't type anything. you should sysctl ddb.console=1 for that to work... - Original Message - From: "Pedro Martelletto" <[EMAIL PROTECTED]> To: "diego" <[EMAIL PROTECTED]> Cc: Sent: Monday, July 03, 2006 9:34 AM Subject: Re: 3.9 freeze >Can you break into ddb? > >-p. -- paranoic mickey (my employers have changed but, the name has remained)
openwebmail with chrooted apache
I installed openwebmail from the ports and when trying to launch: http://your_server/cgi-bin/openwebmail/openwebmail.pl I get a 500 error. I suppose that this is due to the chrooted apache but how do I find the dependencies for a perl script? Thanks George
Re: 3.9 freeze
no... - Original Message - From: "vladas" <[EMAIL PROTECTED]> To: "diego" <[EMAIL PROTECTED]> Sent: Monday, July 03, 2006 10:00 AM Subject: Re: 3.9 freeze On 03/07/06, diego <[EMAIL PROTECTED]> wrote: no, I can only ping the server or change tty (ctrl alt fn), but I can't type anything. how about by ssh? - Original Message - From: "Pedro Martelletto" <[EMAIL PROTECTED]> To: "diego" <[EMAIL PROTECTED]> Cc: Sent: Monday, July 03, 2006 9:34 AM Subject: Re: 3.9 freeze > Can you break into ddb? > > -p.
Re: kernel settings for pf default block
On Mon, Jul 03, 2006 at 05:30:44PM -0700, c.s.r.c.murthy wrote: > Hi, > This seems to be widely discussed problem in openbsd pf. There is no > kernel parameter that makes the pf to block all packets by default. I > have searched on the internet and found some discussion taken place in > 2005 regarding this. The discussion concludes no such parameter in > kernel. Are there any changes done in openbsd latest to have a kernel > configurable parameter to make pf block packets by default? Alexey already answered this, why do you repost it? Joachim
Re: ftp-proxy does not work in secure level 2
On Mon, Jul 03, 2006 at 05:25:31PM -0700, c.s.r.c.murthy wrote: > Hi, > We have configured a firewall with pf on openbsd-3.9. It is found that > ftp-proxy is unable to operate when system is put in secure level 2. > This is due to the fact that ftp-proxy can't add/delete rules in pf in > secure level 2. But for security reasons we would like to have the > system running in secure level 2. Is there a soultion to have the > ftp-proxy working in secure level 2? Camiel already pointed out that the answer is no. As to securelevels, they are officially considered broken (which caused quite a bit of a stir here on misc@). One obvious vulnerability is that mounting stuff is still possible, and thus, what any filename points to can be altered, even if the inode it originally pointed to has restrictive flags set. Plus, a quick look at securelevel(7) does not give any obvious benefit for a firewall, except locking the pf rules - which doesn't work with ftp-proxy, as you noted. Some alternatives to ftp-proxy exist, like the pre-3.8 ftp-proxy and a program called ftpsesame (sp?) that I know very little about. Both would be able to work without changing pf rules from userspace, I believe - of course, this also means they are quite a bit slower. Joachim
Re: carp with hosts in different vlans
Hi, sorry for late reply, unfortunately I was a bit off... > On 2006/06/23 12:53, Sebastian Reitenbach wrote: >> Both hosts are in different VLAN's. to reach each other >> I have to set a host route via the default gateway to reach >> the other system. > > You need to be able to multicast between them to run CARP. > Would your hosting provider be willing to move them into the > same vlan? before I am going to try that for ours to find out it will not work: do I can setup a tunnel between both hosts, and route the mulitcast packets through the tunnel and then have the IP address shared between the two hosts? kind regards Sebastian __ Erweitern Sie FreeMail zu einem noch leistungsstdrkeren E-Mail-Postfach! Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131
Re: Reading a file that is been written make the system freeze?
Federico Giannici wrote: Pedro Martelletto wrote: On Thu, Jun 22, 2006 at 03:25:41PM +0200, Federico Giannici wrote: Yesterday another PC freezed! It just crashed again! did it freeze or did it crash? I wrote it into the first email: it freezes with no error at all, no network, only freezed video. Looking at the vmstat's output (copied below), I have noticed that the "HighUse" value of "UVM amap" is near the "Limit" value. If the value reach the Limit value, can this be the cause of the freezes? Thanks. Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 1649512 163480 2830073091280 1313 3239388 100132 399456442 640 1430 6447091 33421 661407513 320 49732 12829957 21051 104321973 160 39189 25630799 28417 54954624 80 373841 51219707 17973 21017834 40 795062 1024 5986 4302 119601358 20 18398836 2048 1154562 773127 10 306230 4096 4842381619835 51615453 8192 38 27 10932 5 10778 163849 0 53806 5 0 327683 0 1134 5 0 655364 0253 5 0 1310722 0 18 5 0 2621441 0 4 5 0 Memory usage type by bucket size Size Type(s) 16 devbuf, pcb, routetbl, sysctl, UFS mount, dirhash, exec, xform_data, VM swap, UVM amap, UVM aobj, USB, USB device, temp 32 devbuf, pcb, routetbl, ifaddr, sem, dirhash, in_multi, exec, xform_data, UVM amap, USB, temp 64 devbuf, pcb, routetbl, ifaddr, vnodes, dirhash, proc, VFS cluster, in_multi, ether_multi, exec, VM swap, UVM amap, USB, packet tags, NDP, temp 128 devbuf, pcb, routetbl, ifaddr, UFS quota, UFS mount, sem, dirhash, ttys, pfkey data, inodedep, UVM amap, USB, NDP, temp 256 devbuf, routetbl, ifaddr, ioctlops, vnodes, UFS mount, shm, dirhash, UVM amap, USB, USB device, temp 512 devbuf, ifaddr, sysctl, ioctlops, mount, vnodes, UFS mount, VM map, dirhash, file desc, proc, NFS srvsock, NFS daemon, ttys, newblk, UVM amap, USB, USB device, temp 1024 devbuf, pcb, ioctlops, UFS mount, shm, dirhash, file desc, ttys, exec, UVM amap, crypto data, temp 2048 devbuf, ifaddr, ioctlops, namecache, UFS mount, file desc, proc, VM swap, UVM amap, UVM aobj, temp 4096 devbuf, ioctlops, UFS mount, shm, file, file desc, pagedep, UVM amap, temp 8192 devbuf, UFS mount, file, file desc, MSDOSFS mount, UVM amap 16384 devbuf, NFS node, namecache, UFS quota, UFS mount, file, ISOFS mount, inodedep, indirdep, UVM amap, temp 32768 devbuf, UVM amap 65536 VM swap, UVM amap 131072 VM swap, UVM amap 262144 namecache, UVM amap Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) devbuf 2000 1340K 1340K 78644K 20940 0 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768 pcb6712K 38K 78644K 23425980 0 16,32,64,128,1024 routetbl94 9K 11K 78644K205810 0 16,32,64,128,256 ifaddr5616K 16K 78644K 560 0 32,64,128,256,512,2048 sysctl 2 1K 1K 78644K20 0 16,512 ioctlops 0 0K 4K 78644K 8800 0 256,512,1024,2048,4096 mount 4 2K 3K 78644K50 0 512 NFS node 116K 16K 78644K10 0 16384 vnodes4513K 93K 78644K 1012100 0 64,256,512 namecache 3 274K274K 78644K30 0 2048,16384,262144 UFS quota3621K 21K 78644K 360 0 128,16384 UFS mount1753K 53K 78644K 170 0 16,128,256,512,1024,2048,4096,8192,16384 shm72 282K 1062K 78644K598830 0 256,1024,4096 VM map 3 2K 2K 78644K30 0 512 sem 2 1K 1K 78644K20 0 32,128 dirhash 28256K 83K 78644K 3579000 0 16,32,64,128,256,512,1024 file 0 0K 12K 78644K 1380 0 4096,8192,16384 file desc7244K142K 78644K655130 0 512,1024,2048,4096,8192 proc14 6K 6K 78644K 140 0 64,512,2048 VFS cluster 0 0K 11K 78644K 34697140 0 64 NFS srvsock 2 1K 1K 78644K20 0 512 NFS da
Re: ftp-proxy does not work in secure level 2
On Mon, 3 Jul 2006, c.s.r.c.murthy wrote: > We have configured a firewall with pf on openbsd-3.9. It is found that > ftp-proxy is unable to operate when system is put in secure level 2. > This is due to the fact that ftp-proxy can't add/delete rules in pf in > secure level 2. But for security reasons we would like to have the > system running in secure level 2. Is there a soultion to have the > ftp-proxy working in secure level 2? I don't think so. Securelevel 2 makes sure that userland can no longer modify pf rules. ftp-proxy is a userland program that modifies pf rules... both work that way by design. Those are clearly opposites so it's not something that can be fixed, short of changing the design. I'll add this to the CAVEATS section of the ftp-proxy manpage. -- Cam
Re: [OpenBGPd] Can a nexthop be set on routes announced as "my network" ?
On Mon, Jul 03, 2006 at 03:58:13PM +0200, Andrea Cocito wrote: > Hi, > > after googling, rereading the manuals and lurking into the code I > really could > not find a way to do this, unless I am missing something really simple! > > I have two BGP routers on a small subnet where they peer with a transit > provider, the two routers have a carp shared IP aswell, thus each of > them has > in there a $myip a $carpip and a $peerip > > I wish that each of them when announcing the network I have in > configuration > as "network x.x.x.x/19" sends the announcement stating that $peerip > is the > nexthop, I am not using "depend" options on carp, what I want is that > the > traffic form the peer AS goes straight to the CARP IP (which > failovers in 50 ms, > much faster than anything BGP can ever do..). > Are you sure that you want to set the nexthop to $peerip. You send a update to your peer with himself as nexthop?! -- this will not work. I guess you want to set the nexthop to the $carpip instead. > I have tried: > > - Having inside the "neighbor" configuration block a "set nexthop > $carpip", > but this seems to be plainly ignored > This will change the incomming routes and not the outgoing ones. See man page almost all set options inside neighbor statements work on incomming updates. You can verify that with bgpd -nvv where these set roules are expanded to real filter rules. > - Having an explicit "match to $peerip set nexthop $carpip", but that > seems > to affect only routes re-announched to the peer and not routes coming > from my "network a.b.c.d/19" option. > match to + set nexthop was "broken" until recently. The problem is that nexthops are added and verified asynchronously and so setting them on outgoing rules did not work. I fixed this by preloading nexthops that are used by the filters. > - Checking into the code, from what I see into mrt.c, function > mrt_dump_bgp_msg(), lines 123-124, the address placed into the BGP > message > is abruptly ((struct sockaddr_in *)&peer->sa_local)- > >sin_addr.s_addr) which > confirms why any option does not work. > This has nothing to do with what is set as nexthop. mrt_dump_bgp_msg() dumps a BGP message and in the header both the local and remote IP address is stored. This header is written by mrt_dump_bgp_msg(). Have you tried network a.b.c.d/19 set nexthop $carpip this should already work with -stable. > I think that the possibility to announce an explicit nexthop to a > peer for > our AS's network(s) would be useful not only with this specific setup > but also > for all those who run BGP on an IP that is not the one of the > "router" that > has to receive the traffic. > > I am more than willing to change the code myself but an hint would be > very > appreciated: am I missing something ? Is mrt_dump_bgp_msg() the right > place to > do it ? Hints on how to make it configurable (I would say an option > into the > peer or group configuration block). > First try the "network a.b.c.d/19 set nexthop $carpip" option if that does not help you need to run a -current bgpd. Additionally mrt_dump_bgp_msg() is totaly the wrong spot to fix this. The code is more in rde_update.c and rde_filter.c plus some parts in rde_rib.c. > Thank you for your attention and help. > No problem. -- :wq Claudio
Re: starting Apache in SSL mode
On Mon, Jul 03, 2006 at 03:02:46PM +0200, FTP wrote: > On Mon, Jul 03, 2006 at 10:47:04AM +0200, Joachim Schipper wrote: > > On Sun, Jul 02, 2006 at 10:32:12PM +0200, FTP wrote: > > > On Tue, Jun 27, 2006 at 05:03:52PM +0200, FTP wrote: > > > > when I try to access the site via lynx I do get an SSL error message > > > > moaning that I have a self-signed cert. After accepting this, the > > > > page gets dispalyed. So it looks like the problem is with the CA? > > > > How do I correct that? I found the a reference in > > > > "manual/mod/mod_ssl/ssl_faq.html#ToC24" but mentions a "sign.sh" > > > > script wich isn't present in the OBSD package. > > > > > > any chance to draw some attention to the above? > > > > There are two basic solutions: > > 1. Get a certificate from a commercial CA - Verisign, Thawte, > > and the like. This will be trusted by default in most applications, > > especially browsers. > > 2. Create your own certificate, or whole CA chain. In this case, > > you'll have to tell applications and visitors to accept the certificate. > > I created my own CA, and had it sign one certificate per service. The > > users then import the CA (in the ideal world) or just click 'accept > > always' or the equivalent in their browser/mail client/... (in the real > > world). [1] > > > > If you want to go with the second option, Google has lots of HOWTO's. > > It's not too difficult, but it does cost some work - and, being crypto, > > finding out just why it doesn't work is not trivial. > > > > Joachim > > > > [1] And then complain when the certificate expires. Well, the CA has a > > much longer lifetime... > > > > but I was following the procedure described in: > http://openbsd.org/faq/faq10.html#HTTPS > > which normally should cover the self-signed cert part as well - or not? > > Thanks > > George > now I get via lynx the following: # lynx https://x.x.x.x Looking up x.x.x.x Making HTTPS connection to x.x.xx. Alert!: Unable to connect to remote host. lynx: Can't access startfile https://x.x.x.x/
[OpenBGPd] Can a nexthop be set on routes announced as "my network" ?
Hi, after googling, rereading the manuals and lurking into the code I really could not find a way to do this, unless I am missing something really simple! I have two BGP routers on a small subnet where they peer with a transit provider, the two routers have a carp shared IP aswell, thus each of them has in there a $myip a $carpip and a $peerip I wish that each of them when announcing the network I have in configuration as "network x.x.x.x/19" sends the announcement stating that $peerip is the nexthop, I am not using "depend" options on carp, what I want is that the traffic form the peer AS goes straight to the CARP IP (which failovers in 50 ms, much faster than anything BGP can ever do..). I have tried: - Having inside the "neighbor" configuration block a "set nexthop $carpip", but this seems to be plainly ignored - Having an explicit "match to $peerip set nexthop $carpip", but that seems to affect only routes re-announched to the peer and not routes coming from my "network a.b.c.d/19" option. - Checking into the code, from what I see into mrt.c, function mrt_dump_bgp_msg(), lines 123-124, the address placed into the BGP message is abruptly ((struct sockaddr_in *)&peer->sa_local)- >sin_addr.s_addr) which confirms why any option does not work. I think that the possibility to announce an explicit nexthop to a peer for our AS's network(s) would be useful not only with this specific setup but also for all those who run BGP on an IP that is not the one of the "router" that has to receive the traffic. I am more than willing to change the code myself but an hint would be very appreciated: am I missing something ? Is mrt_dump_bgp_msg() the right place to do it ? Hints on how to make it configurable (I would say an option into the peer or group configuration block). Thank you for your attention and help. A. PS: I am off-list though I check it on the web, cc: would be appreciated, thanks. -- Andrea Cocito [EMAIL PROTECTED] IEO -- European Institute of Oncology Department of Experimental Oncology Fundamental Bioinformatics Research Unit - Director Via Ripamonti 435 20141 Milano - Italy tel: +39-02-57489857 fax: +39-02-57489851 IFOM -- FIRC Institute of Molecular Oncology IT and Bioinformatics services - Coordinator Via Adamello 16 20139 Milano - Italy tel: +39-02-56816055 fax: +39-02-574303231
Re: starting Apache in SSL mode
On Mon, Jul 03, 2006 at 10:47:04AM +0200, Joachim Schipper wrote: > On Sun, Jul 02, 2006 at 10:32:12PM +0200, FTP wrote: > > On Tue, Jun 27, 2006 at 05:03:52PM +0200, FTP wrote: > > > when I try to access the site via lynx I do get an SSL error message > > > moaning that I have a self-signed cert. After accepting this, the > > > page gets dispalyed. So it looks like the problem is with the CA? > > > How do I correct that? I found the a reference in > > > "manual/mod/mod_ssl/ssl_faq.html#ToC24" but mentions a "sign.sh" > > > script wich isn't present in the OBSD package. > > > > any chance to draw some attention to the above? > > There are two basic solutions: > 1. Get a certificate from a commercial CA - Verisign, Thawte, > and the like. This will be trusted by default in most applications, > especially browsers. > 2. Create your own certificate, or whole CA chain. In this case, > you'll have to tell applications and visitors to accept the certificate. > I created my own CA, and had it sign one certificate per service. The > users then import the CA (in the ideal world) or just click 'accept > always' or the equivalent in their browser/mail client/... (in the real > world). [1] > > If you want to go with the second option, Google has lots of HOWTO's. > It's not too difficult, but it does cost some work - and, being crypto, > finding out just why it doesn't work is not trivial. > > Joachim > > [1] And then complain when the certificate expires. Well, the CA has a > much longer lifetime... > but I was following the procedure described in: http://openbsd.org/faq/faq10.html#HTTPS which normally should cover the self-signed cert part as well - or not? Thanks George
Re: 3.9 freeze
On Mon, Jul 03, 2006 at 09:45:22AM -0300, diego wrote: > no, I can only ping the server or change tty (ctrl alt fn), but I can't > type anything. you should sysctl ddb.console=1 for that to work... > - Original Message - > From: "Pedro Martelletto" <[EMAIL PROTECTED]> > To: "diego" <[EMAIL PROTECTED]> > Cc: > Sent: Monday, July 03, 2006 9:34 AM > Subject: Re: 3.9 freeze > > > >Can you break into ddb? > > > >-p. > -- paranoic mickey (my employers have changed but, the name has remained)
Re: 3.9 freeze
no, I can only ping the server or change tty (ctrl alt fn), but I can't type anything. - Original Message - From: "Pedro Martelletto" <[EMAIL PROTECTED]> To: "diego" <[EMAIL PROTECTED]> Cc: Sent: Monday, July 03, 2006 9:34 AM Subject: Re: 3.9 freeze Can you break into ddb? -p.
Re: 3.9 freeze
Can you break into ddb? -p.
kernel settings for pf default block
> This seems to be widely discussed problem in openbsd pf. There is no > kernel parameter that makes the pf to block all packets by default. I > have searched on the internet and found some discussion taken place in > 2005 regarding this. The discussion concludes no such parameter in > kernel. Are there any changes done in openbsd latest to have a kernel > configurable parameter to make pf block packets by default? use siteXX.tgz to customize install/upgrade process as you need including "block all" in /etc/pf.conf. see http://www.openbsd.org/faq/faq4.html#site
3.9 freeze
Hi all, I have problems with 3.9, sometimes I recived "/bsd:
uvm_mapent_alloc: out of static map entries" without panics, but the last
time after 4 thar message the server freeze.
Yesterday server freeze again without any message, I can't connect to the
server, but ping respond.
It's run apache, qmail, mysql, djbdns, vpopmail, courier-imap, clamav,
spamassassin, pure-ftpd.
When server freeze I running a "systat vmstat", maybe it's help.
thanks in advance.
OpenBSD 3.9-stable (GENERIC) #0: Thu May 18 07:50:56 ART 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz ("GenuineIntel" 686-class) 2.80 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,CNXT-ID
real mem = 2146140160 (2095840K)
avail mem = 1952202752 (1906448K)
using 4278 buffers containing 107409408 bytes (104892K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 11/05/04, BIOS32 rev. 0 @ 0xf0010
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3d40/224 (12 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801EB/ER LPC" rev 0x00)
pcibios0: PCI bus #3 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x2200
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82875P Host" rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel 82875P AGP" rev 0x02
pci1 at ppb0 bus 1
ppb1 at pci0 dev 3 function 0 "Intel 82875P PCI-CSA" rev 0x02
pci2 at ppb1 bus 2
em0 at pci2 dev 1 function 0 "Intel PRO/1000CT (82547EI)" rev 0x00: irq 10,
address 00:11:11:c1:1c:bf
uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: irq 5
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: irq 9
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 29 function 2 "Intel 82801EB/ER USB" rev 0x02: irq 10
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3 at pci0 dev 29 function 3 "Intel 82801EB/ER USB" rev 0x02: irq 5
usb3 at uhci3: USB revision 1.0
uhub3 at usb3
uhub3: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: irq 9
usb4 at ehci0: USB revision 2.0
uhub4 at usb4
uhub4: Intel EHCI root hub, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered
ppb2 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0xc2
pci3 at ppb2 bus 3
ami0 at pci3 dev 0 function 0 "Symbios Logic MegaRAID" rev 0x01: irq 10 LSI
523 64b/lhc
ami0: FW 713N, BIOS vG119, 64MB RAM
ami0: 1 channels, 0 FC loops, 1 logical drives
scsibus0 at ami0: 40 targets
sd0 at scsibus0 targ 0 lun 0: SCSI2 0/direct fixed
sd0: 572331MB, 572331 cyl, 64 head, 32 sec, 512 bytes/sec, 1172133888 sec
total
scsibus1 at ami0: 16 targets
vga1 at pci3 dev 6 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pciide0 at pci3 dev 7 function 0 "Promise PDC20319" rev 0x02: DMA
pciide0: using irq 11 for native-PCI interrupt
fxp0 at pci3 dev 8 function 0 "Intel PRO/100 VE" rev 0x01, i82562: irq 11,
address 00:11:11:c1:1c:c2
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
ichpcib0 at pci0 dev 31 function 0 "Intel 82801EB/ER LPC" rev 0x02
pciide1 at pci0 dev 31 function 1 "Intel 82801EB/ER IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
pciide1: channel 0 disabled (no drives)
pciide1: channel 1 disabled (no drives)
pciide2 at pci0 dev 31 function 2 "Intel 82801EB SATA" rev 0x02: DMA,
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide2: using irq 10 for native-PCI interrupt
ichiic0 at pci0 dev 31 function 3 "Intel 82801EB/ER SMBus" rev 0x02: irq 11
iic0 at ichiic0
adt0 at iic0 addr 0x2e: lm85 (ADT7460) rev 62
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
biomask ef65 netmask ef65 ttymask ffe7
pctr: user-level cycle count
kernel settings for pf default block
Hi, This seems to be widely discussed problem in openbsd pf. There is no kernel parameter that makes the pf to block all packets by default. I have searched on the internet and found some discussion taken place in 2005 regarding this. The discussion concludes no such parameter in kernel. Are there any changes done in openbsd latest to have a kernel configurable parameter to make pf block packets by default? thanks in advance murthy [demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a name of murthy.20019DEFANGED-vcf]
Re: Boost OpenBSD security - Zophie for 3.9
On Mon, 03 Jul 2006 12:47:40 +0200 Marcin Wilk <[EMAIL PROTECTED]> wrote: > > Do I understand correctly I could just cvs co usr/bin/who and use the > official who and see who is online? > > Yes because only process privacy is done in kernel. > What's the point ?
ftp-proxy does not work in secure level 2
Hi, We have configured a firewall with pf on openbsd-3.9. It is found that ftp-proxy is unable to operate when system is put in secure level 2. This is due to the fact that ftp-proxy can't add/delete rules in pf in secure level 2. But for security reasons we would like to have the system running in secure level 2. Is there a soultion to have the ftp-proxy working in secure level 2? thanks in advance murthy [demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a name of murthy.23611DEFANGED-vcf]
Re: inetd on by default
On Mon, 3 Jul 2006, [EMAIL PROTECTED] wrote: > Hi > > Here we go again, why is inetd on by default? > > I am very sorry to ask this question! My guess is that it has been asked a > thousand times. I did look in the archives and on google, trying to find a > clear answer but I must have mised it. > > The note on the inetd.conf file, which states, that it is almost always > needed, doesn't provide that as the reason why it is on. > > The reason why I post this is because I have read many times about OpenBSD, > that EVERYTHING is off by default. I never gave it much thought until I had to > do some testing at work, with both FreeBSD and NetBSD. I was rather surprised > that both FreeBSD and NetBSD have inetd off by default but OpenBSD doesn't. So > what? So nothing! You were misinformed that we shut everything off. We do not want to create an unusable system. > > One of the first things I do, after installing OpenBSD, is to turn it off. > Later if needed I turn it on but I have never needed it except on a machine > running tftp. inetd provides a few standard services, like ident. Some things use those services, like mail. > > I do understand that since it is running by default it doesn't provide a risk, > otherwise OpenBSD would have turned it off. > > With the risk of being flamed: In my opinion it should be off be default. That > way absolutely nothing is running before it is turned on by the user. It is useful, there's no risk and it consumes very little resources. Why shut it off? You have given no reason other than: I do not like to run it. So don't. -Otto
Re: IPSec unspec transport
Massimo Lusetti wrote: On Mon, 2006-07-03 at 00:51 -0700, Clint Pachl wrote: Are both end points trying to negotiate? Try using the "passive" keyword on one endpoint: "ike passive esp ..." Yes both active. Does that should cause problems? Here is what I have noticed while watching tcpdump: each end point will negotiate with the other end point at some time interval, which seems to be somewhat random. I have started both end points in active mode and because of the randomness and different times each isakmpd was started on each end point, one isakmpd is able to make the negotiation before the other one and every thing works fine. However, (and I may be totally wrong here) at some agreed upon time in the future, new keys will be exchanged. This is where you may be running into problems, when both boxes are trying to initiate the exchange, creating an unknown state. I have experienced the same issue. I don't know the details of what exactly is happening, however, it seems to be a synchronization problem. Here's what I have done to get rid of the "unspec transport" and setup the proper flows and SAs: Execute on the "passive" box first, then the other: # ipsecctl -F # echo R > /var/run/isakmpd.fifo # ipsecctl -f /etc/ipsec.conf I know how to put it up again and i actually use -d just to keep up others tunnel. Very good, forgot to mention that. Anyway you're telling me that every time your tunnel fall you are there to cast that command to bring it up again? That's not suitable... : Agreed, that is not suitable and I don't do that. I guess I misunderstood the point at which your failure was occurring. I believed it to be initially or some short time after you started each end point. In my experience, I am using IPSec to secure wireless clients to an AP. In my first configuration, all clients and the AP were ike negotiators, "active," and I was experiencing unspec transport. I changed the ipsec.conf on the AP only to be a passive ike and ran the set of commands I mentioned earlier and everything worked. I guess I assumed you changed your ipsec.conf, making one end point passive, hence the set of commands to put every thing in sync. Sorry I misunderstood. What i really want to know (investigate) is what is causing this drops since they happen just on one line not in the other and the devices are all the same just as the OpenBSD version. Is the traffic the same on each line? I have had much success with ssh, http, ftp, and ICMP traffic through my IPSec tunnel, however, X11 seems to be unreliable. -pachl
Re: Boost OpenBSD security - Zophie for 3.9
At 07:18 2006-07-03, you wrote: On 7/2/06, Marcin Wilk <[EMAIL PROTECTED]> wrote: At 22:35 2006-07-02, you wrote: >On Sun, Jul 02, 2006 at 12:20:49PM -0700, Greg Thomas wrote: > > On 7/2/06, Tobias Ulmer <[EMAIL PROTECTED]> wrote: > >> On Sun, Jul 02, 2006 at 03:13:59PM +0200, Tomasz Zielinski wrote: > >>> Hello, > >>> > >>> Zophie is patch that contains new security features for OpenBSD 3.9. BSD > >>> license. I have not tested it personaly, but probably it's worth to > >>> analyze it and maybe even incorporate. More info: > >>> http://www.0penbsd.com/zophie.html, http://akcja.0penbsd.com/zosia/ > >>> > >> I normally don't take the bait, but this one is so cute... > >> > >> After reading through the diffs: (not supplied for added obfusication?) > >> > >> - add a new sysctl to the kernel. > >> - patch some userland tools. > >> - If this sysctl is set, supress certain information. > >> > >> Rocket sience! Even the dumbest scriptkiddie could just compile > >> and run these tools from the original OpenBSD sources. > >> > >> Probably the whole "Polish Underground Group profess OpenBSD OS as a > >> religion" is a big subtle joke? If so, well done and thanks for the good > >> laugh :) > > > > If it is a subtle joke I sure like the screenshots of the install. > >However, note that the page is quite frank about what is being done, >from the web page quoted above: > >- kern.zophie.privacy > This setting is responsible for process privacy in finger, last, >netstat, ps, users, w, and who. > Value 1 turns on this feature. > >This, obviously, still doesn't make it very useful (if only because, >even after you've mounted everything noexec, you still have top, and so >on and so forth) - but the above should be enough to arouse suspicion. > > Joachim Process privacy itself is done in kernel so top & other tools (like lsof for example) will not work. Ps, users, w & who are pathed to not show other users that are in & this is independent with process privacy. You may find OpenBSD that is on screenshots here: http://nicram.sytes.net/openbsd/openbsd-3.9-i386-zophie.iso It is extactly same OpenBSD. & yes it is very easy to make it on Your own :) This is how KISS apps should be made, even when they change something in kernel :) Best Regards Do I understand correctly I could just cvs co usr/bin/who and use the official who and see who is online? Yes because only process privacy is done in kernel.
Re: IPSec unspec transport
On Mon, 2006-07-03 at 00:51 -0700, Clint Pachl wrote: > Are both end points trying to negotiate? Try using the "passive" keyword > on one endpoint: "ike passive esp ..." Yes both active. Does that should cause problems? > I have experienced the same issue. I don't know the details of what > exactly is happening, however, it seems to be a synchronization problem. > Here's what I have done to get rid of the "unspec transport" and setup > the proper flows and SAs: > > Execute on the "passive" box first, then the other: > # ipsecctl -F > # echo R > /var/run/isakmpd.fifo > # ipsecctl -f /etc/ipsec.conf I know how to put it up again and i actually use -d just to keep up others tunnel. Anyway you're telling me that every time your tunnel fall you are there to cast that command to bring it up again? That's not suitable... : What i really want to know (investigate) is what is causing this drops since they happen just on one line not in the other and the devices are all the same just as the OpenBSD version. To add infos i just dropped down the max-mss size to a lower value cause i was seeing a lot of DF! packets without that setting and now all packets aren't fragmented by the routers between my peers. Again i'm not so sure how this is related but digging through the problem i've discovered that the time the tunnel fall is near the time the ISP's router is negotiating its own wan IP address through PPPoA with the ISP's kerberos server. Does this sound resonable or it is totally unrelated? > > Also, make sure all IP addresses in ipsec.conf are reachable; check > netstat -rnfinet. Double checked. Thanks for your time -- Massimo
Re: Encryption and Compression with ipsecctl?
1. IPcomp is only used if it results in smaller packets 2. IPcomp on OpenBSD is broken and does not work correctly (some packets are not compressed correctly). -m
Re: Patent jeopardizes IETF syslog standard
2006/7/3, laurent FANIS <[EMAIL PROTECTED]>: Yeah that is true i didn't see it but wouldn't be possible to buy off people ?I mean the company is in china and it is a country that has a certain degree of corruption.This is what i'm afraid of too. You are right to a degree (the patent will surely be tried in USA too), but it's also a question of double standards. I wonder how the USA will see the patent system in 2020 when most of the patents will come out of China... Best Martin
Re: starting Apache in SSL mode
On Sun, Jul 02, 2006 at 10:32:12PM +0200, FTP wrote: > On Tue, Jun 27, 2006 at 05:03:52PM +0200, FTP wrote: > > when I try to access the site via lynx I do get an SSL error message > > moaning that I have a self-signed cert. After accepting this, the > > page gets dispalyed. So it looks like the problem is with the CA? > > How do I correct that? I found the a reference in > > "manual/mod/mod_ssl/ssl_faq.html#ToC24" but mentions a "sign.sh" > > script wich isn't present in the OBSD package. > > any chance to draw some attention to the above? There are two basic solutions: 1. Get a certificate from a commercial CA - Verisign, Thawte, and the like. This will be trusted by default in most applications, especially browsers. 2. Create your own certificate, or whole CA chain. In this case, you'll have to tell applications and visitors to accept the certificate. I created my own CA, and had it sign one certificate per service. The users then import the CA (in the ideal world) or just click 'accept always' or the equivalent in their browser/mail client/... (in the real world). [1] If you want to go with the second option, Google has lots of HOWTO's. It's not too difficult, but it does cost some work - and, being crypto, finding out just why it doesn't work is not trivial. Joachim [1] And then complain when the certificate expires. Well, the CA has a much longer lifetime...
inetd on by default
Hi Here we go again, why is inetd on by default? I am very sorry to ask this question! My guess is that it has been asked a thousand times. I did look in the archives and on google, trying to find a clear answer but I must have mised it. The note on the inetd.conf file, which states, that it is almost always needed, doesn't provide that as the reason why it is on. The reason why I post this is because I have read many times about OpenBSD, that EVERYTHING is off by default. I never gave it much thought until I had to do some testing at work, with both FreeBSD and NetBSD. I was rather surprised that both FreeBSD and NetBSD have inetd off by default but OpenBSD doesn't. So what? So nothing! One of the first things I do, after installing OpenBSD, is to turn it off. Later if needed I turn it on but I have never needed it except on a machine running tftp. I do understand that since it is running by default it doesn't provide a risk, otherwise OpenBSD would have turned it off. With the risk of being flamed: In my opinion it should be off be default. That way absolutely nothing is running before it is turned on by the user. Best and kind regards, Rico
Re: IPSec unspec transport
Massimo Lusetti wrote: I got a VPN network which works quite well, i mean works very well thanks to OpenBSD and its implementation but i got one end point over the 6 running which causing me troubles. The configuration is done with ipsec.conf and is identical to others which works well. Here some example config: ike esp from $MY_NET to $OTHER_NET peer $VPN_PEER main auth hmac-md5 enc aes Are both end points trying to negotiate? Try using the "passive" keyword on one endpoint: "ike passive esp ..." Isakmpd is started with no .conf and .policy just with -K and use IPv4 private/pubkeys as identifiers on public static IPs. This all on a OpenBSD 3.9-current (GENERIC-RD) #0: Tue Mar 28 12:41:04 EST 2006 From the troubling VPN gateway and respectively from the central VPN gatewayt i (apparently randomly) got: unspec transport from x.y.w.z to z.w.y.x spi 0xa0a35d6a and the tunnel with the flows along falls. What unspec transport actually means? What could cause the above message? I have experienced the same issue. I don't know the details of what exactly is happening, however, it seems to be a synchronization problem. Here's what I have done to get rid of the "unspec transport" and setup the proper flows and SAs: Execute on the "passive" box first, then the other: # ipsecctl -F # echo R > /var/run/isakmpd.fifo # ipsecctl -f /etc/ipsec.conf Note: if you have other flows and SAs setup that you want to preserve, ipsecctl -F may be hazardous. Also, make sure all IP addresses in ipsec.conf are reachable; check netstat -rnfinet. -pachl
Re: Patent jeopardizes IETF syslog standard
On 7/3/06, J. C. Roberts <[EMAIL PROTECTED]> wrote: On Mon, 3 Jul 2006 09:40:01 +0300, "laurent FANIS" <[EMAIL PROTECTED]> wrote: >Couldn't resist asking but can they really patent : >"sending "formatted" data over SSL" ? >That is just plain ridiculous !! As far as I know, at the moment it's only a patent *application* rather than a granted patent. You can *apply* for a patent on anything you like but that doesn't mean the patent will be granted. Yeah that is true i didn't see it but wouldn't be possible to buy off people ?I mean the company is in china and it is a country that has a certain degree of corruption.This is what i'm afraid of too.And countries/companies are bending over to get parts in the country growing economics (cough *yahoo* cough *google*).Anyways that is off-topic and I don't have that much liberties in my country so i will shut up now. >If i remember correctly the is also an RFC just for syslog under BSD. >A lot of devices already have syslog build in (for instance my AP >piece of crap USR has a syslog function) machines are going to be >pulled of the market ? That is plain dumb, we are heading for another >one of those frenzy" lets patent everything". You a said "another" ? -Unfortunately, the frenzy has never stopped or even slowed down, instead, it's only continued to grow worse. Well i felt it calmed down a little after some debacle in the states,but then again i was wrong , sorry . Best Regards Laurent.
Re: Patent jeopardizes IETF syslog standard
On Mon, 03 Jul 2006 01:14:59 -0600, Theo de Raadt <[EMAIL PROTECTED]> wrote: >> I'm a bit confused by your reply. Yes, I kind of see what you mean but >> it also seems I failed miserably to write things clearly. By putting >> "Official" in quotes, I was trying to point out the stupidity of the bad >> corporate decisions that occur far too often. >> >> There are countless corporate idiots which make the wrong choice because >> they like to waive a nonsense marketing banner saying that they are >> "Compliant" with some "official" standard, regardless if there is a >> standardized, completely free, unincumbered and technically superior >> replacement available. Those bad decisions do slow adoption of a free >> replacement (CARP) and in general, affect inter operability of systems >> because they chose to support some encumbered protocol rather than CARP. >> >> I can kind of see how saying their decisions are wrong/bad might be >> limiting but I don't understand how it would give them more power to do >> it again? >> >> I've got this bad feeling that I'm missing something that should be >> totally obvious... please apply the clue stick. > >What did you miss? > >By even using "official" in quotes, and your statement: > >>> Don't misunderstand me, CARP is an amazingly innovative and extremely >>> useful implementation of a redundancy protocol. It's technically better >>> than HSRP or any of the versions of VRRP but the problems till stands >>> that it is not an "official" protocol, which simply means adoption and >>> inter operability will suffer to some degree. > >What are you doing? You are saying that your prediction is that >it WILL suffer in adoption, it WILL suffer in inter operability. > >Keep at it. You might get what you want. Because what you wrote, it >is what you wanted right? > >The problem is there are a whole lot of people who are willing to discuss >the problems their ideas/implimentations face. And it actually does >affect the adoption of our stuff. That's because noone from a corporate >role would every say such a thing. > >So go ahead, be honest. Fight the losing fight. > >The fact is that CARP (+ pfsync + sasync) kicks the crap out of anything >that is standardized.. Got it. It's the ``self-fulfilling prophecy '' thing. Thanks. jcr -- Free, Open Source CAD, CAM and EDA Tools http://www.DesignTools.org
IPSec unspec transport
I got a VPN network which works quite well, i mean works very well thanks to OpenBSD and its implementation but i got one end point over the 6 running which causing me troubles. The configuration is done with ipsec.conf and is identical to others which works well. Here some example config: ike esp from $MY_NET to $OTHER_NET peer $VPN_PEER main auth hmac-md5 enc aes Isakmpd is started with no .conf and .policy just with -K and use IPv4 private/pubkeys as identifiers on public static IPs. This all on a OpenBSD 3.9-current (GENERIC-RD) #0: Tue Mar 28 12:41:04 EST 2006 >From the troubling VPN gateway and respectively from the central VPN gatewayt i (apparently randomly) got: unspec transport from x.y.w.z to z.w.y.x spi 0xa0a35d6a and the tunnel with the flows along falls. What unspec transport actually means? What could cause the above message? Any hint is really appreciated, thanks. -- Massimo
Re: Patent jeopardizes IETF syslog standard
On Mon, 3 Jul 2006 09:40:01 +0300, "laurent FANIS" <[EMAIL PROTECTED]> wrote: >Couldn't resist asking but can they really patent : >"sending "formatted" data over SSL" ? >That is just plain ridiculous !! As far as I know, at the moment it's only a patent *application* rather than a granted patent. You can *apply* for a patent on anything you like but that doesn't mean the patent will be granted. >If i remember correctly the is also an RFC just for syslog under BSD. >A lot of devices already have syslog build in (for instance my AP >piece of crap USR has a syslog function) machines are going to be >pulled of the market ? That is plain dumb, we are heading for another >one of those frenzy" lets patent everything". You a said "another" ? -Unfortunately, the frenzy has never stopped or even slowed down, instead, it's only continued to grow worse. jcr -- Free, Open Source CAD, CAM and EDA Tools http://www.DesignTools.org
Re: Patent jeopardizes IETF syslog standard
J.C. Roberts wrote: Don't misunderstand me, CARP is an amazingly innovative and extremely useful implementation of a redundancy protocol. It's technically better than HSRP or any of the versions of VRRP but the problems till stands that it is not an "official" protocol, which simply means adoption and inter operability will suffer to some degree. Adoption and interoperability are immaterial if everything is OBSD of course. I wonder what percentage of people using OBSD face interoperability issues? Isn't CARP so easy, and OBSD in general, that you just want to install it on all of your machines? -pachl
Re: Patent jeopardizes IETF syslog standard
> I'm a bit confused by your reply. Yes, I kind of see what you mean but > it also seems I failed miserably to write things clearly. By putting > "Official" in quotes, I was trying to point out the stupidity of the bad > corporate decisions that occur far too often. > > There are countless corporate idiots which make the wrong choice because > they like to waive a nonsense marketing banner saying that they are > "Compliant" with some "official" standard, regardless if there is a > standardized, completely free, unincumbered and technically superior > replacement available. Those bad decisions do slow adoption of a free > replacement (CARP) and in general, affect inter operability of systems > because they chose to support some encumbered protocol rather than CARP. > > I can kind of see how saying their decisions are wrong/bad might be > limiting but I don't understand how it would give them more power to do > it again? > > I've got this bad feeling that I'm missing something that should be > totally obvious... please apply the clue stick. What did you miss? By even using "official" in quotes, and your statement: >> Don't misunderstand me, CARP is an amazingly innovative and extremely >> useful implementation of a redundancy protocol. It's technically better >> than HSRP or any of the versions of VRRP but the problems till stands >> that it is not an "official" protocol, which simply means adoption and >> inter operability will suffer to some degree. What are you doing? You are saying that your prediction is that it WILL suffer in adoption, it WILL suffer in inter operability. Keep at it. You might get what you want. Because what you wrote, it is what you wanted right? The problem is there are a whole lot of people who are willing to discuss the problems their ideas/implimentations face. And it actually does affect the adoption of our stuff. That's because noone from a corporate role would every say such a thing. So go ahead, be honest. Fight the losing fight. The fact is that CARP (+ pfsync + sasync) kicks the crap out of anything that is standardized..
Re: Patent jeopardizes IETF syslog standard
On Sun, 02 Jul 2006 22:09:02 -0600, Theo de Raadt <[EMAIL PROTECTED]> wrote: >> Don't misunderstand me, CARP is an amazingly innovative and extremely >> useful implementation of a redundancy protocol. It's technically better >> than HSRP or any of the versions of VRRP but the problems till stands >> that it is not an "official" protocol, which simply means adoption and >> inter operability will suffer to some degree. > >You are wrong. It is officially free and unencumbered. > >Now if you wish to redeclare the word "official" to mean "because >some corporate people playing politics have dictated it be so", >fine, be that way. > >But when you do so you are doing two things: > >1. Limiting yourself. > >2. Giving them the power to do it again. > >I suppose that is your choice. Keep saying that the Man is right. I'm a bit confused by your reply. Yes, I kind of see what you mean but it also seems I failed miserably to write things clearly. By putting "Official" in quotes, I was trying to point out the stupidity of the bad corporate decisions that occur far too often. There are countless corporate idiots which make the wrong choice because they like to waive a nonsense marketing banner saying that they are "Compliant" with some "official" standard, regardless if there is a standardized, completely free, unincumbered and technically superior replacement available. Those bad decisions do slow adoption of a free replacement (CARP) and in general, affect inter operability of systems because they chose to support some encumbered protocol rather than CARP. I can kind of see how saying their decisions are wrong/bad might be limiting but I don't understand how it would give them more power to do it again? I've got this bad feeling that I'm missing something that should be totally obvious... please apply the clue stick. jcr -- Free, Open Source CAD, CAM and EDA Tools http://www.DesignTools.org
