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

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.
Parents Reply Children
  • 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.
  • 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.
  • 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."
  • How do I not allow any DNS through the Astaro?
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • No, I didn't flush the DNS, so I tried it again with flushing the DNS, and I could still get to web sites.  I had the packet filter log open and I noticed it did block some requests to UDP port 53, but it didn't affect my web browsing.

    I do have a strange problem that I don't think is related.  When I did the test above, I noticed I couldn't get to Google using my IE browser, but I had no problems with Firefox getting to Google, or any other site.  I changed the DNS settings on my PC back to point to ASG and flushed the DNS again.  I still had this Google issue with IE.  In the Packet Filter log I noticed that IP below was being blocked for some reason:

    Default DROP TCP 192.168.2.100 : 3249  → 64.233.169.147 : 80  [SYN] len=48 ttl=127 tos=0x00 

    IP Lookup on 64.233.169.147 showed this as a Google server, so I created a new Packet filter rule to allow this and then I was able to get to Google using IE.  When I did get to google.com IE gave me the following warning message: 
    "Intranet settings are now turned off by default.  Intranet settings are less secure then internet settings Click for options"

    I don't really know why IE is giving me this message.

    I can get to lots of other sites with no problem; with both DNS scenarios.

    --Scott