More realtime monitoring they offer, easier the process will be. How easy or difficult this process will be, depends very much on the monitoring and management tools your firewall vendor is providing you.
Usually this will be cleaned up in a day or two. Using the denied traffic logs and the information from the user about the application that stopped working, it is simple to add new rules that will enable the broken application. This is the point, where I switch the role of the generic rule from allow anything into deny anything and wait for some users to start complaining that some of their applications stopped working. I would continue to identify connections and applications that use these connections on the generic rule and create explicit rules for them, until the traffic left on the generic rule is no more definable where it would belong to. That will again reduce the traffic on the initial generic rule. Probably it will be HTTP/S traffic, and add explicit firewall rules for HTTP and HTTPS. Now I'd pick the next type of traffic, that is most frequent. Once this rule is enabled, there will be no more DNS traffic in the initial generic firewall rule's logs.
Also I'd drop all other outgoing DNS traffic, forcing my users to use ma internal DNS servers only. So I would create a specific rule for outgoing DNS traffic only and limit that for selected destinations and allow only for my internal DNS servers. So by watching the generic rule's traffic, I would first see a lot of outgoing DNS queries. My firewall makes it easy for me, to set up a generic firewall rule, that will let out all traffic and provide me all the required information about the connections. That will than enable you to create firewall rules for traffic you actually have - instead of rules, that you possibly might have - by scraping the web for information about required ports. This will work in combination with logging other outgoing connections - including with their application recognition. When you have really good logging capabilities, you will first of all need to log all the DNS queries, to be able to collect all the fqdn's that are actually used by your clients. So one would think, that it's pretty simple to set up all the required firewall rules - unfortunately it is not so simple.
I don't own a Sonicwall, and I have the luxury to be able to use FQDN's in firewall rules. I've read about PAC files as well as RSS feeds that can be scripted to auto-import into some Firewalls, but I'm not finding enough information to feel confident about attempting this in my environment.Īny tips/tricks/corrections will be appreciated! I'm also interested to know how other admins manage updates to Microsoft's massive list, to keep up-to-date with any new addresses added. I can try to make some sort of visual reference if none of this makes sense. I also have a SonicWALL/Firewall specific question which seemed to belong here in the SonicWALL section:īecause there are so many items/endpoints required by O365, what are the best practices for creating access rules? Specifically, If I were to create a Service Group containing ALL of the services, as well as an Object Group containing ALL of the addresses/FQDNs, would it be advisable to create a single Access Rule (LAN to WAN) for all of them? Or would it be better to create different rules for each group of addresses who share the same required ports? Some of my questions are more O365 related, and are stated here. I'm in the process of allowing outbound traffic to the extensive list of O365 IPs and URLs.
0 kommentar(er)
