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.)"

Comments

Phirst Poast - The GIANT! Coach! sugarbitch ;p

[Anonymous Coward]

Okay, let's give it a try," said Kristoff. Paul set an unopened can of soda pop on the table, and Kristoff lined up the sights. Then Kristoff turned back to the computer and typed for a few moments. "Okay, ready," said Kristoff. Both grad students backed up a respectful distance from the table; the computers and other equipment were still drippings from the can of soda which had exploded in a failed test a few minutes earlier. Then Kristoff hit a key to start the process.
There was no sound; only the small glowing red indicator on the side of the magnetic gun indicated that it was being prepared. Both grad students waited for the bang of another exploding can of soda. But when the indicator turned briefly green this time to indicate that the transformation was occurring, there was no bang; there was only a faint sucking sound of air molecules rushing inward, and suddenly the can of soda was twice its original size.
The grad students laughed and slapped each other a highfive. "Excellent!" said Paul. Their months of clandestine work had finally paid off. Paul, a physics student, had been working out two separate but related problems: first, he had been working out a way to measure the location and makeup of each molecule in a body; and second, he had been doing work in nanotechnology, or the direct manipulation of individual atoms. It had occurred to Paul some time ago that these two pieces of technology, driven by the proper software, could be used to enlarge or shrink items. If the soda pop contained ten water molecules for every sucrose molecule, one should in principle be able to enlarge or shrink the mass of pop by adding or removing the appropriate molecules in the right locations and in the proper proportions.
What Paul needed was the help of a computer scientist who could write the code to make the right generalizations about what molecules were found where, and about what needed to be added or removed. He and Kristoff had worked together over several months to put together their test system, and after many false tries, they had finally achieved this initial success. "Let's have some soda," said Paul, lifting the doublesized can from the table and popping it open. He poured some into a glass, eyed it and smelled it, and took a sip. Kristoff watched Paul's contemplative expressive as tasted it. "It's the real thing!" Paul declared, and poured another glass for Kristoff.
"You know, we're gonna be rich filthy, stinking rich," said Kristoff, taking his glass. "Transportation is going to cost next to nothing now. You want to move a bunch of steel girders across the country? Drop them in a shoebox and stick them in the mail! Think of the possibilities for space colonization we've overcome the cost of lifting the payload."
But Paul was looking out the window, his eyes turned absently toward the high school football team practicing in the field by the school across the street; he was not watching the team, but rather was already thinking about the next challenge. "You know, the thing we can't do yet is manipulate living tissue," he said slowly. Then he looked at Kristoff. "I mean, you'd need a much more complicated algorithm. Right now we can make a duplicate of a DNA molecule right next to the original, but that wouldn't result in a viable cell; not with the same DNA twice in one nucleus. What we need is a way of duplicating the whole cell."
Kristoff frowned thoughtfully. "I don't know enough biology to know how to make a copy of a whole cell beside the original; we'd need to no more about the structure of a cell to be able to do something so specialized." But he could immediately see the commercial implications: how cheap it would be to fly some temporarily reduced people coast to coast, and then restore them to regular size at their destination! Or, as an advertising novelty, one might make a person into a giant. But that could only be temporary what would such a giant eat, after all?
Paul was thinking. "You know Bruce over in the biology department? He might be able to help us."
And so, in the weeks that followed, Paul and Kristoff brought Bruce into their confidence, and the three grad students gradually worked out their improved algorithm.
It was almost summer when the three grad students were ready for the next stage of their testing. The window was open, and the sound of gentle wind through the new leaves drifted in from the open window, as did the sound of the high school football team practicing across the street.
Paul nervously set the cage on the same table. A white mouse was continually searching for an exit from its little prison, its delicate paws soft against the metal bars. "Okay, let's give it a go," said Paul again.
Kristoff typed at the keyboard, and again there was silence, and the red indicator glowed. Then the light turned green; there was a familiar sucking rush of air, and the mouse had abruptly grown to become a rat.
"It worked!" said Bruce. He had never more than half believed that this dubious new technology could be made to work.
The rat was still. "Is he alive?" asked Kristoff.
But then the rat slowly began to move again. "He was just a little stunned," said Paul. "He's all right."
"We should see if we can get him back to his right size," said Kristoff. "Paul, can you please point the magnetic gun away from him while I get this set up?"
Bruce's eyes were on the mouse, and Kristoff's eyes were on the computer screen. Paul absently swiveled the gun away from the rat without paying attention to where he was pointing it. There was a quiet minute where the only sounds were Kristoff's typing, the distant sound of the football team, and the tinny sound as Paul tapped his finger against the cage side, playing with the rat.
Suddenly, there was a earthshaking rumble outside, and a sound like air being sucked in, although on a much larger scale than before. The three grad students looked at each other in alarm. "What the hell was that?" asked Bruce.
Just then, Kristoff noticed which way the magnetic gun was pointing. "Hey, man! You should be careful where you point that thing. You don't know..." He stopped, realizing what might have just happened. His code hadn't been thoroughly debugged, after all; what if some bug had scheduled the gun to turn on at a time that he had not intended? He went to look out the window. "Oh, shit!" he cried.
Joel had been running a fourth lap around the field with his teammates. He was getting tired, and would be glad when the Coach's whistle rang out to order the boys into the shower.
But the sound of the whistle never came; instead, Joel heard a strange sound of rushing air, a sort of sucking sound. Joel thought at first that it was the wind blowing. But the sound seemed to be coming from behind him, and it quickly became louder than the wind ought to be. He turned to see what was going on.
What he saw was so entirely outside his experience that at first he could not take it in properly. Coach Johnson was growing growing faster than a flag is hoisted up a pole. This was impossible; Joel stared openmouthed. By the time Joel what was happening, the Coach had already completely outgrown his gym clothes and had burst out of him; already, the Coach's naked, muscular figure was taller than the school building, taller than the trees.
Terrified and bewildered, Joel could only stare. By the time the Coach's growth stopped, he was as tall as a 10story building. High above, the Coach himself looked rather bewildered as well; what had happened to him? He looked down at the tiny football players staring up at him, at the roofs of the school and neighboring houses and at the treetops, and although he had no clue as to the reason, he realized that he had somehow become a giant.
The three grad students had not thought to anticipate that such a change in size would almost certainly result in a major change in personality of the transformed person. Although the students had succeeded in duplicating the nerve cell's of the Coach's brain properly, it had not occurred to them that the massive new number of cells would work together in a different way than the original cells had. This is why, as the Coach regained his bearing, he looked down at his football players with an evil masculine smile.
"Here, boys, let me get you somewhere where you'll be safe," said the Coach. His massive naked form stooped down and began to pick up the football players, setting them on the flat roof of the school where they could not get away without a ladder. Some of the boys scattered in fright, but many, like Joel, were too astonished to move. In a moment Joel felt himself caught between the giant's thumb and forefinger, and felt a lurch in his stomach as he was lifted faster than an elevator to the school's roof. Joel was dropped coarsely to the gravelandtar rooftop. Crawling to the edge of the roof, he watched as the Coach reached from side to side, gathering up most of Joel's fleeing teammates.
Finally, the Coach stopped and took a few steps over to stand beside the school. At each step, the earth shuddered under the giantUs weight. Joel craned his neck up to see the massive legs towering up like skyscrapers. The Coach did not seem at all shy about being naked in front of so many people; even before this transformation, he had showered with his students all the time, and he was even less modest now. The Coach's cock hung down proudly between his legs. The rippled muscles of his abdomen were on the same scale as the markings of a football gridiron. Above all was the Coach's face, looking down at his team with a smile that looked to Joel like no good.
"Get out of your uniforms, boys," ordered the Coach in a voice that boomed like thunder. The football players looked at each other, each waiting for the others to act. "Strip," said the Coach in a louder voice. Nervously, each football player undressed. Joel trembled as he slid his Tshirt over his head, took off his shoulder pads, and quickly unlaced his cleats. Soon, the whole team stood on the roof as naked as their giant Coach.
"That's good, boys," said the Coach, and looked them over as if considering. Finally he moved his enormous hand over the boys and picked up Stu, one of Joel's friends. The coach lifted Stu up until Stu was even with the Coach's enormous face; he was so far up that the football players below could barely see their teammate. But they could see as the Coach slowly opened his giant mouth and pushed Stu inside. The Coach closed his mouth and swallowed, and the boys below could see the struggling lump move down the Coach's throat. A cry of dismay went up from the football team. The coach smiled his evil smile and looked back down at the football team.
Across the street, Paul and Bruce looked out the window in dismay at what was happening. Kristoff was typing frantically at the keyboard, trying to get a program running that would reduce the coach back to his proper height.
"Oh, my god, he swallowed him!" cried Paul in dismay.
"What? What?" said Kristoff, who had not been looking out the window.
"The coach he picked one of the football players and and just plain ate him!" said Paul.
"Can't you get that program to work?" asked Bruce.
At that moment, the system froze. "Aw, shit," said Kristoff. "I have to reboot! We're going to be in a lot of trouble."
The Coach reached for a second football player. The young men scattered from side to side on the roof, trying to avoid the giant hand. But the edges of the roof kept them from running far. This time, it was Joel who was caught in the sandpaperywarm grasp.
Joel struggled as he was lifted up toward the Coach's mouth, but the fingers that encircled him were hopelessly too strong for him. Joel caught sight of a few confused images: blue sky, treetops, the wiry curls of hair on the Coach's vast field of chest, the tiny naked teammates on the school roof. But soon he was face to face with the Coach, only a few yards from the giant lips.
"Please don't!" Joel squeaked. "Don't don't eat me! Please!"
The coach smiled. "What are you going to do to stop me?" he asked. Without waiting for an answer, he opened his mouth to a gaping cavern and brought Joel closer. Joel felt the soft lips against his naked body. Then the Coach sucked him all the way inside, so that Joel was lying facedown on the wet, coarse surface of the giant's tongue. The sunlight disappeared as the Coach closed his mouth behind Joel. The interior of the Coach's mouth was dark and soft and humid; Joel was covered with the hungry Coach's saliva, and he could hear the low rumble of the Coach's breathing further back in the cavernous mouth.
But Joel was given no time to contemplate his surroundings, because the Coach immediately swallowed him. Joel felt the tongue lift him; and then he felt the smooth surface of the Coach's throat pressing and sliding against every bit of his naked skin as the Coach's throat muscles took over and forced him down, down, down to the huge, nearlyempty belly.
When the tightness of the throat opened up, Joel knew that he had arrived in the Coach's stomach. There was a little air here; Joel managed to sit upright on the floor of the stomach and panted for several moments. It was dark and hot and moist, and the walls of the Coach's stomach were soft to the touch. Joel could hear the rumble of the Coach's breathing from above. Then Joel remembered that he should not be alone here. "Stu?" he asked.
"Is that Joel?" asked Stu's voice.
"Yes," said Joel. Even though he knew Stu could do nothing to get him out of the Coach's stomach, he was glad to have a friend nearby.
"How are we going to get out of here?" asked Stu, hopelessly. Stu still could not believe that the Coach, who had been every player's pal, would suddenly decide to eat them all.
After a long pause, Joel said, "I don't think we're getting back out."
The Coach, meanwhile, was having the time of his life. He picked up boy after boy and swallowed them as carelessly as he might have gobbled cocktail peanuts. He loved the struggle of those hard young bodies in his grasp. He loved the taste of young man on his tongue. And he loved the feeling of swallowing the boys whole and alive; they went down as smoothly and as easily as if he were swallowing an oyster. He could feel a pleasant sensation in his stomach which felt like the tiny boys inside still struggling. Never before had he felt power like this. What a great day this was!
Across the street, Kristoff had just succeeded in getting the computer back up. He was typing furiously, but it was becoming increasingly and painfully obvious to him that while the flesh enlargement program was working more or less properly (other than somehow being inadvertently activated when the Coach was enlarged), the flesh reduction program still had serious bugs which would take much time to resolve. Paul and Bruce looked at him helplessly as boy after boy disappeared into the Coach's mouth.
Although it was not obvious from the outside, it was getting quite crowded inside the Coach's stomach by now. The Coach had eaten nearly the entire football team, and he was starting to feel pleasantly full. He ate the last few boys more slowly, taunting them and playing with them. "You like my big balls?" the Coach asked the boy in his hand, rubbing the boy against the giant ball sac. "You like them? You're gonna help make my balls even bigger, boy!" he said, popping the squirming boy in his mouth and swallowing him at one gulp.
The Coach placed the next boy in his mouth, but did not swallow him right away. He simply used his tongue to force the boy to the back of his mouth, and opened his lips slightly so that the boy could see the way out. After a moment, the Coach could feel the boy crawling forward, trying to escape; it made a kind of tickling sensation on the Coach's huge tongue. But just as the boy stuck his tiny head out from between the lips, the Coach's tongue forced him back to start over again. Several times the Coach allowed the boy to almost escape. But finally the Coach grew tired of this game and simply swallowed the boy down.
Finally, the Coach had eaten the very last boy. He felt wonderfully full, and he slapped his huge belly in satisfaction. The three grad students watched helplessly as the Coach stretched and then strode away. Each step made a tremor like an earthquake, but the tremors grew weaker as the giant grew further away.
The football players in the Coach's dark stomach gradually succumbed to the Coach's digestion, and were absorbed and made into more of the Coach's muscle. Soon the Coach was many miles away, and when he had finally disappeared beyond the horizon, the grad students knew that they were going to have a terrible time getting him back to his right size, even if they could get the reduction program working properly. And in the meantime, what would the Coach do? When he got hungry again, how many more people would he eat?
To be continued?

