[RndTbl] MTS blocking NTP

[Wyatt Zacharias]

Our "high-end" fibre business internet from MTS at work hasn't blocked any
NTP traffic.
Our internal NTP servers sync out on port 123, and it's all been allowed so
far.

--
Wyatt Zacharias



On Fri, Jan 25, 2019 at 8:55 AM Colin Stanners <cstanners at gmail.com> wrote:

> 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.
>>
>> John
>>
>> On Fri, Jan 25, 2019 at 4:55 AM Trevor Cordes <trevor at tecnopolis.ca>
>> wrote:
>>
>>> 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
>>> https://muug.ca/mailman/listinfo/roundtable
>>>
>>
>>
>> --
>> John Lange
>>
>> _______________________________________________
>> Roundtable mailing list
>> Roundtable at muug.ca
>> https://muug.ca/mailman/listinfo/roundtable
>>
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.ca
> https://muug.ca/mailman/listinfo/roundtable
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://muug.ca/pipermail/roundtable/attachments/20190125/2f1dd105/attachment-0001.html>