Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Time Syncing Through a Firewall Without NTP?

Cliff posted more than 9 years ago | from the route-around-the-problem dept.

Networking 112

dvdsmith asks: "Say are dealing with a Windows network that for internet access must pass through a firewall that you have no control over. Said firewall apparently blocks the known time protocols (NTP,daytime,etc) and you know from experience that those who control it will not allow any exceptions. If one sets up an internal NTP server (Windows XP or 2000 workstation) for all others to sync from, is there another reliable method for updating time on the server, like pulling from a Java website? See the time.gov website as an example. Any ideas?"

Sorry! There are no comments related to the filter you selected.

COOKING WEB SERVICES WITH ELZAR (5, Funny)

captnitro (160231) | more than 9 years ago | (#13204465)

Of course, your most important ingredient is this baby right here: the external web service. You can get it in a can but to really do things right, you gotta strangle yourself a fresh one.

We're going to sync with our outside web service using a simple SOAP client, written in whatever language you prefer, and setting the time. (Your users will get their time from you via NTP still, of course.) This isn't required, but for that fresh BAM! taste, it's recommended. Mind the delay calculations if you're writing the client side of it yourself [php.net] , the WWWait will have a little bit more effect here depending on your setup. If you want to make it quick and dirty, there's no reason to go through the SOAP/WSDL hoops, the point is having it on a known port and piggybacking across HTTP's fame and success, and then sleeping with its girlfriend, and stealing her wallet on the way out. BAM!

Re:COOKING WEB SERVICES WITH ELZAR (2, Insightful)

Anonymous Coward | more than 9 years ago | (#13205120)

Use SOAP XML bloat to get the current time? Jebus. People in this industry are utterly clueless. How about a 10-line daemon in C that sends the current time as a 64-bit value when you connect to it?? Or can't people program any more unless they use SOAP and PHP???

Re:COOKING WEB SERVICES WITH ELZAR (1)

ctr2sprt (574731) | more than 9 years ago | (#13205753)

You're not going to get a reply that way. Here, let me try:
We're going to sync with our outside web service using a simple SOAP client,
A SOAP client? Interesting!
written in whatever language you prefer, and setting the time. (Your users will get their time from you via NTP still, of course.) This isn't required, but for that fresh BAM! taste, it's recommended. Mind the delay calculations if you're writing the client side of it yourself [php.net], the WWWait will have a little bit more effect here depending on your setup.
Oh yeah, bam it up again, Elzar! Knock it up another notch!
If you want to make it quick and dirty, there's no reason to go through the SOAP/WSDL hoops
Come on, you wimp! Work those web acronyms! Quit holding out on us!

Re:COOKING WEB SERVICES WITH ELZAR (1)

bigberk (547360) | more than 8 years ago | (#13208550)

amen, rdate still works as well now as ever. Trivial server to run too, no security breaches

Re:COOKING WEB SERVICES WITH ELZAR (1)

Guspaz (556486) | more than 8 years ago | (#13208814)

And what port is that C daemon going to listen on? Port 80? What if that is proxied? The only thing that is certain to get through is HTTP traffic.

I'd go for a much simpler approach. It depends on how accurate this needs to be, but find a web server with accurate time (Perhaps a friend has webspace or a dedicated server, or even a home DSL/Cable connection), and put a one-line PHP, Perl, anything, script on it that simply sends the timestamp. Perhaps try to speed things up marginally by removing all but the crucial headers.

Then, on the client side, a short script that is called by cron every so often. The script simply downloads the output of the PHP script, times the download, and sets the system time to the downloaded time plus half the time taken for the download. Is it perfectly accurate? No. Is it good enough for almost any use? Yes.

Using the half-the-download time is sort of cheating, but it gets you close enough to the actual time, and it's dead simple. The original poster doesn't specify how accurate he needs this to be, but as a rough guess I'd say that the method I've outlined will probably sync the time on the two servers to closer than a quarter second.

Re:COOKING WEB SERVICES WITH ELZAR (0)

Anonymous Coward | more than 8 years ago | (#13210130)

#include <stdio.h>
#include <time.h>
 
int main(int argc, char *argv[]) {
        printf("Content-Type: text/plain\n\n%ld\n", time(NULL));
        return 0;
}
That's all that's needed.

Re:COOKING WEB SERVICES WITH ELZAR (1)

Guspaz (556486) | more than 9 years ago | (#13210479)

That probably isn't enough since we have to assume we might be going through a proxy. At the very least we have to tell the proxy not to cache anything.

FUNNY, but I totally disagree (1)

arete (170676) | more than 9 years ago | (#13214546)

You don't want to make a new SOAP service and have to do all the delay calculations.

If you have access to an external server, just tunnel NTP over HTTP. (http://htun.runslinux.net/docs.html [runslinux.net] )

Essentially no programming required.

It might be slighly less accurate than your way, but only if the time on the existing server really is hyperaccurate.

(That is, SOAP directly to an authoritative time server is probably more accurate than a tunneling proxy, but a tunneling proxy is probably more accurate than the two sets of drift calculations involved in syncing from a random server synced from somewhere else.)

Here's what I'd do... (5, Insightful)

Anonymous Coward | more than 9 years ago | (#13204509)

Ask the morons in charge of the firewall to please open the NTP port and take the time to explain why this is important.
Take it up with management if said morons disagree.

Re:Here's what I'd do... (1)

IvyKing (732111) | more than 9 years ago | (#13204794)

I'm almost in excatly the same boat as "dvdsmith" - the most likely solution for our situation is a GPS stabilized NTP appliance. We've also been taking a hit with the lack of FTP access and a couple of other protocols - we have a clear need for access, but that doesn't seem to make any difference to the IT guys.

One basic problem is that the IT folks are being graded on keeping their costs down - but not graded on whether they keep the overall costs down.

Re:Here's what I'd do... (1)

bluGill (862) | more than 9 years ago | (#13205288)

Who is playing the political games? IT does what the boss tells them to. If you are a typical slashdotter you do not play the political games well. So you should have your boss play them for you, that is his job. Just tell your boss that you need good time, and let him do it.

If you boss won't play those games, think about sending thing up the line. Start asking questions in the company meetings about why IT isn't responding to employee needs. Your point will get across. (Careful here though, this is playing politics, so you need to understand the politics of your question more than the technical content!)

Re:Here's what I'd do... (1)

IvyKing (732111) | more than 9 years ago | (#13206008)

Who is playing the political games? IT does what the boss tells them to.

W-e-l-l, IT's ultimate boss is 4 to 5 levels up in management (I'm part of a very large organization, IT is largely in India). My boss is well aware of the problem and his boss is well aware of the problem but isn't in the position to do anything about it. :-(

Re:Here's what I'd do... (1)

OrangeSpyderMan (589635) | more than 9 years ago | (#13220401)

My boss is well aware of the problem and his boss is well aware of the problem but isn't in the position to do anything about it. :-(

Then go to someone who can. This is a no-brainer - it's probably worth speaking to your IT Security Head - any application logging is worthless unless you can rely on the timestamp. If your company is quoted on the NYSE - they'll have to answer questions like this soon anyway because of Sarbanes-Oxley etc.

Re:Here's what I'd do... (4, Insightful)

ColaMan (37550) | more than 9 years ago | (#13205300)

Get quotes for your time-sync hardware, and a *formal* quote from IT. (if no formal quote is forthcoming, keep your evidence of attempting to obtain one, and do a best-guess yourself, factoring labour/bandwidth/etc).

Go up the chain to whoever manages both the IT and your division. Say "We need time sync for such-and-such. It's necessary."

Give them a breakdown of costs like so:

$x for GPS stabilised NTP appliance.
$y for some bonehead in IT to open the port up.

Make sure you put the expensive one first. If it costs the IT department more to poke a hole in the firewall, well, hell, you'll get a new toy to play with. But most likely management will say (paraphrased) "WTF? Bring me the head of the IT department manager, on a silver platter."

IT departments are there to provide services for the rest of the company. That's their job. If they're not doing their job, call them on it. They're just a lead weight around the company's neck otherwise.

Re:Here's what I'd do... (3, Informative)

secolactico (519805) | more than 9 years ago | (#13205604)

Give them a breakdown of costs like so:

$x for GPS stabilised NTP appliance.
$y for some bonehead in IT to open the port up.


And don't forget to include installation costs in the breakdown. Depending on your building infrastructure, you might have to run wiring for an external gps antenna, plus related costs of mounting an outdoor equipment, which will probably be done by the maintenance people or subcontracted.

Are IT departments there to provide service??? (1)

hadaso (798794) | more than 9 years ago | (#13207000)

> IT departments are there to provide services ...

In one college I teach in they have an internal time server, and that server is one hour off... The way they set it to daylight savings time is by adding one hour to UTC... (And by inspecting email headers I think that's the way most IT departments in Israel do it. Then of course they cannot sync to an external time server because then everything is one hour off what they think is correct. But it might be the common knowledge of all system admins in Israel that time syncing is "broken" and cannot be used at summertime...).

Re:Are IT departments there to provide service??? (1)

phliar (87116) | more than 9 years ago | (#13223612)

In one college I teach in they have an internal time server, and that server is one hour off... The way they set it to daylight savings time is by adding one hour to UTC...
Great Scott! The rest of the world (including weird places like Arizona that don't use summer time while everyone around them does) has no problem with shifting UTC offsets. (NTP itself is UTC, it doesn't care about time zones -- that's upto the user applications.) Why is Israel in this mysterious temporal anomaly?

Re:Are IT departments there to provide service??? (1)

hadaso (798794) | more than 9 years ago | (#13224455)

> Why is Israel in this mysterious temporal anomaly?

I guess that's because of politicians. The authority on setting the duration of Daylight Savings Time in Israel is given to the minister of interior. Over the past 30 years or so the politicians have been constantly changing the duration of daylight savings time to suit the needs of different political parties (or to comply with supreme court decisions when the court ruled the changes exceeded the minister's authority set in the law). Often it happened on "last minute". On Windows 95 we still had the "daylight savings time" checkbox in the time zone control panel thing. On WinXP (and perhaps earlier versions) it is grayed out, so I guess M$ gave up on trying to follow all the changes in policy, and now the only option in our timezone is to set things up manually (at least on Windows systems that are the most common system).

I wrote a tutorial on setting the time correctly in Israel during summertime (in Hebrew in http://guides.co.il/wiki [guides.co.il] ). Basically it says to choose Bagdad (UTC+0300) as timezone and uncheck the daylight savings time. However, I think most system administrators think that they don't need a tutorial: if they know how to set their wristwatch to daylight savings time it means they can do it the same way on a computer... Well actually I looked there now and saw that someone added a section on how to enable the automatic DST adjustment in Windows and how to setup the start and end days. However, she(?) says these should be updated because the dates change each year (because they correspond to Hebrew calendar dates), so I don't see the point in doing it automatically... What a mess...

Re:Here's what I'd do... (1)

Transcendent (204992) | more than 9 years ago | (#13221482)

With a firewall, you can easily block incoming syn/ack's through the ntp port, but use a keep-state to allow outgoing TCP connections (someone internally has to initialize it, then you can get bi-directional communication). ...at least with PF.

Cost? 30 seconds to modify pf.conf and 5 seconds to load in the new rule. What's that for an hourly wage? Hell, drop 5 bucks on the table and the company made a profit.

Re:Here's what I'd do... (1)

EnronHaliburton2004 (815366) | more than 9 years ago | (#13205900)

lack of FTP access

Well, any techie worth their salt shouldn't consider FTP except in very special cases. Plaintext passwords is a huge security hole in the security models at most businesses.

I always encourage use of SFTP instead. However, most developers seem scared of SFTP for some reason. It's pretty much the same darn thing.

And I always allow NTP :)

Re:Here's what I'd do... (1)

op00to (219949) | more than 9 years ago | (#13212775)

FTP over TLS or FTP over SSL, anyone?

Re:Here's what I'd do... (1)

EnronHaliburton2004 (815366) | more than 9 years ago | (#13215892)

What is the advantage of those over SFTP?

There seems to be a real lack of FTPS clients but plenty of SFTP clients.

And by installing OpenSSH, I gain access to other handy file transfer tools like SCP & Rsync over SSH which is incredibly powerful.

Re:Here's what I'd do... (1)

bogeskov (63797) | more than 9 years ago | (#13222886)

It's mighty hard to do connection tracking (which is needes to open for the data port) on an encrypted socket...

Re:Here's what I'd do... (1, Insightful)

Anonymous Coward | more than 9 years ago | (#13205266)

If these IT guys are worth their salt, the must already have NTP servers inside the firewall. Why not just use those?

Afterall, if those internal servers are not reliable, then that reflects poorly on the IT guys, which gives you even more leverage to justify removing the restriction.

Re:Here's what I'd do... (3, Insightful)

AndroidCat (229562) | more than 9 years ago | (#13206111)

Slick, that turns the problem around and drops it in their lap. Providing reliable network time would certainly be their job (especially if they block access to outside servers), and it would be easy to show that it's a requirement for network operation and logging. (OP might want to jury rig something to periodically test their time for accuracy.)

Re:Here's what I'd do... (1)

James_Aguilar (890772) | more than 9 years ago | (#13206460)

The guy already said, "It's impossible to change the firewall." You can't answer that by saying, "Change the firewall."

Re:Here's what I'd do... (1)

Flounder (42112) | more than 9 years ago | (#13212406)

Then either the firewall is crap, somebody lost the manual, or the firewall manager is a frigging idiot.

Based on my IT experiences, my guess is all of the above.

Re:Here's what I'd do... (1)

James_Aguilar (890772) | more than 9 years ago | (#13212808)

The original article says specifically that the guy who manages the firewall would refuse to change it come hell or high water.

Re:Here's what I'd do... (1)

putaro (235078) | more than 9 years ago | (#13218569)

Well, then if it is truly is impossible you wind up buying the GPS hardware and installing all that stuff. Odds are though that when the costs make their way up the management chain, "impossible" becomes "yes sir, I'll stop being a butthead"

Re:Here's what I'd do... (1)

jginspace (678908) | more than 9 years ago | (#13206753)

" Ask the morons in charge of the firewall to please open the NTP port and take the time to explain why this is important. Take it up with management if said morons disagree."

I strongly suspect said firewall is placed at country level (think Arab countries, or North Korea) and said "morons" are the boyz from the Interior - or whatever - Ministry. Now you were talking about taking up with the "management"...?

Re:Here's what I'd do... (1)

dheltzel (558802) | more than 9 years ago | (#13206906)

He has good reason to be very afraid of the "morons", as you, brave Mr. AC, have so cavalierly stated.

Remember - Do not meddle in the affairs of wizards, for you are crunchy and taste good with ketchup.

Simon

Re:Here's what I'd do... (0)

Anonymous Coward | more than 9 years ago | (#13224548)

Like stated in below comments. This is political. Big picture though. The people running the firewall should already know the importance of NTP and time syncronization. If not, I would not feel comfortable letting them oversee the firewall but that is a different topic. I have seen many IT departments that feel they run the company. In many places the IT department opinions mean more then others. Bottom line, the IT department is a NOT a profit center. They are there to support the company. If people need access to something, that department makes the request. The IT department should present the pros and cons with all the details, and work with the requestor of the company to come to an agreement. It may take a third management arm to make the final decision but either way, the IT department is off the hook from responsibility provided they actually did a good analysis of the disadvantages.

We can provide your department plain old telnet access from the outside BUT, it is a huge security risk due to the plain text password flying around hells half acre. We may be able to limit our exposure by forcing users to change passwords daily and limit connections to only those from certain subnets to reduce the risk but providing this functionality is not an industry standard because of the overall risk and not recommended at all. However, we can provide SSH access and use key pairs which is more secure but will require XX hours and money to implement and will allow one more entry point into our network. Bam, you are covered. If someone higher up makes the decision to use tlenet, do what you can to limit potential damage but the IT department's ass is covered.

Tunnel. (5, Informative)

SharpFang (651121) | more than 9 years ago | (#13204514)

Set up a host outside the firewall, and tunnel the NTP data over some "allowed" port, so it gets through. Or set it up as NTP server on non-standard port (80?) outside the firewall.
If you want precise measurement, this is the way to go. NTP software will correct the latency errors, no matter if you have direct connection or if it goes through tunnels around the globe, so you have precise time. But if you go for methods like reading time from website applet, all the network latency problems get completely neglected and just add up to the error of the internal server. You could just as well sync it to your hand watch instead.

Re:Tunnel. (0)

Anonymous Coward | more than 9 years ago | (#13206543)

Since ntp is UDP based, and http traffic over port 80 is TCP based this will still be blocked. You would have to misuse an open UDP port, like perhaps UDP 53 (DNS).

radio (4, Interesting)

Fanro (130986) | more than 9 years ago | (#13204518)

you could build a device that gets the time via radio (LINK [buzzard.me.uk] ) or buy one that does this (like a gps receiver?).

or if any udp port is open in the firewall, set up a ntp server outside that answers on that port

Re:radio (3, Insightful)

samjam (256347) | more than 9 years ago | (#13204687)

I like this idea.

First get a written refusal in response to a written request to open NTP on the firewall.

Then use this to justify a hardware purchase for the clock hardware.

Wait till bosses realise that a $500 piece of kit and a couple of days setting up could be replaced by 5 mins configuration by a dolt.

Sam

Re:radio (1)

bonezed (187343) | more than 9 years ago | (#13204721)

thats the way i would do it too

Re:radio (1)

barzok (26681) | more than 9 years ago | (#13212912)

Wait till bosses realise that a $500 piece of kit and a couple of days setting up could be replaced by 5 mins configuration by a dolt.
You sure about that? My boss told me to buy a switch so that I could have additional ports in my cube (I have 2 and need 2, but one is used by the workgroup printer), as opposed to having someone move the printer 6 feet to hook up to an unused second port in another cube - or just get a longer LAN cable.

Re:radio (1)

samjam (256347) | more than 9 years ago | (#13213233)

Well, that makes sense.

You are already feeling the pinch of the scarcity of switch ports, juggling them around isn't a long term solution and one day the pinch will be very inconvenient.

Better get a new switch now before it gets urgent instead of afterwards.

The expense will be offset against the convenience now and the lack of severe inconvenience in the future.

Sam

Re:radio (1)

barzok (26681) | more than 9 years ago | (#13213678)

No, he wants a small switch (actually, he asked that I purchase a "router" complete with a WAP built in, even though the company doesn't support wireless networks and it'd be a big security problem if left open) just in my cube to serve only me. I'm one of a very few people who have a second computer, so the idle LAN drops in the other 90% of cubes (yes, they wired 2 for each cube, but don't use them) are going to remain idle for a very, very long time.

Re:radio (1)

samjam (256347) | more than 9 years ago | (#13214794)

Gosh. Indeed.

Sam

Tunneling (1, Informative)

digitalvengeance (722523) | more than 9 years ago | (#13204529)

The most common solution to a firewall blocking a particular port or service: tunnel it. SSH is probably the easiest form of tunneling and putty has a great command line utility for just that. But you can also tunnel over HTTP using some basic programming skills. Worst case: set up a port forwarder on the outside of the network that forwards requests on port 80 to time.gov (or some other trusted NTP server) then set your internal NTP server to sync with it on port 80. (This assumes, of course, port based filtering.)

Uh, yeah - *great* idea (0)

Anonymous Coward | more than 8 years ago | (#13208321)

set up a port forwarder on the outside of the network that forwards requests on port 80 to time.gov (or some other trusted NTP server) then set your internal NTP server to sync with it on port 80

How exactly would this work? If they're blocking UDP/123, why wouldn't they also be blocking UDP/80?

Oh, that's right - you're an idiot who doesn't know the difference between UDP and TCP.

Re:Uh, yeah - *great* idea (1)

digitalvengeance (722523) | more than 8 years ago | (#13209253)

I have written dozens of systems taking advantage of UDP and TCP based on the need of the system. I absolutely do know the difference. I haven't, however, had any reason to learn the underpinnings of the NTP protocol as yet, so you're right in that I didn't bother to look up whether its UDP or TCP based. UDP can be tunneled as well, and the idea is still valid. Maybe they allow UDP for some other application (video conferencing etc.) and you could always just use that port with a known outside source. Think before you post - especially as a coward. Oh, that's right - you're an idiot who can't take a smart concept and apply it as necessary to a given situation.

Re:Uh, yeah - *great* idea (0)

Anonymous Coward | more than 9 years ago | (#13215529)

Think before you post

If you truly do know the difference between TCP and UDP, I could say the same thing to you..

But yeah, you're pissed off at me because I pointed out that you're an idiot.

Don't blame the messenger.

Re:Uh, yeah - *great* idea (1)

digitalvengeance (722523) | more than 9 years ago | (#13215778)

If you were half as smart as you thought you were, you'd shut up and take the time to learn and appreciate the difference between a concept and a plan. I suggested the concept of tunneling then gave some examples of good tunneling systems to examine. You, lacking the intelligence to take that concept and apply it to a real-world situation, assumed the role of an anonymous coward to display to the world your own stupidity. Nice going.

Now, as the other poster who replied to you stated, virtually any protocol can be tunneled through something as simple as HTTP with a little effort and ingenuity; however, I suppose it takes a little imagination to understand that.

Let me explain it to ya. I'll try to use small words so you don't get too confused.

The NTP client is configured to NTP Sync with a custom daemon running inside the firewall. That custom daemon listens for UDP traffic on a given port. When received, it creates a false HTTP connection to some outside host and passes the information from the UDP connection. That outside host (also running a custom daemon), re-creates an appropriate UDP connection to a trusted time server and the process continues in that fashion until the sync is complete.

You could even use a simple TCP/UDP bridge daemon then tunnel outbound traffic through SSH. (Though this would add another daemon to maintain, secure, etc. and is not necessary as NTP traffic doesn't need to be encrypted.)

This model should allow accurate NTP syncing through just about any firewall with some standard protocol spoofing. Is it complex? Yes. Is it trivial? No. I would submit, however, that any developer worth his/her salt could do it if properly motivated.

Re:Uh, yeah - *great* idea (1)

Webmoth (75878) | more than 9 years ago | (#13211755)

How exactly would this work? If they're blocking UDP/123, why wouldn't they also be blocking UDP/80?

A friend of mine wrote a userspace application that allowed him shell access to a remote system when he was behind a gestapo firewall that not only restricted you to TCP/80, but it also further restricted you to HTTP.

He "simply" tunneled the shell commands and response thru HTTP packets. He figured he could forward just about anything else similarly.

Re:Uh, yeah - *great* idea (1)

WhiteDragon (4556) | more than 9 years ago | (#13216542)

We have a completely locked down firewall where I work. The only external access is through an http proxy (ok, there is also DNS, but TCP/IP over dns, while it does actually exist, is not very convenient). I used to use SSHWebProxy [ericdaugherty.com] , a java servlet that makes an ssh connection using only http requests, so it has no problem getting through a proxy. It was ok, but I have since switched to anyterm [anyterm.org] which, while still using only http, manages to get pretty much a complete interactive terminal.

I realize this is slightly off topic, so to return to the issue of time, I agree with others that if you need a precise time source, just buy GPS or a WWVB based one, such as this one [beaglesoft.com] or a gps based one.

too easy (0)

Anonymous Coward | more than 9 years ago | (#13204531)

Use any of the windows scripting tools, or cygwin tools to provide wget, awk, etc. We use this for changing IP addresses, time, and firewall control. Just write a batch file or shell script to get the time from any website that shows the current time of refresh on a page.

man wget - will tell you how to get a single webpage and write to std out (yes, works on windows), use grep and awk to single out what you need, then pass it to date. You can also use command line PHP or PERL without much trouble.

Re:too easy (2, Interesting)

Anonymous Coward | more than 9 years ago | (#13204613)

Just write a batch file or shell script to get the time from any website that shows the current time of refresh on a page.

How about
$ wget --spider -S $WEBSITE 2>&1 | grep -i 'date:'
No need to parse the HTML, just use standard HTTP headers.

Re:too easy (2, Informative)

vadim_t (324782) | more than 9 years ago | (#13207297)

BAD idea! Don't do that!

Think of it for a while. The HTTP server takes its local date, writes it into a socket, and sends it to you. By the time you get it, the time will have changed. If your time was actually right, it'll go like this:

You (10:00:00): HTTP request
Server (10:00:01): Sends date
You: (10:00:02): Date received, set

And here you set the date backwards in time, which is definitely going to cause problems.

Two completely untested suggestions (3, Informative)

moreati (119629) | more than 9 years ago | (#13204640)

1. Hook up a GPS receiver directly, via the usb/serial port, use whatever software [google.co.uk] to interface

2. Use HTP: HTTP Time Protocol [clevervest.com]

Re:Two completely untested suggestions (0)

Anonymous Coward | more than 9 years ago | (#13204666)

That's what I was 'bout to say - use a GPS receiver - can't get wrong with that!

Either that, or hit your firewall admins for being stupid - they really should be providing an NTP server for everyone to synch from.

Make sure you sync the time on your PDC emulator domain controllers, and all members of Windows 2000 and above domain will automatically follow that computer's clock using NTP by default - don't fight the infrastructure for this that Microsoft have already built in.

(Time synch is important in a Windows domain as Kerebos requires fairly decent agreement on the current time.)

(In Win 2K it's net time /setsntp and in w2k3, it's w32tm -something. Use google.)

Re:Two completely untested suggestions (1)

nyrk (779328) | more than 8 years ago | (#13208698)

1. Hook up a GPS receiver directly, via the usb/serial port, use whatever software to interface

This might work if your server is near a window, or you could get a GPS with an external antena that you can run outside.

GPS's tend not to work too well when you are inside a building. Mine does not work inside unless it is near a window. In fact it does not work too well with heavy tree cover. If I am an a forest with large trees, and cannot see the sky, it gets no signal. Sadly, when I am in the trees like that it is usually when I need it the most.

Quit (1)

hackwrench (573697) | more than 9 years ago | (#13204650)

Find a new job that comes with the authority you need to do it.

You should use NTP (5, Insightful)

Anonymous Coward | more than 9 years ago | (#13204684)

Correct subsecond time is important.

If your boxes are hacked and you go into court and you can't demonstrate that your log timestamps have anything to do with reality, you might not be able to use them as evidence.

You also would like to be able to accurately judge HTTP cache timeouts and other time-sensitive things.

You also don't want your time to "step" (jump by more than one second) if you can help it. It screws up sensitive daemons and I've seen more than one box crash and burn and start spawning crap when the clock jumped backwards.

Have them open up the damn firewall, set up a reliable Unix-based NTP server on the inside that syncs to something outside, and have the workstations sync up with that.

You CANNOT tunnel NTP over SSH. NTP uses UDP.

You also don't want to just get the time from some web page and set the clock because your clock may jump, and you don't adjust for latency correctly either (NTP is *complicated* because there are a lot of edge cases and complex concepts here). Also you'd like to be able to select from multiple sources and throw out any outliers, in case one has been hacked.

If you can't do the sane thing, which is open up the firewall, you can just set up a local Unix NTP server and at least your boxes will all have the same time as that box, even if it's the "wrong" time.

You can also use GPS or a dialup modem to set the time on your NTP server.

To recap:

1) set up a centralized NTP server
2) sync to that NTP server
3) if possible, sync that NTP server to another external NTP server, OR a radio or modem signal.

It ain't rocket science folks.

Re:You should use NTP (1)

hixie (116369) | more than 9 years ago | (#13204747)

You can tunnel NTP over SSH if you first tunnel the UDP over TCP, e.g. using tcptunnel(1).

Re:You should use NTP (2, Insightful)

ComputerSlicer23 (516509) | more than 9 years ago | (#13205110)

Hmmm, curious, I thought you could tunnel IP over SSH. It doesn't matter what what NTP uses as transport for it. It should tunnel. Now, it might screw up the protocol. However, the protocol should just treat the tunnel as a UDP connection with fairly odd properties.

Kirby

Re:You should use NTP (0)

Anonymous Coward | more than 9 years ago | (#13207676)

Hmmm, curious, I thought you could tunnel IP over SSH. It doesn't matter what what NTP uses as transport for it. It should tunnel. Now, it might screw up the protocol. However, the protocol should just treat the tunnel as a UDP connection with fairly odd properties.

SSH will not tunnel UDP. Period. Can NTP be hacked to run over TCP? Probably, but NTP uses UDP because UDP is normally a bit faster than TCP since it doesn't have to wait for ACKs.

Re:You should use NTP (2, Informative)

ComputerSlicer23 (516509) | more than 8 years ago | (#13208258)

You really shouldn't be so absolute about those things. I've done IP over ssh, which means you can do ICMP, UDP, and TCP over it. Not using ssh and port forwarding, but using ssh, pppd, it can be done. You create a pppd device that is attached to a terminal, the terminal gets created by sshd. You do all the same things at the other end. It's a bit more work on both ends to accomplish it, but anywhere you can do ssh port forwarding, you should be able to tunnel PPP over SSH.

It's standard and fairly simple. You can read about it here [faqs.org]

As to why UDP is used, has nothing to do with "faster". The protocol is designed to use UDP, because it's connectionless, it has lower latency, and the TCP connection encapsulates a lot of the properites that NTP measures to correct for latency and transmission delay. If a packet gets dropped via UDP, NTP can compensate for that, with TCP it's much harder. If a packet gets dropped, retransmitting the same one again is stupid (that's what TCP would do), you should transmit a new one with a new timestamp (you can do this via UDP).

Kirby

Re:You should use NTP (0)

Anonymous Coward | more than 9 years ago | (#13213832)

We're sorry. Your post is above the intelligence threshold for Slashdot. In the future, please try making more misspellings and use incorrect analogies to prove your points, rather than actual experience. You are banned from posting again for 2 minutes (give or take 1 hour).

Re:You should use NTP (1)

martian67 (892569) | more than 9 years ago | (#13206707)

You CANNOT tunnel NTP over SSH. NTP uses UDP

Completely untrue, newer versions of OpenSSH have a Socks 5 proxy built in that allows you to tunnel both TCP and UDP ports...

Re:You should use NTP (1)

grozzie2 (698656) | more than 9 years ago | (#13220062)

If your boxes are hacked and you go into court and you can't demonstrate that your log timestamps have anything to do with reality, you might not be able to use them as evidence.

Unless you are logging to write once media, or something other than a text file that you can manually edit, aren't many courts that'll consider logs as evidence. Police may like them, and use them as pointers for a trail to 'real evidence', but logfiles themselves wont stand up to cross examination, unless they are proven to be written initially to indellible media, which cannot be altered after the fact. timestamps are the least of your concerns in this area.

"Atomic Clock" card (5, Informative)

SA Stevens (862201) | more than 9 years ago | (#13204767)

You can run a local NTP server, and install an 'Atomic Clock' receiver in it, on a Card. Basically it's a 10 MHz WWV receiver that decodes the time info and reads it into the PC. They've been around a long time.

This is what this guy is really asking for (1)

ZosX (517789) | more than 9 years ago | (#13206159)

This has got to be the easiest suggestion someone has said. Not only are you avoiding potential NTP exploits in the network, you are also not going head to head with your boss. The solution is likely extremely cost effective, easy to implement, and relatively pain free. It solves all of his problems and very elegantly too. Sir, you deserve to be modded up, but for some reason, I have not seen modpoints for months now. What's going on with that? I tried metamoderating 20 times in a row and still no modpoints. Oh well.

Is the router an NTP server? (2, Informative)

Webmoth (75878) | more than 9 years ago | (#13211795)

Have you checked the obvious? Many routers and firewalls also serve NTP. Try polling NTP on the firewall. It just might work.

If that doesn't work, try polling the local router. Try polling a remote router that's still inside the firewall.

A customer of mine has several sites, and the sites are linked through frame relay (or is it T-1?). The firewall blocks port 123, so NTP with the outside world is (generally) out of the question. However, the frame provider is MCI, who also happens to manage the routers for the customer, and the routers poll NTP from MCI's network, and serve NTP to the local network. Rather handy.

I wonder if HTTP time on their server is reliable (1)

marat (180984) | more than 9 years ago | (#13204781)

:~> curl --dump-header - -o /dev/null time.gov
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Sat, 30 Jul 2005 23:55:38 GMT
Content-type: text/html
Etag: "3f2f157-1-292b-41dc304b"
Last-modified: Wed, 05 Jan 2005 18:22:03 GMT
Content-length: 10539
Accept-ranges: bytes


You don't have milliseconds this way, but with a program smart enough you can collect them over time.

Not a "Java" website (1)

jrivar59 (146428) | more than 9 years ago | (#13205051)

That site uses Javascript, not Java.

Furthermore, all the Javascript does is tick a clientside counter. A timestamp is supplied when the page is loaded, and a javascript increments it using ticks on your PC, not the server.

You could parse the HTML page to pull off the timestamp. It wouldn't be very precise, but might be good enough. NTP does lots more then just ask a server for a timestamp though, it does predictions of network latency and factors that in as well.

Re:Not a "Java" website (0)

Anonymous Coward | more than 9 years ago | (#13205073)

It is a Java website. You probably have Java disabled or not installed. From time.gov's help page [time.gov] :
To see the animated clock, be sure that java is enabled on your browser. Otherwise, try a different or newer browser. Also, you may be behind a firewall and you will need to have your network administrator open port 8013 in order for it to work.

Re:Not a "Java" website (1)

FLEB (312391) | more than 9 years ago | (#13205652)

Also, you may be behind a firewall and you will need to have your network administrator open port 8013 in order for it to work.

Which brings us back to do.

Get a freaking GPS receiver (0)

Anonymous Coward | more than 9 years ago | (#13205272)

And set up your own "primary" NTP server. You can either hook a standard GPS receiver to a serial port, or buy a whole server-in-a-box.

Voila. No packets through the unfriendly firewall at all.

Synced with what? (3, Interesting)

spaceyhackerlady (462530) | more than 9 years ago | (#13205890)

Do the systems need to be synced to the outside world, or merely consistent with each other?

If the silly firewall people won't help you (you might remind them that you do in fact work for the same company...), you need to set up your own NTP server. Either a real one with a GPS receiver, or a pretend one that everybody can follow and have the same time, regardless of what that time actually is (see initial question).

The occasional phone call to the NIST's dialup time server [nist.gov] might be useful too.

...laura

use HTPDate ... (0)

Anonymous Coward | more than 9 years ago | (#13205915)

http://www.clevervest.com/htp/intro.html [clevervest.com]
syncs time via http header info

p.s.: wow. actually the fist ask-slashdot-question i'm not too lazy to answer (perhaps because this time its a GOOD question...)

greetings

is it your hardware? (1)

thenerdgod (122843) | more than 9 years ago | (#13206093)

Companies make GPS-timeclock receivers that connect to your server with a serial cable and have software to do clock drift adjustment. If you can get a GPS signal, you're set.

Re:is it your hardware? (1)

thomasa (17495) | more than 9 years ago | (#13207953)

I had a GPS based time clock. It would only work with an outside roof based antenna. The WWV based receivers generally do better inside a building.

Sounds like you're after htpdate (1)

phaze3000 (204500) | more than 9 years ago | (#13206208)

HTPdate [clevervest.com] would seem to be what you're after here.

There's a perl implementation that will work on Windows machines.

Naviscope (1)

Decker-Mage (782424) | more than 9 years ago | (#13206275)

I just use a nice little program that, among many other features, happens to synch the clock over HTTP. It's called Naviscope and is, the last time I looked, now abandonware. No biggie since they never charged for it in the first place.

Other features include: DNS caching, programmable (delayable) prefetch by site including number of threads and depth, blocking of (simple) advertisements, site backgrounds, blinking text, pop-ups (while loading or entirely), UserAgent, Referrer, cookies, Javascripts, and sounds. All that can be set for default as well as on a site by site basis. My default is block everything which keeps the malware sites confused and limited ;-).

Other handy features include recording all headers in and out of the program and your system as well as building a site map (handy for programming web crawlers). And of course, given all those functions, it is a web proxy.

I've been using it some five odd years or more now and it goes on all my Windows systems. For *nix, which may be what we are discussing here, you'll have to hack your own.

If your are interested, Google will turn it up in the first few entries (PCWorld site in #1 but you may desire a different source). Enjoy.

Need vs Want (1)

tengu1sd (797240) | more than 9 years ago | (#13206352)

You want NTP opened on the firewall. Do you have a business need for time or will just having your systems synch'd with each meet the requirements?

If you can get by with keeping the same time, set up a master/secondary time server and keep time with those.

If you need accurate time, you start with a formal request to the group that maintains the firewall. State your case, list the time source(s) you'll be using. Assuming that request is turned down, you provide the quotes for setting up in house time synchronization services. Remember you'll need at least 2 units for redundancy (you do have a legitmate business requirement right?). You don't want a single point of failure.

If it turns into a policy struggle, you need to be the reasonable one who's trying to meet a business requirement. Let your management know early what the issues and costs will be.

Never let your manager be surprised. Let him make the waves. That's why he's management and you get to play with the cool toys.

cisco! (1)

ldspartan (14035) | more than 9 years ago | (#13206422)

Cisco routers (almost always...) have the ability to be an NTP server and client. Have them do that. Clean, simple solution.

Failing that, look at clockspeed from DJB. He's terribly clever.

--
lds

Use the HTTP Date header (1)

cbcbcb (567490) | more than 9 years ago | (#13206678)

Most webservers return the date in the HTTP headers.

For example, try:
curl --head http://www.google.com/ [google.com]

NIST.pl (1)

MikeDawg (721537) | more than 9 years ago | (#13206881)

Try NIST.pl [freshmeat.net]

UK Rugby Time transmitter (1)

dismentor (592590) | more than 9 years ago | (#13207724)

I'm in the UK and we sync from the Rugby time service, which broadcasts UTC time over radio. This is reliable, but not authenticated.
You can get a serial dongle and software that receives this for very little money.

Use a cheap GPS (2, Informative)

Telecommando (513768) | more than 8 years ago | (#13208177)

Buy a Delorme Tripmate on Ebay. Buy or build a power/serial cable. Connect pins 2&3 on the serial port so the Tripmate will self start. Parse the ASCII strings sent by the Tripmate. The string you need looks like this:

$GPRMC,HHMMSS,A,LATITUDE,N/S,LONGITUDE,E/W,SPEED,D IRECTION,DDMMYY,MAGNETIC,E/W*CHECKSUM

A search on Google for "Delorme Tripmate" and/or "NMEA-0183" should turn up plenty of info.

I use a Tripmate in my car connected to a Microchip PIC and an LCD to display time, date, location, speed and direction.

Re:Use a cheap GPS (1)

TheSHAD0W (258774) | more than 8 years ago | (#13208672)

Pins 2&3 on a 9-pin or 25-pin port? (I'm guessing it's 9-pin, but please be specific.)

Re:Use a cheap GPS (0)

Anonymous Coward | more than 9 years ago | (#13210452)

Um, it doesn't matter, the end result is the same, as you're connecting the transmit and receive pins together.

On a DB-25, 2 is transmit, 3 receive. On a DB-9, 2 is receive, 3 transmit...

Re:Use a cheap GPS (1)

fruity_pebbles (568822) | more than 9 years ago | (#13214236)

Cheap mass market GPS's don't make very good time sources for NTP. They don't output the NMEA text on the GPS second, and they don't output the NMEA text at precise 1-second intervals.

There are inexpensive OEM GPS boards that include a precision PPS output that work very well with NTP.

Getting the IT idiots to open up the NTP port seems like the easiest thing though.

Second resolution out of HTTP (1)

frantzen (137260) | more than 8 years ago | (#13208362)

HTTP servers send a Date: modifier in their response. It doesn't get you millisecond resolution but it's better than nothing the way some machines' clocks drift.

$ telnet ntp.isc.org 80
Trying 204.152.184.138...
Connected to ntp.isc.org.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 302 Found
Date: Sun, 31 Jul 2005 17:10:58 GMT
Server: Apache
Location: http://ntp.isc.org/bin/view/Main/WebHome [isc.org]
Connection: close
Content-Type: text/html; charset=iso-8859-1

Connection closed by foreign host.

Ask for an NTP source (2, Interesting)

ken95357 (666403) | more than 8 years ago | (#13208575)

Why not ask the firewall people if they have an NTP source you can use? If they don't, ask them to set one up for you that way they don't have to open their firewalls to your NTP needs.

Slashdot being evil? (0)

Anonymous Coward | more than 8 years ago | (#13208719)

Can anyone tell me why slashdot is strobing my machine?

Jul 31 01:05:08 firewall /kernel: Connection attempt to TCP firewall:444 from 66.35.250.150:59340 flags:0x02
Jul 31 01:05:09 firewall /kernel: Connection attempt to TCP firewall:1080 from 66.35.250.150:59368 flags:0x02
Jul 31 01:05:10 firewall /kernel: Connection attempt to TCP firewall:3127 from 66.35.250.150:59389 flags:0x02
Jul 31 01:05:11 firewall /kernel: Connection attempt to TCP firewall:3128 from 66.35.250.150:59413 flags:0x02
Jul 31 01:05:12 firewall /kernel: Connection attempt to TCP firewall:6588 from 66.35.250.150:59428 flags:0x02
Jul 31 01:05:13 firewall /kernel: Connection attempt to TCP firewall:8000 from 66.35.250.150:59450 flags:0x02
Jul 31 01:05:14 firewall /kernel: Connection attempt to TCP firewall:8080 from 66.35.250.150:59478 flags:0x02
Jul 31 01:05:15 firewall /kernel: Connection attempt to TCP firewall:81 from 66.35.250.150:59512 flags:0x02
Jul 31 01:05:16 firewall /kernel: ipfw: 150 Deny TCP 66.35.250.150:59535 firewall:1026 in via rl0
Jul 31 01:05:17 firewall /kernel: Connection attempt to TCP firewall:3124 from 66.35.250.150:59564 flags:0x02
Jul 31 01:05:18 firewall /kernel: Connection attempt to TCP firewall:3382 from 66.35.250.150:59574 flags:0x02
Jul 31 01:05:19 firewall /kernel: Connection attempt to TCP firewall:7032 from 66.35.250.150:59589 flags:0x02
Jul 31 01:05:20 firewall /kernel: Connection attempt to TCP firewall:8002 from 66.35.250.150:59609 flags:0x02
Jul 31 01:05:21 firewall /kernel: Connection attempt to TCP firewall:8090 from 66.35.250.150:59628 flags:0x02
Jul 31 01:05:22 firewall /kernel: Connection attempt to TCP firewall:2578 from 66.35.250.150:59655 flags:0x02
Jul 31 01:05:23 firewall /kernel: Connection attempt to TCP firewall:8081 from 66.35.250.150:59669 flags:0x02

TV tuner card (2, Interesting)

Hangeron (314487) | more than 8 years ago | (#13209536)

I have a cheap Hauppauge WinTV card and I sometimes use alevt-date in linux to set clock. I've setup a script that sets clocks on 3 other computers aswell through ssh.

This is so easy, it hurts... (1)

jo42 (227475) | more than 8 years ago | (#13209779)

Configure your internal NTP server to syncronize with the internal domain controller(s).

Sometimes having Linux-on-the-Brain makes you dumb...

Re:This is so easy, it hurts... (1)

Anthony (4077) | more than 8 years ago | (#13209976)

And what stratum would those controllers be?

Re:This is so easy, it hurts... (1)

kylegordon (159137) | more than 8 years ago | (#13209995)

What the fuck are you on about? This is exactly what he has just said. Try RTFA.
He's asking how to go about syncing the domain controller (or equivalent workstation with time server) to the outside world, tard.

Ask around first, then buy a cheap GPS (1)

anticypher (48312) | more than 8 years ago | (#13210200)

I understand the extreme paranoia of a firewall admin, especially if there are large numbers of windoze machines on her network. There may be a touch of tin-foil hat syndrome from rumours that windoze machines report activation codes encoded in SNTP requests to time.windows.com. If you are on a government network, then some security dudes have already demo'd tunneling secret info over NTP UDP [doxpara.com] packets, resulting in your properly locked down windoze network. There really is no reason a windoze machine needs to get its time from the internet, when a local time server will do.

There probably is an NTP service on the internal network. Start by asking around if there is an alternative you can use on the inside of the firewall. Try pointing your NTP client at the default router on your segment, and see what happens. Do a traceroute towards the internet, and see if NTP is present on any of the hops before the firewall.

If one sets up an internal NTP server (Windows XP or 2000 workstation)

One note about XP or 2K machines as NTP servers. Windows clocks are accurate to only 10 milliSeconds, and no amount of tweaking will improve that. Save yourself the headache and set up a *nix machine, where clock increments are usually between 2 mSec and 500 nanoSec.

If you have no NTP inside the firewall, you can always pick up a cheap GPS unit with a serial NMEA connector, or if you are in the US, a CDMA timebase. Plug it into a *nix based machine, compile the latest NTPv4 code, and read the docs about setting up a generic NMEA driver. Now you've got a machine accurate to about .05 seconds, and after a few weeks of running will probably settle down to .02 seconds with little drift. If you can spend more and get a GPS with a pulse per second output, you can get 1 microsecond accuracy. If your department has $500 extra in the budget, and you don't want the hassle of setting up a *nix box and GPS, there are GPS based NTP servers out there.

Its probably easier and cheaper to ask the network admins to enable an NTP server on a router.

the AC

GPS time piece (1)

Monkelectric (546685) | more than 9 years ago | (#13215961)

Forget time syncing. If you absoultely can't get the time from outside -- get a GPS time piece. They hook up to your computer and provide accurate time signals from the GPS satelites which all carry atomic clocks. Use the computer this is connected to to run internal NTP.

GPS-based NTP appliance (1)

un4given (114183) | more than 9 years ago | (#13215987)

If the firewall truly cannot be changed, then use your own NTP primary time source which syncs off of the GPS constellation. This is a more secure way of keeping accurate time and is used by telecoms to sync their networks.

http://www.truetime.net/nts200.html [truetime.net]

The old-fashioned way (1)

jesboat (64736) | more than 9 years ago | (#13216284)

Is there anything particularly wrong with getting a few UNIX boxen (for redundancy) with accurate clocks and setting their times manually?

Hardware boxes (2, Interesting)

wcdw (179126) | more than 9 years ago | (#13216440)

This is not what the submitter wanted to know. However, for all of you who have proposed hardware GPS-based solutions, you might want to note that there are also companies making similar hardware which get their time signal from the CDMA cellphone signals.

CDMA in turn gets its time from GPS, but is far easier to receive in most locations - no need to run an antenna cable up to the roof. They also tend to be cheaper.

Do you really need to go outside the network? (1)

Darth_brooks (180756) | more than 9 years ago | (#13225565)

Like the title says, do you really need to pull time from the outside world, or are you just looking for reasonable consistancy?

If it's the latter (and assuming the servers support feeding time to clients, which they probably do), you can use a windows task on the client machines to run the following command:

net time \\server /set /y

You can put that into a batch file, put a "cls" at the end, set the task to run said batch file (as an account with admin priv's) and make it run whenever you feel like it. Logon, logoff, specific time, etc.

The usefulness of windows tasks is somewhat underrated.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?