December 27th, 2001, 08:28 PM
Internet Protocol Addressing
Greetings everyone. Today class, we're going to discuss IP Addresses, IP Address allocation, CIDR Allocation, Loopback,Private networks,Name resolution, and various other subjects dealing with Internet Protocol Addresses. Yes, this is another copy and past article but before you decide to post something irrelevant to security or send the flames, keep in mind that I am trying to help the members and Guest of AO and I did show the Source.
Internet Protocol Addressing
Each machine connected to an IP network (such as the Internet) is addressed using a unique 32 bit number, the IP address.
Many machines will have more than one IP address - for example a machine running virtual websites will have an IP address for each website they host.
Other times a pool of IP addresses is shared between a number of machines - eg on a dynamic-IP dialup connection your machine will be allocated a different IP address each time you connect.
These addresses are usually written in Dotted Quad notation, as a series of four 8 bit numbers, written in decimal and separated by periods. For example 126.96.36.199
Each number is in the range 0 to 255 - so if you ever see something that looks like an IP address with numbers outside those ranges it's not a real address.
The leftmost number is the most significant, and the rightmost the least.
So 188.8.131.52 and 184.108.40.206 are right next-door to each other whilst 220.127.116.11 and 18.104.22.168 are completely unrelated.
IP Address allocation
Traditionally IP addresses were allocated to companies and ISPs in blocks.
A Class A Address Block or, less formally, an A Block is a block of 16,000,000 or so (2^24) addresses from X.0.0.0 to X.255.255.255, where 0 < X < 127.
So the entire 22.214.171.124 - 126.96.36.199 range of addresses is the A Block owned by IBM.
A B Block is a block of 65,000 or so (2^16) addresses from X.Y.0.0 to X.Y.255.255, where 127 < X < 192 and 0 <= Y < 256
A C Block is a block of 256 addresses from X.Y.Z.0 to X.Y.Z.255 where 191 < X < 224, 0 <= Y,Z <256
(There are also D and E class addresses allocated in the 224-255 range - these are reserved for multicast and experimental applications - you'll never see them in practice)
Traditional blocks are often described using the first address in the block, eg IBM own A Block 188.8.131.52 and Cyberpromo own C Block 184.108.40.206. Other times they may be described using just the constant prefix, eg net 9 for IBM or net 205.199.2 for CyberPromo
[You'll often hear any address range from X.Y.Z.0 to X.Y.Z.255 called a C Block, even though it technically isn't unless 191 < X < 224]
Recently things have changed. IP addresses are in short supply and routers have become more sophisticated, so it's now usual to allocate blocks of addresses on pretty much any bit boundary. You'll often see blocks of 64 addresses for instance, such as 220.127.116.11 to 18.104.22.168
A common way of naming these blocks is CIDR syntax, this is the initial constant prefix and the length in bits.
So 22.214.171.124 to 126.96.36.199 might be described as 151.196.75/24
and 188.8.131.52 to 184.108.40.206 might be described as 220.127.116.11/26
[It's difficult to filter out addresses on arbitrary bit boundaries using sendmail so you'll sometimes hear talk about the /26 problem. This is when someone is spamming from, for example, 18.104.22.168/26 (22.214.171.124 to 126.96.36.199). It's then difficult to block the spammers without also blocking any legitimate users in the surrounding blocks 188.8.131.52/26, 184.108.40.206/26 and 220.127.116.11/26]
But who's in charge of this address block?
To find out who administers a block of addresses you can use whois to query the internic database. This is sometimes wildly out of date, but can be a good start. Sometimes it'll tell you that the block is administered by RIPE or APNIC (the European and Asia-Pacific registries) in which case you can try whois at those registries instead to find the real owner.
[To access RIPE you can use whois -h whois.ripe.net x.y.z.0 or whois email@example.com, depending on your whois command. APNIC are at whois.apnic.net and Internic are at whois.internic.net]
So whois 18.104.22.168 will give you information on IBM and whois 22.214.171.124 will point you at Bell Atlantic.
There are some special ranges of addresses reserved for special uses.
The 127.*.*.* block is reserved for local loopback - so these addresses will always point back to your own machine.
The canonical loopback address is 127.0.0.1
Some blocks of addresses are allocated for private networks - packets from these machines should be dropped by most routers. Why is this useful? If you want to setup a private network you don't need to use up any of the scarce allocation of 'real' IP addresses. So you need to make up your own addressing scheme to use internally.
As long as you're not connected to the internet in any way you could use any scheme you wanted. But what if you have a gateway machine that lets you e.g. send mail to and from the internet? If you chose an arbitrary IP address range for your local network and the packets leaked through the gateway onto the internet they'd end up going to the Real owner of those addresses, probably fubaring their system and provkoking stern 'phone calls.
This has happened, even within huge multinational corporations who didn't follow the rules and chose arbitrary addresses for their internal network.
So there are ranges of addresses allocated as private addresses. You can use these quite safely, as everyone's routers are told to just throw packets to or from these addresses away. So if your packets escape they'll be deleted.
These private address blocks are:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
If you see one of these addresses in a received line it means the email has been forwarded around an internal network before being gatewayed to the internet proper.
So far, so froody.
There are some IP addresses in each block reserved for broadcast and other obscure stuff. Check the RFCs if you're really interested.
Email to an IP address
Incidentally, if you want to send email to a machine and you know the machines IP address you can send it to user@[w.x.y.z]
So, just for the sake of example, if you were to put this HTML tag:
in a web page, and someone were to scan your webpage for email addresses and then try to send spam to them they'd end up sending a copy to postmaster at the machine 127.0.0.1. As we said earlier 127.0.0.1 is always your own machine, so this would make the spammer spam their own system administrator....
IP addresses work pretty well, but they're not as memorable as machine names. So we need some way to map names to addresses (and ideally back again).
The old, easy way to do this is with a hosts file. These are a unix-ism really, but exactly the same format is used on most Windows and OS/2 systems, thankfully.
Where is it?
On unix: /etc/hosts
On Windows 95: \windows\hosts
On Windows NT4: \winnt\system32\drivers\etc\hosts
On OS/2: \MPTN\ETC\hosts (depending on your ETC environment variable)
What does it look like?
On my local network I have three machines:
penfold at address 192.168.1.1
dangermouse at address 192.168.1.2
taz at address 192.168.1.4
(the perceptive amongst you will have spotted that these are private addresses - yep, it's a private network with penfold as the gateway. But that's not important right now...)
So on all three machines (one runs Linux, the others boot between 95,NT & Linux) the hosts file looks like this:
# hosts This file describes a number of hostname-to-address
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
# On small systems, this file can be used instead of a
# "named" name server. Just add the names, addresses
# and any aliases to this file...
# For loopbacking.
192.168.1.1 penfold.blighty.com penfold
192.168.1.2 dangermouse.blighty.com dangermouse
192.168.1.4 taz.blighty.com taz
Anything beginning with a '#' is a comment.
The format is an IP address, followed by a list of hostnames.
If I want to connect to penfold I can use any of
..they're all equivalent.
This is fine for a network of a few hosts, but for anything bigger you need a more distributed system...
Domain Name Service
DNS is a distributed system. The end user doesn't really care about this, but in case you're interested here's how it works.
You try and access http://www.blighty.com. Netscape wakes up and asks Windows what IP address www.blighty.com maps to.
Windows then sends a request to your local nameserver, usually the nameserver of your ISP. If someone else has looked up the address recently the nameserver might already know the answer. If not it realizes that it doesn't know, and works out who might know.
Your ISPs nameserver then contacts that nameserver - if it knows it answers. If not, it works out who might know.... you get the idea.
Finally the result gets forwarded back to your local nameserver, which caches the result so it can use it again later and passes the answer back to your system - 126.96.36.199.
[In reality it's a bit more formal than that, with 'zones of authority' rather than guesswork to find out who might know the answer]
Some systems check the hosts file first, and only if that fails will they try DNS. This is the useful way to do things. Others check DNS first, and only check the hosts file if DNS fails.
Linux, Windows 95 & Windows NT check the hosts file first.
OS/2 systems check DNS first unless SET USE_HOSTS_FIRST=1 is set in config.sys (or you do the equivalent in the Hostnames page of the TCP/IP configuration notebook)
Other unix systems may do it either way, depending on how they're configured. Some may even have different applications using different policies.
If you want to query your DNS server directly you can use the nslookup command (under NT and unix at least)
There are a lot of more powerful tools for unix, including host and dig. DNS can tell you a lot more than name->address mappings if you ask it nicely.
There are freeware nslookup tools for Win95 too.
Cyberkit by Luc Neijens is a nice ping / nslookup / traceroute / whois tool. http://www.ping.be/user/Luc.Neijens/. It's postcardware.
Sam Spade/Personal is my version. http://www.blighty.com/products/spade/. It's freeware. It does a lot more (dig, port probing, SMTP relay checking...), but is only an alpha release at the moment, so tends to crash occasionally.....
There are also versions available on the web
Get That Spammer
DNS Query Tools
Finding the hostname given the IP address is very useful. If you're tracing spam you need the domainname to be able to find whois information.
So you just need to do an 'nslookup w.x.y.z', right?
*** penfold can't find 188.8.131.52: Non-existent domain
Just because a host has forward DNS from name to address there's no guarantee or requirement for it to have reverse DNS from address to name. Many sites do, many sites don't.
[Note: Some nslookups don't accept reverse lookup on the command line. If you get caught with a braindead tool and need to do a reverse lookup you can do this: nslookup z.y.x.w.in-addr.arpa will do a reverse DNS lookup for address w.x.y.z. Don't ask...]
If there's no reverse DNS you need to resort to guerrilla approaches. If there's a web site that's a good bet. Do a view source to look at the HTML source, particularly for forms and mailto links.
Sometimes telnetting to the machine will give a banner identifying the machine. Or telnetting to other ports on the machine (25, 110, 119) can sometimes give a banner. Then you can use forward DNS to confirm that the address maps back to the right IP.
A port-scan tool can scan a range of ports on a machine, to see which are providing services. Then you can telnet to each one in turn to see if any leak information.
What if the site is being coy, and trying to hide their domainname? Most virtual web-hosting companies require customers to have a domain name, but if it's not used anywhere and the website is advertised using it's IP address rather than domain name it's hard to find.
On some virtual web servers accessing http://w.x.y.z/stats or http://w.x.y.z/logs triggers a redirect that can give you the name.
DNS has all sorts of good stuff in it, not just the address-name mappings. Under unix you can get at this with dig, the Domain Internet Groper.
dig [@nameserver] domain [query]
This will ask the DNS server nameserver (by default your default nameserver) about domain asking for records of type query (by default A)
These are some of the things you can ask about:
The Address of a hostname. There's only one A record for each host.
The authoritative nameserver for a domain
The mail exchanger for the domain. For example, there is no such machine as demon.net, yet you can send email to firstname.lastname@example.org. The MX record tells the mail system to send mail for email@example.com to firstname.lastname@example.org instead.
An alias for a machine. A number of different names may resolve to the same IP address. A CNAME entry for a domain points you at the real name of the system.
Hardware and software used by the host
The responsible person for a domain
All records available
Request a zone transfer
There are around 40 more, but these are the most common.
AXFR is useful - it asks the nameserver to send you all the records it has for a domain. If there's no reverse DNS setup this can be the only way of getting a full list of the machines within a domain. You can only do a zone transfer from the name server that is authoritative for a domain - you can do an NS query at your local nameserver to find out where that is.
Dig is part of the Bind package, standard on most unix systems. There is allegedly a version for Windows NT available. The only tool I know of that allows interrogation of DNS servers from Windows 95 is Sam Spade/Personal but there may be others.
Name resolution games
If your system checks the hosts file first you can do things like banner killing: If you add
to your hosts file all references to ad.doubleclick.net will be sent to 127.0.0.1 rather than the real machine.
So when you hit a page with a doubleclick banner it'll try and load the banner from http://ad.doubleclick.net/yadda/yadda/yadda.cgi netscape really tries to load from http://127.0.0.1/yadda/yadda/yadda.cgi.
127.0.0.1 is your local machine, so netscape will try and connect to your local machine to get the banner cgi script, animated gif, cookies and all. But your machine isn't running a web server, so it'll fail instantly without using up any of your precious dialup bandwidth.
Bingo, no banners. Of course advertisers can get around this the same way spammers do, by using IP addresses in the html source.
[Don't do this for all advertising. All these cool free services on the web are funded by advertising. If you use a free web site make a point of clicking on a few banner ads occasionally. Reserve banner blocking for the more obnoxious cookie spewing domains such as ad.doubleclick.net and ad.preferences.com]
What other games can we play. Well, if you run a nameserver you can add name->address mappings for any arbitrary address. So if I run the DNS for wugga.com I could add things like
If somebody tried to send email to email@example.com it would try and send it to user on their local machine.
If someone tried to send email to firstname.lastname@example.org it would be sent to email@example.com instead (184.108.40.206 is the mail exchanger for agis.net).
Unlike the [127.0.0.1] hack it's very hard to filter these out of email address lists, so salting web-pages and usenet posts with references to firstname.lastname@example.org would ensure the local sysadmin at a spammers site will be notified.
(Note: wugga.com doesn't exist.)
A More Technical Tutorial
A Good DNS Over View
LOTS of DNS Resources
Linux DNS HowTo
TCP/IP Netwerk Administration
DNS And BIND
Essential Windows NT System Administration
Linux Networking Administrator's Guide
Hope This Helps,
December 27th, 2001, 08:51 PM
I think it is a great thing to have people posting information that belongs on a site like this. I do believe that it would be more interesting if you would put it in your own words. Pasting tables and raw data is fine (hell, even I am to lazy to type that much) but the rest would be more easily understood if explained in local geek instead of textbook. Most of us have already read the books and are looking for personal views on technology and things like that. But thanks for the time and effort applied. I thought it was really informative. Maybe next time we jump into OSPF, EIGRP, or BGP? Hey! That gives me something to write about! (Long day at work )