Another ISP

[DiSKiLLeR]

How about finding another ISP (and telling them WHY you are changing to someone else too).

D.

You're the customer

[druzicka]

I wouldn't pay for that kind of service... There's no reason that they shouldn't be able to put in a firewall rule that permits NTP to one or two public time servers. If your ISP isn't going to serve you, go elsewhere.

SSH?

[rjw57]

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.

Try the routers...

[h3]

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

Re:Try the routers...

[kgburl]

not a good idea for hosts to access this service even if the isp is stupid enough to leave it open.

Routers typically run the ntp service on their control CPUs so having lots of hosts getting ntp service off a router means that its wasting cpu cycles serving this rather then doing the work that it was meant to do.

Re:Try the routers...

[mauryisland]

Thanks for the tip. It seems to work.

The next question is, "Where does the router get the time, and how often does it sync?" I imagine that routers have to be very accurate with regards to time, but I don't have access to any documents.

Re:Try the routers...

[Zappa]

The next question is, "Where does the router get the time, and how often does it sync?" I imagine that routers have to be very accurate with regards to time, but I don't have access to any documents.

watching your peers using ntpq also gives you the timesource of the server youre getting the time from. If you add more than one source, youll notice inaccurate timeservers quite obviously.

What if he can't

[iq in binary]

