Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 2 subscribers
  • Views 6395 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

Firewall rule to force users to use OpenDNS

ScottG
I heard a good tip recently where you can setup a packet filter rule that only allows UDP port 53 to connect to OpenDNS  servers.  A smart user could go into the network TCP/IP properties on their PC and bypass the DNS settings in ASG.  The rule above would prevent their computer from connecting to any non-OpenDNS IP.  I wanted to test this on my machine, so I looked at my firewall rules and didn't find anything that allowed port 53 in the first place, so it seemed to me I don't need a new rule.  I assumed that in my configuration the ASG box is pointing to the DNS server, so a firewall rule doesn't apply here.  I expected that when I changed the DNS setting in my computer, I would not be able to get to any websites.  Well, I was able to surf the web just fine.  My question is, why is Astaro allowing this to work?  Maybe there is a default packet filter rule that was created when I installed (ver 7) that is allowing this port, but it's just not obvious by looking at the rules.  Of all the rules I added, I never added any rule that did anything with this port.

--Scott


This thread was automatically locked due to age.
  • 0
    Are you using ASL HTTP proxy?  It will lookup DNS using the ASL DNS....
  • 0 in reply to Simon Shaw
    I don't know what ASL is. Is it another Astaro product?  I'm using Astaro Security Gateway v7.301.  I due use HTTP proxy.
  • 0 in reply to ScottG
    Scott, just don't allow any DNS through the Astaro.  Force the clients to use the Astaro DNS Proxy, and set the forwarders on the Astaro DNS settings to OpenDNS servers.  That's the simple solution.
  • 0 in reply to BrucekConvergent
    Oh, and "ASL" and ASG Software are the same thing; Astaro used to call their software license only product Astaro Security Linux (ASL), but they started calling both the Appliance and the license-only product ASG .... some of us (me included sometimes) still call the software license version "ASL."
  • 0 in reply to BrucekConvergent
    How do I not allow any DNS through the Astaro?
  • 0 in reply to ScottG
    Do not have a packet filter rule that allows DNS, or "ANY" from the internal network to the outside world.  By default, if traffic is not allowed via a packet filter, it is dropped.

    Alternatively, define a Internal Network -> DNS -> ANY  Drop rule, and put it at the top of the packet filter list.
  • 0 in reply to ScottG
    Make sure none of your packet filters allow DNS queries out of the LAN.  

    Either delete any rules allowing DNS outbound, or add a rule at the top which blocks connections from the LAN to TCP/UDP port 53 on external hosts.
  • 0 in reply to Jack Daniel
    ASL=ASG now I guess, tho I like to use ASL for the software product and ASG for the hardware bundle.

    If your ASG/ASL DNS forwarders are NOT set to use opendns and your users are using the ASG/ASL proxy server, then sites will be looked up using the DNS settings on the ASL/ASG.

    As BruceK said, set your ASG/ASL forwarders to OpenDNS.
    Block all other DNS traffic from LAN.

    Should work ok.
  • 0 in reply to Simon Shaw
    I guess I could add a rule near the top that blocks DNS, but I'd like to understand how it's getting out now.  I know that everything is blocked by default so I have to create a rule to allow anything through.  Below are all my firewall rules where the destination is 'Any'.  I don't see anything allowing UDP Port 53.  Most, if not all, of these rules were created during ASG install.

    VoIP Protocols
     H323 - TCP/UDP 1:65535 → 1719:1720 
     SIP - TCP/UDP 1:65535 → 5060 

    Instant Messaging (IM)
     AOL IM - TCP 1:65535 → 5190 
     Google Talk IM - TCP 1:65535 → 5222 
     ICQ IM - TCP 1:65535 → 5190 
     IRC IM -  TCP 1:65535 → 6667:6668 
     Jabber IM -  TCP 1:65535 → 5222 
     Yahoo IM - TCP 1:65535 → 5050 

    Terminal Applications
     Apple Remote Desktop 1 - TCP/UDP 1:65535 → 3283 
     Apple Remote Desktop 2 - TCP 1:65535 → 5900 
     Citrix ICA - TCP 1:65535 → 1494 
     Microsoft Remote Desktop (RDP) - TCP 1:65535 → 3389 
     Microsfot Terminal Services (RDP) - TCP 1:65535 → 3389 
     SSH - TCP 1:65535 → 22 
     Telnet - TCP 1:65535 → 23 
     VNC - TCP 1:65535 → 5900 

    Email Messaging
     IMAP - TCP 1:65535 → 143 
     IMAP SSL - TCP 1:65535 → 993 
     POP3 - TCP 1:65535 → 110 
     POP3 SSL - TCP 1:65535 → 995 
     SMTP - TCP 1:65535 → 25 
     SMTP SSL - TCP 1:65535 → 465 

    VPN Protocols
     IPSec - AH - IP IP Protocol 51 
     IPSec - ESP - IP IP Protocol 50 
     IPSec - IKE - UDP 1:65535 → 500 
     IPSec - NAT-T - UDP 1:65535 → 4500 
     L2TP - TCP/UDP 1:65535 → 1701 
     PPTP - TCP 1:65535 → 1723 

    Media Streaming Group
     MMS - TCP 1:65535 → 1755 
     Real Audio - TCP/UDP 1:65535 → 7070 
     RTSP - TCP/UDP 1:65535 → 554


    --Scott
  • 0 in reply to ScottG
    Did you flush the dns cache on your computer when you changed the dns server when you were doing your testing? 

    At a glance I don't see anything in your packet filter rules that would be allowing the dns traffic.