Re: Request comment: list of IPs to block outbound
On 10/13/19 3:36 PM, Stephen Satchell wrote: Are you saying that Terendo should come off the list? Is this useful between an ISP and an edge firewall fronting an internal network? Would I see inbound packets with a source address in the 2001::/32 netblock? If you are running services which are "generally available to the public". you can absolutely expect to see these. Anyone stuck behind an IPv6-hostile NAT44 is likely to end up using Teredo as the "transition mechanism of last resort". It usually works, albeit with poor performance, in almost all situations unless the IPv6-hostile network has actively blocked it in their IPv4 ruleset. I personally use Teredo somewhat frequently. Yes, I could set up a similar tunneling mechanism to a network I control and get "production" addressing and probably better quality of service, but Teredo is as simple as "apt-get install miredo". It's also available on stock Windows albeit (I think) disabled by default. If your network only talks to specific, known destinations, then it's up to you. Your network; your rules. It's certainly unlikely you'll ever see any publicly accessible services of consequence being hosted in 2001::/32 if only because the addressing tends to be somewhat transient and NAT hole punching unreliable for inbound, unsolicited data. In my research, this is marked as deprecated. Would I see packets with a source address in the 2002::/16 netblock? In theory, this is just as legitimate as Teredo. In practice, it is indeed deprecated, and almost anyone who can set up 6to4 can get a "production" tunnel to someone like HE.net or likely has 6rd available from their native IPv4 provider. It can also be tricky to prevent reflection type attacks using 6to4 address space. IIRC, Windows used to set up 6to4 by default if it found it had what it believed to be publicly routable IPv4 connectivity, but I think this may now be disabled. Some consumer routers did the same. It was handy because you got a full /48 allowing non-NAT addressing of subtended networks and even prefix delegation if you wanted it. While this probably falls under the same justifications as the above, in practice I'd say 6to4 is probably all but dead in terms of legitimate uses on the public Internet of today. I haven't personally run 6to4 in over a decade. 6to4 was a neat idea, but I think it's dead, Jim. -- Brandon Martin
Re: Request comment: list of IPs to block outbound
On 10/13/19 9:58 AM, Stephen Satchell wrote: The Linux rp_filter knob is effective for endpoint servers and workstations, and I turn it on religiously (easy because it's the default). I think it's just as effective on routers as it is on servers and workstations. For a firewall router without blackhole routes, it's less effective because, for incoming packets, a source address matching one of your inside netblocks will pass. I'm not following that statement. Is incoming a reference to packets from the Internet to your LAN? Or is incoming a reference to packets coming in any interface, thus possibly including from your LAN to the Internet? Even without blackhole (reject) routes, a packet from the Internet spoofing a LAN IP will be rejected by rp_filter because it's coming in an interface that is not an outgoing interface for the purported source IP. A subset of the list would be useful in endpoint boxes to relieve pressure on the upstream edge router -- particularly if a ne'er-do-well successfully hijacks the endpoint box to participate in a DDoS flood. rp_filtering will filter packets coming in from the internal endpoint that's been compromised if the packets spoof a source from anywhere by the local LAN. (No comment about spoofing different LAN IPs.) I've been exceedingly happy with rp_filter and blackhole (reject) routes. I've taken this to another level where I have multiple routing tables and rules that cascade across tables. One of the later rules is a routing table for any and all bogons & RFC 3330. I am still able to access specific networks that fall into RFC 3330 on internal lab networks without a problem because those prefixes are found in routing tables that are searched before the bogon table that black holes (rejects) the packets. IMHO it works great. (I really should do a write up of that.) I think you should seriously re-consider using rp_filter on a router. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Request comment: list of IPs to block outbound
On 10/13/19 9:08 AM, Florian Brandstetter wrote: > Hi, > > sorry - but why would you want to block Teredo? I know nothing about Terendo tunneling. > In computer networking, Teredo is a transition technology that gives > full IPv6 connectivity for IPv6-capable hosts that are on the IPv4 > Internet but have no native connection to an IPv6 network. Unlike > similar protocols such as 6to4, it can perform its function even from > behind network address translation (NAT) devices such as home routers. > > Teredo operates using a platform independent tunneling protocol that provides > IPv6 (Internet Protocol version 6) connectivity by encapsulating IPv6 > datagram packets within IPv4 User Datagram Protocol (UDP) packets. Teredo > routes these datagrams on the IPv4 Internet and through NAT devices. Teredo > nodes elsewhere on the IPv6 network (called Teredo relays) receive the > packets, un-encapsulate them, and pass them on. Are you saying that Terendo should come off the list? Is this useful between an ISP and an edge firewall fronting an internal network? Would I see inbound packets with a source address in the 2001::/32 netblock? > sorry - but why would you want to block 6to4? In my research, this is marked as deprecated. Would I see packets with a source address in the 2002::/16 netblock?
Re: Request comment: list of IPs to block outbound
On Sun, 13 Oct 2019 at 19:29, William Herrin wrote: > The current IPv6 Internet is 2000::/3, not ::/0 and that won't change in the > foreseeable future. You can tighten your filter to allow just that. Only do this, if this isn't CLI jockey network now or in the future. -- ++ytti
Re: Request comment: list of IPs to block outbound
Hi, On Sun, Oct 13, 2019 at 08:58:17AM -0700, Stephen Satchell wrote: > The following list is what I'm thinking of using for blocking traffic > between an edge router acting as a firewall and an ISP/upstream. This > fe80::/10 LinkLink-local address. most people allow that range as blocking it will drop NA/NS packets with the upstream router which in turn can delay the establishment of the BGP session (provided there is one over IPv6). best Enno -- Enno Rey https://theinternetprotocol.blog Twitter: @Enno_Insinuator
Re: Request comment: list of IPs to block outbound
On Sun, Oct 13, 2019 at 8:58 AM Stephen Satchell wrote: > The following list is what I'm thinking of using for blocking traffic > between an edge router acting as a firewall and an ISP/upstream. This > table is limited to address blocks only; TCP/UDP port filtering, and IP > protocol filtering, is a separate discussion. This is for an > implementation of BCP-38 recommendations. > BCP-38 as it applies to outbound traffic is more about blocking SOURCE IP addresses. You should block everything whose source IP address is not within your assigned address space. > 100.64.0.0/10 Private network Shared address space[3] for > communications between a service > provider and its subscribers > when using a carrier-grade NAT. > This space is set aside for your ISP to use. like RFC1918 but for ISPs. It is not specifically CGNAT. Unless you are an ISP using this space, you should not block destinations in this space. > 224.0.0.0/4 InternetIn use for IP multicast. > 240.0.0.0/4 InternetReserved for future use. > 255.255.255.255/32 Subnet Reserved for the "limited > broadcast" destination address. > This can be covered with a single rule: 224.0.0.0/3 > IPv6 > Address block Usage Purpose > ::/0Routing Default route. > The current IPv6 Internet is 2000::/3, not ::/0 and that won't change in the foreseeable future. You can tighten your filter to allow just that. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Request comment: list of IPs to block outbound
On 10/13/19 8:58 AM, Stephen Satchell wrote: In trying to research what would constitute "best practice", the papers I found were outdated, potentially incomplete (particularly with reference to IPv6), or geared toward other applications. This table currently does not have exceptions -- some may need to be added as a specific "allow" route or list. https://www.team-cymru.com/bogon-reference-http.html
Re: Request comment: list of IPs to block outbound
Hi, sorry - but why would you want to block Teredo / 6to4? Florian Brandstetter President & Founder W // https://www.globalone.io (https://link.getmailspring.com/link/5edc7c51-257c-47ac-b303-4b5a7f6e9...@getmailspring.com/0?redirect=https%3A%2F%2Fwww.globalone.io=bmFub2dAbmFub2cub3Jn) On Okt. 13 2019, at 5:58 pm, Stephen Satchell wrote: > The following list is what I'm thinking of using for blocking traffic > between an edge router acting as a firewall and an ISP/upstream. This > table is limited to address blocks only; TCP/UDP port filtering, and IP > protocol filtering, is a separate discussion. This is for an > implementation of BCP-38 recommendations. > > I'm trying to decide whether the firewall should just blackhole these > addresses in the routing table, or use rules in NFTABLES against source > and destination addresses, or some combination. If NFTABLES, the best > place to put the blocks (inbound and outbound) would be in the FORWARD > chain, both inbound and outbound. (N.B. for endpoint boxes, they go > into the OUTPUT chain.) > > In trying to research what would constitute "best practice", the papers > I found were outdated, potentially incomplete (particularly with > reference to IPv6), or geared toward other applications. This table > currently does not have exceptions -- some may need to be added as a > specific "allow" route or list. > > The Linux rp_filter knob is effective for endpoint servers and > workstations, and I turn it on religiously (easy because it's the > default). For a firewall router without blackhole routes, it's less > effective because, for incoming packets, a source address matching one > of your inside netblocks will pass. A subset of the list would be > useful in endpoint boxes to relieve pressure on the upstream edge router > -- particularly if a ne'er-do-well successfully hijacks the endpoint box > to participate in a DDoS flood. > > IPv4 > Address block Scope Description > 0.0.0.0/8 Software Current network (only valid as > source address). > 10.0.0.0/8 Private network Used for local communications > within a private network. > 100.64.0.0/10 Private network Shared address space[3] for > communications between a service > provider and its subscribers > when using a carrier-grade NAT. > 127.0.0.0/8 Host Used for loopback addresses to > the local host. > 169.254.0.0/16 Subnet Used for link-local addresses > between two hosts on a single > link when no IP address is > otherwise specified, such as > would have normally been > retrieved from a DHCP server. > 172.16.0.0/12 Private network Used for local communications > within a private network. > 192.0.0.0/24 Private network IETF Protocol Assignments. > 192.0.2.0/24 Documentation Assigned as TEST-NET-1, > documentation and examples. > 192.88.99.0/24 Internet Reserved. Formerly used for > IPv6 to IPv4 relay > 192.168.0.0/16 Private network Used for local communications > within a private network. > 198.18.0.0/15 Private network Used for benchmark testing of > inter-network communications > between two separate subnets. > 198.51.100.0/24 Documentation Assigned as TEST-NET-2, > documentation and examples. > 203.0.113.0/24 Documentation Assigned as TEST-NET-3, > documentation and examples. > 224.0.0.0/4 Internet In use for IP multicast. > 240.0.0.0/4 Internet Reserved for future use. > 255.255.255.255/32 Subnet Reserved for the "limited > broadcast" destination address. > > IPv6 > Address block Usage Purpose > ::/0 Routing Default route. > ::/128 Software Unspecified address. > ::1/128 Host Loopback address to local host. > :::0:0/96 Software IPv4 mapped addresses. > :::0:0:0/96 Software IPv4 translated addresses. > 64:ff9b::/96 Global Internet IPv4/IPv6 translation. > 100::/64 Routing Discard prefix. > 2001::/32 Global Internet Teredo tunneling. > 2001:20::/28 Software ORCHIDv2. > 2001:db8::/32 Documentation Addresses used in documentation > and example source code. > 2002::/16 Global Internet The 6to4 addressing scheme > fc00::/7 Private network Unique local address. > fe80::/10 Link Link-local address. > ff00::/8 Global Internet Multicast address. >
Request comment: list of IPs to block outbound
The following list is what I'm thinking of using for blocking traffic between an edge router acting as a firewall and an ISP/upstream. This table is limited to address blocks only; TCP/UDP port filtering, and IP protocol filtering, is a separate discussion. This is for an implementation of BCP-38 recommendations. I'm trying to decide whether the firewall should just blackhole these addresses in the routing table, or use rules in NFTABLES against source and destination addresses, or some combination. If NFTABLES, the best place to put the blocks (inbound and outbound) would be in the FORWARD chain, both inbound and outbound. (N.B. for endpoint boxes, they go into the OUTPUT chain.) In trying to research what would constitute "best practice", the papers I found were outdated, potentially incomplete (particularly with reference to IPv6), or geared toward other applications. This table currently does not have exceptions -- some may need to be added as a specific "allow" route or list. The Linux rp_filter knob is effective for endpoint servers and workstations, and I turn it on religiously (easy because it's the default). For a firewall router without blackhole routes, it's less effective because, for incoming packets, a source address matching one of your inside netblocks will pass. A subset of the list would be useful in endpoint boxes to relieve pressure on the upstream edge router -- particularly if a ne'er-do-well successfully hijacks the endpoint box to participate in a DDoS flood. IPv4 Address block Scope Description 0.0.0.0/8 SoftwareCurrent network (only valid as source address). 10.0.0.0/8 Private network Used for local communications within a private network. 100.64.0.0/10 Private network Shared address space[3] for communications between a service provider and its subscribers when using a carrier-grade NAT. 127.0.0.0/8 HostUsed for loopback addresses to the local host. 169.254.0.0/16 Subnet Used for link-local addresses between two hosts on a single link when no IP address is otherwise specified, such as would have normally been retrieved from a DHCP server. 172.16.0.0/12 Private network Used for local communications within a private network. 192.0.0.0/24Private network IETF Protocol Assignments. 192.0.2.0/24Documentation Assigned as TEST-NET-1, documentation and examples. 192.88.99.0/24 InternetReserved. Formerly used for IPv6 to IPv4 relay 192.168.0.0/16 Private network Used for local communications within a private network. 198.18.0.0/15 Private network Used for benchmark testing of inter-network communications between two separate subnets. 198.51.100.0/24 Documentation Assigned as TEST-NET-2, documentation and examples. 203.0.113.0/24 Documentation Assigned as TEST-NET-3, documentation and examples. 224.0.0.0/4 InternetIn use for IP multicast. 240.0.0.0/4 InternetReserved for future use. 255.255.255.255/32 Subnet Reserved for the "limited broadcast" destination address. IPv6 Address block Usage Purpose ::/0Routing Default route. ::/128 SoftwareUnspecified address. ::1/128 HostLoopback address to local host. :::0:0/96 SoftwareIPv4 mapped addresses. :::0:0:0/96 SoftwareIPv4 translated addresses. 64:ff9b::/96Global Internet IPv4/IPv6 translation. 100::/64Routing Discard prefix. 2001::/32 Global Internet Teredo tunneling. 2001:20::/28SoftwareORCHIDv2. 2001:db8::/32 Documentation Addresses used in documentation and example source code. 2002::/16 Global Internet The 6to4 addressing scheme fc00::/7Private network Unique local address. fe80::/10 LinkLink-local address. ff00::/8Global Internet Multicast address.
