ibpalle

What SteveHill said is indeed the main problem regarding DDOS - at the receiving end, very little can be done for mitigation locally due to the fact that it's the amount of traffic arriving that is the problem, not so much what it does.

I have my firewall on a virtual machine - a Smoothwall running Virtualbox. 2 interfaces bridged to physicals on my file server. The 2nd physical interface is not active on the file server so that's used by the firewall for my internet connection. I have an AP as well for Wireless. All on one subnet - too many home devices rely on broadcasts to communicate so decided I wouldn't bother with segregating networks. Works great - file server serves as host for 2 other VMs. One Zentyal Linux distro (SMB) for AD functionality and a test VM for my chosen Linux distro at the time. Windows, laptops, chromebooks, tablets, devices and phones all connect to same subnet.

That's a good idea. I'll put it to the team to see if they can make something of it.

Hm, sounds like you said, the search didn't trigger monitor - the search results might have. Guardian picked up on the search though so that's good. Monitor does seem to need more when picking up searches - I assume we want to have as few false positives as possible. Submit the search o Smoothwall support then we can get the team to have a look.

Was it the search itself that popped up in the safeguarding alert or was it the content of the search results?

For content filtering, Smoothwall is one of the leaders. There are a lot of interesting options and new products available so in my biased opinion, do take a look.

I think this thread has proved otherwise?

Hello all - just wanted to relay this from the management team at Smoothwall: Thank you for your comment. This was an accounting issue that is resolved. We are well aware that many of our customers work in challenging circumstances and so being a courteous, supportive and helpful partner, at all times, is incredibly important to us. If anyone has any concerns please do not hesitate to let us know.

I find it odd that it can't be done on Netsweeper - maybe if you press them a bit. Otherwise DNS redirection seems to be the best choice.

One more thing to add for reverse lookup to work. In the conditional forwarders section(networking - configuration - DNS) you will need to add the reverse lookup to the conditional forwarder pointing to your AD DNS. If you internal subnets are all in 192.168.0.0/16 for example, you will need to add an entry like this to the domains field. myad.domain 168.192.in-addr.arpa And then save the setting. The in-addr.arpa entry is subnet reversed and the in-addr.arpa at the end. So for a 10.20.9.0/24 subnet the entry would be 9.20.10.in-addr.arpa Once done, go to system - diagnostics - ip tools and try to ping an IP address there. When you do (and there's a hostname associated with that IP) the lookup should show a hostnamer before the pings, otherwise it will state - no reverse lookup found.

In order for hostnames to be recorded, a reverse DNS zone needs to be configured on your AD DNS server and dynamic hostname updates enabled. https://en.wikipedia.org/wiki/Reverse_DNS_lookup REverse lookup allows a lookup for the hostname based on IP - normal lookup is the other way around, hence reverse.

Thanks SteveHill Much more elegant and descriptive than what I put down.

No, interception is perfectly doable. If the app workaround doesn't suit users first, turn https decrypt off for the app. You can still see they are using it and for how long, just not see content. This keeps them on the BYOD instead of them switching to 4G and you will still get filter log data for their other web access - on 4G you don't get anything at all. As always, there's no 100% here. One or the other is not always the only option. One and the other and the third too even sometimes - that's the way normally in IT

Thanks for checking back in - good to hear Robert sorted it out.

Since BYOD devices aren't managed, getting a CA on those devices is all about availability. Web page with download and instructions on how to install - with a link redirect from blockpage is part of what Smoothwall does. The web page can be hosted on other locations as well. Instructions can be copied to an email with the ca as attachment and sent out in intro e-mail to students. Link on homepage to a download and install info page. As many options as possible to make it as easy for the users to find.

Smoothwall is just now releasing Classroom Management software - for Google classroom currently so will need to use Chrome. It's simple so easy to use for teachers. Might be an idea to look into that as well. If you are already using Smoothwall, pricing is even better. https://smoothwall.com/solutions/classroom-manager/

I'd like to do a complete rework of that - for now try, from a normal client, to ping hostname(only) of Smoothwall - it should work and resolve to the correct IP. If that works, change the auth method on the highlighted non-transparent proxy on port 3128 (I am assuming that's the one you mainly use) to be NTLM Identification (via redirect) and on the transparent proxy change the auth method to core authentication. Save and restart the proxy service and test. I would suggest you call support and go through a change process with them for this though - the change I proposed should be safe.

HTTPS inspection on BYOD can still be performed though and if users wan't access to app functionality and will have to use the web page to get it, then they will, rather than be without. Not without any gripes though, as usual

BYOD filtering is still an option - there will be issues with some apps but most apps have a webpage as well that could be used instead. Whatsapp, facebook for example both will work fine in the browser, just not in the app. Monitoring what users do on BYOD is important but even if HTTPS decrypt is not universally possible on BYOD the information learned can still be useful.

I am not a dev so not sure about specifics - what Arthur states seem right to me Android obviously won't be affected by this client obviously. Android does not seem to have a lot of use on School devices so it's not on the priority list at the moment. I don't think an iOS client is expected either as iPads are being phased out in most US Schools it seems.

I meant what auth method is the proxy set to use? We are using AD for verification of user credentials, but the proxy has to get those from somewhere so look at the web proxy - authentication - manage policies and tell me what auth method the proxy is set to use?

Not certain about pricing but unless you need additional infrastructure, like a cloud Smoothwall gui for policy control (If you have an on-prem already, that can be used instead) I believe the cost of the UC is included in the filtering license, but don't hold me to that

The extension is part of the new product range - the unified client is the internal name for it and if all goes according to plan, we should start seeing release to testing internal in a weeks time. I's being rolled out to select customers as well. So not long now. This is one client for Windows, MacOSX and ChromeOS. Currently the filter client is only available as a chrome extension so windows and mac clients enforce that extension installation. We will be working on supporting other browsers. Your account manager will know more about specific release dates.

What auth method is the proxy set to use and is the ad connection working otherwise (all diags green)?

Encryption certainly makes life more interesting in the web filter space. Shameless plug here - the new client from Smoothwall (currently Chrome extension only) does not perform MiTM attacks - not needed. It sits as a client extension and sees what the browsers shows, before it show this to the user. The filtering process has moved from sitting on a proxy between client and server, to a local instance on the client, reading browser output and adjusting/blocking before showing end result to the user.