Re: [pfSense Support] 0.73.6-WRAP board
Uhmm, I see what you mean. Well, I tried with WRAP 2C and the trick is: - configure as normal, with LAN as ethernet nic and WAN as wireless; - give an IP address to both in the same network; - bridge LAN and WAN, you have to change IP because as soon you save the GUI is disconnected...after that reboot and you should be able to connect via wireless ath0 the web GUI. From WAN is forbidden. Let me know Giorgio On 8/5/05, Thomas Huber [EMAIL PROTECTED] wrote: Hello Giorgio I 'd like to have the ath0 on the LAN interface, but it doesn't allow me to configure the LAN to hostap mode, and with only 2 nics, there's not opt1 :-( Maybe that is not how the wireless nics are meant to be used? I am going to try bridging the single ath0 now, maybe that's the solution .. Maybe a hint, anybody? Regards, Thomas On 05.08.2005, at 09:41, Giorgio Ducci wrote: Hi, I'm using WRAP 1E. but I have a tested on a 2C, too. Does make a difference, I just miss an ethernet nic. Cheers Giorgio On 8/5/05, Thomas Huber [EMAIL PROTECTED] wrote: Hi, Just out of curiosity, are you using a 2C or a 1D/E? Thomas On 04.08.2005, at 10:46, Giorgio Ducci wrote: Hi, I'm testing 0.73.6 on a Wrap board with an Atheros mPCI and when I enable interface OPT1 (ath0) and I click on SAVE I get a new page with this on the header: Warning: fopen(/tmp//sbin/ifconfig_wireless): failed to open stream: No such file or directory in /etc/inc/interfaces.inc on line 464 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/interfaces.inc on line 465 Warning: fclose(): supplied argument is not a valid stream resource in /etc/inc/ interfaces.inc on line 466 ifconfig: not found -- The interface settings are ok, anyway, but the SSID is still the default HIDE instead of the new one...when I check on status-interfaces cheers Giorgio PS which is the freeBSD command to mount the CF card in RW and correct some file and to mount in RO mode? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Captive Portal Problems 0.73.6
I'm not sure what's going on, but every time we enable the Captive Portal in 0.73.6 (and older versions we were trying yesterday), the WebGUI starts to hang. Just after enabling it (with Local User Manager being the only setting not at the default value), the WebGUI responds and states that the settings were applied, but after that, nothing I do in the WebGUI works.. I can't get to any other WebGUI page, nor can I change any setting and Save settings... It's like the WebGUI goes out to lunch. Other info: - We're using the Metallic theme. - Our WebGUI runs on HTTPS. (Though we have had the same results on HTTP) - We have had the Squid package installed, but have removed it after running into this problem, thinking it may be related. Even though it has been removed, the problem persists... Is it possible that something was left behind in the uninstall? - We have Advanced Outbound NAT enabled (with only the default rule) with registered IPs on the LAN segment handed out via DHCP. - We have only the default firewall rules in place. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] FreeRadius Package - slight security issue
While looking through the config.xml file to see if I could spot anything unusual (to help me fix the last issue I posted about), I noticed the FreeRadius config... The problem that I saw is that the passwords are stored in clear text. I would think that the passwords should be at least base64encoded for storage, so at least they would be as secure as the locally managed passwords, native to pfSense and Monowall. Paul
[pfSense Support] Resend: Problem with SQUID install
Note: I'm resending this because I'm not sure it actually got through the first time. Been having that problem with gmail on occassion. Currently running 0.73.6 I've actually had this same problem since 68.x, but have just not reported it. If I try to install squid, i get the following: Downloading package configuration file... done. Saving updated package information... done. Downloading squid and its dependencies... done. Checking for successful package installation... done. Loading package configuration... done. Configuring package components... Custom commands... done. Writing configuration... done. Installation completed. However, at the bottom of the screen, under the rest of the interface, the following errors occur: Warning: fopen(/usr/local/etc/squid/squid.conf): failed to open stream: No such file or directory in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fwrite(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 Warning: fclose(): supplied argument is not a valid stream resource in /etc/inc/pkg-utils.inc(424) : eval()'d code on line 1 In the log, I get the following entries: Aug 5 00:06:12 squid: Unable to open configuration file: /usr/local/etc/squid/squid.conf: (2) No such file or directory Aug 5 00:06:12 kernel: pid 1637 (squid), uid 0: exited on signal 6 (core dumped) Aug 5 00:06:12 kernel: pid 1633 (squid), uid 0: exited on signal 6 (core dumped) Aug 5 00:06:12 squid: Unable to open configuration file: /usr/local/etc/squid/squid.conf: (2) No such file or directory Any suggestions? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] FreeRadius Package - slight security issue
On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: While looking through the config.xml file to see if I could spot anything unusual (to help me fix the last issue I posted about), I noticed the FreeRadius config... The problem that I saw is that the passwords are stored in clear text. I would think that the passwords should be at least base64encoded for storage, so at least they would be as secure as the locally managed passwords, native to pfSense and Monowall. Actually, base64encoding would still be less secure (and as an application auditor, wouldn't provide more than another 10 seconds of delay in retrieving them) than local passwords which are one way hashed. I don't know anything about the FreeRadius package so I can't comment directly on what it requires or what the passwords it stores in our config.xml are supposed to resemble. It's an issue, I don't know how to fix it at this point as I've never even looked at that part of code. --Bill --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] FreeRadius Package - slight security issue
Contact the authors of freeradius then. This setup would be no different from freebsd in the back of your room running the same configuration! On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: While looking through the config.xml file to see if I could spot anything unusual (to help me fix the last issue I posted about), I noticed the FreeRadius config... The problem that I saw is that the passwords are stored in clear text. I would think that the passwords should be at least base64encoded for storage, so at least they would be as secure as the locally managed passwords, native to pfSense and Monowall. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] FreeRadius Package - slight security issue
Bill, Well, yes, I realize that base64encoding doesn't provide much in the way of security... But it's better than the data being completely in the clear... I have some encryption/decryption code around here somewhere that could probably be used, but of course the key would have to be in the code, where it could be seen, so even that doesn't provide great security... Paul -Original Message- From: Bill Marquette [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 11:01 AM To: Paul Taylor Cc: support@pfsense.com Subject: Re: [pfSense Support] FreeRadius Package - slight security issue On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: While looking through the config.xml file to see if I could spot anything unusual (to help me fix the last issue I posted about), I noticed the FreeRadius config... The problem that I saw is that the passwords are stored in clear text. I would think that the passwords should be at least base64encoded for storage, so at least they would be as secure as the locally managed passwords, native to pfSense and Monowall. Actually, base64encoding would still be less secure (and as an application auditor, wouldn't provide more than another 10 seconds of delay in retrieving them) than local passwords which are one way hashed. I don't know anything about the FreeRadius package so I can't comment directly on what it requires or what the passwords it stores in our config.xml are supposed to resemble. It's an issue, I don't know how to fix it at this point as I've never even looked at that part of code. --Bill --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Captive Portal Problems 0.73.6
If this is happening then your hitting some big giant locked area of the freebsd kernel. I haven't personally seen this issue but I have noticed that sometimes during filter reload operations the console keyboard stops responding which reminds me of your issue. Just a complete guess. Scott On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: I'm not sure what's going on, but every time we enable the Captive Portal in 0.73.6 (and older versions we were trying yesterday), the WebGUI starts to hang. Just after enabling it (with Local User Manager being the only setting not at the default value), the WebGUI responds and states that the settings were applied, but after that, nothing I do in the WebGUI works.. I can't get to any other WebGUI page, nor can I change any setting and Save settings... It's like the WebGUI goes out to lunch. Other info: - We're using the Metallic theme. - Our WebGUI runs on HTTPS. (Though we have had the same results on HTTP) - We have had the Squid package installed, but have removed it after running into this problem, thinking it may be related. Even though it has been removed, the problem persists... Is it possible that something was left behind in the uninstall? - We have Advanced Outbound NAT enabled (with only the default rule) with registered IPs on the LAN segment handed out via DHCP. - We have only the default firewall rules in place. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] FreeRadius Package - slight security issue
On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: Bill, Well, yes, I realize that base64encoding doesn't provide much in the way of security... But it's better than the data being completely in the clear... I have some encryption/decryption code around here somewhere that could probably be used, but of course the key would have to be in the code, where it could be seen, so even that doesn't provide great security... And I disagree. base64encoding provides zero security. Obscuring the data is no excuse for real protection. If we can protect it the right way (a one way hash), we will. Anything less than a one-way hash means it's reversible, passwords shouldn't be reversible in any way shape or form - I'd rather have glaring plaintext passwords reminding me to do something about them than something that at first glance passes muster. I'll personally back out any commit that does a half-ass job at it (not that I expect anyone to make such a commit). Don't hand out your config.xml and you'll be fine. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] FreeRadius Package - slight security issue
Not to mention I have to stress that this is no different from running free-radius in a non pfSense environment. Your real beef is with the freeradius authors, not us. Scott On 8/5/05, Bill Marquette [EMAIL PROTECTED] wrote: On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: Bill, Well, yes, I realize that base64encoding doesn't provide much in the way of security... But it's better than the data being completely in the clear... I have some encryption/decryption code around here somewhere that could probably be used, but of course the key would have to be in the code, where it could be seen, so even that doesn't provide great security... And I disagree. base64encoding provides zero security. Obscuring the data is no excuse for real protection. If we can protect it the right way (a one way hash), we will. Anything less than a one-way hash means it's reversible, passwords shouldn't be reversible in any way shape or form - I'd rather have glaring plaintext passwords reminding me to do something about them than something that at first glance passes muster. I'll personally back out any commit that does a half-ass job at it (not that I expect anyone to make such a commit). Don't hand out your config.xml and you'll be fine. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] FreeRadius Package - slight security issue
Bill, Sure, if someone gets a hold of the config.xml file, no amount of base64encoding will stop them from getting a password.. But, if someone is in the same room with you looking over your shoulder while you are looking through the config.xml file, there is no need to give them a clear view of usernames and passwords. In a corporate environment, people can walk by your office or cube any time... We have found ourselves in this very situation more than once... Having passwords in a file that we were working on in clear text, when someone unexpectedly dropped by.. In our situation, we are pretty out-of-the-way, but in most corporate environments, that just isn't the case... People are crammed in cubes right next to each other, and they might not even be doing related jobs. Paul -Original Message- From: Bill Marquette [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 11:17 AM To: Paul Taylor Cc: support@pfsense.com Subject: Re: [pfSense Support] FreeRadius Package - slight security issue On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: Bill, Well, yes, I realize that base64encoding doesn't provide much in the way of security... But it's better than the data being completely in the clear... I have some encryption/decryption code around here somewhere that could probably be used, but of course the key would have to be in the code, where it could be seen, so even that doesn't provide great security... And I disagree. base64encoding provides zero security. Obscuring the data is no excuse for real protection. If we can protect it the right way (a one way hash), we will. Anything less than a one-way hash means it's reversible, passwords shouldn't be reversible in any way shape or form - I'd rather have glaring plaintext passwords reminding me to do something about them than something that at first glance passes muster. I'll personally back out any commit that does a half-ass job at it (not that I expect anyone to make such a commit). Don't hand out your config.xml and you'll be fine. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] FreeRadius Package - slight security issue
This whole argument is pointless. If this is really this big of a problem you have these choices: 1. Dont use freeradius and use a seperate server where you will be entering these configs in _PLAIN TEXT_ as well. 2. Dont use pfSense Scott On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: Bill, Sure, if someone gets a hold of the config.xml file, no amount of base64encoding will stop them from getting a password.. But, if someone is in the same room with you looking over your shoulder while you are looking through the config.xml file, there is no need to give them a clear view of usernames and passwords. In a corporate environment, people can walk by your office or cube any time... We have found ourselves in this very situation more than once... Having passwords in a file that we were working on in clear text, when someone unexpectedly dropped by.. In our situation, we are pretty out-of-the-way, but in most corporate environments, that just isn't the case... People are crammed in cubes right next to each other, and they might not even be doing related jobs. Paul -Original Message- From: Bill Marquette [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 11:17 AM To: Paul Taylor Cc: support@pfsense.com Subject: Re: [pfSense Support] FreeRadius Package - slight security issue On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: Bill, Well, yes, I realize that base64encoding doesn't provide much in the way of security... But it's better than the data being completely in the clear... I have some encryption/decryption code around here somewhere that could probably be used, but of course the key would have to be in the code, where it could be seen, so even that doesn't provide great security... And I disagree. base64encoding provides zero security. Obscuring the data is no excuse for real protection. If we can protect it the right way (a one way hash), we will. Anything less than a one-way hash means it's reversible, passwords shouldn't be reversible in any way shape or form - I'd rather have glaring plaintext passwords reminding me to do something about them than something that at first glance passes muster. I'll personally back out any commit that does a half-ass job at it (not that I expect anyone to make such a commit). Don't hand out your config.xml and you'll be fine. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] FreeRadius Package - slight security issue
Get a privacy screen for your monitor. Or get a mirror for the monitor so you can see the corporate spies. Or retrieve the config file via status.php which will sanitize the passwords. Masking the passwords w/ base64 doesn't solve the problem and we will _NOT_ implement a half assed solution. --Bill On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: Bill, Sure, if someone gets a hold of the config.xml file, no amount of base64encoding will stop them from getting a password.. But, if someone is in the same room with you looking over your shoulder while you are looking through the config.xml file, there is no need to give them a clear view of usernames and passwords. In a corporate environment, people can walk by your office or cube any time... We have found ourselves in this very situation more than once... Having passwords in a file that we were working on in clear text, when someone unexpectedly dropped by.. In our situation, we are pretty out-of-the-way, but in most corporate environments, that just isn't the case... People are crammed in cubes right next to each other, and they might not even be doing related jobs. Paul -Original Message- From: Bill Marquette [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 11:17 AM To: Paul Taylor Cc: support@pfsense.com Subject: Re: [pfSense Support] FreeRadius Package - slight security issue On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: Bill, Well, yes, I realize that base64encoding doesn't provide much in the way of security... But it's better than the data being completely in the clear... I have some encryption/decryption code around here somewhere that could probably be used, but of course the key would have to be in the code, where it could be seen, so even that doesn't provide great security... And I disagree. base64encoding provides zero security. Obscuring the data is no excuse for real protection. If we can protect it the right way (a one way hash), we will. Anything less than a one-way hash means it's reversible, passwords shouldn't be reversible in any way shape or form - I'd rather have glaring plaintext passwords reminding me to do something about them than something that at first glance passes muster. I'll personally back out any commit that does a half-ass job at it (not that I expect anyone to make such a commit). Don't hand out your config.xml and you'll be fine. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] FreeRadius Package - slight security issue
I didn't mean this to be any sort of argument, but you seem to be taking it as a personal attack... I was just pointing out something that I thought could be an issue. If you don't agree about this being an issue, that's fine.. Leave things the way they are, I'll cope.. I was just trying to provide feedback, which I thought you wanted... Paul -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 11:27 AM To: Paul Taylor Cc: Bill Marquette; support@pfsense.com Subject: Re: [pfSense Support] FreeRadius Package - slight security issue This whole argument is pointless. If this is really this big of a problem you have these choices: 1. Dont use freeradius and use a seperate server where you will be entering these configs in _PLAIN TEXT_ as well. 2. Dont use pfSense Scott On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: Bill, Sure, if someone gets a hold of the config.xml file, no amount of base64encoding will stop them from getting a password.. But, if someone is in the same room with you looking over your shoulder while you are looking through the config.xml file, there is no need to give them a clear view of usernames and passwords. In a corporate environment, people can walk by your office or cube any time... We have found ourselves in this very situation more than once... Having passwords in a file that we were working on in clear text, when someone unexpectedly dropped by.. In our situation, we are pretty out-of-the-way, but in most corporate environments, that just isn't the case... People are crammed in cubes right next to each other, and they might not even be doing related jobs. Paul -Original Message- From: Bill Marquette [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 11:17 AM To: Paul Taylor Cc: support@pfsense.com Subject: Re: [pfSense Support] FreeRadius Package - slight security issue On 8/5/05, Paul Taylor [EMAIL PROTECTED] wrote: Bill, Well, yes, I realize that base64encoding doesn't provide much in the way of security... But it's better than the data being completely in the clear... I have some encryption/decryption code around here somewhere that could probably be used, but of course the key would have to be in the code, where it could be seen, so even that doesn't provide great security... And I disagree. base64encoding provides zero security. Obscuring the data is no excuse for real protection. If we can protect it the right way (a one way hash), we will. Anything less than a one-way hash means it's reversible, passwords shouldn't be reversible in any way shape or form - I'd rather have glaring plaintext passwords reminding me to do something about them than something that at first glance passes muster. I'll personally back out any commit that does a half-ass job at it (not that I expect anyone to make such a commit). Don't hand out your config.xml and you'll be fine. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Hackathon time!
Sorry for cross posting but I wanted to make everyone aware that the lists will be going offline for the weekend as the developers hackathon is starting today. Please hold all bug reports, etc until after monday of next week. Would also like to thank everyone that has donated to the hackathon. Because of your kindness we should be eating and drinking all weekend. Thanks again! Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