go to another ISP?

If his area is anything like where I live (near Denver, Colorado), he can't hope to find another ISP that is reasonable.

Well, at least not one that can handle the amount of traffic he might expect.

Around here, there are 2 ISP's that I (an average Joe computer nerd) can run a sturdy server through. One of them is probably as strict as his and the other couldn't even handle enough traffic to let me get /.ed

Re:What if he can't

[alfaiomega]

Around here, there are 2 ISP's that I (an average Joe computer nerd) can run a sturdy server through.

With only three ports (25, 80, 443) open for outgoing traffic I don't think the original poster wants to "run a sturdy server."

Re:What if he can't

[druzicka]

Fortunately, the poster isn't limited to ISPs in his local area. The Internet is globally accessible, so he should be able to find another host that meets his needs somewhere. For example, I live in the Midwest, and my host is located on the West Coast.

Besides, the issue really is that this guy pays money for an ISP to host his webserver... NTP is a completely legitimate service to run, but the "service" provider won't open the necessary firewall rules in order to permit the traffic. It should be up to them to comply with his requests, not find arbitrary ways to limit how he can use the service.

This is not a solution

[Christopher Doopov]

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?

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.

Re:This is not a solution

[Naikrovek]

even paranoids i know allow any and all traffic out of any given subnet, but they heavily firewall incoming traffic.

