Date: Sun, 7 Apr 2002 13:55:42 -0400 From: "Joe & Fhe Barbish" <barbish@a1poweruser.com> To: "Crist J. Clark" <cjc@FreeBSD.ORG> Cc: <freebsd-bugs@FreeBSD.ORG> Subject: RE: kern/36683: Stop dynamic rules from displaying using ipfw list command Message-ID: <LPBBIGIAAKKEOEJOLEGOAEFPCNAA.barbish@a1poweruser.com> In-Reply-To: <20020406121844.A70207@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank You Crist for your reply, I am still confused on some of the
questions and would like to discuss them in more detail.
>> When do these sysctl mibs get control, before the packet gets to
>> ipfw or after the packets have passed through the ipfw firewall?
>>
>> net.inet.icmp.drop_redirect=1
>> net.inet.icmp.log_redirect=0
>> net.inet.ip.redirect=0
>> net.inet.icmp.bmcastecho=0
>> net.inet.tcp.blackhole=2
>> net.inet.udp.blackhole=1
>> net.inet.tcp.log_in_vain=1
>> net.inet.udp.log_in_vain=1
>
>After.
The ipfw firewall is built on the foundation principle that every packet
passes through the firewall rules and if the packet does not match any of
the rules it gets rejected by default. Now your answer "after" is saying
that packets which get caught by the above Mibs have passed through the
ipfw firewall and do not get caught by the default rule that is suppose
to deny everything. What you are saying is in direct conflict of how
ipfw works. Please explain what is really happening with these packets
that they are not being caught by the ipfw default reject rule.
***************************
Crist, don't take this the wrong way, But your answers to my questions about
how the new limit option works did not answer my questions.
'I believe' translated into, I do not know for sure, and have not looked
into it to find out, here is my best educated guess. My educated guess is
the author of the new limit function either dove-tailed the limit logic into
the existing dynamic rules table or pirated some of that code and built his
own
limit dynamic table or a variation there of.
On the second part of my limit questions which dealt with the occurrences
per
unique IP address for that limit option or for the base rule the limit
option is on. The man ipfw info in the example section says this
'To limit the number of connections a user can open you can use the
following type of rules:
ipfw add allow tcp from my-net/24 to any setup limit src-addr 10
ipfw add allow tcp from any to me setup limit src-addr 4
The former (assuming it runs on a gateway) will allow each host on a /24
network to open at most 10 TCP connections. The latter can be placed on a
server to make sure that a single client does not use more than 4
simultaneous connections.'
I interpret this sentence from the man page example 'The former (assuming it
runs on a gateway) will allow each host on a /24 network to open at most 10
TCP connections.' to mean that using my original question below the first
group is what is really happening and not the second group as you said.
Crist, you are in the inner circle and have access to the author of the
limit option. Please contact the author to get the details or put me in
contact with the author so we can work out the answers, one on one.
> ipfw add allow tcp from any to me setup limit src-addr 4
>
> Is it saying that for each unique ip address in the src ip
> address field it will allow up to 4 simultaneous connections?
> So I would see
>
> src_ip_addr 122.33.45.11 accept
> src_ip_addr 122.33.45.12 accept
> src_ip_addr 122.33.45.12 accept
> src_ip_addr 122.33.45.11 accept
> src_ip_addr 122.33.45.11 accept
> src_ip_addr 122.33.45.12 accept
> src_ip_addr 122.33.45.12 accept
> src_ip_addr 122.33.45.11 accept
> src_ip_addr 122.33.45.11 rejected
******************************************
>> kern.ipc.somaxconn=1024
>Hmmm... Not sure if this is a good idea in the first place or if it is
>even relevant now with the SYN-cookie implementation.
I have no frame of reference to even begin to understand what you are
saying here. Please explain what the 'SYN-cookie implementation' is,
and what release it is in?
*********************************************
>> net.link.ether.inet.max_age=600
>Cutting the age in half will have little impact on that type of
>attack.
What do you mean by your statement? Are you saying the age limit needs to
be even shorter, say 100 or 200 or what? This attack type is targeted at
creating an Denial of Service when the ARP table fills up. When this type
of thing happens to the dynamic rules table the solution is to shorten the
life time limit to release table resources faster, so it's only normal that
this same solution will work here also. Please clarify what you mean.
***********************************************************
>> These are /etc/rc.conf options. The first 2 have sysctl mibs, what
>> is the relationship between the mibs and these rc.conf options.
>> Does the exclusive use of keep-state rules address what the
>> tcp_drop_synfin option is doing?
>
>Look at the code in the rc-files for each one.
You really lost me with this statement. What rc.files are you talking about?
Where are they located. There is no /etc/rc.tcp_drop_synfin file.
***********************************************************
>> Does the blackhole mib do the same thing as the tcp_restrict_rst option?
>There is no such option anymore.
Again what are you talking about? Which MIB are you referring to and in
what version of FBSD are you referring to?
***********************************************************
>> What is the exact difference between ipfw forwarding and ipfw divert?
>> From what I read in the man page it's just a play on words and they both
>> do the same thing.
>> Is forward the ipfw version of the external divert program?
>Very, very, different. 'divert' sends a packet to a divert(4)
>socket. 'fwd' actually sends a packet to a new network
>destination. 'fwd' involves no userland programs.
Yes this is very obvious from the ipfw man page info that divert is an
external program and forward is built into ipfw. But my question still
is unanswered. 'Is forward the ipfw version of the external divert program?'
Maybe I need to clarify my question. As user ppp has a built in Nat
function and there is a natd external program which does the same thing.
So is ipfw forward the ipfw version of the external divert program and
ipfw goes one step further by enabling ipfw to issue rules which will pass
packets direct to the external divert program. Now the common functionally
in both cases is a another box on the lan behind the firewall can be pointed
to by a port number which is different that what was contained in the
original packet. The documentation on forward is very sparse and not very
enlighten. Please describe what exactly forward is intended to do in the
light of what divert does.
***********************************************************
Finally we come to the FTP question. I get the idea from your response that
a request from behind the firewall to start an FTP session with a FTP server
on the public internet can be coded with one keep-state ipfw rule that will
allow the complete session conversation to happen (including the FTP server
opening data port 20 and the sending of data over the high port range) if
the original request uses passive FTP.
In 4.4 I have to use these 2 rules to do that for passive FTP.
allow tcp from any to any 21 out via tun0 setup keep-state
allow tcp from any 20 to any 1024-49151 in via tun0 setup keep-state
Why does the first rule not handle the complete session conversation?
Thanks for you help
Joe
-----Original Message-----
From: Crist J. Clark [mailto:cjc@FreeBSD.ORG]
Sent: Saturday, April 06, 2002 3:19 PM
To: Joe & Fhe Barbish
Cc: freebsd-bugs@FreeBSD.ORG
Subject: Re: kern/36683: Stop dynamic rules from displaying using ipfw list
command
On Fri, Apr 05, 2002 at 04:00:05PM -0800, Joe & Fhe Barbish wrote:
> The following reply was made to PR kern/36683; it has been noted by GNATS.
>
> From: "Joe & Fhe Barbish" <barbish@a1poweruser.com>
> To: <freebsd-gnats-submit@FreeBSD.org>,
> "Barbish (Home)" <barbish@a1poweruser.com>
> Cc:
> Subject: Re: kern/36683: Stop dynamic rules from displaying using ipfw
list command
> Date: Fri, 5 Apr 2002 18:54:09 -0500
>
> I have been corresponding with David Malone about this PR.
> He has been very helpful. He informs me that there is now
> a -d flag to ipfw to just list the static rules without the
> dynamic rules. I just installed 4.5 and it's man ipfw does not
> include the -d flag, I have used the FBSD online man page for 5.0
> and it does not show the -d flag either.
Other way around. That _used_ to be the behavior, but now only the
static rules are listed by default. You need '-d' to see the dynamic
rules.
> So it comes down to is there a new flag -d to suppress the listing
> of the dynamic rules and if so what release is it in?
It's in 4.5, and it's in the manpage,
-d While listing, show dynamic rules in addition to static ones.
-e While listing, if the -d option was specified, also show
expired
dynamic rules.
It's been there since 4.4-STABLE (October 27th). So this has actually
been around for a long time.
> **********
>
> I see in 4.5 that a new option was added "limit".
> The man page contains no information on how this works.
> Just the syntax of the command.
Here's what it says in the manpage.
limit {src-addr | src-port | dst-addr | dst-port} N
The firewall will only allow N connections with the
same
set of parameters as specified in the rule. One or
more
of source and destination addresses and ports can be
specified.
> ipfw add allow tcp from any to me setup limit src-addr 4
>
> Is it saying that for each unique ip address in the src ip
> address field it will allow up to 4 simultaneous connections?
> So I would see
>
> src_ip_addr 122.33.45.11 accept
> src_ip_addr 122.33.45.12 accept
> src_ip_addr 122.33.45.12 accept
> src_ip_addr 122.33.45.11 accept
> src_ip_addr 122.33.45.11 accept
> src_ip_addr 122.33.45.12 accept
> src_ip_addr 122.33.45.12 accept
> src_ip_addr 122.33.45.11 accept
> src_ip_addr 122.33.45.11 rejected
>
> or would I see
>
> src_ip_addr 122.33.45.11 accept
> src_ip_addr 122.33.45.12 accept
> src_ip_addr 122.33.45.12 accept
> src_ip_addr 122.33.45.11 accept
> src_ip_addr 122.33.45.11 rejected
> src_ip_addr 122.33.45.12 rejected
> src_ip_addr 122.33.45.12 rejected
> src_ip_addr 122.33.45.11 rejected
> src_ip_addr 122.33.45.11 rejected
I believe the second.
> How does Limit know when a packet has completed
> so as the remove it from the count?
I believe it's the usual 'keep-state' timeout mechanism.
> ***********************************
> When do these sysctl mibs get control, before the packet gets to
> ipfw or after the packets have passed through the ipfw firewall?
>
> net.inet.icmp.drop_redirect=1
> net.inet.icmp.log_redirect=0
> net.inet.ip.redirect=0
> net.inet.icmp.bmcastecho=0
> net.inet.tcp.blackhole=2
> net.inet.udp.blackhole=1
> net.inet.tcp.log_in_vain=1
> net.inet.udp.log_in_vain=1
After.
> Will these sysctl mibs enable these functions without first compiling
> them into the kernel from the kernel source options?
> net.inet.ip.fw.verbose=1
> net.inet.ip.fw.verbose_limit=#
> net.inet.ip.forwarding=1
No.
> What is the exact difference between ipfw forwarding and ipfw divert?
> From what I read in the man page it's just a play on words and they both
> do the same thing.
> Is forward the ipfw version of the external divert program?
Very, very, different. 'divert' sends a packet to a divert(4)
socket. 'fwd' actually sends a packet to a new network
destination. 'fwd' involves no userland programs.
> Is this still a good idea to do?
> # To defend against SYN attacks more commonly known as SYNFLOOD attacks,
> # the two queues which are targeted by this type of attack should have
it's
> # size increased so that the queues can withstand an attack of low to
> moderate
> # intensity with little to no effect on the stability or availability of
the
> # server. FBSD maintains separate queues for inbound socket connection
> # requests. One queue is for half-open sockets (SYN received, SYN|ACK
sent),
> # the other queue for fully-open sockets awaiting an accept() call from
the
> # application. The following statement increases the queue size from 128.
>
> kern.ipc.somaxconn=1024
Hmmm... Not sure if this is a good idea in the first place or if it is
even relevant now with the SYN-cookie implementation.
> Is this still a good idea to do?
> # By allowing aged ARP entries to remain cached or lying around allows
for
> # the possibility of a hacker to create a resource exhaustion or
> # performance degradation by filling the IP route cache with bogus
> # ARP entries. This in turn can be used as Denial of Service attack.
> # To prevent this sort of problem the following statement shortens the
> # amount of time an ARP will be cached from 1200 to 600 seconds.
>
> net.link.ether.inet.max_age=600
Cutting the age in half will have little impact on that type of
attack.
> These are /etc/rc.conf options. The first 2 have sysctl mibs, what
> is the relationship between the mibs and these rc.conf options.
> Does the exclusive use of keep-state rules address what the
> tcp_drop_synfin option is doing?
Look at the code in the rc-files for each one.
> Does the blackhole mib do the same thing as the tcp_restrict_rst option?
There is no such option anymore.
>
> log_in_vain="YES" # NO is default. YES enables logging of
> # connection attempts to ports that have no
> # listening socket on them. Put msg on consol
>
> icmp_drop_redirect="YES" # YES will cause the kernel to ignore
> # ICMP REDIRECT packets.
>
> tcp_drop_synfin="YES" # YES will cause the kernel to ignore TCP
> # frames that have both the SYN and FIN flags
> # set. Only available if the kernel was built
> # with the TCP_DROP_SYNFIN option.
> # change to NO if web server behind firewall.
>
> tcp_restrict_rst="YES" # YES will cause the kernel to refrain from
> # emitting TCP RST frames in response to
> # invalid TCP packets (e.g., frames destined
> # for closed ports). This option is only
> # available if the kernel was built with the
> # TCP_RESTRICT_RST option.
> ***********************************
>
> Since writing the pr I have come up with two more suggestions.
>
> When the user lists the ipfw active rules with ipfw show the listing
> shows the action as allow when it was entered as pass and
> xmit or recv for via. The user is expecting to see what they entered.
> This does nothing but confuse the user.
>
> How about changing ipfw so the values entered are shown when listed?
>
> Example
>
> 00020 pass tcp from me to any 80 out via tun0 # rule as written
>
> 00020 allow tcp from me to any 80 out xmit tun0 # rule as listed
That'd be a big PITA to maintain. You have to store this extra
information about what people typed in the kernel. It has no impact on
how the rules work so it shouldn't be there. It is clear those are the
same rule,
allow Allow packets that match rule. The search terminates.
Aliases are pass, permit and accept.
> ************************
>
> The keep-state dynamic rules is great, but it falls short of it's
> intended design when used for FTP. Every one knows the remote host
> is going to open port 20 followed by an port in the high number range.
No, you don't. That's one common way for FTP to work, but by no means
the only.
> The original keep-state on the allow rule that lets the original request
> on port 21 out, should continue to process the reply for port 20 and the
> high number port as part of the original rule, it's all part of the
> ftp session conversation.
>
> Worded a different way
> Change the keep-state dynamic rules processing for FTP so it will
> accept the FTP server opening data port 20 and the sending of data
> over the high port range as part of the original rule for port 21.
> Basically keep-state for a FTP session should process the complete
> FTP session conversation from beginning to end.
> It should not take 2 keep-state rules to do it, one for port 21 going
> out, and a second rule for port 20 coming back in.
> The rule to allow the port 20 in is a security hole.
> An attacker can target port 20 or the high number port
> range and slip right in.
Proxying FTP is not easy. The easiest thing to do is to use passive
FTP. The only way to effectively implement this in ipfw(8) rules was
actually removed recently. You used to be able to give 'keep-state' an
option. Most people rely on the proxy in natd(8).
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LPBBIGIAAKKEOEJOLEGOAEFPCNAA.barbish>