Re: NIST NTP servers
> On May 11, 2016, at 6:31 AM, Leo Bicknell wrote: > ... > You're replacing one single point of failure with another. > > Personally, my network gets NTP from 14 stratum 1 sources right now. > You, and the hacker, do not know which ones. You have to guess at least > 8 to get me to move to your "hacked" time. Good luck. ...except for people who think that N internet only servers is enough redundancy. Pretty much anything with unfiltered outbound could put out enough forged UDP to effectively jam ALL the Stratum 1 servers for a given endpoint. George William Herbert Sent from my iPhone
RE: NIST NTP servers
>>> I know it's supposed to have better range and signal quality, but I thought accuracy was about the same. The variables that affect accuracy are mostly external to the signal itself (propagation delay affected by atmospheric conditions). You are correct, but the what I read from NIST is that the Enhanced (PM) format " will allow faster and more accurate synchronization, as well as further address reception at particularly low SNIR." So perhaps I should have said better "resolution" rather than "accuracy". :) John John Souvestre - New Orleans LA -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Chris Adams Sent: 2016 May 12, Thu 21:21 To: nanog@nanog.org Subject: Re: NIST NTP servers Once upon a time, John Souvestre said: > The Enhanced WWVB signal has better range and more accuracy, but I don't know if any receivers are available yet. I know it's supposed to have better range and signal quality, but I thought accuracy was about the same. The variables that affect accuracy are mostly external to the signal itself (propagation delay affected by atmospheric conditions). At one point, they were going to put a second transmitter closer to the east coast, and it was going to be at the Army's Redstone Arsenal, next to Huntsville, AL, where I live; I probably could have put a receiver in a steel box and still had good signal! NASA vetoed it though. -- Chris Adams
Re: NIST NTP servers
Once upon a time, John Souvestre said: > The Enhanced WWVB signal has better range and more accuracy, but I don't know > if any receivers are available yet. I know it's supposed to have better range and signal quality, but I thought accuracy was about the same. The variables that affect accuracy are mostly external to the signal itself (propagation delay affected by atmospheric conditions). At one point, they were going to put a second transmitter closer to the east coast, and it was going to be at the Army's Redstone Arsenal, next to Huntsville, AL, where I live; I probably could have put a receiver in a steel box and still had good signal! NASA vetoed it though. -- Chris Adams
RE: NIST NTP servers
> ... a dedicated WWVB receiver. The Enhanced WWVB signal has better range and more accuracy, but I don't know if any receivers are available yet. John John Souvestre - New Orleans LA -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jon Meek Sent: 2016 May 11, Wed 10:40 To: nanog@nanog.org list Subject: Re: NIST NTP servers A note on using a Raspberry Pi as a NTP server. In my limited home lab testing the RPi server had enough instability that Internet time sources were always preferred by my workstation after ntpd had been running for a while. Presumably this was due to the RPi's clock frequency drifting. At some point I will look at it again. If you do want to build your own Stratum 1 server you might want to glance at: https://github.com/meekj/ntp/blob/master/jon_meek_ntp_poster2009a.pdf and the references there. I had hoped to use the very low cost RPi Stratum 1 servers at $DAY_JOB, but the test device was clearly not up to the job. At some point I hope to revisit this and do some more testing like I did for that poster. I'll add in a CDMA server and a dedicated WWVB receiver. Jon
AT&T postmaster
I help run a community machine (not for my employer) and we've been trying unsuccessfully for a month to get off AT&T's email blacklist; their automated systems claim we're off, but mail is still being blocked. Can an AT&T postmaster drop me an email to help work through this? Thanks. -d
Internet DATA Center IP base utilization/Bandwidth Billing
Hello All, We are looking for software/hardware which can monitor bandwidth usage of each IP address that enters Data center/Leave data center. Based on Bandwidth usage it will draw a graph or calculate Billing. We are running Datacenter and having 2000 and more clients. they are hosted their Network devices. -- With Regards, Sathish Ippani 9177166040
Re: NIST NTP servers
[...] but I would also have doubts over running anything business critical on a RP2. We use them as reverse terminal servers, for dhcp/tftp bootstrapping other machines, and soon, NTP. They are absolutely rock solid. There's something to be said for "no moving parts inside." --lyndon
Re: NIST NTP servers
I did and it works! But as other mentioned, using a passive antenna means that you are very limited in where you can actually use the NTP server. The device failed to acquire a GPS lock with it was 2-3 feet away from a window. But when it did acquire a signal, it happily worked as a Stratum 1 device servicing what felt like all the CPE devices around Montreal. It's definitely not something that can be massively deployed to data centers where the physical layout can change a lot. It might be worth looking into an active antenna but I would also have doubts over running anything business critical on a RP2. https://coldnorthadmin.com/raspberry-pi-2-ntp-server-stratum-1/ Cheers, Laurent On 5/11/2016 6:47 AM, Dovid Bender wrote: What about something like this? http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html Has anyone used a Pi to create their own server? On Wed, May 11, 2016 at 3:24 AM, Mel Beckman wrote: Regarding Roland’s reference to time and position spoofing via a hacked GPS signal, the hacker has to get physical line of sight to the victim’s antenna in order to succeed with this attack. That’s likely within a few blocks, if not within a few feet. And a rooftop antenna might require a drone attack. And how does the drone get guidance without a reliable GPS signal? :) Eric, I agree that sometimes a site can’t get a GPS signal, but in my experience designing data centers, that’s still pretty rare. Many NTP systems use an active GPS antenna that can be hundreds of feet away. But you can always put the $300 NTP server in an outdoor enclosure and power it with PoE. There’s always CDMA, GSM, and even WWV for a less-accurate plan B time source. Here’s a somewhat pricey ($700) CDMA gizmo I haven’t investigated yet: http://www.beaglesoft.com/celsynhowworks.htm And their $400 WWV-based Stratum 1 time server: http://www.beaglesoft.com/radsynreceiver.htm So if you want non-Internet clock diversity, you can have clock diversity. You just have to pay for it. -mel On May 10, 2016, at 9:18 PM, Eric Kuhnke > wrote: For quite some time, in debian the default configuration for the ntpd.conf that ships with the package for the ntpd is to poll from four different, semi-randomly assigned DNS pool based sources. I believe the same is true for redhat/centos. In the event that one out of four sources is wildly wrong the ntpd will ignore it. If people have routers/networking equipment inside their network that only supports retrieving ntp from one IP address (or hostname) and have manually configured it to request time from a single external source, not their own internal ntpd that is <10ms away, bad things could definitely happen. It is worthwhile to have both polling from external sources via IP as well as GPS sync. Many locations in a network have no hope of getting a GPS signal or putting an antenna with a clear view to the sky, but may be on a network segment that is <4ms away from many other nodes where you can colocate a 1U box and GPS antenna. On Tue, May 10, 2016 at 9:05 PM, Joe Klein > wrote: Is this group aware of the incident with tock.usno.navy.mil & tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 years for the period of one hour, then return? The reasons were not fully explained, but the impact was global. Routers, switches, power grids, phone systems, certificates, encryption, Kerberos, logging and any tightly coupled transaction systems were impacted. So I began doing 'security research' on the topic (don't confuse me with joe hacker), and discovered both interesting and terrifying issues, which I will not disclose on an open forum. Needless to say, my suggestions are: 1. Configure a trusted time source and good time stratum architecture for your organization. 2. When identifying your source of time, the majority of the technologies can be DDOS'ed, spoofed or MITM, so consider using redundant sources and authentication. 3. For distribution of time information inside your organization, ensure your critical systems (Encryption, PKI, transactions, etc) are using your redundant sources and authentication. 4. Operating systems, programming languages, libraries, and applications are sensitive to time changes and can fail in unexpected ways. Test them before it's too late. 5. Disallow internal system to seek NTP from other sources beyond your edge routers. 6. All core time systems should be monitored by your security team or SOC. One question, is this a topic anyone would find interested at a future NANOG? Something like "Hacking and Defending time?". Joe Klein "Inveniam viam aut faciam" PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Tue, May 10, 2016 at 9:59 PM, Mel Beckman > wrote: I don't pretend to know all the ways a hacker can find out what nap servers a company uses, but I can envision a virus that could do that once behind a firewall. Every ntp response lists the current reference ntp server in the next higher stratu
Re: NIST NTP servers
The WWV signal is still accurate within a few milliseconds. Light is fast. Really fast. -mel > On May 12, 2016, at 10:19 AM, Jean-Francois Mezei > wrote: > > On 2016-05-11 10:30, Mel Beckman wrote: > >> Read deeper into the thread and you'll find where I sourced inexpensive >> RF-based NTP servers using CDMA, GSM, and even WWV. > > For shortwave, you would need to calculate propagation delay between > transmitter and receiver. (does signal reach via line of sight, bounce > against ionosphere ?). > > Since CDMA is dead outside the USA and drying in USA, I wouldn't rely on > that. If GSM towers rely on a GPS receiver on the tower and those > towers are near enough to your location (< 30km), then chances are that > blocked GPS signals at your location would also jam the signals at the > GSM antenna. > > And if you are setup to be totally autonomous in case of power failures, > you need to know whether the GSM antenna you are relying on is also on > permanent power backup or only has autonomy of a few hours.
Re: NIST NTP servers
On 2016-05-11 10:30, Mel Beckman wrote: > Read deeper into the thread and you'll find where I sourced inexpensive > RF-based NTP servers using CDMA, GSM, and even WWV. For shortwave, you would need to calculate propagation delay between transmitter and receiver. (does signal reach via line of sight, bounce against ionosphere ?). Since CDMA is dead outside the USA and drying in USA, I wouldn't rely on that. If GSM towers rely on a GPS receiver on the tower and those towers are near enough to your location (< 30km), then chances are that blocked GPS signals at your location would also jam the signals at the GSM antenna. And if you are setup to be totally autonomous in case of power failures, you need to know whether the GSM antenna you are relying on is also on permanent power backup or only has autonomy of a few hours.
Re: NIST NTP servers
On 2016-05-10 10:59, Stephane Bortzmeyer wrote: > Yes, but they may switch it off for civilian use (by going encrypted, > for instance) at any time, if it is better for *their* operations. In the days of selected availability (GPS precision reduced on purpose), the time signal was still very accurate from the point of view of using it as a time source for computers. When Clinton lifted SA, the military reserved the right to re-instate it, and stated that it reserves the right to kill the civilian signal outside the USA. The EU considered launching their own constellation to counter the US possibiliy of a shutdown. Russia launched Glonass and eliminated the need for EU to launch their own. With Glonass now fairly common in GPS receivers, the USA can't unilaterally shut it down anymore. A satellite that is visible from Syria couldn't shutdown its signal without affecting a WHOLE lot of other areas. It is more likely that the USA would just jam the frequencies from a plane over Syria or some other means to geographically block those frequencies. Today, if someone were to jam the GPS signal in an areas in USA, you'd likely hear about large number of car accidents in the news before noticing your systems canMt get time from the GPS-NTP and went to a backup ip address (nist etc).
Re: CALEA
My comments were strictly limited to my understanding of CALEA as it applied to ISPs, not telcos. A request for a lawful intercept can entail mirroring a real time stream of all data sent to/from a customer's Internet connection (cable modem/DSL/dedicated Ethernet) to a LEA. AFAIK this requires mediation before being sent to the LEA and it is the mediation server itself that initiates the intercept when so configured by the ISP. Perhaps some LEAs have undertaken the mediation function so as to facilitate these intercepts where the neither the ISP nor a third party can do so. If that were the case then very little would be needed on the part of the ISP in order to comply with a request for lawful intercept. I can say with certainty that these types of requests are being made of broadband ISPs though I agree that they are very rare. On Wed, May 11, 2016 at 2:58 PM, Ricky Beam wrote: > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel > wrote: > > AFAIK being able to do a lawful intercept on a specific, named, >> individual's service has been a requirement for providers since 2007. >> > > It's been required for longer than that. The telco I worked for over a > decade ago didn't build the infrastructure until the FCC said they were > going to stop funding upgrades. That really got 'em movin'. (suddenly "data > services" people -- i.e. ME -- weren't redheaded stepchildren.) > > have never heard of a provider, big or small, being called out for being >> unable to provide this service when requested. >> > > Where existing infrastructure is not already in place (read: T1/BRI/etc.), > the telco can take up to 60 days to get that setup. I know more than one > telco that used that grace period to actually setup CALEA in the first > place. > > did not perform intercepts routinely. >> > > The historic published figures (i've not looked in years) suggest CALEA > requests are statistically rare. The NC based telco I worked for had never > received an order in the then ~40yr life of the company. > > The mediation server needed to "mediate" between your customer aggregation >> box and the LEA is not inexpensive. >> > > And also is not the telco's problem. Mediation is done by the LEA or 3rd > party under contract to any number of agencies. For example, a telco tap > order would mirror the control and voice traffic of a POTS line (T1/PRI > channel, etc.) into a BRI or specific T1 channel. (dialup was later added, > but wasn't required in my era, so we didn't support it.) We used to test > that by tapping a tech's phone. Not having any mediation software, all I > could do is "yeap, it's sending data" and listen to the voice channels on a > t-berd. > > --Ricky >
Re: DDoS protection: Corero
hi On 05/12/16 at 01:21pm, Ragnar Sigurðsson Joensen wrote: > Quick question. Is there anyone on this list using Corero for DDoS > protection? If so I'd much appreciate an off-list review of it. Thanks in > advance. hummm ... just some generic comments when comparing "DDoS protection" one DDoS solution is NOT necessarily a cost-effective mitigation against all the various types of DDoS attacks various types of attacks: - tcp-based DDoS attacks on any port are best mitigated with iptables + tarpits ( in-house appliance could handle up to 100gig/sec ) the attacking zombie bots should crash long before they can affect your servers ( 100,000 ddos packet/sec * 2Kbyte/packet * 120sec tcp timeouts ) - udp-based DDoS attacks are best mitigated by confirming that your DNS server/app, NTP server/app, SNMP server/app, NFS, X11, etc, etc properly patched and hardened your ISP will most likely have to be involved to mitigate incoming UDP and ICMP based attacks using various methods like flow analysis/collection/mediation, rtbh, bgp, etc # # if you like the idea of just 'drop the packet" or "limit it", # then, it's too late as you have already received the DDoS packets # and the damage is done ... # - volumetric attacks ( say over 10gigbit/s ) probably will require various data-centers spread across the oceans or use the cloud ... - you will need a security policy ( infrastructure policy ) to define "legitimate traffic" and possibly incomign DDoS attacks simple minded rule: web servers should only run "apache/etc", all packets to the 65,534 ports are attacks mail servers should only run "sendmail/etc", all packets to the other 65,534 ports are attacks - DDoS attacks consisting of silly spam, virii, worms should be non-issues and imho, is easily mitigated w/ dozens of different foss tools and "company/computer/infrastructure policy" magic pixie dust alvin # # http://DDoS-Mitigator.net . http://DDoS-Simulator.net #
Re: NIST NTP servers
> On May 11, 2016, at 1:42 PM, Majdi S. Abbas wrote: > > On Wed, May 11, 2016 at 03:24:43PM +, Jay R. Ashworth wrote: >> We're all aware this project is underway, right? >> >> https://www.ntpsec.org/ > > Despite the name, I'm not aware of any significant protocol > changes. It's just a recent fork of the reference implementation > minus the refclocks, which isn't particularly helpful if you /don't/ > trust network time sources. I’ll also say that if you’re running NTP with -g beware. "This option allows the time to be set to any value without restriction” Game over if someone decided to go after you, you will never sync. Make sure systemd won’t just restart your daemon, if you get “invalid” time the process dies and then you’re off. Game over, press redo or back. (yay ti99/4a references) - Jared
Re: NIST NTP servers
On 5/11/2016 11:24 AM, Jay R. Ashworth wrote: > - Original Message - >> From: "Jared Mauch" > >>> Yes, and properly monitor your ntpd instances. >> >> And upgrade them. >> >> Some software distributors don’t ship modern software. if you >> are using a distribution packaged ntpd it’s likely old and >> difficult to determine its lineage due to how it’s packaged. >> >> If you’re using Redhat based systems consider using chrony >> instead, even the new beta fedora 24 uses 4.2.6 derived code >> vs 4.2.8 > > We're all aware this project is underway, right? > > https://www.ntpsec.org/ > Speaking of nascent time projects http://nwtime.org/projects/ntimed/ So far, I like the overall architecture of the client/slave/master task differentiation. I've played around with the client in a test environment and ~it seems to work OK~, but it looks like the project is still a bit in the future.
DDoS protection: Corero
Hello, Quick question. Is there anyone on this list using Corero for DDoS protection? If so I'd much appreciate an off-list review of it. Thanks in advance. Thanks, Ragnar Sigurðsson Joensen, rjoen...@synack.fo Operations, +40799694635 Sp/f Synack | syn...@synack.fo | +298 20
