Date: Fri, 5 Apr 2002 16:00:05 -0800 (PST) From: "Joe & Fhe Barbish" <barbish@a1poweruser.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/36683: Stop dynamic rules from displaying using ipfw list command Message-ID: <200204060000.g36005123854@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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.
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?
**********
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.
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
How does Limit know when a packet has completed
so as the remove it from the count?
I guess the real question is what is the limit option
really doing and how does it do it?
Is it building it's own version of dynamic rules table?
***********************************
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
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
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?
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
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
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?
Does the blackhole mib do the same thing as the tcp_restrict_rst option?
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
************************
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.
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.
Please enlighten me about these subjects.
If there are in the process of being address please let me know the target
release they will be come available in.
Thanks
Joe
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?200204060000.g36005123854>