Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 2 subscribers
  • Views 6383 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.
Parents Reply Children
  • 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.
  • 0 in reply to dilandau
    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
  • 0 in reply to ScottG
    I figured out the Google + IE problem is related to my VPN.  When my VPN is connected, I have this problem, when I disconnect, it goes away.

    I retested changing the DNS on my PC to point to my ISP with the VPN disconnected.  No change, I can still get to any site.

    --Scott