[RndTbl] MTS blocking NTP
cstanners at gmail.com
Fri Jan 25 08:55:05 CST 2019
Likely they're trying to block NTP amplification attacks,
https://www.incapsula.com/ddos/attack-glossary/ntp-amplification.html , and
they went overboard on the firewall rule.
On Fri, Jan 25, 2019 at 8:51 AM John Lange <john at johnlange.ca> wrote:
> One of my favorite sayings is "never suspect a conspiracy, that which can
> be explained by incompetence". This is likely an accidental side effect of
> something else they've done because unless they are now trying to sell you
> some kind of Bell branded time-sync service, I can't think of any business
> reason why they would do this intentionally.
> Although, one thing I can think of is, perhaps there is a whole lot of
> unsecured NTP on their network being actively exploited?
> Might be worth going through the pain of opening a ticket to see if you
> can get an official answer. I believe the CRTC regulations prevent them
> from arbitrarily manipulating, blocking, or shaping the network traffic
> without disclosing what they are doing.
> On Fri, Jan 25, 2019 at 4:55 AM Trevor Cordes <trevor at tecnopolis.ca>
>> On 2019-01-25 Trevor Cordes wrote:
>> > Looks like chrony (and others) lets you specify src port, but I'm
>> > loathe to uproot the system I know because Bell is braindead. (MTS
>> > didn't use to block it, and block-happy Shaw does not block it.)
>> Epiphany moment: iptables can probably solve this. 20 minutes later:
>> iptables -t mangle -A OUTPUT -o $iext -p udp --sport 123 --dport 123 -j
>> MARK --set-mark 30
>> iptables -t nat -A POSTROUTING -p udp -m mark --mark 30 -j SNAT
>> --to-source :60000-61000
>> Works perfectly! ntpd now syncs with peers. ntpdate doesn't need -u.
>> I don't need to switch to chrony. And I don't need to wait for ntpd to
>> add this feature*. Go take a hike Bell!!!
>> *http://bugs.ntp.org/show_bug.cgi?id=1109 ... looks like never
>> Note, it could be just 1 rule, but I used 2 to make sure that I only
>> SNAT packets originating from within the actual firewall/router itself,
>> and not packets being forwarded from within the internal LAN (PC's). I
>> can't figure out a way to specify "really originated locally" other
>> than with mark, but I'm open to ideas. It's not as easy as it sounds
>> with multiple interfaces on the box, unless there's a trick I'm missing.
>> If I wanted internal LAN PCs to also have their traffic go through, I'd
>> need to use a -j MASQUERADE (it's a dynamic IP) in an extra rule and
>> change the syntax slightly. Since all internal PCs should be set to
>> use the firewall as ntp server, this shouldn't be a problem (in fact
>> could help me id broken PC ntp setups).
>> Roundtable mailing list
>> Roundtable at muug.ca
> John Lange
> Roundtable mailing list
> Roundtable at muug.ca
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Roundtable