PF: can't get ftp to work

dennylin93 said:
It is much more convenient this way, but it has a higher risk. Occasionally, some programs will have vulnerabilities, and when they do, someone might take advantage of them and send some nasty stuff.
Click to expand...

Yes, but as we all know, once we're not running win* OSes, the possibility to install trojans and/or viruses/malware on our boxes is extremely low. Moreover, if such a program reaches our boxes, then the traffic it will produce will probably be directed to "legitimate" ports...

I don't know, when I was younger I used to restrict even my laptop's outgoing traffic to specific ports, and I also used to log my block rules on disk. The more I get older the more I come to the conclusion that I do not gain much from this policy, and tend to leave all outgoing traffic of my external interfaces free (statefully), and block all incoming traffic except from the specific ports I run services on.

...then again, all these are personal opinions..
 
Thanks, for fixing my firewall rule :)
I had wrong understanding of out and in.... I thought it was about traffic, not incoming/outgoing connection
 
You are kindly welcome!

You do well that you treat your laptop as a server, this is my approach too. Try using freebsd jails to play with services, and you'll become well acquainted with pf and firewalls as well.

My idea of learning how to build "good" firewalls is to first read a good book about them, even those that refer to older firewall syntaxes (as those not mentioning statefull filtering), because of the fact that you'll have to understand how the traffic flows through them (more rules are written but you get a good understanding of how it works, and statefull firewalls become much easier to develop afterwards). A good old book regarding firewalls is "building internet firewalls" from O'Reilly, but this is not the only one. Most guides and howtos around the Internet are not very strict with the way they teach firewall building. Even the "pf guide" (which is not a tutor's book of course, and is an excellent guide in general) uses "any" in most of its examples instead of using"!$my_pc" or "!$my_external_interface". This allows, under certain conditions only, spoofed packets to pass through these rules. In any case !$my_interface is the "mathematically" correct clause in most cases.

Once you get a good idea of how the IP suite works, building a firewall in most implementations will become a lot easier (you'll only have to learn the semantics and syntax of each vendor).

Lastly, one of the things that makes pf my best choice to use for firewalls, is the policy-based filtering that it allows. Try understanding how "tagging" works, and you'll turn out to write very easy to read-and-administer pf.conf's.
 
...ah! and a last rule of thumb, which is valid on most firewall syntaxes:

in and out clauses refer to the interface. In means that the traffic flows your interface's next hop to the specific interface, and out means the opposite. From an to clauses refer to what the packet states as source address and destination address. So even though that these two clauses seem similar, this is not the case (always keep spoofing in mind). In and out refer to the direction of traffic relative to the interface the rule refers to, and from and to refer to the IP headers of the packet traversing the particular interface.

Good luck with your study on firewalls!

PS. Pay a good deal of attention whether you (or your firewall vendor) follow a first-rule-match policy, a last-rule-match or both. As your rulesets grow, many mistakes may arise if you don't keep it in mind, where you don't expect them to.
 
...oops some quick corrections on my previous post:

mamalos said:
..."In" means that the traffic flows from your interface's next hop to the specific interface, and "out" means the opposite. "From" and "to" clauses refer to what the packet states as source address and destination address. So even though that these two clauses seem similar, this is not the case (always keep spoofing in mind). "In" and "out" refer to the direction of traffic relative to the interface the rule refers to, and "from" and "to" refer to the IP headers of the packet traversing the particular interface.
Click to expand...
 
My strategy is to block everything.
Then quick block in/out ssh and telnet

and then allow in/out one by one...
 
killasmurf86 said:
My strategy is to block everything.
Then quick block in/out ssh and telnet

and then allow in/out one by one...
Click to expand...

Your first two rules overlap, canceling your second rule.

You could first block quick all spoofing-traffic on each interface for both directions. So if you have eg. 2 interfaces, you need 4 rules for that. This way you are through with spoofing once and for all. Next you could bock all traffic. After that you may start with quick pass rules to allow access to the services of interest, on each interface and each direction. In very-very advanced setups (where first-rule-match policy fails), you may combine quick pass rules and plain pass rules, but this is very rare. Try keeping the same strategy for your whole setup.
 
Most rules can work without direction, so e.g.

Code: 
antispoof quick for { $ext_if $int_if }

and

Code: 
scrub all

are entirely functional.
 
This is true, and this is why we usually use "block all" when we start our rulesets. Nevertheless, in your example, the antispoof syntax is ok for our laptops, but is not that "protective" in routers, where specific non-routed networks should be used for each direction. Moreover, in rare scenarios (where one may need to have the same subnet on two interfaces, in a bridge-firewall, with no IP on the specific interfaces. An example which I have come up to), the way "antispoof" works may yield unwanting results (it will block incoming traffic from these hosts on both interfaces).
In general, I use antispoof for simple setups (non-routers setups, and/or sometimes non-servers setups). For the rest of my setups, I keep a list of non routable IPs in one of more files, which is copied to a table when pf starts. The list is updated when IANA changes its list of non routable networks.
 
I don't think antispoof and unroutable networks in general have a lot do with one another; antispoof just forces a particular network to remain 'attached' to a particular interface.

So if you have 192.168.0.0/24 on interface fxp0, 'antispoof fxp0' stops incoming traffic from 192.168.0.0/24 on any other interface, and the antispoof rule expands to:

Code: 
block drop in quick on ! fxp0 inet from 192.168.0.0/24 to any

And whether it's RFC1918 netspace or a publicly routable IP network does not matter. The only difference wrt antispoof is that using it on a public IP network will add an extra rule:

Code: 
block drop in quick on ! re0 inet from public.ip to any
block drop in quick inet from public.ip to any

For RFC1918 space, I just use a table on the basis of IANA data, and several 'bogon' sources.
 
DutchDaemon,

by saying antispoof, one thinks what the word says: anti-spoof :); and in particular we mean anti-IP-spoofing. So if I want to use a rule for anti-spoofing I should first consider which would be the spoofed packets that could pass through an interface (different for each direction). These would be all non-routeable networks, along (maybe) with all other networks which I know that shouldn't pass, because they maybe "belong" to some other segment of my network (or interface). So for antispoofing rules, I use the list I told you before. To achieve what antispoof clause stands for, a typical technique would be to use $my_specific_net in the from clause of a pass-in rule, eg.

pass in [quick] on $some_if inet proto $some_proto from $my_specific_net to $blabla[or any] [keep/modulate state]

that way I achieve the same result, by just being more specific with my rules.

If I want to also include the interface's IP (which is what antispoof does when expanded to rules), I could use the following table (not just a list, since it will have completely different results, beware!! the list expands to a sequence of similar rules!):

table <my_specific_net> { 192.168.0.0/24, ! 192.168.0.1}

In this scenario, my interface has the 192.168.0.1 IP, and the network subnet it belongs to is 192.168.0.0/24.

Using this table in the aforementioned example rule, instead of $my_specific_net would replace the use of the antispoof clause, without being more generic than one should.
 
mamalos said:
DutchDaemon,

by saying antispoof, one thinks what the word says: anti-spoof
Click to expand...

Sorry, but no. This was and is a thread about PF, and antispoof is a PF concept. So semantics and redefining the subject matter are fine, but we do like to stick to the topic at hand when choosing our words ever so carefully ... So put the goalposts back ;)
 
Ok DutchDaemon, you're the moderator :). I just posed my opinion on how understand antispoof..but to be honest, our conversation on antispoofing started from a comment on one of my previous replies which stated that:

"You could first block quick all spoofing-traffic on each interface for both directions...bla bla"

Then you replied with the antispoof-clause alternative. All I was talking about in that message, was antispoofing, not "interface-attaching". Therefore I quoted my last messages, as well as this one.

But as I stated before: ok, you're the moderator :):)
 
I'm giving the mic back to killasmurf86. How's your FTP coming along?
 
So I was right all this time ;) heh

want to become admin, so sometimes I treat my box as if it was server
Click to expand...
Move your blog to your own server and you will become the admin. Real geeks use wordpress, hosted on their own box :D
 
You can host it on your home server. It can be done one 1M ADSL connection too..are you connected via slow Dialup / Mobile phone?
 
I have good net (Up/Down: 100Mbs)... the problem will be increased electricity bill ;)
Besides that I sleep in same room (for now)
 
You must log in or register to reply here.
Back
Top