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

Filter rules, M$ svc ports, worms and attacks

ElJefe
Greetings,

I have noticed (thanks to the latest worm attacks) that Microsoft ports like RPC(135) and others are not defined or blocked. I have made those definitions manually and set rules to block them along with some of the worm ports like 123 and 8998.

The thing that confuses me is that it has been my understanding that ASL is "mostly closed" where everything is blocked and you must define the services you want to allow. If this is true then why do I have to define RPC udp/135 and then block it? Shouldn't everything but what I allow be blocked?

I ask these questions while my first hand perception tells me that my understanding explained above is incorrect somehow. If this is indeed the case does anyone have examples of catch-all rules that will close up all External to Internal traffic that was not explicitly defined as being allowed? 

Thanks,

El Jefe  


This thread was automatically locked due to age.
  • 0
    ok..for incoming..everything that you do not specify as being allowed is by default blocked...there is an added "bonus"..if you are using NAT(masquerading) then the rule kinda changes..anything that is not spcified OR initiated by a client on the internal network is rejected...now then i am assuming you are running a Masquerading rule with a packet filter rule of internal network to external network allow all..what htis means is that anything that is originating from inside the firewall's network will be forwarded to the firewall and sent outside the firewall..so what you ahve to do is this...leave the incoming things at default...this will allow you to block these worms and such..however if you leave the general masquerading rule in place then an infected computer could scan form behind your firewall other machines...that is why you would define the rpc ports and set them to be blocked on the inside..using a rule like..internal network--->----->external interface(or any)--->drop(or log drop)...this would prevent machine form the inside from scanning outside..I have al netbios ports and protocols blocked internally just because i do not want netbios leaks..turns out I had relaly good reason(with blaster and nachi) for doing it.. 

    here are my definitions for netbios:
    rpc worm 2   tcp   445   445    
    rpc worm netbios  tcp/udp  135:139  135:139 
    rpcworm 3  tcp/udp  593  593 
    I then have in my packet filter those three 1,2,3 
    number packet filter rule is:
     { Private_Networks_-_RFC1918 }--->{ netbios }--->Any--->Drop
    my #5 rule is my general nat rule:
    { Private_Networks_-_RFC1918 }--->Any--->Any--->Allow

    As things need to get blocked internally from leaking outside i add them above the last rule..because the packet filter is order sensitive..so every packet is ran against rule 1, then 2, and so on..[:)]
  • 0 in reply to William Warren
    I am not running NAT, I am lucky and have two full class A registered networks along with a /24 for my external firewall nic. I always thought the firewall was mostly closed yet some machines would still get the dreaded "pop-up" action by outside machines hitting port 135 on an internal machine. This is where my confusion came in. If it is mostly closed how dothe packets get in? 

    Thank you for your RPC/worm definitions. I will add them to my collection. 

    If someone can explain the mostly closed yet curiously open thing I would like to hear it.

    EJ  
  • 0 in reply to ElJefe
    sounds to me like you have a rule set that is allowing this traffic form the external nic to the internal nic..also since you use public ips on all segments(if i read this right) you would be better off specifying the rules to be safe..