Thread Info
  • State Verified Answer
  • +9 person also asked this people also asked this
  • Locked Locked
  • Replies 132 replies
  • Answers 1 answer
  • Subscribers 60 subscribers
  • Views 77607 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Where is V18 at?

rfcat_vk

Hi,

this request for an update on progress is for those of us that do not have access top partners/resllers.

Would some-one in the know who is allowed to provide progress on v18 please add to this thread.

I am not after guesses or conjecture, but real timelines (give or take a month).

Ian



This thread was automatically locked due to age.
Parents
No Data
Reply
  • 0 in reply to cryptochrome

    Putting NAS, phone systems etc onto a firewall is not really the same as putting networking components onto a networking device.

     

    Regarding DNS for satellite offices there is nothing wrong with putting forwarders on the UTM, with client devices using the IP address of the UTM as a DNS server - you would ideally have the firewall configured with rules that only allow DNS communication from the device to these forwarders.

     

    For the UTM, it is considered best practices to use the DNS functionality when dealing with external DNS servers, as in the UTM becomes the DNS server for internal devices - this provides an extra layer of security, and certainly with the SG firewalls by enforcing DNSSEC - and you will find that most firewall / security appliances support DNS on them for this very particular reason.

     

    For DHCP - you're damned if you do and you're dammed if you don't - it's not a security risk by having a permitter firewall perform this or not - and a lot of edge firewalls have DHCP in them for satellite offices - mainly offering DHCP relay, but some also have the ability to work as a DHCP server.

     

    Your firewall is the first line of defence, if this is breached then most of the time the hackers will be in the network anyway, so I really don't see how DNS and DHCP would be a worry at that point.

     

    The XG, as many other devices have these functionalities included as for the what if situations, as in what if a customer needs them...sometimes they do, sometimes they don't - there's no correct answer here if DNS & DHCP should be on the firewall or not - small business can enable them, larger businesses can disable them - no right answer.

     

    Reas Sophos's recommendations community.sophos.com/.../120283

Children
  • 0 in reply to BLS

    BLS said:

     

    Regarding DNS for satellite offices there is nothing wrong with putting forwarders on the UTM, with client devices using the IP address of the UTM as a DNS server - you would ideally have the firewall configured with rules that only allow DNS communication from the device to these forwarders.

    I agree on using a firewall as a forwarder, but I do not agree on running a full-blown DNS server on a firewall. 

    For the UTM, it is considered best practices to use the DNS functionality when dealing with external DNS servers, as in the UTM becomes the DNS server for internal devices - this provides an extra layer of security, and certainly with the SG firewalls by enforcing DNSSEC - and you will find that most firewall / security appliances support DNS on them for this very particular reason.

    Again, agreed. See above. The assumption on my end was that people were talking about having a DNS server on the firewall that is managing DNS zones as authoritative entity. 

    For DHCP - you're damned if you do and you're dammed if you don't - it's not a security risk by having a permitter firewall perform this or not - and a lot of edge firewalls have DHCP in them for satellite offices - mainly offering DHCP relay, but some also have the ability to work as a DHCP server.

    It very much is a security risk as outlined in my previous post. I do (again) agree that a DHCP forwarder is fine, but a full blown DHCP server has no place on a firewall (except in small business scenarios where you simply have no other option). DHCP servers belong on routers, dedicated servers, AD controllers and the like. Features that have nothing to do with security should not be put on a security device. 

    Your firewall is the first line of defence, if this is breached then most of the time the hackers will be in the network anyway, so I really don't see how DNS and DHCP would be a worry at that point.

    You guys all just think about your small networks. Larger networks have multiple layers of firewalls, and that not just in the perimeter, but also internally. The loss of one firewall would be dramatic, but it wouldn't mean hackers infiltrated the entire network. Also, it's not just about breaches. Security is also about availability. If you have just one firewall that hosts some of your more important services then you have a real problem when the firewall goes down. If you separate services, then in this particular scenario your internet is gone but you can at least still work. Those are all things that can't be denied and should be considered. Even in small businesses. 

     

    The XG, as many other devices have these functionalities included as for the what if situations, as in what if a customer needs them...sometimes they do, sometimes they don't - there's no correct answer here if DNS & DHCP should be on the firewall or not - small business can enable them, larger businesses can disable them - no right answer.

    It was a hypothetical discussion and I think I mentioned numerous times that I realize that having DNS and DHCP on the firewall is a viable option for many, and the only option for some. 

    The point I am trying to make is that not everything is a small business and you can't apply general assumptions to everyhing. I think some of you would be really surprised if you worked for a large enterprise once. No one in their right mind would ever put DNS and DHCP on their firewalls in those kind of networks.