Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?

[Mailman]

Dear Gurus,

Background Information Part:
We rent an IP Address Block and a DNS zone.
[We have to pay the annual fees, so they are renting, yes? ]

We run our own DNS authoritative server, with DNSsec on.

We register our IP block on both IRR and ROA, and monitor them both for
‘poisoning records’.

Authority over DNS records, ROAs, and BGP table are with us, but authority
over the Web Servers are (naturally) not.

Question Part:
1. How (or where) can I monitor/control such that no one can ‘map’ my IP
addresses to external FQDNs [hijacking my IPs] without me knowing about it?
1.1. My understanding is that, as long as I control the authoritative
(DNSsec)server and people out there validate the DNS responses, hijacking
my IPs outright for use somewhere else is (theoretically) impossible, yes?
[leaving out Route Hijacking for now]

2. But, web admins can still essentially ‘rent out’ part or whole of my
websites by hosting 'forreign' pages/codes and allowing in ‘external
redirection’ from outside (to use my hardware! my IPs!) anyway, yes?

3. How (or where) can I monitor/control such that no one can ‘map’ FQDNs
from within my DNS zone to external IP addresses [hijacking my hostnames]
without me knowing about it?
3.1. My understanding is that, web admins can write all sorts of ‘redirect’
in such a way that parts or even my whole websites can be ‘hosted’ on
external IPs/hardware, yes?

4. Does that mean I need a big Web Application Firewall (WAF) or something
worse to monitor/control those above scenarios?

The thing is, no one should be able to use organization resources [IPs,
FQDNs, and Web Services, for a start] for his/her own purpose without
asking permission.

Thanks in advance for any pointers,

[_Bill_Woodcock]

Background Information Part:
We rent an IP Address Block and a DNS zone.
[We have to pay the annual fees, so they are renting, yes? ]

We don’t have enough information to know whether you’re renting or are the registrant, based on what you’ve said.

If you receive your domain name from a registrar, and the whois shows you to be the registrant, you’re the registrant. If you have a subdomain or you pay “rent” to someone who is shown as the registrant in the whois, then you’re just renting.

Likewise, if you receive your IP addresses from a regional Internet registry (ARIN in the NANOG region), you’re the LIR, or Local Internet Registry. If you have a subnet (which may be SWIPped into the whois, or may not) which you received from an LIR, then you’re just renting.

We run our own DNS authoritative server, with DNSsec on.

Meaning that you’re DNS signing both the forward (A/AAAA) and reverse (in-addr/ip6) zones?

Authority over DNS records, ROAs, and BGP table are with us, but authority over the Web Servers are (naturally) not.

It’s not clear what you mean by this. You mean that you don’t operate your own web servers, but instead use an outsourced service, which in turn uses its own IP addresses?

Question Part:
1. How (or where) can I monitor/control such that no one can ‘map’ my IP addresses to external FQDNs [hijacking my IPs] without me knowing about it?

These are separate and unrelated things.

Hijacking your IP addresses would be originating BGP announcement of them. Which other people should not do, and other people should not pay attention to if they’re validating ROAs and IRR entries.

Mapping your IP addresses to domain names (in-addr/ip6) is not an effective attack vector, and nobody will pay attention to anyway, if you’re the authoritative delegate for those blocks.

Mapping domain names to IP addresses (A/AAAA) is not an effective attack vector, and anyone can do, without disrupting anything.

1.1. My understanding is that, as long as I control the authoritative (DNSsec)server and people out there validate the DNS responses, hijacking my IPs outright for use somewhere else is (theoretically) impossible, yes?

If someone else conducts an effective DNS hijacking attack, intermediating themselves between your users and your servers, and your users don’t DNSSEC validate, then the attack will be successful. If your users do DNSSEC validate, AND THE APPS AND OSES THEY USE DON’T CIRCUMVENT IT, then the attack will fail. But that’s a big if. Many apps and OSes prefer a MITM attacker to a DNSSEC validation failure, because support costs.

2. But, web admins can still essentially ‘rent out’ part or whole of my websites by hosting 'forreign' pages/codes and allowing in ‘external redirection’ from outside (to use my hardware! my IPs!) anyway, yes?

If by “web admins” you mean third parties, rather than people who are responsible to you, yes. Which is why people concerned with security host their own services.

3. How (or where) can I monitor/control such that no one can ‘map’ FQDNs from within my DNS zone to external IP addresses [hijacking my hostnames] without me knowing about it?

