Jump to content

ssouth

Members
 View Profile  See their activity

  • Posts

    185

  • Joined

Reputation

20 Excellent

About ssouth

Personal Information

  • Occupation
    IT Manager
  • Location
    York
  1. ssouth
    After running a recent security audit on AD, it highlighted that the Smoothwall object in AD still supports all insecure encryption types. This is shown in the msDS-SupportedEncryptionTypes attribute. I'm guessing that this is a legacy thing needed to support older devices? By default the setting was on DES_CBC_CRC, DES_CBC_MD5, RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 and I've changed it to a default value that supports RC4_HMAC_MD5 On Microsoft's website it says the following regards DES encryption - DES encryption uses a 56-bit key to encrypt the content and is now considered to be highly insecure. Hence, accounts that can use DES to authenticate to services are at significantly greater risk of having that account’s logon sequence decrypted and the account compromised. What are people's thoughts? Thanks in advance
  2. ssouth
    Thanks - I have emailed you. Regards
  3. ssouth
    Hi Thanks for that. I'd be very interested to see what your smoothwall access and firewall rules are relating to your chromebooks. I'd be very grateful if you could PM a couple of screenshots. It seem to me that for whatever reason the VLAN chromebook \ Secet Knock traffic is being just not being processed the same way that standard LAN \ other VLAN traffic is. A simple test of that is pings to the smoothwall when a lot of student chromebooks are connected - >250ms from the student chromebooks | <1ms from everywhere else. Thanks in advance
  4. ssouth
    Hi - tried the secret knock on and off - not a massive difference though possibly worse with the secret knock on. Not looked at channeling them through a proxy - never had to, and never had an issue when we used the connect for chromebooks app. An option though - thanks
  5. ssouth
    Hi - Yes - all ip addresses relating to the Chromebooks - all looks good there.
  6. ssouth
    Hi - yes it is already on the max value.
  7. ssouth
    We are fine with anything up to 250+ its when we get above that, that the fun starts.
  8. ssouth
    Hi No we don't clear profiles. We have our smoothwall support through NYES, but I'm quite happy for you to get involved. This morning Resource Usage on Smoothwall box has gone above 14! - why would that be? To me everything seems to point to the cloud filter - but very happy for someone to find some other issue. Regards
  9. ssouth
    Hi - I don't have \ allowed SSH access to the device, so can't run Top. Its an S9 Appliance - Intel® Xeon® E-2276G CPU @ 3.80GHz (GenuineIntel) Cores 6 (hyperthreaded to 12) Speed 3801.000 MHz 32GB Ram
  10. ssouth
    Hi - Yes, configured the secret knock method and the VLAN method as shown on their support website. Neither method seemed to make any difference sadly.
  11. ssouth
    According to our ISP all is good, thought I may need them to dig a little deeper. 500Mbit up and down with a dedicated fibre line to premises. I think the issue is more to do with the Smoothwall box and how that is maxing out - we have an S9 box.
  12. ssouth
    Cloud filter is also a total nighmare for us - I've just put a post on edugeek. If anyone can get this working properly, that would be great. For us it just "falls over" once we have a few hundred students using their own chromebooks.
  13. ssouth
    500Mbit on a 1Gbit bearer
  14. ssouth
    Hello Are they any schools out there who run a large 1 to 1 chromebook deployment and use the Smoothwall Cloud Filter on a separate VLAN? A few years ago we decided to use the cloud filter and the internet speed for the whole school just ground to a halt. We went back to the Connect for Chromebooks app method and all was fine. Over the summer we decided to try the Cloud filter again and the same thing is happening. When we get 500+ chromebooks on, the resource usage on the smoothwall box rises above 10. A simple ping to the IP address of the smoothwall box goes from <1ms to 100ms plus and also timing out. We are at a loss what to try, other than scrapping using the cloud filter again. Any advice or shared experiences would be happily recieved. Thanks in advance.
  15. ssouth
    After Easter this suddenly started working, so I suspect a Smoothwall update has sorted this. I don't recall changing anything.
×
×
  • Create New...