Re: [pfSense-discussion] FTP Helper on WAN - bug?
Am Montag, den 02.10.2006, 19:10 -0400 schrieb Scott Ullrich: > You want to use: > > o afterfilterchangeshellcmd > > http://pfsense.blogspot.com/2005/06/new-xml-system-tag-introduced.html No, since system_start_ftp_helpers() is launched _after_ filter_configure_sync in /etc/rc.bootup. Scott, beside that it's really ugly hacking around a problem in principle. Shouldn't we discuss how to solve it problem-oriented instead of hacking around with "*shellcmd"? Where, if not here, is the best place to talk about it? I invite all devs to make proposals to the everlasting FTP problem. What do we need? 1) FTP-Server on the inside: is it behind NAT? no || yes| || use pftpx, see 2) use ftpsesame 2) FTP-Server on the outside: is your public IP on WAN interface? --- no | | yeswhat public reachable IP to use as source IP? | | pftpx -c -g ifaceIPpftpx -c -g -p pubIP ifaceIP 3) A way to mix these possibilities: what to do, if someone has an FTP-Server in DMZ with public reachable IPs and also one FTP-Server internally with a private IP? BR, PIT --- copyleft(c) by | _-_ any new sendmail hole I have to fix Peter Allgeyer | 0(o_o)0 before going on vacations? -- Seen on #Linux ---oOO--(_)--OOo---
Re: [pfSense-discussion] FTP Helper on WAN - bug?
On 10/3/06, Peter Allgeyer <[EMAIL PROTECTED]> wrote: Am Montag, den 02.10.2006, 19:10 -0400 schrieb Scott Ullrich: > You want to use: > > o afterfilterchangeshellcmd > > http://pfsense.blogspot.com/2005/06/new-xml-system-tag-introduced.html No, since system_start_ftp_helpers() is launched _after_ filter_configure_sync in /etc/rc.bootup. Scott, beside that it's really ugly hacking around a problem in principle. Shouldn't we discuss how to solve it problem-oriented instead of hacking around with "*shellcmd"? Where, if not here, is the best place to talk about it? I invite all devs to make proposals to the everlasting FTP problem. I am telling you how to solve your problem now, not long term. I agree that the FTP system is a mess. What do we need? 1) FTP-Server on the inside: is it behind NAT? no || yes| || use pftpx, see 2) use ftpsesame 2) FTP-Server on the outside: is your public IP on WAN interface? --- no | | yeswhat public reachable IP to use as source IP? | | pftpx -c -g ifaceIPpftpx -c -g -p pubIP ifaceIP 3) A way to mix these possibilities: what to do, if someone has an FTP-Server in DMZ with public reachable IPs and also one FTP-Server internally with a private IP? Sounds good. If you want to submit patches, feel free. I am focused on getting on 1.0 out the door then I plan on taking a vacation for a bit but will be happy to review a patch. Scott
Re: [pfSense-discussion] FTP Helper on WAN - bug?
Am Dienstag, den 03.10.2006, 09:09 -0400 schrieb Scott Ullrich: > I am telling you how to solve your problem now, not long term. I > agree that the FTP system is a mess. Ok, fine, how? At the moment I start the ftpsesame per hand after booting up the firewall (which gladly isn't so often). > Sounds good. If you want to submit patches, feel free. I am focused > on getting on 1.0 out the door then I plan on taking a vacation for a > bit but will be happy to review a patch. So I'll wish you happy holidays. BTW: It was a question to all devs here. Anyone else? I'm especially looking for a solution to point 3). Maybe someone might know a good way to implement this. BR, PIT --- copyleft(c) by | People disagree with me. I just ignore them. Peter Allgeyer | _-_ -- Linus Torvalds, regarding the use of C++ | 0(o_o)0 for the Linux kernel ---oOO--(_)--OOo---
Re: [pfSense-discussion] FTP Helper on WAN - bug?
On 10/3/06, Peter Allgeyer <[EMAIL PROTECTED]> wrote: Am Dienstag, den 03.10.2006, 09:09 -0400 schrieb Scott Ullrich: > I am telling you how to solve your problem now, not long term. I > agree that the FTP system is a mess. Ok, fine, how? At the moment I start the ftpsesame per hand after booting up the firewall (which gladly isn't so often). With the afterfilterchangeshellcmd command. It is run every time a filter change occurs as the last item. So you can override *ANYTHING* the system does including launching your own scripts or launching a custom ftpsesame process. > Sounds good. If you want to submit patches, feel free. I am focused > on getting on 1.0 out the door then I plan on taking a vacation for a > bit but will be happy to review a patch. So I'll wish you happy holidays. BTW: It was a question to all devs here. Anyone else? I'm especially looking for a solution to point 3). Maybe someone might know a good way to implement this. I cannot think of any way to cleanly solve this problem. In addition the entire FTP situation has me a little burned out at this point. I just want to get 1.0 out the door, relax a bit then revisit the problem for a future version. However, don't let me distract you from trying. If you can figure out a solution I am all ears. Scott
Re: [pfSense-discussion] FTP Helper on WAN - bug?
On 10/3/06, Peter Allgeyer <[EMAIL PROTECTED]> wrote: Am Dienstag, den 03.10.2006, 09:09 -0400 schrieb Scott Ullrich: > I am telling you how to solve your problem now, not long term. I > agree that the FTP system is a mess. Ok, fine, how? At the moment I start the ftpsesame per hand after booting up the firewall (which gladly isn't so often). > Sounds good. If you want to submit patches, feel free. I am focused > on getting on 1.0 out the door then I plan on taking a vacation for a > bit but will be happy to review a patch. So I'll wish you happy holidays. BTW: It was a question to all devs here. Anyone else? I'm especially looking for a solution to point 3). Maybe someone might know a good way to implement this. FTP is a broken and insecure protocol. If I had my way, you wouldn't see any FTP helpers in pfSense. If you want it working a certain way, make it work, send in patches, rejoice when they get commited. It works "as is" for 99% of our user base, the few users who need more are certainly technical enough to come up with a solution that works (and doesn't break the other 99% of the users). --Bill
Re: [pfSense-discussion] FTP Helper on WAN - bug?
Hi Scott, hi Bill! Am Dienstag, den 03.10.2006, 10:05 -0400 schrieb Scott Ullrich: > With the afterfilterchangeshellcmd command. It is run every time a > filter change occurs as the last item. So you can override *ANYTHING* > the system does including launching your own scripts or launching a > custom ftpsesame process. No, as I told you already, the system_start_ftp_helpers() is launched _after_ filter_configure_sync in /etc/rc.bootup. And ftpsesame is killed by "killall" in system_start_ftp_helpers() after been started in filter_configure_sync :-( So, you can see, that the afterfilterchangeshellcmd command isn't any solution for that problem. When I'm posting lines of source code, you can believe me that I have bravely taken a look at it ;-) OK, I'll write my own code, since I'm experienced enough. I wanted a clean solution for all users, but that's apparently not the goal here. People will further cry at the forum that ftp isn't working. I do know the reason why and now you know too. > I cannot think of any way to cleanly solve this problem. In addition > the entire FTP situation has me a little burned out at this point. I > just want to get 1.0 out the door, relax a bit then revisit the > problem for a future version. Yes FTP is a shame. But it's used in many places and the solution isn't to tell people not to use it (though I'm of the same opinion as Bill is, don't use "bad" protocols over a FW). And think of the other bad designed - i case of firewalls - protocols like SIP, PPTP, many meeting/colaboration protocols ... BTW: I do love the way the netfilter connection tracking modules in linux are solving that problem and don't know any reason why that code isn't adapted by the pf devs. There must be any reason for not using such an API. I'll have to search why. Maybe you can give me a link. > However, don't let me distract you from trying. If you can figure out > a solution I am all ears. I'll try to find one that will fit 99.999% of all users. Point 3) isn't solved and I do not know how, but give me some time. BR, PIT --- copyleft(c) by | This code passes Torvalds test grades 0, 1 and Peter Allgeyer | _-_ 2 (it looks ok, it compiles and it booted). | 0(o_o)0 -- Alan Cox ---oOO--(_)--OOo---
Re: [pfSense-discussion] FTP Helper on WAN - bug?
On 10/3/06, Peter Allgeyer <[EMAIL PROTECTED]> wrote: Hi Scott, hi Bill! Am Dienstag, den 03.10.2006, 10:05 -0400 schrieb Scott Ullrich: > With the afterfilterchangeshellcmd command. It is run every time a > filter change occurs as the last item. So you can override *ANYTHING* > the system does including launching your own scripts or launching a > custom ftpsesame process. No, as I told you already, the system_start_ftp_helpers() is launched _after_ filter_configure_sync in /etc/rc.bootup. And ftpsesame is killed by "killall" in system_start_ftp_helpers() after been started in filter_configure_sync :-( So, you can see, that the afterfilterchangeshellcmd command isn't any solution for that problem. When I'm posting lines of source code, you can believe me that I have bravely taken a look at it ;-) Yes, but the filter reloads yet again on final bootup, and it is the final thing to run, and you could work your magic at this point. OK, I'll write my own code, since I'm experienced enough. I wanted a clean solution for all users, but that's apparently not the goal here. People will further cry at the forum that ftp isn't working. I do know the reason why and now you know too. The goal here is to satisfy 99% of the users, which we have done. If someone really wants a FTP server on their dmz, then they can open up the port range that is required by the FTP server. > I cannot think of any way to cleanly solve this problem. In addition > the entire FTP situation has me a little burned out at this point. I > just want to get 1.0 out the door, relax a bit then revisit the > problem for a future version. Yes FTP is a shame. But it's used in many places and the solution isn't to tell people not to use it (though I'm of the same opinion as Bill is, don't use "bad" protocols over a FW). And think of the other bad designed - i case of firewalls - protocols like SIP, PPTP, many meeting/colaboration protocols ... BTW: I do love the way the netfilter connection tracking modules in linux are solving that problem and don't know any reason why that code isn't adapted by the pf devs. There must be any reason for not using such an API. I'll have to search why. Maybe you can give me a link. Maybe because its linux? FreeBSD != Linux, but I am sure you know this. > However, don't let me distract you from trying. If you can figure out > a solution I am all ears. I'll try to find one that will fit 99.999% of all users. Point 3) isn't solved and I do not know how, but give me some time. See above, DMZ's should simply punch the port range open on the firewall. Scott
Re: [pfSense-discussion] FTP Helper on WAN - bug?
On 10/3/06, Peter Allgeyer <[EMAIL PROTECTED]> wrote:
No, as I told you already, the system_start_ftp_helpers() is launched
_after_ filter_configure_sync in /etc/rc.bootup. And ftpsesame is killed
by "killall" in system_start_ftp_helpers() after been started in
filter_configure_sync :-( So, you can see, that the
afterfilterchangeshellcmd command isn't any solution for that problem.
When I'm posting lines of source code, you can believe me that I have
bravely taken a look at it ;-)
I wonder if the package system is called far enough into the boot
process to shim this in after start_ftp_helpers is called. You might
be able to create a start script that calls /etc/rc.filter_configure.
Looks like this is what you want in /etc/rc.bootup
mwexec("sh /usr/local/etc/rc.d/{$filename} start >>/tmp/bootup_messages 2>&1");
it's well past the ftp_helpers.
OK, I'll write my own code, since I'm experienced enough. I wanted a
clean solution for all users, but that's apparently not the goal here.
People will further cry at the forum that ftp isn't working. I do know
the reason why and now you know too.
Yeah, 1.0 is too close, we can't afford to break FTP for this somewhat
edge case. Hopefully we can come up with a better long term solution.
BTW: I do love the way the netfilter connection tracking modules in
linux are solving that problem and don't know any reason why that code
isn't adapted by the pf devs. There must be any reason for not using
such an API. I'll have to search why. Maybe you can give me a link.
There's plenty of discussions on this, I don't have any links handy,
sorry. But it goes along the lines of layer7 protocol analysis in
kernel is a bad idea - protocol bugs directly result in ring0
compromise (bad!). Using divert() style sockets is moderately better,
but results in dropping the analysis and throughput to userland which
can be slow. ftpsesame is a better compromise in that all it really
needs to do is run a bpf listener and add/remove rules as needed.
Some protocols (pptp, ipsec), etc, can only be NAT'd in kernel due to
the way the protocols work, but in those cases, it's not a rule issue,
it's a NAT issue that can't be solved outside of the kernel. IPFilter
has various "proxy" modules to handle some of this. At the end of the
day, the linux folks are more open to polluting their kernel with junk
than the OpenBSD folks.
--Bill
[pfSense-discussion] Getting involved
Been running pfSense for a few months. Good stuff. But, the box I have it on where it counts (80ish users, old PIII 550 MHz box) the on board NIC's not supporting ALTQ. At home, the old box I have it running on, it's on board NIC starts dropping packets when I turn on traffic shaping. So, I figured I needed some new NICs. Bought a case of D-Link DGE-530T cards. (Seem good. And cheap) # pciconf -lv [EMAIL PROTECTED]:9:0: class=0x02 card=0x4b011186 chip=0x4b011186 rev=0x11 hdr=0x00 vendor = 'D-Link System Inc' class= network subclass = ethernet This is the so-called revision-B1 chip, it is newer than the A1 that is included to the 6.1-RELEASE. Following: http://www.freebsd.org/cgi/query-pr.cgi?pr=99903 And the guidance from freebsd-net mailing list. They're schooling me on how to patch my driver source. I've got the basic idea. I've done simple patches before. Not exactly sure if I'll need to just rebuild the module or if I'll need to redo the whole kernel. I guess I need to do that on a separate box and then, I dunno, install either the driver module or a whole new kernel on the router? That'll be a first for me. I downloaded the pfsense-development version last night as well. Looking it over in between solving whatever pops up at work. Got some questions: Where's the src files? How does the pfsense kernel differ from the generic fbsd kernel (or the modules)? How have you modified pf to make it work here? Why's there no sysinstall ? Basically, what should I know about pfsense to start (trying) developing in it? I've done a little coding in a variety of languages. Hacks mostly. Tools to make whatever I'm doing easier (or possible). Bout 1/4 way through McKusick's "Design and Implementation" Bit by bit, it's starting to make a little more sense each day. I want to get more involved. Not just hacks. I want to learn to contribute to serious collaborative open-source projects. Thought I'd drop a line in here fishing for direction.
Re: [pfSense-discussion] FTP Helper on WAN - bug?
Am Dienstag, den 03.10.2006, 12:15 -0500 schrieb Bill Marquette:
> I wonder if the package system is called far enough into the boot
> process to shim this in after start_ftp_helpers is called. You might
> be able to create a start script that calls /etc/rc.filter_configure.
> Looks like this is what you want in /etc/rc.bootup
> mwexec("sh /usr/local/etc/rc.d/{$filename} start >>/tmp/bootup_messages
> 2>&1");
> it's well past the ftp_helpers.
No problem for me to adapt some bootup scripts. I've got more than 13
years experience in several *NIX systems. I simply don't want to. I'm
choosing a system like pfsense because it's easy to set up, backed up
and so on. Everything I'm adding manually breaks that. If I find sth.
that not ok, I'll take a look on it and I'm trying to solve it, giving
some of my results back to the community.
> There's plenty of discussions on this, I don't have any links handy,
> sorry. But it goes along the lines of layer7 protocol analysis in
> kernel is a bad idea - protocol bugs directly result in ring0
> compromise (bad!). Using divert() style sockets is moderately better,
> but results in dropping the analysis and throughput to userland which
> can be slow. ftpsesame is a better compromise in that all it really
> needs to do is run a bpf listener and add/remove rules as needed.
> Some protocols (pptp, ipsec), etc, can only be NAT'd in kernel due to
> the way the protocols work, but in those cases, it's not a rule issue,
> it's a NAT issue that can't be solved outside of the kernel. IPFilter
> has various "proxy" modules to handle some of this. At the end of the
> day, the linux folks are more open to polluting their kernel with junk
> than the OpenBSD folks.
OK, that makes sense to me. The old problem userland vs. kernel space
coding. I've brought down the linux kernel several times when I wrote
some vlan code for my diploma thesis some years ago (was linux
1.5.x ;-)). I do know what one wrong pointer in kernel code does mean,
believe me.
BR and thanks for explaining,
PIT
---
copyleft(c) by | _-_ Win95 is not a virus; a virus does something.
Peter Allgeyer | 0(o_o)0 -- unknown source
---oOO--(_)--OOo---
Re: [pfSense-discussion] FTP Helper on WAN - bug?
On 10/3/06, Peter Allgeyer <[EMAIL PROTECTED]> wrote:
Am Dienstag, den 03.10.2006, 12:15 -0500 schrieb Bill Marquette:
> I wonder if the package system is called far enough into the boot
> process to shim this in after start_ftp_helpers is called. You might
> be able to create a start script that calls /etc/rc.filter_configure.
> Looks like this is what you want in /etc/rc.bootup
> mwexec("sh /usr/local/etc/rc.d/{$filename} start >>/tmp/bootup_messages
2>&1");
> it's well past the ftp_helpers.
No problem for me to adapt some bootup scripts. I've got more than 13
years experience in several *NIX systems. I simply don't want to. I'm
choosing a system like pfsense because it's easy to set up, backed up
and so on. Everything I'm adding manually breaks that. If I find sth.
that not ok, I'll take a look on it and I'm trying to solve it, giving
some of my results back to the community.
Using the shellcmd* items will be backed up since the changes are made
to config.xml.
Scott
Re: [pfSense-discussion] FTP Helper on WAN - bug?
Am Dienstag, den 03.10.2006, 13:03 -0400 schrieb Scott Ullrich: > Yes, but the filter reloads yet again on final bootup, and it is the > final thing to run, and you could work your magic at this point. Scott, forget it. When I'm telling you that it doesn't work when it's definitly not working that way. > The goal here is to satisfy 99% of the users, which we have done. If > someone really wants a FTP server on their dmz, then they can open up > the port range that is required by the FTP server. No. Before I'm opening such a port range, I'll forbit ftp at all. > Maybe because its linux? FreeBSD != Linux, but I am sure you know this. Thanks for the hint. Bill's description was what I was looking for. > See above, DMZ's should simply punch the port range open on the firewall. And I'm telling you NO. If there's one better solution we should try that. Nethertheless, let's keep an eye on this for 1.1. BR, PIT --- copyleft(c) by | "Even more amazing was the realization that Peter Allgeyer | _-_ God has Internet access. I wonder if He has | 0(o_o)0 a full newsfeed?" (By Matt Welsh) ---oOO--(_)--OOo---
Re: [pfSense-discussion] IDS yet?
On 9/20/06, Sam Newnam <[EMAIL PROTECTED]> wrote: I've read a couple places but couldn't find a clear answer to whether SQUID or another intrusion diction system had been integrated yet. SQUID is a cache, not a NIDS. -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: [pfSense-discussion] IDS yet?
On 9/20/06, Scott Ullrich <[EMAIL PROTECTED]> wrote: There is no IDS package with no intention on creating one. We are waiting for you all to step up to the plate. I somewhat lied about this. For some reason after seeing your post something clicked in my head and I spent a good 35 hours on a IDS package. Upgrade to 1.0-RC3a and you will now find Snort in our packages area. Scott PS: it appears that I also have a sponsor for the package. Will post more information once I secure the funds.
RE: [pfSense-discussion] IDS yet?
I meant SNORT. Sorry - my mistake - thanks. Sam Newnam SystemSam Technologies, LLC www.systemsam.com -Original Message- From: Travis H. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 4:45 PM To: discussion@pfsense.com Subject: Re: [pfSense-discussion] IDS yet? On 9/20/06, Sam Newnam <[EMAIL PROTECTED]> wrote: > I've read a couple places but couldn't find a clear answer to whether SQUID > or another intrusion diction system had been integrated yet. SQUID is a cache, not a NIDS. -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: [pfSense-discussion] IDS yet?
Sorry do you plan to use snort as IDS or as IPS? I think that the former should be easier to implement as a package, but the latter is the direction to follow, in a long term project. Few days ago I saw StillSecure Strataguard, and I found that their interface/approach to IPS is very good... If you like to go in that direction, I'll be pleased to help..at least for what I can do...On 10/3/06, Scott Ullrich < [EMAIL PROTECTED]> wrote:On 9/20/06, Scott Ullrich < [EMAIL PROTECTED]> wrote:> There is no IDS package with no intention on creating one. We are> waiting for you all to step up to the plate.I somewhat lied about this. For some reason after seeing your post something clicked in my head and I spent a good 35 hours on a IDSpackage.Upgrade to 1.0-RC3a and you will now find Snort in our packages area.ScottPS: it appears that I also have a sponsor for the package. Will post more information once I secure the funds.
