[RndTbl] MTS blocking NTP

[Colin Stanners]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://muug.ca/pipermail/roundtable/attachments/20190125/c5d86454/attachment.html>