SPF and DNS problem

Discussion in 'other firewalls' started by Karl_Menshy, Jul 8, 2003.

Thread Status:
Not open for further replies.
  1. Karl_Menshy

    Karl_Menshy Registered Member

    Joined:
    Apr 18, 2003
    Posts:
    135
    I have been recently trying Sygate Personal Firewall free; however it is a little too good in blocking ;) : when I disable the server rights for applications, no DNS server can be addressed and thus no IPs resolved. This and similar topics are discussed in the sygate forums, but more in a "guessing...try this or that" way, so maybe the experts in here can help:

    I want to set up a rule to allow DNS resolution for a choice of applications. Is it safe to set up a rule which allows UDP remote port 53/local ports 1024-4999, connections only to the DNS-server ip and for the selected applications, both incoming and outgoing.

    As for the problem: it works! But is it the safe and best way to set up a DNS rule?

    Thanks for your help.
     
  2. root

    root Registered Member

    Joined:
    Feb 19, 2002
    Posts:
    1,723
    Location:
    Missouri, USA
    Don't remember much about how to set SPF rules, but with Outpost it can be done safely, two ways.
    One is to have a global DNS rule allowing UDP to remote port 53, to the DNS IP address. No direction or local port needed.
    It is even safer to set it up on each application that needs it, UDP remote port 53, remote IP of DNS server(s).
    Sometimes my computer tries to use TCP port 53 for DNS and I have allowed that also.
    It is important to use the DNS servers IP on DNS rules as there are exploits that can be used on port 53.
     
  3. Karl_Menshy

    Karl_Menshy Registered Member

    Joined:
    Apr 18, 2003
    Posts:
    135
    Hi root,

    thanks for the advice...I was afraid that there are exploits... ;)...
     
  4. jvmorris

    jvmorris Registered Member

    Joined:
    Feb 9, 2002
    Posts:
    618
    root,

    I've never experienced this with TCP, but I know someone else who has, on occasions. Do you know why some people see this, but not others? Just curious.
     
  5. jvmorris

    jvmorris Registered Member

    Joined:
    Feb 9, 2002
    Posts:
    618
    You can find a short discussion of this at DSLR Security Forum in http://www.dslreports.com/forum/remark,7068557~root=security,1~mode=flat . Specifically, you might want to take a look at the URL in TheWiseGuy's first response on DNS. That was one I hadn't been aware of.



    Added URL tags
     
  6. Karl_Menshy

    Karl_Menshy Registered Member

    Joined:
    Apr 18, 2003
    Posts:
    135
    Very interesting reading, thanks for the link.
    So I guess (if I read and understood everything correctly :)) most of the exploits are prevented by tying the DNS rule to an app + limiting it to the DNS server ip. Good to know.
     
  7. Cynder^

    Cynder^ Guest

    Whether or not you specify the Source IP Addresses, unless the users Software Firewall uses Stateful Packet Inspection Technology over UDP Protocols it’s still very possible for one to exploit using Spoofed IP Sources… ;)
     
  8. root

    root Registered Member

    Joined:
    Feb 19, 2002
    Posts:
    1,723
    Location:
    Missouri, USA
    Hi JV. David H told me that sometimes UDP 53 gets too busy or something like that and the browser will switch to TCP to continue resolving.
    What I have noticed is that there is usually a site or two that would trigger this request for TCP port 53. I now have it allowed, but if you block it, I don't think you would ever notice the difference.

    Cynder^, I'm not sure this would be the case with every firewall. For instance, Outpost version 1 did not have SPI as such but it did look to see if the machine had originated the conversation or not. I think that every firewall vendor out there has a different concept of what SPI is, and some probably run a partial SPI firewall like Outpost did.
    I am beginning to appreciate more and more the benefits of having a software firewall with a router with SPI
     
Loading...
Thread Status:
Not open for further replies.