There are at least three possibilities here.

One is that someone has access to the unsigned zone data below your delegation, in which case this is an internal security problem. If you’re using NSEC3 to prevent zone enumeration, and it were occurring in a delegated subdomain, this might actually be a difficult problem.

The second possibility is that someone external to your organization, who has access to DNS traffic flows (client, recursive, etc.) interposes themselves as a MITM or injects false data into a resolver cache. You could, hypothetically, buy access to “passive DNS” feeds which might reveal some portion of such traffic, if it existed, but that’s a very long shot.

A third (and probably most likely) possibility is that someone hijacks your domain at the registrar level, because registrars generally have crap security and fall over all the time, and registrants routinely use crap passwords to secure their accounts with registrars, etc. They could then add an additional nameserver, or substitute in all of their own nameservers. At that point, their actions would be fairly visible, and they’d still have to do a dirty roll of the DNSSEC KSKs, if they wanted to make things validate, but most wouldn’t bother doing so. There are monitoring services which watch for nameserver changes, but all the ones I’ve seen don’t actually check as often as they say they do, so miss attacks of this sort that are done quickly.

3.1. My understanding is that, web admins can write all sorts of ‘redirect’ in such a way that parts or even my whole websites can be ‘hosted’ on external IPs/hardware, yes?

Yep. See “why you shouldn’t do that” above.

4. Does that mean I need a big Web Application Firewall (WAF)

Absolutely not. I have no idea what a Web Application Firewall is, but if it’s anything like it sounds like, I wouldn’t let one anywhere near anything I was responsible for securing.

The thing is, no one should be able to use organization resources [IPs, FQDNs, and Web Services, for a start] for his/her own purpose without asking permission.

Sounds like you’re going to be writing a lot of shell scripts and cron jobs. Welcome to security. Remember to test your backups, that’s always the most important thing in any security regime.

                                -Bill

[Mailman]

Huh.
And I thought that I did lay down information (and questions) pretty clearly, but as you correctly pointed out, I didn’t.
So, here goes the second version:

Background Information Section (v2):
We are a Registrant and already registered a zone/domain with a Registry, we are also a LIR and have been allocated an IP block straight from RIR.
[What I meant to say is that they all keep saying that we don’t “own” those resources and we also have to pay the annual fee so, even though we are a Registrant and a LIR, it’s still practically a form of rent anyway.]
We DNSsec-sign and host both forward and reverse zones ourselves, with NSEC3 to prevent zone enumeration.
We register our IP block on both IRR and ROA, and constantly monitor them both for poison records.

Here’s the sticky part:
We have ‘jurisdiction’ over all those things above.
But: the Web Server part—hardware, software, and content—belongs to the ‘other department’. That’s my fact-of-life; can’t change it. [Does anyone have this same ‘arrangement’? Or do you guys rule over everything?]
Second but: ‘they’ want me to prevent anyone from using organization resources—IPs, hostnames, web server hardware/software—without asking permission; essentially asking me to look over the web admins’ shoulders.

I know for a fact that some websites with FQDN outside our zone have A/AAAA records with addresses from my IP block.

On the other hand, some other websites offload contents onto our servers.

Question Section (v2):
Since I am not the web admin:

1. How-to monitor whether some outsiders are putting our IP addresses into their A/AAAA records without me knowing about it?
2. How-to monitor whether some outside websites are just ‘shells’, with contents actually being hosted by our servers without me knowing about it?

[Adam_Thompson]

I just had a conversation with John Curran (of ARIN) about this, in fact…

You don’t own IP addresses. But you also don’t rent IP addresses, either.

IP addresses are not a thing, good, or object, not even an intangible good. They are an address, or an index, if you will. (You might think of an IP address as the index on a giant, internet-wide, shared array… that we call “the routing table”.)
Your annual fee purchases registration services, specifically, the service of ARIN entering your IP addresses into their master copy of a database that other people use. (And some ancillary services that ARIN provides to you.) That’s it.

The closest analogy I have are either phone numbers or street addresses. You don’t own either of those things, nor do you rent them. In the case of phone numbers, the phone company isn’t renting you the phone#, they’re renting you the POTS service that gives you the ability to make outgoing, and answer incoming, calls. Your ILEC also typically adds your name and # into a phone book, as part of the service. (Yeah, VoIP providers have mangled this analogy beyond recognition.) They can (and have) changed your phone number at will. At least ARIN doesn’t do that.

