Re: DNS Filtering

[Mark Picone <000001e59c5ae616-dmarc-request () LISTSERV EDUCAUSE EDU>]

Hi All,

Deakin has been running OpenDNS/Cisco Umbrella DNS filtering, organisation wide since Jan 2017 with minimal problems.
Our main DNS resolver hosts forward queries to Umbrella, but we also run Umbrella Virtual Appliances (Ubuntu based VM) 
which have been handy for investigations as they record the client IP of all queries.
The implementation approach we took was to block all security threats immediately and gradually block specific content 
categories for the purpose of enforcing existing IT/student policies.

There are of course times when we need to unblock specific sites or entire categories for users:
 - The domain is clearly legitimate and has been incorrectly categorised (i.e. as Web Spam or Malware)
 - The domain is incorrectly classified due to "bad neighbours" (same IP in a shared hosting environment): 
https://umbrella.cisco.com/blog/websites-and-bad-neighbors
 - The customer has a legitimate business/academic need to access the site and has a request signed by their manager, 
supervisor or lecturer to unblock

We have the capability to generate unique bypass codes for users which grant access to specific sites or whole 
categories which are usually blocked.
Without this capability then I believe we would have had much stronger resistance when it comes to filtering specific 
content categories.


All of our policies are publicly available so I have included them below to give you some idea of our approach:

Policies:
 - Information and Communications Technology Use policy: https://policy.deakin.edu.au/view.current.php?id=00133
 - Schedule A: Conditions of Information Technology Use: 
https://policy.deakin.edu.au/download.php?id=92&version=2&associated
 - Student Academic Integrity Policy: https://policy.deakin.edu.au/document/view-current.php?id=107

The policies states that ICT users must not:
- [1] Knowingly display or store electronic material that is offensive, sexually explicit or racially, religiously or 
sexually intolerant unless prior approval has been granted for the purpose of research or study
- [2] Circumvent or subvert system security measures
- [3] Use ICT Facilities, Services and Materials in ways that constitute an infringement of copyright or a license 
agreement, including but not limited to downloading, transmitting and storing of copyrighted entertainment materials
- [4] Knowingly introduce or disseminate programs or data intended to damage ICT facilities or services (this includes 
but is not limited to computer spyware, viruses, Trojan horses or worms)
- [5] Breaches of academic integrity include (but are not limited to): Contract cheating: A student requesting someone 
else to produce all or part of an assessment task that is submitted as their own work, including arrangements through a 
third party.

Content categories:
- Academic Fraud: Sites that promote educational fraud, including but not limited to plagiarism and cheating. [5]
- Adware: Sites that distribute applications which display advertisements without user's knowledge or choice. Does NOT 
include sites which serve advertising.   (nice to have - no specific policy)
- Hate / Discrimination: Sites that promote intolerance based on gender, age, race, nationality, religion, sexual 
orientation or other group identities. [1]
- P2P/File sharing: Sites that facilitate the sharing of digital files between individuals, especially via peer-to-peer 
software, including torrent sites.      [3]
- Pornography: Anything relating to pornography, including mild depiction, soft pornography or hard-core pornography. 
[1]
- Proxy / Anonymizer: Sites providing proxy bypass information or services. Also, sites that allow the user to surf the 
net anonymously, including sites that allow the user to send anonymous emails.  [2]
- Sexuality: Sites that provide information, images or implications of bondage, sadism, masochism, fetish, beating, 
body piercing or self-mutilation. This category is not intended for LGBT related sites that do not fall under the 
aforementioned criteria. [1]
- Tasteless: Sites that contain information on such subjects as mutilation, torture, horror, or the grotesque. Includes 
Pro-Anorexia and Pro-Suicide related sites. [1]
- Web Spam: Redirect targets containing unwanted Sweepstakes/Survey/Advertisements for free merchandise, pharmaceutical 
spam or Rolex distributions.    (nice to have - no specific policy)

Security categories:
- Command and Control Callbacks: Prevent compromised devices from communicating with attackers' infrastructure. [4]
- Cryptomining: Cryptomining allows organizations to control cryptominer access to mining pools and web miners. [4]
- DNS Tunneling VPN: VPN services that allow users to disguise their traffic by tunneling it through the DNS protocol. 
These can be used to bypass corporate policies regarding access and data transfer. [2]
- Malware: Enables Umbrella default security settings. Optionally block/allow Suspicious Response, Dynamic DNS, Newly 
Seen Domains, and High Risk Sites and Locations. [4]
- Phishing Attacks: Fraudulent websites that aim to trick users into handing over personal or financial information. [4]
- Potentially Harmful: Domains that exhibit suspicious behavior and may be part of an attack. [4]

Regards,

Mark Picone
Senior Systems Administrator
Deakin eSolutions

Deakin University
Geelong Waterfront Campus
1 Gheringhap Street, Geelong, VIC 3220
Phone: +61 3 52479505
Deakin University CRICOS Provider Code 00113B


-----Original Message-----
From: Alan Amesbury <amesbury () OITSEC UMN EDU>
Sent: Tuesday, 22 September 2020 3:22 AM
Subject: Re: DNS Filtering

On 11 Sep 20, at 12:52, Barton, Robert W. <bartonrt () LEWISU EDU> wrote:

> We're looking to add DNS filtering to our tool set here.  We know that filtering of any kind can be controversial, 
> even for known security specific issues, in education.  Of those that have implemented DNS filtering, how did you 
> introduce the solution and gain acceptance?

Everything we do is driven by our stated policies.  We use BIND's RPZ capabilities to selectively poison demonstrably 
malicious domains.  Acceptance hasn't ever been a problem because the poisonings are done in direct response to a 
security problem, and people seem to generally accept that.  Our policy permits this because it's a direct response to 
a security event or events.

We do not have a policy that states we filter domains in advance of a security event or other clearly demonstrable need 
to filter it, so our filtering (by way of poisoning) is done sparingly.  People seem to generally accept this because 
our policy pretty clearly describes the actions we're likely to take.


--
Alan Amesbury
Security Analyst | University Information Security (UIS) University of Minnesota | umn.edu | 612-625-8810 Information 
Security is a shared responsibility. Learn more at: https://it.umn.edu/what-security-incident

**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any 
unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in 
error, please delete it and any attachments immediately and advise the sender by return email or telephone.

Deakin University does not warrant that this email and any attachments are error or virus free.

**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community