Replicator - PostgreSQL for DB backend
Hi Peter, We use a modified (well hacked) version of PostgreSQL Replicator and have experienced no significant problem. These were our primary DBMS replication requirements: 1. We needed a solution to operate securely within our distributed data environment 100 physical locations, and 10,000 virtual datamarts. 2. We needed a replication topology that was scalable and reliable with no single-point-of-failure, as present in most DBMS Replication topologies. (Another reason why MySQL was not attractive, as at the time only master-slave replication was supported) 3. We required the ability to do asynchronous queries. 4. We required the metadata catalog and file replica catalog to be distributed yet appear virtually centralized. 5. Since we were creating a virtual metadata catalog and a unique autonomous security monitoring and incident handling system, access to all of the source code was required. After looking at a few othersÂ… DBBALANCER http://dbbalancer.sourceforge.net/ we picked PostgreSQL Replicator http://pgreplicator.sourceforge.net/ and made a few customized changes to the source to accommodate our unique security monitoring and incident handling system. I am now in the early stages of planning a complete design of our own PostgreSQL BDMS replicating technology featuring our autonomous security monitoring and incident handling method. I am not sure if the project will be a public or private. On 14 Jul 2003 at 16:44, Peter Nixon wrote: On Mon, 14 Jul 2003 04:24 pm, Bernie, CTA wrote: On 14 Jul 2003 at 10:30, Peter Nixon wrote: Hi List I would like to take a quick straw poll. a) If you use a Database backend for FreeRadius which one do you use? We are an BSDi / Open BSD environment Accounting - Redundant Postgres DB == to other DBMS such as MySQL, Oracle its: 1. No license fee 2. Less Security Vulnerabilities 3. Easier to replacate 4. Lends to a Decentralized / Virtually Centralized DBMS topology, which is better for security applications 5. Better Transaction Processing Performance 6. Less overhead 7. Control of source 8. Scales well 9. Faster Yep. No arguements from me on these :-) For general purpose DB work Postgres pretty much walks all over the competition when you take all these factors into account. I can only imagine needing to pay for a commercial DB if I was handling Terabytes of data. (Postgres happily handles many gigabytes of data per table for me currently) Do you mind telling me what replication system you use (Postgres has several) and how you find it? Are there any gotchas/problems? (I currently run my DBs standalone as I simply don't have the reliability issues with postgres that used to force me to replicate/cluster my MySQL boxes..) TIA -- - - Bernie Chief Technology Architect Chief Security Officer [EMAIL PROTECTED] Euclidean Systems, Inc. *** // There is no expedient to which a man will not go //to avoid the pure labor of honest thinking. // Honest thought, the real business capital. // Observe Think Plan Think Do Think *** - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Replicator - PostgreSQL for DB backend
On 16 Jul 2003 at 8:54, Sean wrote: On Wed, 16 Jul 2003, Bernie, CTA wrote: We use a modified (well hacked) version of PostgreSQL Replicator and have experienced no significant problem. big scissors Just out of curiosity, I am wondering why postgres looked like a better solution than an ldap based solution. LDAP is supposed to be scalable and replicable, and designed for mostly read-only data which to me is what you were looking for. Don't get me wrong, I can also see where replicable postgres stuff would be nice and I would be interested in it for another project (that quite possibly will never get off the gorund), but the first read through your requirements seemed like it was screaming ldap =) Well, for starters we could not tolerate the security vulnerabilities found in certain LDAP implementations, which if exploited could result in denial-of-service attacks and unauthorized privileged access. Furthermore, I believe that the overhead involved implementing and maintaining an LDAP solution cannot be justified when considering security, performance and economics. - - Bernie Chief Technology Architect Chief Security Officer [EMAIL PROTECTED] Euclidean Systems, Inc. *** // There is no expedient to which a man will not go //to avoid the pure labor of honest thinking. // Honest thought, the real business capital. // Observe Think Plan Think Do Think *** - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: User Survey - Which DB backend do you use?
On 14 Jul 2003 at 10:30, Peter Nixon wrote: Hi List I would like to take a quick straw poll. a) If you use a Database backend for FreeRadius which one do you use? We are an BSDi / Open BSD environment Accounting - Redundant Postgres DB == to other DBMS such as MySQL, Oracle its: 1. No license fee 2. Less Security Vulnerabilities 3. Easier to replacate 4. Lends to a Decentralized / Virtually Centralized DBMS topology, which is better for security applications 5. Better Transaction Processing Performance 6. Less overhead 7. Control of source 8. Scales well 9. Faster Auth/Authr - Multiple flat files crypted pass (by Realm) with custom admin system (1000 and 5000 users per Realm / Group) Reason: Compared to DBMS its: 1. Faster 2. Easier to Maintain 3. More Reliable 4. More Secure 5. Independent Fault Tolerant 6. More flexibility for customization. b) If you do not use a DB backend for FreeRadius, but do have a DB on your server or in your rack, what DB is it? see A c) If you do not use a DB backend for FreeRadius, but do have a DB on your server or in your rack, why don't you use it as a backend to FreeRadius? see A Please reply to this thread on the mailing list or to me directly (I am one of the developers) if you wish to keep the info private. I will post a summary in a few days. Thanks in Advance -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - Bernie Chief Technology Architect Chief Security Officer [EMAIL PROTECTED] Euclidean Systems, Inc. *** // There is no expedient to which a man will not go //to avoid the pure labor of honest thinking. // Honest thought, the real business capital. // Observe Think Plan Think Do Think *** - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeRadius AP on same physical machine. Possible?
On 31 Mar 2003, at 0:00, Nikhil Chauhan wrote: Hello: Is it possible that freeRadius and AP functionality (on a WLAN NIC card) be on the same physical machine... Comments appreciated. bhh It is possible to have both Radius and an AP on the same physical machine, at least for those running a flavor of BSD. We have built one, incorporating two Network Interfaces, to research and test our wireless security technology. However, I advise that doing this for any production design would not be wise, as there in no easy way to keep the AP daemon and users in jail (insulated / isolated). A User or Trojan code could gain access to the system's resources through conceivably exploitable vulnerabilities in the AP application/interface, and thus attack or bypass freeradius's authentication/authorization structure. IMO - From a security point of view, best practice is to keep the Radius Authentication/Authorization and Accounting on separate and dedicated machines. - Bernie Chief Technology Architect Chief Security Officer [EMAIL PROTECTED] Euclidean Systems, Inc. *** // There is no expedient to which a man will not go //to avoid the pure labor of honest thinking. // Honest thought, the real business capital. // Observe Think Plan Think Do Think *** - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: strange behaviour during PAP authentication
take two...
On 31 Mar 2003, at 21:10, Jochen Kaiser wrote:
Dear List,
I am experiencing a strange behaviour during pap
authentication.
I tried this with freeradius 0.7 and 0.8.1, both running under
freebsd 4.7.
My steps:
0. preparation of radiusd.conf
under modules section:
pap {
encryption_scheme = crypt
}
under authentication section:
authtype PAP {
pap
}
1. create an account in users file:
perl -e 'print crypt(passwort,aa) '
aaFO1iP18KyBk
[Here the relevant part of the 'users' file:]
[...]
cryjk Auth-Type := pap, User-Password ==
aaFO1iP18KyBk
Idle-Timeout := 3000
[...]
bhh
try:
[user] Auth-Type := PAP, Crypt-Password == [crypted
password]
-
Bernie
Chief Technology Architect
Chief Security Officer
[EMAIL PROTECTED]
Euclidean Systems, Inc.
***
// There is no expedient to which a man will not go
//to avoid the pure labor of honest thinking.
// Honest thought, the real business capital.
// Observe Think Plan Think Do Think
***
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: strange behaviour during PAP authentication
On 31 Mar 2003, at 21:46, Jochen Kaiser wrote: THX for your hint, at laest the try ;-) [users] cryjk Auth-Type := pap, Crypt-Password == aaFO1iP18KyBk Idle-Timeout := 3000 Also, you can not generate the crypt password with perl -e 'print crypt(passwort,aa) ' Use: cryptpasswd --des passwort and get... f4TGeVz4/0dxs - Bernie Chief Technology Architect Chief Security Officer [EMAIL PROTECTED] Euclidean Systems, Inc. *** // There is no expedient to which a man will not go //to avoid the pure labor of honest thinking. // Honest thought, the real business capital. // Observe Think Plan Think Do Think *** - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
