(RADIATOR) Rewriting usernames and what gets logged with AcctLogFileName
Hi, I'd like to have my cake and eat it too, if possible. I'd like to be able to strip off the realm in an Access-Request before proxying it to another RADIUS server, and I'd like to log the accounting records locally (and not proxy them) but leave the realm information intact. Is this possible? Handler Realm=blah RewriteUsername s/^([^@]+).*/$1/# I'd like to only r/w this for the auth packet AcctLogFileName /var/log/radacct/remote/tmx.com.au/detail AuthBy RADIUS Identifier Radius Host192.168.129.1 Host192.168.129.13 Secret keepguessing AuthPort1645 AcctPort1646 Retries 3 RetryTimeout5 NoForwardAccounting /AuthBy /Handler Andrew Andrew Pollock Systems Integrator [EMAIL PROTECTED] http://www.asiaonline.net/ Phone: +61 419788191 Asia Online === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) RE: Rewriting usernames and what gets logged with AcctLogFileName
I think I may have answered my own question, but I'd like to check. If I put this handler above the handler example below, will it do the job for me? Handler Realm=blah,Acct-Status-Type=/Start|Stop AcctLogFileName /var/log/radacct/remote/blah/detail /Handler Will this simply intercept (and accept) accounting packets and log them into the file specified? Thanks Andrew -Original Message- From: Andrew Pollock [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 29 February 2000 5:45 PM To: [EMAIL PROTECTED] Subject: Rewriting usernames and what gets logged with AcctLogFileName Hi, I'd like to have my cake and eat it too, if possible. I'd like to be able to strip off the realm in an Access-Request before proxying it to another RADIUS server, and I'd like to log the accounting records locally (and not proxy them) but leave the realm information intact. Is this possible? Handler Realm=blah RewriteUsername s/^([^@]+).*/$1/ # I'd like to only r/w this for the auth packet AcctLogFileName /var/log/radacct/remote/blah/detail AuthBy RADIUS Identifier Radius Host192.168.129.1 Host192.168.129.13 Secret keepguessing AuthPort1645 AcctPort1646 Retries 3 RetryTimeout5 NoForwardAccounting /AuthBy /Handler Andrew Andrew Pollock Systems Integrator [EMAIL PROTECTED] http://www.asiaonline.net/ Phone: +61 419788191 Asia Online === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) RE: Rewriting usernames and what gets logged with AcctLogFileName
On Tue, Feb 29, 2000 at 06:22:55PM +0800, Andrew Pollock wrote: I think I may have answered my own question, but I'd like to check. If I put this handler above the handler example below, will it do the job for me? Handler Realm=blah,Acct-Status-Type=/Start|Stop AcctLogFileName /var/log/radacct/remote/blah/detail /Handler Will this simply intercept (and accept) accounting packets and log them into the file specified? If it's up the top of the radius.cfg it will do what you want. [EMAIL PROTECTED] === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) spaces in user names
Hi, Earlier I reported that I've noticed a few users being able to login with a space and extra characters... (ie. the user 'ricardo' is able to login with the username 'ricardo kustner') I've traced the problem to the radius server on another machine to which radiator proxies auth request for accounts not found in any of the realms (the other machine has old accounts in a Unix passwd file)... the radius server running there is quite and old version of Livingston's radiusd... so i guess i need to upgrade that one or create a RewriteUsername (/^(\w+)/$1/ ?) to strip anything with extra spaces in usernames dialing in... anyway the point is that it's not radiator's fault... ;) Ricardo. Facing Facts B.V. Wibautstraat 120 1091 GP Amsterdam the Netherlands tel: +31 (0)20 460 42 42 fax: +31 (0)20 460 42 52 e-mail: [EMAIL PROTECTED] www.facingfacts.nl === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Fw: FreeBSD Security Advisory: FreeBSD-SA-00:05.mysql322-server
Because many of the folks here use MySQL, I thought this was appropriate to cross-post here. This affects mysql server v3.22 on any platform, not just FreeBSD. Jay West - Original Message - From: FreeBSD Security Officer [EMAIL PROTECTED]; FreeBSD Security Officer [EMAIL PROTECTED] To: undisclosed-recipients: ; Sent: Monday, February 28, 2000 11:26 PM Subject: FreeBSD Security Advisory: FreeBSD-SA-00:05.mysql322-server -BEGIN PGP SIGNED MESSAGE- = FreeBSD-SA-00:05 Security Advisory FreeBSD, Inc. Topic: MySQL allows bypassing of password authentication Category: ports Module: mysql322-server Announced: 2000-02-28 Affects:Ports collection before the correction date. Corrected: 2000-02-15 FreeBSD only: NO I. Background MySQL is a popular SQL database client/server distributed as part of the FreeBSD ports collection. II. Problem Description The MySQL database server (versions prior to 3.22.32) has a flaw in the password authentication mechanism which allows anyone who can connect to the server to access databases without requiring a password, given a valid username on the database - in other words, the normal password authentication mechanism can be completely bypassed. MySQL is not installed by default, nor is it "part of FreeBSD" as such: it is part of the FreeBSD ports collection, which contains over 3100 third-party applications in a ready-to-install format. FreeBSD makes no claim about the security of these third-party applications, although an effort is underway to provide a security audit of the most security-critical ports. III. Impact The successful attacker will have all of the access rights of that database user and may be able to read, add or modify records. If you have not chosen to install the mysql322-server port/package, then your system is not vulnerable. IV. Workaround Use appropriate access-control lists to limit which hosts can initiate connections to MySQL databases - see: http://www.mysql.com/Manual_chapter/manual_Privilege_system.html for more information. If unrestricted remote access to the database is not required, consider using ipfw(8) or ipf(8), or your network perimeter firewall, to prevent remote access to the database from untrusted machines (MySQL uses TCP port 3306 for network communication). Note that users who have access to machines which are allowed to initiate database connections (e.g. local users) can still exploit the security hole. V. Solution One of the following: 1) Upgrade your entire ports collection and rebuild the mysql322-server port. 2) Reinstall a new package obtained from: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/databases/mys ql-server-3.22.32.tgz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-current/databases/my sql-server-3.22.32.tgz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-current/databases/m ysql-server-3.22.32.tgz 3) download a new port skeleton for the mysql322-server port from: http://www.freebsd.org/ports/ and use it to rebuild the port. 4) Use the portcheckout utility to automate option (3) above. The portcheckout port is available in /usr/ports/devel/portcheckout or the package can be obtained from: ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-2.0.tgz -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBOLtYEVUuHi5z0oilAQHtbwP/TF0hNZwrO/wAuBjYF8Eff5aDU1KtnA9D u0bcUakDgF/nODVxgOFZ1MfaK95PAhRqdYvtwssTqTXwlRB+PU0vtwjdt3p3l8d3 SixfhxT+Ys/v222jK+o6lJdxfKOC4chNDseboSRoCSLEESNl2NDGkBKezKSzzlng vzxtva695bI= =KYqf -END PGP SIGNATURE- This is the moderated mailing list freebsd-announce. The list contains announcements of new FreeBSD capabilities, important events and project milestones. See also the FreeBSD Web pages at http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-announce" in the body of the message === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Dynamic IP with Radmin
Hi, I'd like to use radmin to dynamically grant IP addresses to my dialup users, i have read how to do it statically of course but, does any of you guys have any example/hint about the way it would work with dynamic IP addresses? BTW i use radmin with mysql, thanks for your time! Enrique- -- -- RCP - Internet Peru Tel: +51 1 422-4848 Dpto de Operaciones Fax: +51 1 421-8086 -- === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
No Subject
I am having major problems with a ascend filter issue with uunet. I am not running the nas but buying wholesale dialup and clearing radius myself. I am using the default dictionary wich contains a 242 Ascend atribute but they say they are not recieving anything from me on the 242 Mon Feb 28 14:49:39 2000: DEBUG: Packet dump: *** Received from 153.39.245.142 port 1645 Code: Access-Request Identifier: 3 Authentic: (1461fQ188\C245152151_Dq Attributes: User-Name = "[EMAIL PROTECTED]" CHAP-Password = "0195243?231185135*J21617185216255 201821" NAS-IP-Address = 153.39.242.113 NAS-Port = 1645 Proxy-State = "(1461fQ188\C245152151_Dq026q153'24 5142026m2092071682300 0 10T9193K77V 239wmYO`T194" Mon Feb 28 14:49:39 2000: DEBUG: Handling request with Handler 'Realm=ztel.com' Mon Feb 28 14:49:39 2000: DEBUG: Deleting session for [EMAIL PROTECTED], 153.39.242 .113, 1645 Mon Feb 28 14:49:39 2000: ERR: Attribute number 211 (vendor ) is not defined in your dictionary Mon Feb 28 14:49:39 2000: DEBUG: Handling with Radius::AuthFILE Mon Feb 28 14:49:39 2000: DEBUG: Radius::AuthFILE looks for match with uunet@zte l.com Mon Feb 28 14:49:39 2000: DEBUG: Radius::AuthFILE ACCEPT: Mon Feb 28 14:49:39 2000: DEBUG: Access accepted for [EMAIL PROTECTED] Mon Feb 28 14:49:39 2000: WARNING: No such attribute Framed-Address Mon Feb 28 14:49:39 2000: WARNING: No such attribute Framed-Netmask Mon Feb 28 14:49:39 2000: WARNING: No such attribute Ascend-Data-Filter Mon Feb 28 14:49:39 2000: WARNING: No such attribute Ascend-Data-Filter Mon Feb 28 14:49:39 2000: WARNING: No such attribute Ascend-Data-Filter Mon Feb 28 14:49:39 2000: WARNING: No such attribute Ascend-Data-Filter Mon Feb 28 14:49:39 2000: DEBUG: Packet dump: *** Sending to 153.39.245.142 port 1645 Code: Access-Accept Identifier: 3 Authentic: (1461fQ188\C245152151_Dq Attributes: Proxy-State = "(1461fQ188\C245152151_Dq026q153'24 5142026m2092071682300 0 10T9193K77V 239wmYO`T194" Service-Type = Framed-user Framed-Protocol = PPP Framed-Address = 255.255.255.254 Framed-Netmask = 255.255.255.255 Ascend-Data-Filter = ip in forward tcp est Ascend-Data-Filter = ip in forward dstip 209.207.168.229/32 Ascend-Data-Filter = ip in drop tcp dstport = 25 Ascend-Data-Filter = ip in forward === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) RE: Rewriting usernames and what gets logged with AcctLogFileName
Hello Andrew - On Tue, 29 Feb 2000, Andrew Pollock wrote: I think I may have answered my own question, but I'd like to check. If I put this handler above the handler example below, will it do the job for me? Handler Realm=blah,Acct-Status-Type=/Start|Stop AcctLogFileName /var/log/radacct/remote/blah/detail /Handler Will this simply intercept (and accept) accounting packets and log them into the file specified? Yes it will. The usual caveats apply regarding the order of Handlers in the configuration file (more specific to more general). regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Same AcctLogFileName for two handlers
On Fri, 25 Feb 2000, Mike McCauley wrote: Hi Andrew, On Feb 25, 11:42am, Andrew Pollock wrote: Hi guys, If I have the same AcctLogFileName for two different handlers, will the writing of the detail file be messed up by the two handlers writing to it at the same time? No. Radiator always opens writes and closes all files it writes to,. Should be no problem. *However*, just to make you all aware, Radiator *does not* lock the logfiles it writes to. Therefore there is a *slight* chance that two writes could happen at the same time; granted, the odds are strongly against it. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Same AcctLogFileName for two handlers
Hello David - On Wed, 01 Mar 2000, David Lloyd wrote: On Fri, 25 Feb 2000, Mike McCauley wrote: Hi Andrew, On Feb 25, 11:42am, Andrew Pollock wrote: Hi guys, If I have the same AcctLogFileName for two different handlers, will the writing of the detail file be messed up by the two handlers writing to it at the same time? No. Radiator always opens writes and closes all files it writes to,. Should be no problem. *However*, just to make you all aware, Radiator *does not* lock the logfiles it writes to. Therefore there is a *slight* chance that two writes could happen at the same time; granted, the odds are strongly against it. As Mike said previously, the logfile is opened - then the write occurs - then the file is closed again. Unless some other process also tries to write to the file, locking is not an issue. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