see: the 'established' state of tcp connections.

we have a rule saying that *anything* can get out, and *nothing* can get in, unless it is part of an established connection. this allows anyone to connect to any services they want safely, and not be attacked on any open ports. our web servers run on a seperate network with 80 and 443 open.

anyway, change your isp or get a job there so you can fix it. in any event, complain your ass off.

Re:This is not a solution

[Christopher Doopov]

even paranoids i know allow any and all traffic out of any given subnet, but they heavily firewall incoming traffic.

Firewalling outgoing traffic can be useful in case some of the hosts on your network were compromised (e.g. by an email worm, which can go through even in the case every incoming connections are blocked) and you want to lessen the harm which can be done using this host. For example The HoneyNet Project uses a limit of 5 outgoing connections from every compromised host, because they don't want their hosts attacking the outside world. Of course, in the case of HoneyNet it is easy, because every outgoing connection is made by a successful intruder, however my point is that outgoing traffic can do some harm and this may be a reason people block some of it.

anyway, change your isp or get a job there so you can fix it. in any event, complain your ass off.

Here I absolutely agree.

Re:This is not a solution

[p7]

He is not tunneling using HTTP. He wants to find an NTP service that runs on HTTP ports.

Re:This is not a solution

[Zappa]

even paranoids i know allow any and all traffic out of any given subnet, but they heavily firewall incoming traffic.

Nope. Having mostly WinXX systems giving Users the possibility to install soft, spy or whateverware in the internal network, filtering outbound traffic is important.
I have found some Virii/Malware just by wondering about unusual traffic from the inside and I strongly beleive this situation not only applies for me.

Re:This is not a solution

[Meleschi]

Obviously he is co-locating his equipment in the ISP's RDC. Usually, the ISP has different tiers of access for Co Located equipment. If you're co-locating and paying for a web server, they're more than likely ensure that you can't run IRC, ftp, nfs, or any other types of service, when all you're paying for is http/https.

Now, there are a few solutions to this problem:

1. Tunnel ntp through ssh (not recommended on a regular basis)

2. Use the routers as NTP servers (please ask the isp in question before using their routers as NTP servers)

3. Check or ask the isp to broadcast NTP updates on the subnet in question. That's relatively easy to do, and would be a recommended solution. I believe it does require multicast turned on though, but don't quote me on that! You'd then set up your ntp client to accept broadcasted updated, and wala, your clients have pretty darn accurate time, without the isp having to open up firewalls, or use their routers as NTP servers.

Hope this helps,
Ricardo

Re:This is not a solution

[bonezed]

i firewall incoming and outgoing... windows boxes are (l)users are a nasty combination.

i also use a bit bucket for the windows boxes, makes things so much tidier on my network

YAUASQ

[TRoLLaXoR]

that could have been solved by googling.

Re:YAUASQ

[Anonymous Coward]

I don't know why this is marked as a troll, it is the truth.

Tardis does it.

[noselasd]

Someone told me a time ago that Tardis can do ntp-over-http.

Switch ISP

[Khazunga]

Obviously, your ISP is technically incompetent. Comercially, it makes no sense limiting the type of connections allowed. Security-wise, they're finding rope to hang themselves. Their customers will do what you're attempting: hide under HTTP a slew of other protocols, introducing inefficiencies and insecurity.