In the case of a street address, you own the property. The address is just an index to a giant, irregular 2D array called “the streets in your city”. Again, when you buy or rent the property, you aren’t buying or renting the address itself from anyone, much less the city. But there are all sorts of directories (“databases”) you can register your business in so that people know who occupies such-and-such a property, and marketing folks do this all the time (even in 2021). When you pay those companies money, you aren’t renting the property from them, you’re registering​ your property with them.

Here’s the problematic part: there’s absolutely nothing saying you have to register your addreses with an RIR to get them into the global routing table. You could probably find an ISP somewhere willing to overlook all the rules and conventions and advertise new address space that just happens to overlap with someone else’s registered addresses, or maybe you found some that aren’t currently advertised. In fact, I’d say it’s 100% possible to do so.

However, nearly everyone agrees to play by a common set of rules, in order that the Internet, well… works. As expected. Almost 100% of the time, taken as a whole. Those rules include requiring you to register with an RIR, to ensure there are no overlaps, and law enforcement can find you if necessary.

Again, you aren’t buying or renting IP addresses - you’re paying an admission fee of sorts, in order to play in the global routing table. The fact your RIR assigned you a block of addresses is part of good internet governance, and is not actually the commercial aspect of the transaction (even though we all think of it that way anyway, including me).

Ultimately, almost everyone thinks of it the way you do, but it’s technically quite wrong. (My statements may not be correct in jurisdictions deriving from systems other than English common law.)

Beyond this, this is a discussion for ARIN-DISCUSS not NANOG-L. Or perhaps in your case, whatever discussion list APNIC runs, since ARIN rules don’t apply in Thailand. But I expect APNIC will tell you almost the same thing as I just did.

-Adam

P.S. If you feel this is B.S. and it shouldn’t work this way, most of the RIRs are always looking for participants in their policy process - I know ARIN is. Well, I don’t know what’s up with AfriNIC, that unfortunately seems to be a rolling dumpster fire, but I suppose they’ll need new people to put the pieces all back together, too.

[Mailman]

I just had a conversation with John Curran (of ARIN) about this, in fact…

You don’t own IP addresses. But you also don’t rent IP addresses, either.

True, but you can rent the registration of an IP address, or, you can acquire a registration that you pay a monthly maintenance fee for.

In the former case, you are obtaining the registration from an LIR or possibly an end user (though unlikely and not permitted in all RIRs). The LIR takes care of registering your temporary possession of all or part (usually part) of their registration in the appropriate shared database(s) and the rental fee is either included with your connectivity bill or billed separately, depending on the LIR’s particular business practices. Some LIRs don’t provide connectivity services, while most do. Some include address registration in their connectivity price, others do not.

In the latter case, you are going directly to one of the five RIRs and obtaining an allocation or assignment. The registration of a unique set of numbers specifically to your entity is recorded by the RIR in their database(s) and published for all the world to see.

IP addresses are not a thing, good, or object, not even an intangible good. They are an address, or an index, if you will. (You might think of an IP address as the index on a giant, internet-wide, shared array… that we call “the routing table”.)

That analogy breaks down very quickly as the routing table is built out of prefixes and not addresses, but as oversimplifications go, it’s not entirely terrible.

Your annual fee purchases registration services, specifically, the service of ARIN entering your IP addresses into their master copy of a database that other people use. (And some ancillary services that ARIN provides to you.) That’s it.

That depends on who you are paying your fee to, but if you’ve gone directly to an RIR, specifically ARIN, yes, that’s the case.

The closest analogy I have are either phone numbers or street addresses. You don’t own either of those things, nor do you rent them. In the case of phone numbers, the phone company isn’t renting you the phone#, they’re renting you the POTS service that gives you the ability to make outgoing, and answer incoming, calls. Your ILEC also typically adds your name and # into a phone book, as part of the service. (Yeah, VoIP providers have mangled this analogy beyond recognition.) They can (and have) changed your phone number at will. At least ARIN doesn’t do that.

It’s actually a lot more like license plates. You don’t own the license plate or the license plate number, but you pay a registration fee every year for DMV (or your jurisdiction’s equivalent) for the privilege of them telling police officers who that plate points to whenever they ask. The car is like your routers and network… You own that, but you don’t own the numbers you got from DMV to label each piece of equipment. However, the numbers do uniquely point to the fact that the equipment is yours.

