| | |||||||
|
Welcome to the YD Scuba forums. You are currently viewing our boards as a guest which gives you limited access to view most discussions, articles and access our other FREE features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload your own photos and access many other special features. Registration is fast, simple and absolutely free so please, join our community today! If you have any problems with the registration process or your account login, please contact contact support. |
| Technology: Discuss Securing Windows Time service in the Non-Diving Related Forums forums: Any windows folk out there that can assist. We had some penertration tests performed on some servers, one of the ... |
| | LinkBack | Thread Tools | Display Modes |
| ||||
| Quote:
The way I normally go about things is to restrict access at the LAN borders. Only allow NTP between the server/s and the trusted time providers. If you are a bit paranoid, fit an atomic or radio clock to a Domain Controller or two, use those as the source for all other time requests, and completely shut the door to NTP through the perimeter on the firewall. If that still isn't good enough, happy trawling |
| ||||
| Thanks for the response, NTP is already closed on the firewalls, the pentesters ran the scan on the same subnets as the servers. Google used to be my friend until this little gem came along. thanks again. Mike
__________________ Every breath you take, every dive you make, I will be watching you!! |
| ||||
| Quote:
You have to question the validity of the test to your own circumstances. There is usually a lot of other traffic floating around a typical subnet announcing the Windows servers to anyone able to drive Ethereal. Quote:
Quote:
1. Accept that any host able to query the time service can discover it is a Windows server. 2. Completely replace the time syncronisation infrastructure across the Active Directory domain. |
| ||||
| If your not allowing NTP traffic outside of your "trusted perimeter" then its not really an issue. your risk assessment will most likely mitigate the attack chances via internal security mechanisms. i.e. only authorised personal on-site, only approved equipment allowed to connect to lan. Time is critical in the AD domain and its just not worth the risk trying to be too paranoid about it. Time needs to get to all servers and within the AD structure the client machines. It's the clients that can be the tricky bit. I'm assuming your clients and some servers in a distributed environment are all over the place. Davie P.S there is a decent article on Windows Time Service at technet http://technet2.microsoft.com/Window...0c0181033.mspx
__________________ |
| ||||
| Quote:
Quote:
Thanks again
__________________ Every breath you take, every dive you make, I will be watching you!! |
| ||||
| Quote:
Thanks for the technet link. Mike
__________________ Every breath you take, every dive you make, I will be watching you!! |
| Thread Tools | |
| Display Modes | |
| |
| | ||