Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

Tunnelling NTP Through a Firewall? 76

Posted by Cliff from the at-the-tone-the-time-will-be dept.
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.)"
This discussion has been archived. No new comments can be posted.

Tunnelling NTP Through a Firewall? More

Tunnelling NTP Through a Firewall?

Comments Filter:

  • Another ISP (Score:3, Insightful)

    by DiSKiLLeR ( 17651 ) on Friday December 13, 2002 @05:52AM (#4879042) Homepage Journal
    How about finding another ISP (and telling them WHY you are changing to someone else too).

    D.

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

      • 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 (Score:2, Informative)

          by yerricde ( 125198 )

          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.

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

      • 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 (Score:2, Insightful)

        by druzicka ( 314802 )
        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.

  • SSH? (Score:3, Insightful)

    by rjw57 ( 532004 ) <richwareham@nOSPaM.users.sourceforge.net> on Friday December 13, 2002 @06:06AM (#4879100) Homepage Journal
    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.

    • TCP Over TCP Is A Bad Idea (Re:SSH?) (Score:5, Informative)

      by alfaiomega ( 585948 ) <alfaiomega@despammed.com> on Friday December 13, 2002 @07:11AM (#4879344) Homepage

      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 [sites.inka.de] 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.

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

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

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

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

  • Try the routers... (Score:5, Informative)

    by h3 ( 27424 ) on Friday December 13, 2002 @06:09AM (#4879111) Homepage Journal
    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
    • 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.
    • 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.

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

  • This is not a solution (Score:5, Insightful)

    by Christopher Doopov ( 624261 ) <doopov@despammed.com> on Friday December 13, 2002 @06:17AM (#4879137)

    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.

    • 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 (Score:4, Informative)

        by Christopher Doopov ( 624261 ) <doopov@despammed.com> on Friday December 13, 2002 @07:28AM (#4879409)

        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.

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

    • He is not tunneling using HTTP. He wants to find an NTP service that runs on HTTP ports.
    • 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

  • Tardis does it. (Score:4, Interesting)

    by noselasd ( 594905 ) on Friday December 13, 2002 @06:32AM (#4879185)
    Someone told me a time ago that Tardis [ntp-time-server.com] can do ntp-over-http.
  • 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.

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

  • Supposing your host was not a butthead... (Score:3, Informative)

    by floydigus ( 415917 ) on Friday December 13, 2002 @08:16AM (#4879595)
    You can plug a GPS handset into the serial port and get the time off that.
    • 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?
      • Did the 'visitors' forget to remove your anal probe?
      • 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....

  • cron job & http (Score:2, Informative)

    by gabe ( 6734 )
    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?
    • 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? (Score:4, Interesting)

    by Pathwalker ( 103 ) <hotgrits@yourpants.net> on Friday December 13, 2002 @08:36AM (#4879664) Homepage Journal
    If I was stuck, behind a firewall that blocked NTP, I would look into using clockspeed [cr.yp.to] 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).

  • CONNECT (Score:4, Interesting)

    by battjt ( 9342 ) on Friday December 13, 2002 @09:02AM (#4879769) Homepage
    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

    • 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?
      • 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
        • 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? (Score:3, Insightful)

    by Phoukka ( 83589 ) on Friday December 13, 2002 @09:54AM (#4879990)
    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...
    • 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.
      • 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!
    • 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.

  • As an ISP Admin (Score:3, Informative)

    by DSL-Admin ( 597132 ) on Friday December 13, 2002 @10:08AM (#4880066)
    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. (Score:4, Informative)

    by ripler ( 19188 ) on Friday December 13, 2002 @10:13AM (#4880096)
    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 [udel.edu].

    The last option is to find another ISP who will offer time services, or one that will let you find them where you want.

  • NTP over TCP (Score:4, Interesting)

    by funky womble ( 518255 ) on Friday December 13, 2002 @10:31AM (#4880235)
    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.
  • 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!)
  • 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... (Score:4, Interesting)

    by Alethes ( 533985 ) on Friday December 13, 2002 @10:58AM (#4880402)
    If you can run perl scripts on the server, grab http://nist.time.gov/timezone.cgi?/d/0 [time.gov], 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 [loopholesoftware.com]

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

    • 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.
  • 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.
  • (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.

  • Tell your ISP to provide an NTP server on your side of the firewall.
  • check out httport [htthost.com] 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.
  • 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.
  • Most likely you ISP has an NTP Server...why not just sync to that?
  • Id demand better services or move on..

    Safety is one thing, but they are being stupid..
  • 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.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close