That was only an exaple range. I realize that they are supposidly private ranges, however they will sometimes resolve, or are spoofed.

For instance I run a trace route on 10.0.0.1 and i get something such as:


1 15 ms 15 ms 15 ms 66.13.200.101
2 15 ms 16 ms 15 ms 4.24.46.181
3 15 ms 15 ms 16 ms 10.0.0.1

Athough these are trusted servers for the most part, I do not want to give IANA any escalated privledges. Pranoid? maybe... but better safe than sorry.

For this reason I wanted to have the server check to see if the request was received via the local area NIC or the NIC with the internet connection.
avitar.net

I would never trust any IP address in the private ranges. You might have someone elses network

You are assuming that the server has two NICs, one on a private LAN, and another on the Internet connections. This is a rare configuration. Also, it is fairly hard to determine which interface the connection came from. You can look at the incoming IP address. It isn't that reliable for scurity.

It is better to look at the remote IP address. This can be spoofed and isn't very good security. But if you are looking at the IP address for trust, you aren't interested in good security.

The situation I am picturing is an internet sharing situation where you have machines on a wire to the machine with two NICs. One NIC is for the ether, and the other is for the internet. Using Net::CIDR and to test if it is contained on one of these networks should still work. When you are tracerouting to 10.0.0.1, you could be going out of the Internet NIC, as the lowest eth* will be chosen if not specified, so keep that in consideration.
If the situation is what i think it is, then those machine have one NIC and are on an internal network, that the box in question is directly connected to, so they have no choice but to be on the same network.
amt.

perlcheat

For this reason I wanted to have the server check to see if the request was received via the local area NIC or the NIC with the internet connection.

Can't be done using perl. The best you can do is look at the IPs.

I suggest creating a whitelist of all the "trusted" IPs as a bunch of CIDR blocks (using Net::CIDR as someone else suggested), then checking connections against that.

I have a local intranet that will not require an extensive logon, but if you are accessing it via the internet, it will require a more though logon proceder as per my bosses request.

This isn't really answering your question, but I can't help wondering if Perl is the right place to be solving this problem. When you talk of an intranet, I assume you are talking about a web server. If you are talking about a web server, chances are good you're talking about Apache.

In this case, you just want to set your server up so that it's unauthenticated for local addresses, but authenticated for everyone else. Other web servers offer similar functionality

<Location /foo>
  Order deny,allow
  Satisfy any
  AuthType Basic
  AuthName $realm
  AuthGroupFile /usr/local/www/auth/groups
  AuthUserFile  /usr/local/www/auth/users

  Allow from 192.168.0.0/24
  Require valid-user
  # or whatever, e.g. require group foo
  Deny from all
</Location>
[download]

Apache plug-ins exist to let you authenticate against an LDAP server, or a database or other such repositories.

In other words, let Apache worry about authentication, because it's good at doing that; this will simplify your Perl code.

I was wondering if you could do in through Apache by <Listen>ing on both the external and internal IP then set up a virtual host for each ip address. Add Apache auth to the external host.

Listen xxx.xxx.xxx.xxx:80
Listen 192.168.xxx.xxx:80

<VirtualHost xxx.xxx.xxx.xxx:80>
   <Location />
      AuthType Basic
      ...
   </Location>
</VirtualHost>

<VirtualHost 192.168.xxx.xxx:80>
   <Location />
      #AuthType Basic
      ...
   </Location>
</VirtualHost>
[download]

(untested and refers to Apache 2.0)

Using virtual hosts to bypass authentication is not really a good idea as it solely relies on the assumption that someone outside won't know the internal vhost name. And as (AFAIK) this only needs to be send in the HTTP header it would make it very easy to manipulate (an attacker would only have to change his hosts file).
Update: Silly me, above example isn't about name-based vhosts...

Which makes matters worse is that it is also a NAT box with DNS and DHCP in it for the local intranet.