Jump boats.

Re:Switch ISP

[druzicka]

I would be surprised if changing the firewall rules was truly not an available option. There are situations where outbound rules are appropriate... For example, in a DMZ where there are multiple hosts that run different exposed services, you can mitigate some of the exposure (not all) by limiting the outbound-initiated traffic.

So when it comes down to it, the ISP has adopted a firewall policy that requires more management than they're willing to perform... If they don't want to manage firewall rules for every customer, then their going to have to write an outbound ip any any rule and deal with the increased exposure. Otherwise, they will have to identifiy and write firewall rules for every service on every server that a customer wants to run... It's a pain in the ass, but the ISP made their own decision about how to manage their firewalls.

TCP Over TCP Is A Bad Idea (Re:SSH?)

[alfaiomega]

If you have a shell account, they probably allow ssh through the firewall and so you can tunnel the NTP ports over SSH.

Read Why TCP Over TCP Is A Bad Idea by Olaf Titz:

A frequently occurring idea for IP tunneling applications is to run a protocol like PPP, which encapsulates IP packets in a format suited for a stream transport (like a modem line), over a TCP-based connection. This would be an easy solution for encrypting tunnels by running PPP over SSH, for which several recommendations already exist (one in the Linux HOWTO base, one on my own website, and surely several others). It would also be an easy way to compress arbitrary IP traffic, while datagram based compression has hard to overcome efficiency limits.

Unfortunately, it doesn't work well. Long delays and frequent connection aborts are to be expected. Here is why.

Very interesting read.

Re:TCP Over TCP Is A Bad Idea (Re:SSH?)

[gl4ss]

tcp-over-tcp works quite well. udp over tcp (with use of ppp or whatever) is where it gets nasty, sometimes though being the only solution possible, because of either retarded mcse bofhs or other reasons.(ppp-over-tcp isn't possible at the moment though with just plain windows solutions, unless somebody has made some nifty hack during last month)

it's very possible to be behind a firewall, forward a port on outside of the firewall computer with ssh to the computers thats behind the firewall port 21, and serve ftp while being behind the firewall that doesnt allow incoming connections.(note that the transfers don't 'proxy', but rather go straight, pasv doesnt work though.). there is no problems with this tcp-over-tcp solution, the connections aren't unreliable or like that, granted i haven't tried it with sh** connections like 14kbps modems or so. it does work as a solution to arrange ssh from 'the wild' to computers behind firewall, for example if your cablemodem/adsl/whatever isp is retarded in their pricing schemes... there's even a nifty hack to tunnel stuff through http proxy..

Re:TCP Over TCP Is A Bad Idea (Re:SSH?)

[merlyn]

Did you read the article? It works quite well until the lower TCP starts dropping packets, and the upper TCP notices the long delay and starts retransmitting.

You've probably never used it when that happens. Try using TCP-over-TCP in a congested network, and watch it grind to a halt.

TCP-over-UDP approximates TCP-over-layer-2 well enough to ensure everything works during congestion.

Re:TCP Over TCP Is A Bad Idea (Re:SSH?)

[gl4ss]

i had read it ~month ago, or so, when looking for a way to get my friend behind tcp only on a chat of one online game without using normal modem to dialup somewhere else(unfortunately he uses windows only)..

anyways, tcp-over-tcp is 99.99% problem free in 'normal' conditions, i don't count that optical link with 10% to 20% ploss 'normal conditions'. and you need only to have that (relatively)quick, reliable link to that outer side forward-machine. if you can't have that, it's pretty futile anyways.

(anyways, the computer i used for outer-side-forward machine was my brothers computer several hundred km's away behind not so shabby adsl, no connections ever dropped or crawled to halt, unless there was other problems, like power outages&etc..).

Re:TCP Over TCP Is A Bad Idea (Re:SSH?)

[raju1kabir]

Did you read the article? It works quite well until the lower TCP starts dropping packets, and the upper TCP notices the long delay and starts retransmitting.

You've probably never used it when that happens. Try using TCP-over-TCP in a congested network, and watch it grind to a halt.

I'm using ppp-over-ssh in a few sites now, including one where I have to open an inbound terminal session over the top of a 2-hour daily rsync job that completely saturates the 128K line in question.

Keyboard echo is slow during that time, but not any more than I'd expect across a fully-congested slow line halfway around the planet. And the rsync job proceeds at the expected rate.

Possibly more importantly for my applications, though, ppp-over-ssh can be implemented in about 2 minutes using ubiquitous components - no fiddling around or building of complex software is required. In a few minutes I can explain over the phone or via IM to anyone, regardless of partial language barriers, how to set up their end of the link.

I went to the CIPE site and they don't even have documentation online (downloadable texinfo format doesn't count, any more than if it were available in Sumerian on a stone tablet under a camel somewhere) so I can't get a sense of the scale of the installation process. But when they're talking about kernel patches on the main page, I can pretty much guess it's not going to be 2 minutes and fiddle-free.