Here’s the problematic part: there’s absolutely nothing saying you have to register your addreses with an RIR to get them into the global routing table. You could probably find an ISP somewhere willing to overlook all the rules and conventions and advertise new address space that just happens to overlap with someone else’s registered addresses, or maybe you found some that aren’t currently advertised. In fact, I’d say it’s 100% possible to do so.

Fortunately, over time, this is actually getting harder. Between improved IRR filtering and other tools, combined with a tendency to de-peer networks that habitually announce prefixes on behalf of people they are not registered to, the situation has somewhat improved.

OTOH, RPKI, especially with AS0 ROAs radically alters this trust model in that it provides an avenue for an RIR that becomes a bad actor to do great and immediate damage to entities it chooses to attack. I’m not saying there are any RIRs that would abuse this power, but I’m also not as confident as I used to be that none of them would.

However, nearly everyone agrees to play by a common set of rules, in order that the Internet, well… works. As expected. Almost 100% of the time, taken as a whole. Those rules include requiring you to register with an RIR, to ensure there are no overlaps, and law enforcement can find you if necessary.

It’s also important to note that the RIRs have rules they are supposed to play by which are developed through their respective policy development processes. To date, they’ve generally made a pretty strong effort to do so. There is one RIR that is unfortunately a glaring exception at the moment.

Again, you aren’t buying or renting IP addresses - you’re paying an admission fee of sorts, in order to play in the global routing table. The fact your RIR assigned you a block of addresses is part of good internet governance, and is not actually the commercial aspect of the transaction (even though we all think of it that way anyway, including me).

You’re really paying a registration fee, just like you do for the license plates on your car every year. The biggest difference is that nobody is coming with a gun to collect your RIR fee.

Ultimately, almost everyone thinks of it the way you do, but it’s technically quite wrong. (My statements may not be correct in jurisdictions deriving from systems other than English common law.)

To the best of my knowledge, your descriptions of how the RIRs work is accurate regardless of the legal framework. All RIRs specifically call out in their contract that addresses are registered to you and are not property and you don’t own them.

Beyond this, this is a discussion for ARIN-DISCUSS not NANOG-L. Or perhaps in your case, whatever discussion list APNIC runs, since ARIN rules don’t apply in Thailand. But I expect APNIC will tell you almost the same thing as I just did.

If they’re only in Thailand, then yes, APNIC. If they’re also in North America or the Caribbean, they can choose to use either registry or both. There’s a bit of a misstatement of the situation in RFC-7020, unfortunately.

Owen
(Who has some experience with RIR policy processes)

[John_Curran1]

Folks -

(I’ve changed the subject to keep this part of the thread separate - but it would be nice if others more clueful than myself in such matters addressed Pirawat’s actual questions regarding DNS zone and redirection monitoring…)

Regarding IP address blocks, I’m going to provide the simple view that ARIN takes on this, recognizing that we’re not dealing in an area that is clearly established and thus others may have their own views.

To answer what it means to “own an IP address block”, it is first necessary to make some assumption about what an “IP address block” really _is_ – in the case of ARIN, we consider an IP address block to be an entry in the ARIN registry database, and we issue blocks by granting of specific rights to those entries to the resource holder.

When you are issued a block, your organization is associated in the database with that particular IP block entry and you receive a set of contractual rights (right to be exclusively associated with, right to use/update it in the database, and right to transfer in accordance with policy) as per the ARIN RSA. If you “own” an IP address block then you’ve got that bundle of contractual rights that you control, but they are not exclusive - those same entries are subject to other rights - such community’s right to publish portions publicly, to add fields (e.g. abuse contact), etc. that ARIN administers on behalf of the community. (ARIN also works with the other RIRs so that you uniqueness in the ARIN registry translates to uniqueness in the overall Internet number registry system.)

ARIN is the successor operator of the registry database for the region, and we also recognize that some organizations have obtained assignments of similar bundles of rights via implied contract under which recipients desired to cooperate in (and gain the benefits of coordination from) the Internet Number Registry system in the period before ARIN’s administration of the database. ARIN provides such parties (“legacy resource holders”) and their legal successors with the opportunity to formalize their rights (if they wish) via entry into ARIN's registration services agreement.

We have many cases where the rights to specific blocks have been treated as “property” of an estate during bankruptcy or probate proceedings, and this should be no surprise - contractual rights have value and as such can be considered part of an estate and transferred accordingly. It is worth noting that ARIN spends a bit of time engaging to make sure that community policy is followed regarding such transfers and to date we have never had to update ARIN’s database without adherence to our policies and entry into an RSA by the recipient.

