Securing Greenfield Service Provider Clients

Sat Oct 10 15:58:19 UTC 2020

On Sat, Oct 10, 2020 at 8:14 AM Christopher J. Wolff <cjwolff at nola.gov>
wrote:

> Dear Mr. Curtis and Nanog;
>
> Thank you for your responses.  Yes, I am investigating the feasibility of
> public internet access to help with Digital Divide issues in light of the
> COVID-19 pandemic as well as the challenges of security in this public
> application.
>
> It’s relatively straightforward to segment East-West traffic; however, I’m
> not so sure about the case of North-South.  I need to address this issue
> somehow in my assessment of risks in public networks.
>
> I do *not* want to decrypt SSL traffic.  But I would *like* to be able to
> have some black box with a subscription at the network edge prevent malware
> from being downloaded through the network.
>
> My question was whether this is even possible in a public context.  Secure
> DNS services would go a long way toward this goal.
>
> Is it fair to say that an NGFW *must* decrypt SSL traffic in order to
> fully categorize for IPS/IDS prevention?
>
> Thank you,
> CJ
>
>

Just my humble opinion, many network security devices in the middle
decrease the overall network security. Especially if they fall into the
category of NGFW, they do too much and end up blowing themselves up.

https://www.google.com/amp/s/www.zdnet.com/google-amp/article/us-cyber-command-says-foreign-hackers-will-attempt-to-exploit-new-pan-os-security-bug/

https://www.google.com/amp/s/www.bleepingcomputer.com/news/security/cisco-patches-asa-ftd-firewall-flaw-actively-exploited-by-hackers/amp/

Also, they are insanely priced and market to people based on fear.

IPS / IDS only works if you have a full time team of folks willing to tune
it. And, it is never worth it. Been the same way for 20 years.  I was
recently involved in an outage with an IPS rule taking an entire site off
line. The fix was to stop doing IPS.

The fact is,  most modern systems (win10, iOS, Android) are very secure
from a network stack and do not benefit from network based tools.  Even
windows Vista has a local firewall on by default. The real hacks that
happen in the wild are phishing ... and no network based thing is going to
stop that.  You do see occasional nsa tools turned into wannacry style
worms, but those only proliferate when SMB is enabled, and that is easily
blocked with a router acl, and is a best practice below.

For public internet access, please keep it simple. Please do not waste tax
payer money on security snake oil. As mentioned, free dns services like
1.1.1.3 and https://cleanbrowsing.org go a long way

Simple router ACLS are also good to shutdown back trafffic, take a hint
from Comcast

https://www.xfinity.com/support/articles/list-of-blocked-ports

Regards,
CB

>
>
> Get Outlook for iO <https://aka.ms/o0ukef>
>
------------------------------
>
> *From:* Curtis, Bruce <bruce.curtis at ndsu.edu>
> *Sent:* Friday, October 9, 2020 5:23:45 PM
> *To:* Christopher J. Wolff <cjwolff at nola.gov>
> *Cc:* nanog at nanog.org <nanog at nanog.org>
> *Subject:* Re: Securing Greenfield Service Provider Clients
>
> EMAIL FROM EXTERNAL SENDER: DO NOT click links, or open attachments, if
> sender is unknown, or the message seems suspicious in any way. DO NOT
> provide your user ID or password. If you believe that this is a phishing
> attempt please forward this message to phishing at nola.gov
>
>
>
> If you search for this phrase
>
>         During 2020 more than fifty percent of new malware campaigns will
> use various forms of encryption and obfuscation to conceal delivery, and to
> conceal ongoing communications, including data exfiltration.
>
> you will find lots of vendors of decryption have the phrase from Gartner
> mentioned prominently on their web site.
>
>
> I don’t think TLS decryption would be viable in our university environment.
>
> Your email address indicates that you are in a government environment and
> if so you might have more control over devices and could have a better
> chance of making decryption work.
> On the other hand if you have more control over devices a better choice
> might be to spend your resources on implementing whitelisting rather than
> decryption.
>
> Keep in mind that if you implement decryption your decryption device is in
> scope for PCI and subject to the various PCI duding and logging
> requirements.
>
>
>
> Attackers abuse Google DNS over HTTPS to download malware
>
>
> https://www.bleepingcomputer.com/news/security/attackers-abuse-google-dns-over-https-to-download-malware/
>
>
> More general and as focused on decryption but I recommend you watch these
> sessions from RSA conferences.
>
> https://www.youtube.com/watch?v=d90Ov6QM1jE
>
> https://www.youtube.com/watch?v=qzI-N0p9hFk
>
>
> And also the NIST draft on Zero Trust Architecture.  The document is
> mainly about Zero Trust but does briefly mention decryption.
>
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
>
> https://csrc.nist.gov/publications/detail/sp/800-207/final
>
>
>
>
> > On Oct 9, 2020, at 2:09 PM, Christopher J. Wolff <cjwolff at nola.gov>
> wrote:
> >
> > Dear Nanog;
> >
> > Hope everyone is getting ready for a good weekend.  I’m working on a
> greenfield service provider network and I’m running into a security
> challenge.  I hope the great minds here can help.
> >
> > Since the majority of traffic is SSL/TLS, encrypted malicious content
> can pass through even an “NGFW” device without detection and classification.
> >
> > Without setting up SSL encrypt/decrypt through a MITM setup and handing
> certificates out to every client, is there any other software/hardware that
> can perform DPI and/or ssl analysis so I can prevent encrypted malicious
> content from being downloaded to my users?
> >
> > Have experience with Palo and Firepower but even these need the MITM
> approach.  I appreciate any advice anyone can provide.
> >
> > Best,
> > CJ
>
> Bruce Curtis
> Network Engineer  /  Information Technology
> NORTH DAKOTA STATE UNIVERSITY
> phone: 701.231.8527
> bruce.curtis at ndsu.edu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201010/c567ae70/attachment.html>