Re: NAT devices not translating privileged ports
Hi, Blake, Thanks a lot for your comments! In-line On Fri, 2021-06-04 at 11:13 -0500, Blake Hudson wrote: > Current gen Cisco ASA firewalls have logic so that if the connection > from a private host originated from a privileged source port, the > NAT > translation to public IP also uses an unprivileged source port (not > necessarily the same source port though). Did you actaully mean "...also uses a *privileged port*"? > > I found out that this behavior can cause issues when you have devices > on > your network that implement older DNS libraries or configs using UDP > 53 > as a source and destination port for their DNS lookups. Occasionally > the > source port gets translated to one that ISC BIND servers have in a > blocklist (chargen, echo, time, and a few others) and the query is > ignored. As I recall, this behavior is hard coded so patching and > recompiling BIND is required to work around it. > > I forget what the older ASA behavior was. It may have been to leave > the > source port unchanged through the NAT process (I think this is what > you > mean by "not translated"). In that case the client doesn't implement > source port randomization and the NAT doesn't "upgrade" the > connection > to a random source port so I don't really see it as an issue. The issue would be that if the port is not translated, and multiple systems in the internal real of the NAT try to use the same privileged port (say, 123) simultaneously, things wouldn't work. Thanks, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: NAT devices not translating privileged ports
Hi, Jean, On Fri, 2021-06-04 at 08:36 -0400, Jean St-Laurent wrote: > I believe all devices will translate a privileged ports, but it won't > translate to the same number on the other side. It will translate to > an unprivileged port. Is it what you meant or really there are some > devices that will not translate at all a privileged port? What has been reported to us is that some boxes do not translate the src port if it's a privileged port. IN such scenarios, NTP implementations that always use src port=123, dst port=123 might be in trouble if there are multiple NTP clients behind the same NAT device Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: NAT devices not translating privileged ports
Hi, Bjørn, On Thu, 2021-06-10 at 12:10 +0200, Bjørn Mork wrote: > Fernando Gont via NANOG writes: > > > What has been reported to us is that some boxes do not translate > > the > > src port if it's a privileged port. > > > > IN such scenarios, NTP implementations that always use src > > port=123, > > dst port=123 might be in trouble if there are multiple NTP clients > > behind the same NAT device > > This problem used to be very common for 500/udp. Ref > https://datatracker.ietf.org/doc/html/rfc3715#section-2.3 THanks a lot for the link! -- this is indeed a good read. I'm curious if there exists something similar for UDP/123? FWIW, we have this IETF I-D on NTP port randomization: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-06 , which has this section on the same kind of behavior, but for the NTP port: cut here 3.4. Effect on NAT devices Some NAT devices will not translate the source port of a packet when a privileged port number is employed. In networks where such NAT devices are employed, use of the NTP well-known port for the client port will essentially limit the number of hosts that may successfully employ NTP client implementations. In the case of NAT devices that will translate the source port even when a privileged port is employed, packets reaching the external realm of the NAT will not employ the NTP well-known port as the local port, since the local port will normally be translated by the NAT device possibly, but not necessarily, with a random port. cut here So I'm trying to find some reference that documents such behavior for the NTP case Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: NAT devices not translating privileged ports
Hi, Jean, On Thu, 2021-06-10 at 06:54 -0400, Jean St-Laurent via NANOG wrote: > Hi Fernando, > > NTP sounds simple but it could be very complex when you dig deep down > and/or get lost in details. > Here are 2 things to consider: > > 1. NTP clients can query NTP servers by using SRC UDP ports > 1024. This is indeed the case we're addressing. The NTP spec mandates srt port=123, even for client-to-server cases. > In your case, it sounds like you want to achieve NTP server to NTP > server, but you mention NTP clients behind NAT devices. Nope. We simply recommend to randomize the source port for client-to- server cases. So in the quoted section we make the case that requiring src port=123 clients doesnt really make sense: 1) if the NAT translates the port, the server won-t see src 123 anyway 2) if the NAT doesn't translate the port, you won't be able to ahve multiple NTP clients behind the same firewall. > Can you give us more details on what kind of communication you need > here? From what I understand client to server should work just fine > with any NAT devices. > > Maybe you meant multiple NTP servers behind the same NAT to external > NTP servers Please let me know if what I wrote above clarifies our intent. Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: NAT devices not translating privileged ports
Hi, Jean,
On Thu, 2021-06-10 at 08:23 -0400, Jean St-Laurent wrote:
> Let's start with this example. When I click sync my clock in windows,
> this happened.
>
> On the inside or Private side
> 08:15:07.434344 IP 192.168.254.205.123 > 13.86.101.172.123: NTPv3,
> Client, length 48
> 08:15:07.473681 IP 13.86.101.172.123 > 192.168.254.205.123: NTPv3,
> Server, length 48
>
> You are indeed right that the client must use UDP port 123. Is the
> RFC saying must or should on the client SRC port? I'm not sure.
Section 9.1 ("Peer Process Variables") of [RFC5905] SAYS:
dstport: UDP port number of the client, ordinarily the NTP port
number PORT (123) assigned by the IANA. This becomes the source
port number in packets sent from this association.
That said, as noted in
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-06#section-5
, other client implementations don't bind the local port to 123, and
hence assign an ephemeral port.
> But, on the Public, this happened.
> 08:15:07.434381 IP 192.2XX.XXX.58291 > 13.86.101.172.123: NTPv3,
> Client, length 48
> 08:15:07.473656 IP 13.86.101.172.123 > 192.2XX.XXX.58291: NTPv3,
> Server, length 48
>
> // Public ip obfuscated. I know, it indeed starts with 192.2. It's
> EBOX in Canada.
>
> What we see on the public side, is that a network device did a NAT
> translation of the SRC UDP port to 58921. My clock synced perfectly.
>
> So your goal is to find the devices that don't follow this behaviour,
> right?
> No. The goal of our I-D is that NTP clients randomize their source
> port -- there's no need for clients to use port 123, and using that
> port on the client side has negative security implications.
Thanks,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Operational Implications of IPv6 Extension Headers (Fwd: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt)
Hi, folks, After almost 7+ years of working on this topic, our internet-draft entitled Operational Implications of IPv6 Packets with Extension Headers¨ ( https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-08 ), has been approved for publication as an IETF RFC. I believe it iś of value for folks working in security and/or network operations. Kudos to my co-authors for enduring the process, and to Nick Hilliard who did the last push to get this one approved. :-) Thanks! Cheers, Fernando Forwarded Message Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops- 08.txt Date: Fri, 11 Jun 2021 09:28:16 -0700 From: internet-drafts at ietf.org Reply-To: v6ops at ietf.org To: i-d-announce at ietf.org CC: v6ops at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Operational Implications of IPv6 Packets with Extension Headers Authors : Fernando Gont Nick Hilliard Gert Doering Warren Kumari Geoff Huston Will (Shucheng) Liu Filename: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt Pages : 20 Date: 2021-06-11 Abstract: This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200), and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ v6ops mailing list v6ops at ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: shadowserver.org
On Sun, 2021-06-27 at 23:19 -0400, Scott Aldrich wrote: > Anyone have an idea how to get HE/ShadowServer,org servers to stop > attempting to penetrate the comcast drop at my house? > > Their website claims altruism.. but my logs dont support that claim. In theory (at least), your ISP asked for it. Thanks, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: shadowserver.org
On Mon, 2021-06-28 at 13:04 -0400, Jean St-Laurent via NANOG wrote: > What is the difference between shodan.io and shadowserver.org ? At least in theory, for the former anyone that pays for the service (or employs free credit) has access to the scan data, whereas for the later, only the responsible organization for the network prefixes get the scan results. Thanks, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
