Re: [pfSense-discussion] Re: Newbie Q: security of php on perimeter firewall
Id say this is partially right, any misconfigured firewall can be insecure and allow the php interface to be available, there is currently no way to turn off/on the web process for administration either. and currently you cant bind the process to listen on a specific interface. So a default add rule allowing http/https in from wan might expose you. pfSense is currently a default stance from what I can see. but it is functional. Youd imagine by default it should be locked down a bit more. its still a project that deserves merit, and its also why i build my own version. Ive additional tweaks, not found in pfSense, though it is a solid base to start from. Somethings in their simpler form need to be tightened up, its alpha code so theres noway to tell what the plans are for the future. make some suggestions to the list, see what happens. Im sure there are a few tweaks that can be applied to lock down the system a bit better. the web server is thttpd, but i see lighttpd also in the cvs tree so they might be migrating to it. On Mon, 2005-11-28 at 13:30 +0500, sai wrote: While PHP does have some problems, it is mostly PHP software that is poorly written and so vulnerable. The PHP interface is not available to everyone (only admins) so even if PHP is vulnerable you have to get to it first. The webserver is not Apache but something much smaller...forget the name. If you didnt have an easy to use web interface, but had a cli, the security problems associated with mistakes made in configuration etc would be quite major. sai On 11/27/05, Sanjay Arora [EMAIL PROTECTED] wrote: Hi all Just joined the list. Am mostly using IPcop other Linux flavours for perimeter firewalling. Needed ISP WAN-link balancing failover, hence my search for a new option. Also have started experimenting with freebsd, so choice was limited to either freebsd or linux. Have downloaded the iso...will install on a Pentium III 550 MHz and revert with feedback within the week. My thought is that any perimeter firewall should be a minimal design. Would not having php on pfsence make it vulnerable to php vulnerabilities, as well as those of apache. Haven't exactly tried it, so really haven't the right to comment on it but would the community please comment on this and other similar issues inherent in this architecture design? With best regards best wishes for the project. Sanjay.
[pfSense-discussion] pfsense update file damaged??
the latest full update i can successfully download from pfsense.com/old is .90a all version above that i download always gives error something. i cant open the files after it's download. i use getright to download. coz, my connection is quite ugly here. can never download anything 50meg without download manager to do resuming... is it problem with me only? or is the file really is damaged? tnxrgds, dny --- http://bloglines.com/public/bacaan --- harini udah baca blom? ... but that which cometh out of the mouth, this defileth a man. Mat 15:11
Re: [pfSense-discussion] Re: Newbie Q: security of php on perimeter firewall
On 11/28/05, Lists [EMAIL PROTECTED] wrote: system a bit better. the web server is thttpd, but i see lighttpd also in the cvs tree so they might be migrating to it. Actually it's mini_httpd (although we do have thttpd in the tree - not sure why). And yes, we're moving to lighttpd for FastCGI support which should (and does) speed up the webGUI interface. --Bill
Re: [pfSense-discussion] pfsense update file damaged??
Make sure you are not accidently choosing an ISO image from the firmware update page. I did that by mistake once and it came back telling me the image was corrupt. I then chose the proper image and all was well. Scott Ullrich wrote: No the images are not corrupted. Where do you get the error, etc. On 11/28/05, dny [EMAIL PROTECTED] wrote: the latest full update i can successfully download from pfsense.com/old is .90a all version above that i download always gives error something. i cant open the files after it's download. i use getright to download. coz, my connection is quite ugly here. can never download anything 50meg without download manager to do resuming... is it problem with me only? or is the file really is damaged? tnxrgds, dny --- http://bloglines.com/public/bacaan --- harini udah baca blom? ... but that which cometh out of the mouth, this defileth a man. Mat 15:11
Re: [pfSense-discussion] Re: Newbie Q: security of php on perimeter firewall
There are still a few other small ones. In paticular with the status queues screen + fast cgi. When we kill pfctl somehow its signal is being passed up and killing off the fast-cgi handler. Woops. On 11/28/05, Bill Marquette [EMAIL PROTECTED] wrote: On 11/28/05, Lists [EMAIL PROTECTED] wrote: well hell maybe i should do devel work for pfsense cause ive already migrated my build to lighttpd :) then when browsing the cvs trees noticed it was in there We had some problems with lighty when we first imported it - firmware upgrades didn't work on embedded due to a bug in their handling of large POSTs. That's been fixed in a recent release, so we're moving back (that was the only bug that I know of, but it was kinda big ;-P) --Bill
RE: [pfSense-discussion] Re: Newbie Q: security of php on perimeter firewall
Title: Re: [pfSense-discussion] Re: Newbie Q: security of php on perimeter firewall Is there any way we can reboot the mail server now? It is running at 100% cpu but they are services that should normally be runningI think we need to shake it out. Paul From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:27 PM To: discussion@pfsense.com Subject: Re: [pfSense-discussion] Re: Newbie Q: security of php on perimeter firewall There are still a few other small ones. In paticular with the status queues screen + fast cgi. When we kill pfctl somehow its signal is being passed up and killing off the fast-cgi handler. Woops. On 11/28/05, Bill Marquette [EMAIL PROTECTED] wrote: On 11/28/05, Lists [EMAIL PROTECTED] wrote: well hell maybe i should do devel work for pfsense cause ive already migrated my build to lighttpd :) then when browsing the cvs trees noticed it was in there We had some problems with lighty when we first imported it - firmware upgrades didn't work on embedded due to a bug in their handling of large POSTs. That's been fixed in a recent release, so we're moving back (that was the only bug that I know of, but it was kinda big ;-P) --Bill avast! Antivirus: Inbound message clean. Virus Database (VPS): 0547-5, 11/26/2005Tested on: 11/28/2005 1:27:38 PMavast! - copyright (c) 1988-2005 ALWIL Software. avast! Antivirus: Outbound message clean. Virus Database (VPS): 0547-5, 11/26/2005Tested on: 11/28/2005 1:52:52 PMavast! - copyright (c) 1988-2005 ALWIL Software.
Re: [pfSense-discussion] Newbie Q: security of php on perimeter firewall
Sanjay Arora wrote: Hi all Just joined the list. Am mostly using IPcop other Linux flavours for perimeter firewalling. Needed ISP WAN-link balancing failover, hence my search for a new option. Also have started experimenting with freebsd, so choice was limited to either freebsd or linux. Have downloaded the iso...will install on a Pentium III 550 MHz and revert with feedback within the week. My thought is that any perimeter firewall should be a minimal design. Would not having php on pfsence make it vulnerable to php vulnerabilities, as well as those of apache. Haven't exactly tried it, so really haven't the right to comment on it but would the community please comment on this and other similar issues inherent in this architecture design? This part of the architecture has changed slightly from m0n0wall I believe, so if I go astray here, somebody kick me back into shape. ;) Basically, you can't get to PHP without first being authenticated. At this point, if you're authenticated, you have root access to the box. So who cares about any PHP vulnerabilities when you already have root access? And, as others said, most PHP problems are from sloppy PHP code, not issues within PHP itself. Besides, the ability to even attempt to login is restricted to LAN only by default, and if you're in a situation where you have to worry about what your internal users can attempt on the firewall, you can and should restrict that further. It's not like PHP is doing the actual firewalling.
Re: [pfSense-discussion] Newbie Q: security of php on perimeter firewall
Chris Buechler wrote: Sanjay Arora wrote: Hi all Just joined the list. Am mostly using IPcop other Linux flavours for perimeter firewalling. Needed ISP WAN-link balancing failover, hence my search for a new option. Also have started experimenting with freebsd, so choice was limited to either freebsd or linux. Have downloaded the iso...will install on a Pentium III 550 MHz and revert with feedback within the week. My thought is that any perimeter firewall should be a minimal design. Would not having php on pfsence make it vulnerable to php vulnerabilities, as well as those of apache. Haven't exactly tried it, so really haven't the right to comment on it but would the community please comment on this and other similar issues inherent in this architecture design? This part of the architecture has changed slightly from m0n0wall I believe, so if I go astray here, somebody kick me back into shape. ;) Basically, you can't get to PHP without first being authenticated. At this point, if you're authenticated, you have root access to the box. So who cares about any PHP vulnerabilities when you already have root access? And, as others said, most PHP problems are from sloppy PHP code, not issues within PHP itself. Besides, the ability to even attempt to login is restricted to LAN only by default, and if you're in a situation where you have to worry about what your internal users can attempt on the firewall, you can and should restrict that further. It's not like PHP is doing the actual firewalling. As an addition to this: If somebody doesn't like PHP on his firewall, he can just go back, install OpenBSD 3.8 and use vi to edit the rulesets and all the other configuration-options (VLANs, NAT, VPN etc. pp.). Until there's a multi-user, multi-customer capable interface that allows several virtual firewalls to be administered by different clients/customers, I'm not going to worry about PHP-security one single second. Firewalls, which are managed by a fat-client GUI also had their share of vulnerabilties precisely because the communication between the GUI and the firewall was badly designed or implemented. cheers, Rainer
Re: [pfSense-discussion] Unfork m0n0wall
Bennett wrote: This answers one of my biggest questions about the fork. I've been fixated on the package system (though my previous mention of it was brief), thinking it was a solution for both projects. I had envisioned moving everything that isn't a core feature into an optional module. Instead of m0n0wall is too resource-intensive to run on microsystem X, you get m0n0wall will run on microsystem X with features A, B, and C, but not D. I wasn't aware that m0n0wall's file system makes this whole idea infeasible. Perhaps I should troll the m0n0wall list... :) go for it. You'd still get me replying to your messages, with the same stuff mostly. :) But it'll never change to be a full blown hard drive install, and that's precisely where the split between the two is justified. I personally think the embedded pfsense image should be dropped when/if m0n0wall gets on FreeBSD 6. At that point, depending on where m0n0wall 1.3 ends up, it may very well be a wasted effort to put out an embedded image where that's m0n0wall's territory and where it excels. Still, I think moving EVERY non-core feature (e.g., captive portal, load balancing, CARP, even VPN) into an optional module is the way to go for pfSense. Then, only the features a user needs are installed. Umm, no. Virtually all of that is in-kernel stuff, so the only thing (most of it at least) you could add on would be the GUI pages. No sense in separating that. I also got the impression from the pfSense FAQs (yes, I did do some research before posting) that there was a bit more code sharing than there actually is, so I thought the projects were not quite as separate as they are. I understand now that that is not the case, and hence my concerns about patchy code were unjustified. Furthermore, Colin said it's a one-way street (which I assume goes from pfSense to m0n0?), No, the other way around actually. I don't think a single line of pfsense code has made it into m0n0wall at this point. That'll likely happen more once work on 1.3 gets going. so there's no duplicated work since m0n0wall can incorporate, say, the certificate manager that pfSense has already developed. well, not really for many of the things at this point. the back end of the certificate manager is, iirc, almost as big as the entire m0n0wall image. At any rate, it's far too large for the way the file system currently works. that's true of many other things as well that I'm not recalling ATM..
Re: [pfSense-discussion] Newbie Q: security of php on perimeter firewall
On 11/28/05, Chris Buechler [EMAIL PROTECTED] wrote: This part of the architecture has changed slightly from m0n0wall I believe, so if I go astray here, somebody kick me back into shape. ;) *kick* Basically, you can't get to PHP without first being authenticated. At this point, if you're authenticated, you have root access to the box. These days, the auth is completely handled in PHP. So it's certainly possible. --Bill
Re: [pfSense-discussion] Newbie Q: security of php on perimeter firewall
On 11/28/05, Bill Marquette [EMAIL PROTECTED] wrote: On 11/28/05, Chris Buechler [EMAIL PROTECTED] wrote: This part of the architecture has changed slightly from m0n0wall I believe, so if I go astray here, somebody kick me back into shape. ;) *kick* Basically, you can't get to PHP without first being authenticated. At this point, if you're authenticated, you have root access to the box. These days, the auth is completely handled in PHP. So it's certainly possible. Yes, the moral of the story is to lock down the WebGUI to only trusted IP's.
Re: [pfSense-discussion] Newbie Q: security of php on perimeter firewall
On Mon, 2005-11-28 at 15:43 -0500, Scott Ullrich wrote: On 11/28/05, Bill Marquette [EMAIL PROTECTED] wrote: On 11/28/05, Chris Buechler [EMAIL PROTECTED] wrote: This part of the architecture has changed slightly from m0n0wall I believe, so if I go astray here, somebody kick me back into shape. ;) *kick* Basically, you can't get to PHP without first being authenticated. At this point, if you're authenticated, you have root access to the box. These days, the auth is completely handled in PHP. So it's certainly possible. Yes, the moral of the story is to lock down the WebGUI to only trusted IP's. Me?..I'm going to be paranoid and not allow access to WebGUI from the WAN side at all. Anyways, the port 80 is going to be redirected to DMZ, so its the only place anyone can get to playand hell ...thats where php apps...poorly coded or not...will be ;-(( However, I would like to make one request to the project design...users be given easily configured modular way to remove (i.e. not compile in) services they do not want on the pfsense box, i.e. the ones that are not basic to the basic firewall function its GUI e.g. httpd, php cgi. Will pick up the thread again after evaluating myself. With best regards. Sanjay.
Re: [pfSense-discussion] Newbie Q: security of php on perimeter firewall
At 07:32 PM 11/28/2005, you wrote: Will pick up the thread again after evaluating myself. Hmmm... Psychiatrict problems? :)
Re: [pfSense-discussion] Newbie Q: security of php on perimeter firewall
On 11/28/05, Sanjay Arora [EMAIL PROTECTED] wrote: However, I would like to make one request to the project design...users be given easily configured modular way to remove (i.e. not compile in) services they do not want on the pfsense box, i.e. the ones that are not basic to the basic firewall function its GUI e.g. httpd, php cgi. Please see the thread titled Unfork m0n0wall. In paticular, Chris's response to removing non-base items. Scott
Re: [pfSense-discussion] Newbie Q: security of php on perimeter firewall
On 11/28/05, Sanjay Arora [EMAIL PROTECTED] wrote: However, I would like to make one request to the project design...users be given easily configured modular way to remove (i.e. not compile in) services they do not want on the pfsense box, i.e. the ones that are not basic to the basic firewall function its GUI e.g. httpd, php cgi. Request evaluated. W/out the webGUI, it wouldn't be pfSense, it'd be FreeBSD. So uhhh, just install FreeBSD and modify pf.conf by hand ;) You can then rewrite pfSense in shell and feel free not to include a webGUI or use an XML config file (face it, it's not easy to parse that in shell!). Seriously, the whole point of pfSense is the GUI, if you don't want it, and I mean this in the nicest way possible, you really really don't want pfSense. --Bill
Re: [pfSense-discussion] Newbie Q: security of php on perimeter firewall
On Mon, 2005-11-28 at 20:13 -0600, Bill Marquette wrote: OK, apparently I can't read English...disregard (unless you choose not to of course). Upon the 4th read of this, I deciphered the meaning, which wasn't all that difficult to figure out if I'd read it slower the first three times. Erg. *putting on the dunce cap* --Bill Sorry Bill Can't licence my proprietary cap to you ;-) Best regards. Sanjay.
Re: [pfSense-discussion] Unfork m0n0wall
Chris Buechler wrote: Bennett wrote: Perhaps I should troll the m0n0wall list... :) go for it. You'd still get me replying to your messages, with the same stuff mostly. :) Chris won't be the only one, either. :-) But it'll never change to be a full blown hard drive install, and that's precisely where the split between the two is justified. I personally think the embedded pfsense image should be dropped when/if m0n0wall gets on FreeBSD 6. At that point, depending on where m0n0wall 1.3 ends up, it may very well be a wasted effort to put out an embedded image where that's m0n0wall's territory and where it excels. depends on how much of the various packages (802.1x/WPA, plethora of wireless drivers, carp, altq, serial console, ...) are picked up in m0n0. Each of these will serve to make m0n0 a larger, more complicated system, and Manuel will have to cut the baby somewhere. So, I'd rather the embedded image (or at least the option to cut an embedded image) be kept. Keeping it means testing it, too, so its likely that the image itself should be kept. jim