Re:TCP Over TCP Is A Bad Idea (Re:SSH?)

[Alan Shutko]

I've read the article, and used PPP over SSH for about three years now.

In the real world, it works quite well. Occasionally, you might have problems. In those rare cases I've had problems, the raw SSH was also having problems. I don't believe the problems are nearly as dire as Olaf says, unless your on a really bad network (like the 10-20% packet loss network he talks about).

How about

[Hard_Code]

Just use 'netcat' to port forward? Assuming you can also control the remote NTP server and have it listen on the HTTP port (just because you are using the "http" port, doesn't mean you /have/ to talk in HTTP).

Re:How about

[Anonymous Coward]

If the ISp is serious about security than it probably does. Application layer security is not particularly hard in the case of HTTP. Though you've got them by the balls by https. But then again I expect they'd only allow inbound connection on 443.

Supposing your host was not a butthead...

[floydigus]

You can plug a GPS handset into the serial port and get the time off that.

cron job & http

[gabe]

so, assuming for some reason you can't just find an isp that doesn't suck, why not just write a script that will pull / parse the time from some website and setup a cron job to run it?

Re:cron job & http

[i_am_nitrogen]

I used to do this (I'm not the original poster), and the latency introduced by the HTTP connection, transfer, and final parsing made it more accurate to just ssh in and set the time manually. The latency was too inconsistent to simply adjust the time by a predefined or calculated amount. That's what NTP is designed to handle, anyway.

Clockspeed?

[Pathwalker]

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).

Re:Clockspeed?

[djdead]

could you put clockspeed on the laptop first and then hook it up to the server?

CONNECT

[battjt]

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

Re:CONNECT

[loki_2525]

nc worked great. cool idea!

vnc -> local ssh port is easy, but i have not idea on the ssh -> nc |proxy port. Do you have a example?

Re:CONNECT

[battjt]

I'm sure there are more optimal ways to do this.

I use MindTerm, the applet ssh client.

Joe

#!/bin/sh

if [ "$#" != "5" ]
then
echo Usage: $0 user host tmp_port proxy_host proxy_port
exit -1
fi

USER=$1
HOST=$2

TMP=/tmp/bo$$
F1=$TMP.1
F2=$TMP.2
PORT=$3
PR OXY=$4
PROXY_PORT=$5

mkfifo $F1
mkfifo $F2
(
echo CONNECT $HOST:22 HTTP/1.0 >> $F2 ;
echo >> $F2 ;
nc $PROXY $PROXY_PORT ) $F1 &
nc -l -p $PORT > $F2 $F1 &
ssh -p $PORT $USER@localhost
rm $F1 $F2

Re:CONNECT

[battjt]

Now with all the < and > marks.

#!/bin/sh

if [ "$#" != "5" ]
then
echo Usage: $0 user host tmp_port proxy_host proxy_port
exit -1
fi

USER=$1
HOST=$2

TMP=/tmp/bo$$
F1=$T MP.1
F2=$TMP.2
PORT=$3
PROXY=$4
PROXY_PORT=$5

mkfifo $F1
mkfifo $F2
(
echo CONNECT $HOST:22 HTTP/1.0 >> $F2 ;
echo >> $F2 ;
nc $PROXY $PROXY_PORT ) < $F2 > $F1 &
nc -l -p $PORT > $F2 < $F1 &
ssh -p $PORT $USER@localhost
rm $F1 $F2

What about the ISP's servers?

[Phoukka]

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?

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 /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...

As an ISP Admin

[DSL-Admin]

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.

Use theirs, get your own, or go elsewhere.

[ripler]

Usually, an ISP will run NTP on their routers. Check the gateway they provide, and see if it runs NTP. As an alternative, they may run something like timed on one of their servers.

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.

New ISP

[rogerl]

No, the ISP will not change the firewall rules.

Not to state the obvious answer here, but get a new ISP and be done with it.

NTP over TCP

[funky womble]

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.

IN SOVIET RUSSIA

[inteller]

NTP tunnels through YOU!

Re:IN SOVIET RUSSIA

[Anonymous Coward]

That's gotta be painful.

GPS

[gmiller123456]

You can use a GPS receiver which has a serial port and use that. But that's kind of an expensive clock.

Does anybody know of one of the Shortwave clocks (that use WWV) that output the time?

Re:GPS

[Webmoth]

Check out EndRun Techonologies. Stratum 1 time servers using either GPS or CDMA sources. Sorry, they don't have WWV ones.

A little scripting...

[Tom7]

I agree with the folks who say your ISP sucks.

That said, you can do something like the following:
Use wget to grab the correct time zone from www.time.gov.
Use sed or perl or whatever to pull out the time using a regexp.
Reformat that and pass it to 'date'.

Make this a nightly cron job and you're all set. (Of course, you should be careful about the interaction between cron and changing the system time!)

Re:A little scripting...

[iamcadaver]

#!/bin/bash
# Get UTC (GMT) time from NIST
wget -O- http://www.time.gov/timezone.cgi?UTC 2>&1 |
sed -n -e 's/.*size="[75]".*>\(.*\)<br>$/\1/p'

Are you sure

[mattboston]

that it's you ISP and not your company trying to keep it's employees from doing things they're not supposed to? Cyberbite Web Hosting http://www.cyberbite.com Like PHP? Check out PHP|architect magazine. www.phparch.com

Pretty simple solution...

[Alethes]

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.

Loophole

[_Neurotic]

Loophole

I read all of the above.

[Neck_of_the_Woods]

For pets sake, can't you people here read between the lines. This guy is not "paying" someone anything. He is most likely set some shit up behind a company firewall and is having a hard time getting his way around security set to to keep him from doing crap like this.

Ask slashdot has become the defacto "help me breach security for my own means" howto stop of choice. Yes I know how he can get around it, but I am sure as hell not going to tell him. Alas he is not asking for an elegant hack, he is asking for what amounts to a script kiddie hack to tunnel his ntp or anything else he wants.

Do your own homework if your going to do stuff like this, otherwise if I am wrong, change ISP's. An ISP that does not do what the customer asks is not longer providing a service.

Re:I read all of the above.

[Doctor Hu]

He is most likely set some shit up behind a company firewall and is having a hard time getting his way around security set to to keep him from doing crap like this.

Perhaps a mite harsh, but I tend to agree that I'd like to know the ISP's side of this story. I can understand an ISP insisting that the servers it hosts use in-house NTP sources that they run themselves and sync to public servers - it means they don't have to amend the firewall rules for NTP each time a server is added or removed. I can also - just about - understand that an ISP might have a bargain basement hosting contract that's as restrictive as this one. And if the ISP/ whatever does have what they regard as good reasons for this policy, trying to tunnel around it might not be looked on favorably. Just a thought.

Good idea.

[Futurepower(R)]

This seems like a good idea to me. However, both of my web hosts don't keep the time on their own servers current. I've never explored why.

Re:Good idea.

[Wicked Panda]

Then maybe you need to explore another ISP. I was looking and saw the comments about using the ISP's timesource. Afterall, an ISP that is that tight on security, must be using an IDS, and therefore have all the internal servers sync'd so that you can follow the trails correctly.

What?!? An ISP who doesn't know about IDS, or using authenticated NTP to sync everything? Expecially their own routers to prevent sync problems?? Maybe they don't know what they are doing, and you do need to move to a more competent provider.

The Wicked Panda .sig? what sig? we don't need no bloody .sig!

Why not ask the ISP for an NTP server to be setup

[t-maxx cowboy]

It seems logical that the ISP is using NTP to synch their server times. Why not ask them to provide you with access to a server of theirs running NTP. Seems simple enough.

Too much security

[AlecC]

(No, the ISP will not change the firewall rules.)

More fool them. If they have over-tight firewall rules, more and more people will do what you are doing - tunnel through the firewall using HTTP. OK, for NTP, that doean't matter, because it is safe. But suppose some over-clver idion builds a Telnet-over-HTTP client? Your entire security system has just gone out the window.

There is such a thing as too much security. Imagina a physical security system where you could only withdraw documents after having a full body search, fingerprint, retina print, and lie-detector test. What would happen? People wouldn't put things into the repositiry because of the problems of getting them out - so net security would fall.

If everybody started using HTTP tunnelling, firewalls would have no value at all. Of course, you have to install a tunnel-friendly client on the safe side - but if they become routine, people will do it without thinking.

Firewall

[tpurcell]

Some firewalls also run NTP. I know Raptor does. They use it so their firewall logs are accurate. Their firewall policies sound like they are good to me. Maybe open up SSH though. After all, it should be deny everything, then allow only what is explicitly needed.

Your ISP Should Provide Time Service

[John Hasler]

Tell your ISP to provide an NTP server on your side of the firewall.

httPort

[aberson]

check out httport which allows you to run TCP over HTTP (over TCP over IP). You can go right out over port 80, or anything else that's open. There are some public servers, but you can also run your own server elsewhere to tunnel out - you can encrpyt the traffic between you and your own server too. Great for getting web and email from work - setup one browser to be your personal encrypted web connection and use another as your "work" browser.

Who modded this up???

[Andy Dodd]

I wish I had mod points and a good -1 (Moron) for this post.

GPS signals have enough trouble going through trees. How do you propose that his GPS handset gets a signal through the roof of his hosting center? Do you really thing that ANY hosting provider is going to let someone run an antenna cable or serial cable to the outside roof?

I agree with everyone else on the solution in your case - Get a new ISP.

But to rephrase your question a bit and make it more applicable:

I'm behind a corporate firewall that only allows outgoing HTTP(S) via proxy. Any solutions for NTP from within my company?

Re:Who modded this up???

[floydigus]

Did the 'visitors' forget to remove your anal probe?

Re:Who modded this up???

[earlytime]

i was gonna disregard your comment as flamebait, but then i decided i'd rather respond....

First off, I disagree somewhat with the opinion that this ISP is neglecting their goal of providing service. I'm sure if this guy wants to pay he can get his own segment behind (or in front of) the firewall, and he'll have whatever ports protocols he wants open. But the reality is that most hosting providers must offer competitive prices, and that means reducing administrative overhead, and providing some "no frills" service packages. This usually means some customers share the same switched segment (in essence the same security domain), have restricted bandwith, and limited ports to communicate on. So, it's in the collective best interests of these customers that security precautions be taken across the board.

Tha said, suggesting using an NTP reciever is a genuinely helpful comment, and a good idea. Even if he can't get gps reception in his particular rack, he may be able to persuade the ISP to offer ntp service from a GPS reciever/ntp server that they buy and manage (i'd pay an extra $2/month for that, and $2*month*customer*server is a pretty good source of income. Generally a business would be more receptive to an idea that leads to more revenue. I'm sure the ISP would find a way to run an antenna for that....

Why GPS receivers are out of the question

[Andy Dodd]

I've seen at least two people suggest GPS receivers, and one suggest a WWV receiver.

These both aren't going to work - Most likely his machines are in a place where he is NOT going to be allowed to run a serial or antenna cable up to the roof of the building. GPS signals can NOT pass through the roof of a building (they have trouble even passing through trees), and most structures that hosting companies use use quite a bit of metal in their construction, so even WWV isn't going to get inside.

Using a GPS receiver is a good solution for a home user - NMEA-capable receivers are cheap (As little as $35 for the old Rand-McNally StreetFinder units for Palm IIIs on eBay, if they're still available) and accurate to within a second at least. But it's not a solution for anyone who doesn't own the building their server is located in.

not actually true

[bill_mcgonigle]

Maybe academically it is, but in the real world, TCP/TCP works fine. I develop an appliance product that tunnels a TCP protocol over SSH, and we have several dozen customers on all kinds of network using the product several times a day to move gigabytes of data. Data rates are limited by the network pipe, nothing more, using GHz celerons to do the encryption and compression.
The biggest problem is that the NAT boxes at customer sites keep changing NAT addresses, so run the SSH tunnel out of inittab.

Your ISP NTP Server...

[sjanich]

Most likely you ISP has an NTP Server...why not just sync to that?

Monopoly

[yerricde]

How about finding another ISP (and telling them WHY you are changing to someone else too).

Often, only one company provides high-speed Internet access to residential customers in a given geographic area. This is often the telephone company or the cable television company. So in effect, you may have instructed Franklin_DeMatto to either 1. downgrade to dial-up or ISDN, 2. buy a ridiculously expensive T1 line, or 3. sell one's house and move.

Dial-up is fine

[0x0d0a]

I've never understood why people can't get comfortable with dial-up. At the moment, I'm using a pretty high-speed 10Mbps connection to the Internet. Next week, I'll be on a 56k connection. I transition pretty seamlessly.

There's a bit more latency on the modem, which I could see as an issue if you ssh a lot (thought ISDN wipes that out and you don't seem to go for ISDN), but web browsing on a 56k modem is *fine*. You *do* need to have multiple windows loading while you're browsing instead of click-wait-load but I do that anyway...

Re:Dial-up is fine

[yerricde]

but web browsing on a 56k modem is *fine*.

Downloading 10 MB of binaries from Mozilla.org, Windows Update, or apt-get upgrade is not fun on 56K in geographical areas where local calls to your ISP are toll calls at 10c/min.

You *do* need to have multiple windows loading while you're browsing instead of click-wait-load but I do that anyway...

You're right about tab browsing.

Suggestions for a more competent web host company?

[Futurepower(R)]

I totally agree that I should move to a more competent web host company. However, in three days of looking I was not able to find a better one. Any suggestions?

Thats barely useable at best

[nurb432]

Id demand better services or move on..

Safety is one thing, but they are being stupid..

Re:drift

[Anonymous Coward]

Apparantly this script corrects for drift via the use of Voodoo(tm).

People, there is a reason there is an entire protocol designed for syncing time sources. Using the script above for setting your clock for the purposes of having the correct time in your logs, is about as useful as manually setting it every week using the talking clock (by phone). Hell the later probably has a better chance of being accurate with a bit of practice.

Couldn't it be done with some php script fu?

[t0qer]

I'm a PHP n00b but..

Something like that, I know the passthrough function executes a command locally, then spits the output back through http. So basically you would write a php script like the one above, name it"time.php" or something like that.

To synch, you could just use wget.

wget http://yourtimeserver.com/time.php

Then a little perl magic (i'm lost with the chompin and stuff, don't ask me)

and voila, psuedo NTP over http.