How often may the he.net API be pulled?

[tlechler]

Hi there,

I just got my sage level finished, was able to unblock IRC. Now almost nothing stops me from going full v6!
except:
I'm on a kind of flaky adsl landline that frequently loses the sync, which results in a connection error. No bigs, just a few seconds of service outage, then everythings fine again. I cant solve the problem since my provider doesnt allow other routers(and yes, I know for a fact that the router is the problem, I just tried it, however I cannot make the switch since my provider hides the VOIP login data from me, so I'd lose my phone landline if I did), and they claim everythings fine. However every time I get a new IPv4, which means I will need to update the tunnel endpoint. normally, I'd say no problem there, I'll just have a */5 cron job that does the job every 5 minutes. However I'm not sure whether HE wont consider that an abuse of their API-server and just ban me from doing this. Since I didnt find their policy on update frequencies using google, I'm asking here:


How often does he.net allow me to update the tunnel endpoint IP?

[kcochran]

Updates don't get pushed unless your IP changes, so it's not too bad.  However, if you're scripting this already, check if your IP has actually changed prior to submitting a change.  Then it's completely not an issue, since you'll only be pushing updates when there's something to update.

[tlechler]

this might be an issue - right now I do this on an hourly basis, and yes, I do check whether current_ip == last_ip, however, on special conditions(heavy rain outside for example) it can happen that I have as much as 300 different ipv4's per 24 hours. I just dont want to be looking like some ass abusing the service.

[kasperd]

it can happen that I have as much as 300 different ipv4's per 24 hours.

That sounds extreme. Have you really observed such frequent changes?

If your IPv4 address has been stable for a while (say an hour or so), then if it changes, it should be perfectly fine to send the update to HE immediately. If you can detect the change without communication outside of your network, there is no reason not to check for changes every minute and push the update as soon as it is detected.

If the IPv4 address keeps changing, you should probably start backing off and not try to update the tunnel on every change. Under such conditions I'd wait until the IPv4 address has been stable for a while before sending the next update. That's for automated changes. Having the ability to manually push the update in such cases at the click of a button would still make sense.

For how long a period the IPv4 address should stay the same before you consider it stable, and how many updates you will perform before you start backing off, depends on what kind of load you can put on the API. Sounds like you are really only using the API when there is an actual change, which means changes being pushed to the tunnel server. I'm not sure how often it is reasonable to push such changes. But I wouldn't push such changes too frequently, at some point pushing the changes will not make your tunnel more stable. I'd make sure the delay between successive updates is large enough to ensure you don't try to push another change before the previous one has taken effect.

Regardless of when you push changes, I think it would be very helpful to yourself, if you keep a log of when the IPv4 address changes.

[tlechler]

Regardless of when you push changes, I think it would be very helpful to yourself, if you keep a log of when the IPv4 address changes.

I'm already doing that since my prover claims everything is alright, and they wont let me change the provider either(24 month minimum contract time), which is why I check my IP using one of my VPS boxes as remote peer, logging every change in a one minute resolution. Somethings not right with my line, and I want them to either acknowledge that and fix it or let me go to another provider that will.

[tlechler]

ok, just a little update from my side, I set this up for now, should be fine with about 7 updates for today.
btw, it'd be nice to have an example script on he.net for updating the tunnel somewhere.
If this comes into consideration, feel free to use the one I just wrote the other day:

Code Select Expand


#!/bin/sh
new=$(wget -qO - http://v4.tecnode.org/ip.php)
old=$(cat /tmp/old.txt)
if [ "$new" == "$old" ]
then
 echo no need to change tunnel IP
else
 wget -qO - "http://ipv4.tunnelbroker.net/ipv4_end.php?ip=$new&pass=<PASS>&apikey=<USERID>&tid=<TID>"
 echo -n $new > /tmp/old.txt
 echo $(date) - Updated Tunnel Endpoint to $new >> /tmp/update.log
 echo Updated from $old to $new
fi



this will check the current IPv4 and update if it changed. will update the endpoint ip on first start too. I pushed it into my crontab with * * * * *

[kasperd]

Code Select Expand

new=$(wget -qO - http://v4.tecnode.org/ip.php)

You should pipe that through something to ensure it looks like an IPv4 address. Something like

Code Select Expand

wget -qO - http://v4.tecnode.org/ip.php | grep '^[1-9][0-9]*\(\.[0-9]\+\)\{3\}$' | head -1Without that, who knows what sort of injection attacks you'd be vulnerable to? Additionally check that the string is not empty before you do anything else. If the first wget command fails you don't want to execute the lines to update the IP.

You are also sending the update URL in cleartext. It is a bit safer to use SSL, even if it doesn't have a proper certificate.

If you are paranoid you should also think about where you store your files. Predictable names in /tmp is a threat, since another user could create it first and possibly link it to something you did not want to be overwritten.

[tlechler]

hey, as for the first wget, I operate that server, so unless I'm going to inject myself, I'm safe. I also operate the dns for the domain :-)
as for checking whether its empty or not, my busybox wget is modified so it will abort the script, but in general, yes, you're right.

For sending the URL in cleartext, that is because its running on an openwrt box that didnt have enough space to get a wget with ssl support on it.

/tmp was the choice because it's a singleuser system and /tmp is the only volatile(tmpfs) fs in the system. if the box is compromised, I'll have other problems(like a stolen md5 of my pass [sha/salted sha would be nice here as an option]).

I was just posting this here, because I believe something like this should be on the setup examples page on the tunnelbroker.net account menu.

[kasperd]

I operate that server, so unless I'm going to inject myself

Previously you said that you don't operate the link between your gateway and the server yourself, so there is still a possibility for some network operator to inject something or leave a security vulnerability open that would let anybody inject. And there is the possibility of DNS poisoning. And this is probably not a complete list of ways somebody could modify that http stream.

/tmp was the choice because it's a singleuser system

That's why I pointed out that specific precaution is only important for the paranoid. If you check what you have running on that box, you'll probably find something which has switched to run as unprivileged user just in case. That way to compromise the box somebody have to first find a vulnerability to compromise some service they could communicate with, and next they need to find a local exploit to escalate privileges. If you are paranoid about the security, you don't leave one hole open just because you know it takes two holes to exploit it.