1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Stopping Microsoft DLL Hijack Exploit - SMB

Discussion in 'Tomato Firmware' started by unicorn02, Aug 26, 2010.

  1. unicorn02

    unicorn02 LI Guru Member

    Hi,

    is it possible to stop outgoing traffic to smb on the router with the following firewall script?

    Code:
    iptables -I FORWARD -p tcp -m multiport --dports 139,445 -j DROP
    iptables -I FORWARD -p udp -m multiport --dports 139,445 -j DROP
    Is this ok, or is there a shorter more elegant version? Can it also be done through gui options, or do I have to use the script method?

    Update: This syntax won't work. See my answer on page 2. This will work.
     
  2. rhester72

    rhester72 Network Guru Member

    That'll do it, and it has to be in the Firewall script.

    Haven't read up on the exploit - your solution blocks *all* SMB traffic, even inside your LAN. Is that really what you want?

    Rodney
     
  3. unicorn02

    unicorn02 LI Guru Member

    Are you sure that also inside LAN traffic is blocked?
    I think the inside traffic (smb) is blocked when using the -I OUTPUT option, but I am not sure...

    How would the string look like when I just want to filter smb packets outgoing to the internet?
    Maybe using "-I wanout" instead of "-I FORWARD"?
     
  4. rhester72

    rhester72 Network Guru Member

    The OUTPUT chain is only used for LAN traffic. If you are looking to block only outbound WAN traffic, you should choose the wanout chain instead.

    Rodney
     
  5. RonWessels

    RonWessels Network Guru Member

    Rodney, I don't think you are correct that it also affects LAN traffic.

    Regarding the wired LAN, it is simply a switch, so no firewall packet forwarding is performed for wired-LAN<->wired-LAN communications.

    Regarding the wireless LAN, I believe the bridging is done at a lower level than the firewall, so once again no firewall intervention is done for LAN traffic to/from the wireless LAN. Otherwise the firewall rules would have to specify what could be sent between the wired LAN and the wireless LAN.

    The FORWARD chain is only used for packets traversing between the LAN and WAN. It is not used for packets originating on the router and heading out on the WAN, nor for packets originating on the WAN and destined for the router itself (ie. not forwarded).

    The OUTPUT chain is only used for packets created on the router and destined for the WAN. Similarly the INPUT chain is only used for packets destined for the router itself that are not being forwarded.

    See this tutorial for a description of the table/chain traversal.
     
  6. rhester72

    rhester72 Network Guru Member

    You are right - the only way to block LAN-to-LAN traffic is via the INPUT chain - I just tested it. OUTPUT is indeed WAN-outbound, but the custom wanout chain is probably a better choice on Tomato.

    Rodney
     
  7. RonWessels

    RonWessels Network Guru Member

    Can you give details of your test? The INPUT chain should only affect packets going to the router itself. For other machines on the LAN (either wired or wireless), traffic should flow regardless of the router's iptables configuration.
     
  8. rhester72

    rhester72 Network Guru Member

    When I was running a honeypot, this is what I used to protect the "real" LAN from the "fake" virtual LAN:

    Code:
    # Honeynet
    
    iptables -t filter -I INPUT -s 192.168.1.0/24 -m state --state NEW -m recent --update --seconds 1 --hitcount 5 -j DROP
    iptables -t filter -I INPUT -s 192.168.1.0/24 -m state --state NEW -m recent --set
    
    iptables -t filter -I INPUT -d 192.168.1.1 -j REJECT
    iptables -t filter -I INPUT -p tcp -d 192.168.1.1 -j REJECT --reject-with tcp-reset
    iptables -t filter -I INPUT -p udp -d 192.168.1.1 --dport 53 -j ACCEPT
    iptables -t filter -I INPUT -p icmp -d 192.168.1.1 --icmp-type echo-request -j ACCEPT
    
    iptables -t filter -I INPUT -s 192.168.1.0/24 -m state --state NEW -m recent --update --seconds 1 --hitcount 5 -j DROP
    iptables -t filter -I INPUT -s 192.168.1.0/24 -m state --state NEW -m recent --set
    iptables -t filter -I INPUT -s 172.16.0.0/24 -d 192.168.1.0/24 -j DROP
    iptables -t filter -I INPUT -s 192.168.1.0/24 -d 172.16.0.0/24 -j DROP
    
    iptables -t filter -I FORWARD -s 192.168.1.0/24 -m state --state NEW -m recent --update --seconds 1 --hitcount 5 -j DROP
    iptables -t filter -I FORWARD -s 192.168.1.0/24 -m state --state NEW -m recent --set
    iptables -t filter -I FORWARD -s 172.16.0.0/24 -d 192.168.1.0/24 -j DROP
    iptables -t filter -I FORWARD -s 192.168.1.0/24 -d 172.16.0.0/24 -j DROP
    
    iptables verbose packet counts per rule validated the results, passing from a VM on one host, through a wired connection on the router, to a different physical host also on a wired connection on the same router.

    Rodney
     
  9. RonWessels

    RonWessels Network Guru Member

    I see. Firstly, you have two independent non-bridged LAN's set up here, so you will need firewall intervention to go between 192.168.1.X and 172.16.0.X. However, I wouldn't call that "LAN traffic" in the sense of your first reply.

    Secondly, as I mentioned previously, the INPUT chain rules will only affect packets destined for the router itself. Because you have two LAN's, the router will have two LAN addresses in addition to its WAN address. Your rule
    Code:
    iptables -t filter -I INPUT -s 172.16.0.0/24 -d 192.168.1.0/24 -j DROP
    is only effective for packets originating on the 172.16.0.X network and destined for 192.168.1.1 (ie. the router as addressed on the 192.168.1.1 network). Similarly, your rule
    Code:
    iptables -t filter -I INPUT -s 192.168.1.0/24 -d 172.16.0.0/24 -j DROP
    is only effective for packets originating on the 192.168.1.X network and destined for 172.16.0.1 (ie. the router as addressed on the 172.16.0.X network). It is the FORWARD chain rules that govern communication between the 172.16.0.X network and the 192.168.1.X network, not including the router itself.
     
  10. rhester72

    rhester72 Network Guru Member

    Valid point - I didn't consider the issue that it was effectively two bridged VLANs (they were bridged in the sense that 192.168.1.1 was an aliased IP to 172.16.0.1).

    Rodney
     
  11. unicorn02

    unicorn02 LI Guru Member

    OK, I did some testing and this should do the work of blocking wan outgoing SMB-traffic:

    Code:
    iptables -I wanout -p tcp --dport 139 -j DROP
    iptables -I wanout -p udp --dport 139 -j DROP
    iptables -I wanout -p tcp --dport 445 -j DROP
    iptables -I wanout -p udp --dport 445 -j DROP
     
  12. RonWessels

    RonWessels Network Guru Member

    I might be tempted to replace the "-j DROP" with "-j REJECT" to prevent timeout delays from apparently freezing the local machine.
     
  13. unicorn02

    unicorn02 LI Guru Member

    Thanks for the tip!
     
  14. Azuse

    Azuse LI Guru Member

    I understand the implications of this dll problem, but could someone explain (in simple terms) how blocking the above ports prevents it's execution, and how effective it might be?
     

Share This Page