Date: Sat, 6 Apr 2002 12:18:44 -0800 From: "Crist J. Clark" <cjc@FreeBSD.ORG> To: Joe & Fhe Barbish <barbish@a1poweruser.com> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/36683: Stop dynamic rules from displaying using ipfw list command Message-ID: <20020406121844.A70207@blossom.cjclark.org> In-Reply-To: <200204060000.g36005123854@freefall.freebsd.org>; from barbish@a1poweruser.com on Fri, Apr 05, 2002 at 04:00:05PM -0800 References: <200204060000.g36005123854@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?20020406121844.A70207>