Quick question for firewall and exploit analysis specialists!

Discussion in 'other firewalls' started by Gullible Jones, Jun 11, 2014.

Thread Status:
Not open for further replies.
  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    Is there anywhere I can find a list of the destination ports most commonly used by ITW remote shell payloads? Hopefully somewhere reputable (in all applicable ways)? With some statistics?

    While messing around with Metasploit, I noticed that many attack scenarios will fall flat if the shellcode can't establish a reverse connection. If the port in question is not commonly used, or not normally used by the compromised program, then a simple outbound firewall can make the whole thing trip over itself.

    OTOH, if the command server is using a more common port like 443, and the program being attacked is one that uses that port... Then an outbound firewall will not be so useful.

    What I'm interested in here is the statistical side of things. How common is the use of high ports in shellcode attacks? If I write up some outbound firewall rules, based on the typical use patterns of my Windows system (supposing that I have one ;) ), what impact does that have on my chances of being successfully compromised by an ITW shellcode exploit? How valuable are outbound firewalls as a preventative security layer on Windows?
     
  2. FOXP2

    FOXP2 Guest

    For about 20 years, I've always allowed only TCP outbounds to 80 and 443 and "ask" for everything else for apps in the browser space (browser, Flash, Java, RSS and PDF readers etc.). About 19 years ago I became no longer surprised by alerts for outbounds to unresolved servers on ephemeral ports. I also carefully examine alerts to ports like 1935, 843, 8080, etc. and find blocking rarely has any detriment and if it does, I don't need what that site has to offer. IMHO, if it's not on 80 or 443, then that data is not needed.

    I allow svchost.exe outbound UDP port 53 to the two DNS servers. Some interesting alerts pop up every now and then. Again, if it's TCP or on some other servers, I have no use for it.

    Other apps can get more complicated and require attention and care. Thunderbird, for example, is allowed only TCP to the mail server IPs on 995 and 465. explorer.exe and helpane.exe gets everything blocked. taskhost.exe is ask for everything, in and out. I have about 75 app rules.

    So, "How common is the use of high ports in...attacks?" Somewhat common in my experience.

    And yes, "if the command server is using a more common port like 443, and the program being attacked is one that uses that port... Then an outbound firewall will not be so useful." Obviously. Which is why one also runs additional layers of protection.

    "How valuable are outbound firewalls as a preventative security layer on Windows?" The question answers itself and if not, it's one of those "if it is asked, the answer won't be understood" situations. ;)

    I understand there are those who can argue with anecdotal success that an outbound rules strategy has attained irrelevance. I'm deaf to those arguments. And anything else regarding my methods...

    Cheers.
     
  3. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,026
    Location:
    The Netherlands
    Last edited: Jun 11, 2014
  4. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,273
    Windows update may need TCP out to port 80, at least on XP, when you choose to run the updates.

    There are other mail server ports. Useful list:
    http://www.arclab.com/en/amlc/list-of-smtp-and-imap-servers-mailserver-list.html
     
  5. KeyPer4Life

    KeyPer4Life Registered Member

    Joined:
    Dec 18, 2013
    Posts:
    974
    What about firewall rules for svchost.exe UDP port 68 inbound and UDP port 67 outbound? (DHCP/Bootpc)
    Remote address: 255.255.255.255 on UDP port 67 outbound.
     
  6. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    DNS rules, whether for applications or svchost.exe, should be made address and port specific. For standard DNS that's port 53 UDP, and only for the IPs of the DNS servers that you use. On mine, I have allow rules for the individual DNS IPs followed by a blocking rule for all other port 53 traffic that alerts if such attempts are detected. There have been trojans that used port 53 as a way past firewalls. IP specific rules prevent that.

    Regarding DHCP, ideally it should be allowed onluy for the IPs of the device that assigns your IP. If your router is assigning the IP for your PC, it's not that critical. That said, you could assign a static IP to the PC and shut DHCP off completely. The 255.255.255.255 on port 67 is a DHCP broadcast. See https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
     
  7. KeyPer4Life

    KeyPer4Life Registered Member

    Joined:
    Dec 18, 2013
    Posts:
    974
    My DNS rules are address and port specific. Rules are set through hardware/software firewalls. Block non-trusted IP packets
    along with ports associated with browser access to the Internet. Also extended the port blocking capabilities of Sandboxie default settings for IE browser for extra security.
     
  8. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    You might be interested in this paper.
     
  9. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    Thank you very much @MrBrian, that was what I was looking for.

    Conclusion: Unless I'm reading it wrong, outbound firewalling will not provide significant statistical defense against remote shell attacks; since most of those already use HTTP/HTTPS ports, like the browser itself. Even with an interactive firewall you probably won't see a prompt.

    IOW: don't waste your time with outbound rules on a desktop.

    [Obligatory disclaimer: I am not a firewall expert.]
     
Loading...
Thread Status:
Not open for further replies.