Tunnelling NTP Through a Firewall?
Franklin_DeMatto asks: "My ISP keeps my server behind a tight firewall, only allowing outgoing HTTP(S) and SMTP. I would like to sync the system's clock using NTP. Does anyone know of any public time servers that can do some type of NTP over HTTP, to get through the firewall? What about the software (preferably open source) to do it? (No, the ISP will not change the firewall rules.)"
How about finding another ISP (and telling them WHY you are changing to someone else too).
D.
You can tell how powerful someone is by the magnitude of the crime they can commit and be able to get away with.
Do you have a shell account on the box? I assume so otherwise you wouldn't be able to install NTP even without a firewall. If you have a shell account, they probably allow ssh through the firewall and so you can tunnel the NTP ports over SSH. This assumes you have another machine outside the firewall that has access to NTP and an 'always-on' connection.
Rich
I forget where I learned this tip, but it's useful and doesn't seem widely known: many routers provide NTP service. So you can do a traceroute from your server out to anywhere (say google.com) and get a list of upstream routers. Don't forget to try the "-I" option (or whatever the equiv is in your version of traceroute) to use ICMP instead of the default UDP datagrams if your firewall is blocking those.
If/once you have a list of routers, try time syncing against them. It's worth a shot.
-h3
I am sorry, but the only reasonable advice I can give you is to change your ISP if they do not open more ports. You have only outgoing HTTP and SMTP? What about SSH? What about FTP? What about Telnet? What about IRC? Are you also going to tunnel them through HTTP? HTTP is a stateless and sessionless protocol. It is extremely bad idea to tunnel anything which uses long and interactive two-way TCP traffic (like IRC, SSH, FTP, Telnet, ...) using HTTP.
Not only it is technically bad idea,
you also compromise the firewall security if you use covert channels to hide all the forbidden traffic. The firewall rules to not allow
insecure (in the opinion of firewall management team) protocols traffic are ruined when their
users want to consciously
compromise the security.
We all know that using SSH or NTP is not insecure in itself, but when everyone tunnels everything bastardizing HTTP protocol, no one will ever notice when some day there is Back Orifice traffic hidden there between NTP, SSH, Telnet, FTP, IRC, et cetera.
So my advice is: talk to your ISP.
Tell them why you need NTP for security reasons (to have your logs useful).
Tell them what do you want them to change.
It is you,
who are paying them,
for the love of God, not the other way around.
Nothing will ever change unless people start
saying what do they want to be changed.
~Christopher Doopov
Someone told me a time ago that Tardis can do ntp-over-http.
Read Why TCP Over TCP Is A Bad Idea by Olaf Titz:
Very interesting read.
root@aio:~# nmap -sX -iR -p1- # Ho, ho, ho! Merry Xmas, everyone!
You can plug a GPS handset into the serial port and get the time off that.
All things in moderation; including moderation
If I was stuck, behind a firewall that blocked NTP, I would look into using clockspeed to keep the time accurate without constantly resetting to an external source.
You would have to get clockspeed 3 or 4 deltas from another clock over the first few months you use it, but you might be able to borrow a laptop, sync it with a good clock, and use it as a local ntp server to obtain these few deltas to calibrate your system. (with a very short time between when the laptop was synced, and when clockspeed gets it's delta from the laptop).
depending on their proxy of course, but I've had very good luck escaping corporate fire walls with the HTTP CONNECT method.
( echo CONNECT 127.0.0.1:13 HTTP/1.0; echo ) | nc firewall 8000
will print out the time on firewall. Using a similar method and maybe a couple fifos, you should be able to put anything through that firewall.
This is the method that I use to layer VNC over SSH over SSL/HTTP through the firewall back to my home office from all my client locations.
Joe
Joe Batt Solid Design
That is, what about their own internal servers? What about the rest of the servers they host? Do they not have ANY of them that are syncing up to an NTP source somewhere?
/can't switch ISPs, this alternative may be (somewhat) practical -- it depends on how much you trust your ISP to have their NTP server set up properly...
Try asking the ISP if they have an internal NTP server you could sync against, one that itself is properly synced to a reliable source. If you don't want to
As an ISP Asst Admin, I would have to agree with the others. There is no legitimate reason they should block the NTP port from you. I understand why they are so strict though, it's probably to help keep the P2P down from within their network. Move to another ISP, or you can do this. Get a buddy with a *nix machine on the outside to setup an SSH server on port 80, then run the ssh client to connect to the server on port 80 or 25 or 110. Then have your NTP loopback to itself and SSH will forward it to the other machine, and have him run NTPserv, then you can do it..... ---but, it would just be easier to move to a different ISP.
You could also purchase a GPS clock like one on this list.
The last option is to find another ISP who will offer time services, or one that will let you find them where you want.
None of those are UDP (which is what you really want in order to run NTP), otherwise I'd suggest just running your own ntpd on a non-standard port somewhere. Maybe the ISP can be persuaded to operate their own timeserver behind the firewall (which they may be persuaded to do, since it's much better for security/audit purposes if all machines have accurate clocks), or allow access to one specific host. GPS has already been mentioned, though possibly it would be difficult to get a reliable signal in some server rooms without an external antenna. Other radio-based options are available, for example MSF in the UK, DCF in much of W.Europe, or WWVB in N.America, all of which are a bit more likely to penetrate a server room than GPS. Failing that, you could periodically connect to a webpage you trust to have fairly reliable time (obviously this is a much less accurate method, you probably wouldn't want to use this if you need accuracy better than a couple of seconds). Or assuming the firewall only looks at port numbers and doesn't inspect traffic, you could ssh out on e.g. the https port, and forward onto a normal time server.
If you can run perl scripts on the server, grab http://nist.time.gov/timezone.cgi?/d/0, where the 0 is the timezone offset (-5 for Eastern US time), then parse the time and date out of that. Once you have those values, use the date and clock functions to set your system time.