Second Life's IP Address Range

I'm attempting to secure a web application while still allowing requests to be made from objects in Second Life.

What would be the best way to do this? I was going to restrict the web app to only allow requests from the IP address ranges that SL uses, but SL is not making that data available. I found an article on the subnet masks that SL is using (https://support.secondlife.com/ics/support/security.asp?task=knowledge&questionID=5098), but in all truth, I'm not too sure how subnets even come into the picture (what those are, really).

So 1) how can the web app be sure that the specified objects are the only things able to get requests through (I can register them on the web app upon creation)? Is there a key that ONLY the owner of that object can get to other than the public one? One that can be sent to the web app, and then along with future HTTP requests that cannot be sniffed? Is HTTPS possible? Are POST requests possible?

Sorry for the overgeneralized question, but I'm just having the hardest time figuring this one out. Thanks!!

See http://wiki.secondlife.com/wiki/Simulator_IP_Addresses and note that 64.129.44.0/22 is not listed there, but IS listed in the knowledge base question linked to from that page (I've included it as well--I believe because I've seen legitimate requests from that range). Subnet refers to the set of IP addresses in the range, as indicated by the subnet mask. In the notation used on the referenced page, the suffix "/22" indicates that the first 22 bits of the IP address must match for an IP address to be considered in the range or subnet identified (e.g. "8.2.32.0/22" has a subnet mask of 255.255.252.0 and represents an address range of 8.2.32.0 to 8.2.35.255). Keep in mind that each number in the IP address/range is 8 bits of data represented in decimal (0 to 255 rather than 00000000b to 11111111b or 00h to FFh).

For information about protocol (HTTPS), HTTP method (POST), and useful HTTP request headers that might prove useful after you've verified the source of the request, see http://www.lslwiki.net/lslwiki/wakka.php?wakka=llHTTPRequest

There are two parts to every IP address, the network address, and the host address. Depending on the Network class A,B,C, etc, determines how many bits are the network address, and the host address. A simple example would be Google's IP address. I did a quick trace to google, and it bounced back, 24.28.193.9, which is a class A address. In a class A address, the first byte is the network address, and the other 3 are host addresses. N.H.H.H like so. Therefore, the network address is 24.0.0.0 (that's not a valid IP address, it's a network address). and the range is 24.0.0.1 to 24.255.255.254 (with 24.255.255.255 being the broadcast address). Subnet masks are a series of 1's and 0's, that, when logically AND'd with the IP address, will spit out the host address. typically, there a number of 1's on the left, and a number of zero's on the right, but that doesnt have to be the case, but usually is because calculating the various subnets gets to be a nightmare if not. So, a simple subnet mask for the class A network 255.0.0.0, or 11111111.00000000.00000000.00000000. When AND'd with 24.28.193.9, it would produce 24.0.0.0, which would be the network that it's on.

Considering how big of a network SL is, it's most certainly spread out over various network address ranges, and since SL doesnt publish this information freely, you have alot of hacking to do..lol

I did this by checking the CLIENT making the request.. and only accepted requests from SL client... not other web browsers..

That is NOT SECURE in any way, shape, or form. It is easy to spoof the client ID string in the request header, either with a proxy, or through the web browser itself (some browsers allow you to specify a custom ID string for some websites).

Besides, the OP is talking about objects (ie, SL Server via llHTTPRequest) talking to his web app, not the SL viewer.

To the OP:

https is possible, but you should use a valid SSL certificate for your web server, though you don't have to.

The best way to authenticate requests from in-world objects is to use MD5 to sign them. Make sure your request parameters are sufficiently large to begin with (>64 characters, if possible), and then incorporate a long secret key string into them temporarily, llMD5String the result, and append the resultant digest to the original request parameter string, sans the secret key, then make the request. Your web app then has to do the same thing. Remove and hold the digest in a temp var. Incorporate the exact same key the exact same way, MD5 the result, then compare the two digests. If they differ, discard the request, or return an empty response or error message. Otherwise, process the request as a valid one. As long as the key strings remain secret, the system is secure.

Some will point out that MD5 has some weaknesses. While it is possible that someone could theoretically determine the secret key through cryptanalysis, 1) there would have to be a fairly strong motivation to bother, as it isn't trivial, 2) they would have to intercept enough authenticated requests between the SL object(s) and your web server to be used as inputs to the cryptanalysis process. Thus, it is likely to be easier to try and break into your webserver, or exploit the SL permissions system to read your scripts to get the secret key.

If you want to feel a bit safer, most folks recommend using multiple MD5 passes using different secret keys each time. Two is usually sufficient, but the only real limit is the time required per request. The more you do, the slower it gets.

Here's a list of IPs/hostnames making requests to w-hat.com in the past two weeks claiming to be "Second Life LSL":
http://w-hat.com/simips.txt

All the 'faked' requests identify as "Second Life LSL/1.19.0(12345) (http://secondlife.com)" and only make name2key requests which aren't restricted anyway. I'm pretty sure they're just from LSL-Editor.

Here's the code w-hat.com uses to determine if requests are really from SL:
http://w-hat.com/application_controller.html

It's not at all clear what restricting to IP addresses owned by LL buys you. It's still possible for a malicious attacker to create their own object in SL to get at your server. I suppose it could help against external denial of service attacks, since filtering by IP address can be done much more quickly than cryptographic authentication. But you still need to make sure it's just your objects that have access.

So follow Talarus's advice about using MD5 and a long secret key.

What it buys you is some assurance that you can trust the custom HTTP headers added by the LSL library to HTTP requests made from LSL scripts. Meaning, you can be somewhat sure that the request is being made from a script in an object owned by a resident identified by the "X-SecondLife-Owner-Key" header. It's still good to include other security checks (such as the hash signature), but it is a nice check to have in there as a first step.

Noticed something about class A etc. IP addresses, don't try to use those to identify things because classes were abandoned in favor of CIDR some years ago. A and B tied up too many unused addresses, IPv6 was (and still is) taking forever to be adopted, so something have to give.

I try to keep the wiki article up to date.

The range "64.129.44.0/22" isn't explicitly mentioned because it is a subset of "64.129.40.0/21". You will see in the article that they have both "64.129.40.0/22" and "64.129.44.0/22" listed. I contacted them about this last year but nothing ever came of it.

@Masakazu: That sounds correct, LSLEditor does Name2Key so that it can have accurate information for when it generates detect and listen events (and various other functions). For ease of use it lets you enter your account name it then looks up the UUID and automatically fills it in.

EDIT: There are a few very small ranges owned by LL (8 addresses size blocks) that I believe are for remote access to the colo's but considering that there are no good uses for that information I didn't think I needed to replicate it.

Ah, okay. Cool. And thank you Strife. I think that page has to be the absolute most valuable resource there is for advance scripting. Absolutely vital info.