If you think that the “IP address blocks” that you were issued are reflected by the listing of your organization on that entry in the ARIN database, then all of the description above makes sense. There are some other theories out there about what constitutes an “IP address block” – I’ve heard all manner of theories including 'rights to integers’, 'reservations in routing tables’, and pretty much everything in between. Diversity of views is a wonderful thing, but I would advise some caution if someone offers to sell such ephemerally defined “IP address blocks” to you – good luck, but remember that they don’t involve the ARIN database or its entries and one might find them somewhat lacking as a result...

Best wishes (and stay safe!)
/John

John Curran
President and CEO
American Registry for Internet Numbers

[Anne_Mitchell]

John, what an incredibly clear explanation! Thank you for taking the time!

Anne

[Valdis_Kletnieks]

1. How-to monitor whether some outsiders are putting our IP addresses into
their A/AAAA records without me knowing about it?

So some bozo sticks an entry in their DNS that says

bozo-entry.example.com A your.ip.address.here

Who cares? What problem does this cause?

You'd never even know it unless somebody/something actually *uses*
the DNS record - which will result in traffic to the address. And at that
point, you usually don't care what DNS entry was used, except for the
case of a webserver serving multiple names and using different TLS
certificates for each name.

2. How-to monitor whether some outside websites are just ‘shells’, with
contents actually being hosted by our servers without me knowing about it?

Again - what actual problem are you trying to solve here? If you're being used
as a cache or backend site and don't know it, you have *bigger* problems.

[Tim_Franklin]

That's my reading of it - the web admin team are not trusted, and Pirawat / the network team are being asked to police them and make sure they're not running some kind of side business off the company equipment.

Which is going to need some kind of WAF, reverse proxy, load-balancer, or similar in front of the web stuff, operated by the network team. Tech fix for an org problem.

Regards,
Tim.

[Karl_Auer]

Maybe I missed something (the subject line makes me suspect I did) but
I shall press on regardless, in the best traditions of the Internet

There is no technical difference between a web server being misused as
described and a web server being used correctly.

WAF, reverse proxies, load balancers and so on are really for
protecting a web server against clients, not for preventing a web
server from serving whatever content it has. Trying to use the tools
mentioned to control outbound content would be a very frustrating game
of whack-a-mole.

You could block inappropriate inbound requests, but not knowing what is
on the web servers makes that an infinite set of possibilities. So you
would really have to permit only appropriate inbound requests. On
anything but a trivial server the set of appropriate inbound requests
could be very, very large. Not to mention that rewrite rules and
suchlike could be blurring the difference between appropriate and
inappropriate on a web server where the configuration is possibly in
the hands of the bad guys.

If the web admin team is not trusted to properly control what content
is *on the web servers*, then no amount of tech can help you. You need
a trusted team inserted between them and the web servers, and that team
needs to inspect the content, curate it, and vet anything new. That
team will VERY quickly detect malfeasance.

Bear in mind also that there are quite a few attacks that end up
leaving cuckoos in the nest; warez or worse being quietly served up
alongside legitimate info. What I'm saying is that misuse as described
can sometimes be more about incompetence and underfunding than about
malfeasance.

Hope I didn't completely miss the point

Regards, K.

[Tim_Franklin]

That's a good point - I was thinking solely in terms of the DNS-based / simple vhost stuff, where a client is requesting 'Host: www.badguys.com' from an IP address that "should" only be serving www.mystuff.com.

mystuff.com - This website is for sale! - mystuff Resources and Information. is the obvious and trivial workaround, I'm sure there are much more sophisticated ways to do it.

But we may both be talking about the wrong thing until Pirawat confirms

Regards,
Tim.

[William_Herrin]

Hi Bill,

A WAF is a filtering reverse-web proxy. It can sanitize incoming
requests to obstruct hacking against the web server. It's often used
for TLS offload as well since it must decrypt the traffic anyway. You
give the "real" web server RFC 1918 addresses and put a WAF on the
public IP addresses.

It also tends to break web sockets, so there's a capability penalty if
you use one.

A WAF is the second-best answer to Pirawat's problem since it can
filter web requests which arrive without an acceptable "Host" header,
corresponding to the DNS name the browser used.

The best answer is: don't do that. If you have such little trust for
your web staff, replace them with trustworthy people.

Regards,
Bill Herrin