From owner-freebsd-ipfw@freebsd.org Sun Nov 29 01:03:25 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B836A3BF86 for ; Sun, 29 Nov 2015 01:03:25 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from homiemail-a91.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by mx1.freebsd.org (Postfix) with ESMTP id 598011CB9 for ; Sun, 29 Nov 2015 01:03:24 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from homiemail-a91.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a91.g.dreamhost.com (Postfix) with ESMTP id 1A6A6AE069; Sat, 28 Nov 2015 17:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=menhennitt.com.au; h= subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= menhennitt.com.au; bh=nzPwYlGq8KblHRwQR87TMMFArqA=; b=UgK3jwDkyD aAxsG84oBf+TGr3PNM6397OJyuIZgZM2LkOZj8u6J80HwUPbjAQavA6nLwuIJouv DNgz87Ls2p6GvA+8f892INdRLrS8CTi5u2P+quTId0M+6sa4JoXOE09vzvhaUQkz ++6SGUVhxBV68a0rzgIbKcCpN/YXWw8zs= Received: from [203.2.73.68] (c122-107-214-88.mckinn3.vic.optusnet.com.au [122.107.214.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: graham@menhennitt.com.au) by homiemail-a91.g.dreamhost.com (Postfix) with ESMTPSA id 58FE4AE05B; Sat, 28 Nov 2015 17:03:23 -0800 (PST) Subject: Re: connecting a PS4 via IPFW To: =?UTF-8?Q?Thom=c3=a1s_S._Bregolin?= References: <5655405C.1060301@menhennitt.com.au> <20151127180317.GA3661@host> <56592B3D.5070800@menhennitt.com.au> <20151128094753.GA5426@bloo> Cc: freebsd-ipfw@freebsd.org From: Graham Menhennitt X-Enigmail-Draft-Status: N1110 Message-ID: <565A4ED9.2080102@menhennitt.com.au> Date: Sun, 29 Nov 2015 12:03:21 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151128094753.GA5426@bloo> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 01:03:25 -0000 On 28/11/2015 20:47, Thom=E1s S. Bregolin wrote: > Besides the redirect_port option, you still need rules allowing traffic > in to those ports. Excuse-me if you've done that already (I have no way > of knowing). > > > Sat, Nov 28, 2015 at 03:19:09PM +1100, Graham Menhennitt: >> On 28/11/2015 05:03, Thomas wrote: >>> Wed, Nov 25, 2015 at 04:00:12PM +1100, Graham Menhennitt: >>>> I have a box running FreeBSD 10-stable that I use as a >>>> router/firewall/NAT. It runs IPFW and uses kernel NAT. My son is nag= ging >>>> me about playing multi-player online games on his Sony PS4. >>>> >>>> Giving up on that, I'm now trying to enable port forwarding - >>>> apparently, this will fix it. I've allocated the PS4 a static IP add= ress >>>> on my LAN. I need to port forward TCP ports 80, 443, 1935, 3478-3480= , >>>> and UDP ports 3478-3479. I've tried the following command: >>>> >>>> ipfw nat 1 config if re1 same_ports \ >>>> redirect_port tcp ${PS4_LAN_ADDRESS}:1935 1935 \ >>>> redirect_port tcp ${PS4_LAN_ADDRESS}:3478 3478 \ >>>> redirect_port tcp ${PS4_LAN_ADDRESS}:3479 3479 \ >>>> redirect_port tcp ${PS4_LAN_ADDRESS}:3480 3480 \ >>>> redirect_port udp ${PS4_LAN_ADDRESS}:3478 3478 \ >>>> redirect_port udp ${PS4_LAN_ADDRESS}:3479 3479 >>>> >>>> Thanks again, Thomas and Ian. I have attempted to let those ports in, but I'm not really sure what I'm doing. My firewall rules are below - could you please have a look. I allow almost all UDP and I've added rules for the four relevant TCP ports. As Ian suggested, I've removed ports 80 and 443 from the redirects= . Thanks, Graham # stop spoofing add deny all from LAN_NET to any in via OUTSIDE_IF add deny all from WIFI_NET to any in via OUTSIDE_IF # allow anything on the LAN add allow all from any to any via LAN_IF # and from the VPN add allow all from any to any via VPN_IF # allow anything from the wireless network to here and the outside world (but not to the LAN) add allow ip from any to me via WIFI_IF add allow ip from any to not LAN_NET via WIFI_IF # create a table of addresses to block table 1 flush # add RFC1918 nets table 1 add 10.0.0.0/8 table 1 add 172.16.0.0/12 table 1 add 192.168.0.0/16 # and draft-manning-dsua-03.txt nets table 1 add 0.0.0.0/8 table 1 add 169.254.0.0/16 table 1 add 192.0.2.0/24 table 1 add 224.0.0.0/4 table 1 add 240.0.0.0/4 # stop entries in the table on the outside interface add deny all from table(1) to any via OUTSIDE_IF # allow setup of incoming SSH, IMAPS, and OpenVPN add allow tcp from any to me ssh setup add allow tcp from any to me imaps setup add allow tcp from any to me openvpn setup add allow udp from any to me openvpn # allow IPP and SMTP from wireless add allow ip from any to LAN_NET dst-port printer setup via WIFI_IF add allow ip from any to me dst-port ipp setup via WIFI_IF add allow ip from any to me dst-port smtp setup via WIFI_IF # allow ICMP & UDP # ..except UPnP discovery add deny udp from any to any 1900 # .. and SIP in from outside add deny udp from any to any in via OUTSIDE_IF dst-port 5060-5069 #add allow igmp from any to any add allow icmp from any to any add allow udp from any to any # Network Address Translation. nat 1 config if OUTSIDE_IF same_ports deny_in add nat 1 ip4 from any to any via OUTSIDE_IF # Allow TCP through if setup succeeded add pass tcp from any to any established # Allow IP fragments to pass through add pass all from any to any frag # allow TCP ports needed for PS4 add allow tcp from any to any 1935 in via OUTSIDE_IF setup add allow tcp from any to any 3478 in via OUTSIDE_IF setup add allow tcp from any to any 3479 in via OUTSIDE_IF setup add allow tcp from any to any 3480 in via OUTSIDE_IF setup # reject all setup of incoming connections from the outside add deny tcp from any to any in via OUTSIDE_IF setup # reject all setup of incoming connections from the wireless add deny tcp from any to any in via WIFI_IF setup # Allow setup of any other TCP connection add pass tcp from any to any setup From owner-freebsd-ipfw@freebsd.org Sun Nov 29 13:27:38 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99993A3B698 for ; Sun, 29 Nov 2015 13:27:38 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9DAE1D79 for ; Sun, 29 Nov 2015 13:27:37 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id tATDRWPf073321; Mon, 30 Nov 2015 00:27:32 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 30 Nov 2015 00:27:31 +1100 (EST) From: Ian Smith To: Graham Menhennitt cc: "=?UTF-8?Q?Thom=c3=a1s_S._Bregolin?=" , freebsd-ipfw@freebsd.org Subject: Re: connecting a PS4 via IPFW In-Reply-To: <565A4ED9.2080102@menhennitt.com.au> Message-ID: <20151129235037.L63537@sola.nimnet.asn.au> References: <5655405C.1060301@menhennitt.com.au> <20151127180317.GA3661@host> <56592B3D.5070800@menhennitt.com.au> <20151128094753.GA5426@bloo> <565A4ED9.2080102@menhennitt.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 13:27:38 -0000 On Sun, 29 Nov 2015 12:03:21 +1100, Graham Menhennitt wrote: > On 28/11/2015 20:47, Thomás S. Bregolin wrote: > > Besides the redirect_port option, you still need rules allowing traffic > > in to those ports. Excuse-me if you've done that already (I have no way > > of knowing). > > > > > > Sat, Nov 28, 2015 at 03:19:09PM +1100, Graham Menhennitt: > >> On 28/11/2015 05:03, Thomas wrote: > >>> Wed, Nov 25, 2015 at 04:00:12PM +1100, Graham Menhennitt: > >>>> I have a box running FreeBSD 10-stable that I use as a > >>>> router/firewall/NAT. It runs IPFW and uses kernel NAT. My son is nagging > >>>> me about playing multi-player online games on his Sony PS4. > >>>> > >>>> Giving up on that, I'm now trying to enable port forwarding - > >>>> apparently, this will fix it. I've allocated the PS4 a static IP address > >>>> on my LAN. I need to port forward TCP ports 80, 443, 1935, 3478-3480, > >>>> and UDP ports 3478-3479. I've tried the following command: > >>>> > >>>> ipfw nat 1 config if re1 same_ports \ > >>>> redirect_port tcp ${PS4_LAN_ADDRESS}:1935 1935 \ > >>>> redirect_port tcp ${PS4_LAN_ADDRESS}:3478 3478 \ > >>>> redirect_port tcp ${PS4_LAN_ADDRESS}:3479 3479 \ > >>>> redirect_port tcp ${PS4_LAN_ADDRESS}:3480 3480 \ > >>>> redirect_port udp ${PS4_LAN_ADDRESS}:3478 3478 \ > >>>> redirect_port udp ${PS4_LAN_ADDRESS}:3479 3479 > >>>> > >>>> > Thanks again, Thomas and Ian. > > I have attempted to let those ports in, but I'm not really sure what I'm > doing. My firewall rules are below - could you please have a look. I > allow almost all UDP and I've added rules for the four relevant TCP > ports. As Ian suggested, I've removed ports 80 and 443 from the redirects. > > Thanks, > Graham There are some minor details (eg 'almost all UDP' and icmp) that I'll mention but not dwell on, until your $subject issue is solved, so this is just a bit of a first pass; I could miss some significant points :) > # stop spoofing > add deny all from LAN_NET to any in via OUTSIDE_IF > add deny all from WIFI_NET to any in via OUTSIDE_IF > > # allow anything on the LAN > add allow all from any to any via LAN_IF > > # and from the VPN > add allow all from any to any via VPN_IF > > # allow anything from the wireless network to here and the outside world > (but not to the LAN) > add allow ip from any to me via WIFI_IF > add allow ip from any to not LAN_NET via WIFI_IF > > # create a table of addresses to block > table 1 flush > # add RFC1918 nets > table 1 add 10.0.0.0/8 > table 1 add 172.16.0.0/12 > table 1 add 192.168.0.0/16 > # and draft-manning-dsua-03.txt nets > table 1 add 0.0.0.0/8 > table 1 add 169.254.0.0/16 > table 1 add 192.0.2.0/24 > table 1 add 224.0.0.0/4 > table 1 add 240.0.0.0/4 > # stop entries in the table on the outside interface > add deny all from table(1) to any via OUTSIDE_IF Good idea. You may want to also deny these the reverse way, after NAT (refer /etc/rc.firewall 'simple' ruleset), which may inform re this. > # allow setup of incoming SSH, IMAPS, and OpenVPN > add allow tcp from any to me ssh setup > add allow tcp from any to me imaps setup > add allow tcp from any to me openvpn setup > add allow udp from any to me openvpn > > # allow IPP and SMTP from wireless > add allow ip from any to LAN_NET dst-port printer setup via WIFI_IF > add allow ip from any to me dst-port ipp setup via WIFI_IF > add allow ip from any to me dst-port smtp setup via WIFI_IF > > # allow ICMP & UDP > # ..except UPnP discovery > add deny udp from any to any 1900 > # .. and SIP in from outside > add deny udp from any to any in via OUTSIDE_IF dst-port 5060-5069 > #add allow igmp from any to any > add allow icmp from any to any > add allow udp from any to any Likely you should work out which UDP you _do_ want to pass, and deny the rest. Use 'log' on more rules, at least at first, so you can see stuff happening, to catch eg ports you do want open (DNS, NTP...) or closed. allow icmp from any to any icmptypes 0,3,8,11 deny icmp from any to any is safer and generally all you need, and you need 3 and 11 for TCP PMTU discovery and traceroute. Especially don't allow icmp redirects; you can block them with a sysctl but it's easier to just drop them outright along with all the other icmptypes not of interest. > # Network Address Translation. > nat 1 config if OUTSIDE_IF same_ports deny_in What happened to your redirect_ports? You still need these. And I'm not sure whether deny_in is appropriate here, as you do want to allow fresh inbound connections to the redirected ports for the PS4. You're already dealing with unsolicited inbound requests anyway, though tighter UDP would be reassuring. natd(8) has a lot deeper discussion of NAT options, almost all of it is relevant also to kernel NAT, except, as I recall, the proxy_port stuff. > add nat 1 ip4 from any to any via OUTSIDE_IF > > # Allow TCP through if setup succeeded > add pass tcp from any to any established > > # Allow IP fragments to pass through > add pass all from any to any frag > > # allow TCP ports needed for PS4 > add allow tcp from any to any 1935 in via OUTSIDE_IF setup > add allow tcp from any to any 3478 in via OUTSIDE_IF setup > add allow tcp from any to any 3479 in via OUTSIDE_IF setup > add allow tcp from any to any 3480 in via OUTSIDE_IF setup These would be better more explicitly 'to $PS4_IP' than 'to any'. > # reject all setup of incoming connections from the outside > add deny tcp from any to any in via OUTSIDE_IF setup > > # reject all setup of incoming connections from the wireless > add deny tcp from any to any in via WIFI_IF setup > > # Allow setup of any other TCP connection > add pass tcp from any to any setup cheers, Ian From owner-freebsd-ipfw@freebsd.org Mon Nov 30 11:18:50 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17170A249A1 for ; Mon, 30 Nov 2015 11:18:50 +0000 (UTC) (envelope-from kulamani.sethi@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9C521AC1 for ; Mon, 30 Nov 2015 11:18:49 +0000 (UTC) (envelope-from kulamani.sethi@gmail.com) Received: by ioc74 with SMTP id 74so168178007ioc.2 for ; Mon, 30 Nov 2015 03:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cNCnn8zIvv3b0n9Vt2EpMPx7JmVUA1Y0RgJUB+F4d1o=; b=dFCVK1x0ShqbdoYNyii5b46OjjNVjrrbf/OwS2JNMEUEehtLX+sO+PyNCRLsHZh+Xu i+pvF/NMvFGKVxPvWLz25nhqHrZBZJoQItspapVl4lbeVVBsaYJ0EbhoW5qBI1A9l57o ZL3L0ZxtoYIk0msCaOH2Xr2tQ4f6noQMRXTx43EnpfnLsA9pHqjfeN6i/lKoA31F9jWK xC60KLmqmXiIbfdLT7Puib3DZhPk9U7YhFOCT0lNZ+nhd+cJuYMSSmLNyhSF2fkl/Qau KSnozhUt915GY/tnEKIYzq8d+y536mYnjVYDG0HlBzyWzVl1VPZhuu3oL+fpxSLAxWLa yXPQ== MIME-Version: 1.0 X-Received: by 10.107.133.227 with SMTP id p96mr59686985ioi.1.1448882329270; Mon, 30 Nov 2015 03:18:49 -0800 (PST) Received: by 10.36.211.146 with HTTP; Mon, 30 Nov 2015 03:18:49 -0800 (PST) Date: Mon, 30 Nov 2015 16:48:49 +0530 Message-ID: Subject: Set a deny rule for a URL in IPFW by its domain name From: Kulamani Sethi To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 11:18:50 -0000 Hi all, I am using ipfw3, can i block a URL by its domain name? When i am setting rules in IPFW by its domain name, it simple set rule by its corresponding IP. Here example how i set C:>ipfw add 1002 deny log ip from www.google.com to any As i know most of the websites uses dynamic IP, it simple changes there IP periodically. This rule i set for google is worked for few moment, then it allow the packets to my terminal. From owner-freebsd-ipfw@freebsd.org Mon Nov 30 12:02:51 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0598CA3CB7E for ; Mon, 30 Nov 2015 12:02:51 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5456915E2 for ; Mon, 30 Nov 2015 12:02:49 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id tAUC2eoA019684; Mon, 30 Nov 2015 23:02:40 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 30 Nov 2015 23:02:39 +1100 (EST) From: Ian Smith To: Kulamani Sethi cc: freebsd-ipfw@freebsd.org Subject: Re: Set a deny rule for a URL in IPFW by its domain name In-Reply-To: Message-ID: <20151130223514.Q16065@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 12:02:51 -0000 On Mon, 30 Nov 2015 16:48:49 +0530, Kulamani Sethi wrote: > Hi all, > I am using ipfw3, can i block a URL by its domain name? When i am > setting rules in IPFW by its domain name, it simple set rule by its > corresponding IP. > Here example how i set > > C:>ipfw add 1002 deny log ip from www.google.com to any > > As i know most of the websites uses dynamic IP, it simple changes there IP > periodically. This rule i set for google is worked for few moment, then it > allow the packets to my terminal. % dig www.google.com ; <<>> DiG 9.6.-ESV-R3 <<>> www.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16574 ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 43 IN A 220.233.196.223 www.google.com. 43 IN A 220.233.196.219 www.google.com. 43 IN A 220.233.196.249 www.google.com. 43 IN A 220.233.196.234 www.google.com. 43 IN A 220.233.196.229 www.google.com. 43 IN A 220.233.196.245 www.google.com. 43 IN A 220.233.196.212 www.google.com. 43 IN A 220.233.196.251 www.google.com. 43 IN A 220.233.196.216 www.google.com. 43 IN A 220.233.196.227 www.google.com. 43 IN A 220.233.196.238 www.google.com. 43 IN A 220.233.196.241 www.google.com. 43 IN A 220.233.196.240 www.google.com. 43 IN A 220.233.196.230 www.google.com. 43 IN A 220.233.196.208 www.google.com. 43 IN A 220.233.196.218 ;; Query time: 31 msec ;; SERVER: 220.233.0.4#53(220.233.0.4) ;; WHEN: Mon Nov 30 22:34:28 2015 ;; MSG SIZE rcvd: 288 .. and that's just a list of www.google.com addresses at/via my ISP. it's not so much - in this case - of changing addresses periodically (where periodically for things like file and music sharing sites may be as often as once per minute) but also of having many different addresses provided in different parts of the world, as above. Your own provider might also provide fast proxies to google, youtube, netflix, facebook, twitter .. or most/all large content providers. So no, if it doesn't have a fixed IP address, ipfw rules won't work. You could add addresses to a table, easy to update as you go without needing to reload your ipfw rules, and use something like: # ipfw add deny log ip4 from table\(88\) to any but if you hope to block sites like google, expect lots of work :) cheers, Ian From owner-freebsd-ipfw@freebsd.org Mon Nov 30 15:56:18 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBBCBA3D787 for ; Mon, 30 Nov 2015 15:56:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4A741C0C for ; Mon, 30 Nov 2015 15:56:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tAUFuDUA001382 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 30 Nov 2015 07:56:17 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Set a deny rule for a URL in IPFW by its domain name To: freebsd-ipfw@freebsd.org References: <20151130223514.Q16065@sola.nimnet.asn.au> From: Julian Elischer Message-ID: <565C7198.6040504@freebsd.org> Date: Mon, 30 Nov 2015 23:56:08 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151130223514.Q16065@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 15:56:19 -0000 On 30/11/2015 8:02 PM, Ian Smith wrote: > On Mon, 30 Nov 2015 16:48:49 +0530, Kulamani Sethi wrote: > > Hi all, > > I am using ipfw3, can i block a URL by its domain name? When i am > > setting rules in IPFW by its domain name, it simple set rule by its > > corresponding IP. > > Here example how i set > > > > C:>ipfw add 1002 deny log ip from www.google.com to any > > > > As i know most of the websites uses dynamic IP, it simple changes there IP > > periodically. This rule i set for google is worked for few moment, then it > > allow the packets to my terminal. > the only way to do this is to make a daemon similar to what I wrote for cisco many years ago. it acts as a DNS 'man-in-the-middle' and compares all DNS responses against black/white lists. WHen it gets a hit it: 1/ returns a suitably altered answer. 2/ adds the address found to a black or white table in ipfw. Since Secure DNS is getting more popular, it would probably make more sense these days to make unbound or bind feed their work through some filter module to do the same thing. From owner-freebsd-ipfw@freebsd.org Mon Nov 30 22:14:06 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72621A3D2ED for ; Mon, 30 Nov 2015 22:14:06 +0000 (UTC) (envelope-from nathan@reddog.com.au) Received: from mail.7sq.com.au (mail.7sq.com.au [119.148.74.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3046319BE; Mon, 30 Nov 2015 22:14:05 +0000 (UTC) (envelope-from nathan@reddog.com.au) Received: from localhost (localhost [127.0.0.1]) by mail.7sq.com.au (Postfix) with ESMTP id 9F4F02C3316; Tue, 1 Dec 2015 08:09:23 +1000 (AEST) Received: from mail.7sq.com.au ([127.0.0.1]) by localhost (mail.7sq.com.au [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id KDr_khr-xBbd; Tue, 1 Dec 2015 08:09:23 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by mail.7sq.com.au (Postfix) with ESMTP id 6EB9C2C3232; Tue, 1 Dec 2015 08:09:23 +1000 (AEST) X-Virus-Scanned: amavisd-new at mail.7sq.com.au Received: from mail.7sq.com.au ([127.0.0.1]) by localhost (mail.7sq.com.au [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y1D3rGmm4Boj; Tue, 1 Dec 2015 08:09:23 +1000 (AEST) Received: from mailstore1.mail.7sq.com.au (mailstore1.mail.7sq.com.au [192.168.242.86]) by mail.7sq.com.au (Postfix) with ESMTP id 2D72D2C3316; Tue, 1 Dec 2015 08:09:23 +1000 (AEST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Nathan Aherne MIME-Version: 1.0 Subject: Re: Set a deny rule for a URL in IPFW by its domain name Message-Id: Date: Tue, 1 Dec 2015 08:09:23 +1000 (EST) References: <20151130223514.Q16065@sola.nimnet.asn.au> <565C7198.6040504@freebsd.org> To: Julian Elischer In-Reply-To: <565C7198.6040504@freebsd.org> Cc: freebsd-ipfw@freebsd.org X-Mailer: Zimbra 8.6.0_GA_1182 (MobileSync - Apple-iPhone6C2/1301.452) Thread-Topic: Set a deny rule for a URL in IPFW by its domain name Thread-Index: kjTZkZCJAZhfIE2h5bVMuVMmtLy5iA== X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 22:14:06 -0000 Just use a dns override for the domains you want to block. Regards, Nathan Sent from my iPhone > On 1 Dec 2015, at 1:52 AM, Julian Elischer wrote: >=20 >> On 30/11/2015 8:02 PM, Ian Smith wrote: >> On Mon, 30 Nov 2015 16:48:49 +0530, Kulamani Sethi wrote: >> > Hi all, >> > I am using ipfw3, can i block a URL by its domain name? When i am >> > setting rules in IPFW by its domain name, it simple set rule by its >> > corresponding IP. >> > Here example how i set >> > >> > C:>ipfw add 1002 deny log ip from www.google.com to any >> > >> > As i know most of the websites uses dynamic IP, it simple changes ther= e IP >> > periodically. This rule i set for google is worked for few moment, the= n it >> > allow the packets to my terminal. > the only way to do this is to make a daemon similar to what I wrote for ci= sco many years ago. > it acts as a DNS 'man-in-the-middle' and compares all DNS responses agains= t black/white lists. > WHen it gets a hit it: > 1/ returns a suitably altered answer. > 2/ adds the address found to a black or white table in ipfw. >=20 > Since Secure DNS is getting more popular, it would probably make more sens= e these days to make unbound or bind > feed their work through some filter module to do the same thing. >=20 > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@freebsd.org Tue Dec 1 03:48:56 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51843A3D148 for ; Tue, 1 Dec 2015 03:48:56 +0000 (UTC) (envelope-from anonymous@webxc24s08.ad.aruba.it) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 36AEF1037 for ; Tue, 1 Dec 2015 03:48:56 +0000 (UTC) (envelope-from anonymous@webxc24s08.ad.aruba.it) Received: by mailman.ysv.freebsd.org (Postfix) id 33911A3D147; Tue, 1 Dec 2015 03:48:56 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19C3DA3D146 for ; Tue, 1 Dec 2015 03:48:56 +0000 (UTC) (envelope-from anonymous@webxc24s08.ad.aruba.it) Received: from smtplqs-out38.aruba.it (smtplqs-out38.aruba.it [62.149.158.78]) by mx1.freebsd.org (Postfix) with ESMTP id 6D2321036 for ; Tue, 1 Dec 2015 03:48:53 +0000 (UTC) (envelope-from anonymous@webxc24s08.ad.aruba.it) Received: from webxc24s08.ad.aruba.it ([62.149.143.38]) by smartcmd02.ad.aruba.it with bizsmtp id o3ng1r0080pv6h2013ngLQ; Tue, 01 Dec 2015 04:47:41 +0100 Received: (qmail 11169 invoked by uid 18960115); 1 Dec 2015 03:47:40 -0000 To: ipfw@freebsd.org Subject: Your order #00990064 is approved Date: Tue, 1 Dec 2015 04:47:40 +0100 From: "America Airlines" Reply-To: "America Airlines" Message-ID: <0dced62fcf70884321e359babb808402@partneritaly.com> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:48:56 -0000 Dear customer, Your payment has been processed and your credit card has been charged. E-Ticket is attached to this email. Below you can find the order details and e-ticket information: FLIGHT NUMBER / TE153976 DATE & TIME / Dec 05 2015, 13:10 DEPARTING / Fort Worth TOTAL PRICE / $ 400.00 Thank you for choosing America Airlines. From owner-freebsd-ipfw@freebsd.org Tue Dec 1 17:50:29 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEAE5A3E966 for ; Tue, 1 Dec 2015 17:50:29 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81D0E1220 for ; Tue, 1 Dec 2015 17:50:29 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4592220D23 for ; Tue, 1 Dec 2015 12:50:28 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Tue, 01 Dec 2015 12:50:28 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Iu56sJm3bMoasVH ovXkWjnS7aes=; b=FsentpVHDbYTEXWDOyZ6XlaTmhCW8N51LraM2izPhGk7+5s RveWl4AjN7OILEiY+9qvcmga2H6qlwKjFXALMQ7LvmVEIfyCoqQWtjzOfvX0c4Xn 79HqWcqghiXmDsZQgn3MrP0lSWuONx4aEer6UF05uCmmKKkZrpA/ACLBSD40= Received: by web3.nyi.internal (Postfix, from userid 99) id 1BE7E10D6CA; Tue, 1 Dec 2015 12:50:28 -0500 (EST) Message-Id: <1448992228.1319754.454925001.2A341FB4@webmail.messagingengine.com> X-Sasl-Enc: BZ+wCaumqjtbTlnz030oMqYJ1ZcxDPUZawL+t3vK4HJ7 1448992228 From: Mark Felder To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 Subject: IPFW keep-state and software interfaces Date: Tue, 01 Dec 2015 11:50:28 -0600 In-Reply-To: References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 17:50:29 -0000 On Tue, Dec 1, 2015, at 10:27, elof2@sentor.se wrote: > On Tue, 1 Dec 2015, Mark Felder wrote: > > > > > > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: > >> > >> Hi, Mark. > >> > >> > >>> I'm hoping someone can explain what happened here and this isn't a bug, > >>> but if it is a bug I'll gladly open a PR. > >>> > >>> I noticed in my ipfw logs that I was getting a log of "DENY" entries for > >>> an NTP server > >>> > >>> Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP > >>> [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 > > Three long-shots: > > 1) > I see that you use a gif interface. That makes me wonder: > Do the 'keep-state' function in 'ipfw' work as bad as it does in 'pf'? > > In pf, 'keep state" doesn't keep state between software network > interfaces and real network interfaces. So if I allow something in via > tun0 (a software OpenVPN NIC), with keep state, the response is *not* > automatically (via the state table) allowed back in on the ethernet NIC > it > was sent out. So for all my VPN-rules, I have to make two of them like > this: > > Pf example: > pass in quick on tun0 inet proto tcp from to > port 22 keep state label "VpnIN - SSH" > pass out quick on em1 inet proto tcp from to > port 22 keep state label "DmzOUT - SSH" > Curious if anyone on the ipfw list can provide insight into IPFW's "keep-state" behavior with software network interfaces. Eg, with a gif tunnel for IPv6. If it's failing to match that might explain why I've witnessed NTP high-port responses get blocked on v6 but not v4. Why I'm even seeing high port usage for NTP is yet another mystery I'm trying to track down. -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-ipfw@freebsd.org Tue Dec 1 18:23:59 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E3B9A3E35D for ; Tue, 1 Dec 2015 18:23:59 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D44E91F9E for ; Tue, 1 Dec 2015 18:23:58 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D391E204B6 for ; Tue, 1 Dec 2015 13:23:57 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 01 Dec 2015 13:23:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=y6hjFFRQVJP8YZB znj1amV0c2Pw=; b=IhjCSVbhgSY1BP2AnRc1lOdWwZp3Jwy6QzE3x02i+ek3j5P b/MfMhRLWX/wtorNjgl9NkROYZKLlw+faDyMUWY+H8U5RiFuKsKA2Z82mfCGSo8G K6HOXT9Nt8L+F3XlxXuZFe/G2O0J1ZqCJI7bzgtGMLgjnT5J9+K6BvvTQ/rY= Received: by web3.nyi.internal (Postfix, from userid 99) id A934210D828; Tue, 1 Dec 2015 13:23:57 -0500 (EST) Message-Id: <1448994237.1328914.454960825.14BECB56@webmail.messagingengine.com> X-Sasl-Enc: zmpgyGAuad907GuyNd+ininjrAtp+fKsB1GMgO5/2/Et 1448994237 From: Mark Felder To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b94e6169 In-Reply-To: <1448992228.1319754.454925001.2A341FB4@webmail.messagingengine.com> References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <1448992228.1319754.454925001.2A341FB4@webmail.messagingengine.com> Subject: Re: IPFW keep-state and software interfaces Date: Tue, 01 Dec 2015 12:23:57 -0600 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 18:23:59 -0000 On Tue, Dec 1, 2015, at 11:50, Mark Felder wrote: > > > On Tue, Dec 1, 2015, at 10:27, elof2@sentor.se wrote: > > On Tue, 1 Dec 2015, Mark Felder wrote: > > > > > > > > > > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: > > >> > > >> Hi, Mark. > > >> > > >> > > >>> I'm hoping someone can explain what happened here and this isn't a bug, > > >>> but if it is a bug I'll gladly open a PR. > > >>> > > >>> I noticed in my ipfw logs that I was getting a log of "DENY" entries for > > >>> an NTP server > > >>> > > >>> Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP > > >>> [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in via gif0 > > > > Three long-shots: > > > > 1) > > I see that you use a gif interface. That makes me wonder: > > Do the 'keep-state' function in 'ipfw' work as bad as it does in 'pf'? > > > > In pf, 'keep state" doesn't keep state between software network > > interfaces and real network interfaces. So if I allow something in via > > tun0 (a software OpenVPN NIC), with keep state, the response is *not* > > automatically (via the state table) allowed back in on the ethernet NIC > > it > > was sent out. So for all my VPN-rules, I have to make two of them like > > this: > > > > Pf example: > > pass in quick on tun0 inet proto tcp from to > > port 22 keep state label "VpnIN - SSH" > > pass out quick on em1 inet proto tcp from to > > port 22 keep state label "DmzOUT - SSH" > > > > Curious if anyone on the ipfw list can provide insight into IPFW's > "keep-state" behavior with software network interfaces. Eg, with a gif > tunnel for IPv6. If it's failing to match that might explain why I've > witnessed NTP high-port responses get blocked on v6 but not v4. > > Why I'm even seeing high port usage for NTP is yet another mystery I'm > trying to track down. > I solved my mystery: it was another host behind my firewall with almost identical IPv6 address. IPv6 "keep-state" with my gif tunnel is working correctly. Nothing to see here, move along. :) -- Mark Felder ports-secteam member feld@FreeBSD.org