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

Dropping MS RPC traffic

BarryG
Hi, in ASL 3.219, I am having trouble dropping traffic on port 135 (MS RPC, mostly from the Blaster worm, I believe).

I have defined a service
MS-RPC with source:any, dest:any, tcp/udp, port 135, and added a rule (#1) to DROP it, but it is still showing up in the logs:
Code:
 17:25:20 216.63.220.92 2081 ->  123.123.123.70  135 TCP SYN
  

It is listed on the filter livelog page as:
 Code:
Chain USR_FORWARD (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 3014  145K DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0          tcp spts:1024:65535 dpt:135 
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0          udp spts:1024:65535 dpt:135
 

How can I get asl to not log these packets?

Thanks    


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to Simon Shaw
    Hey, why is the filter of barrygold incorrect ?!? [;)]

    The rule your are posting blocks only RPC traffic from outside to inside and not RPC traffic in different inside subnets.

    Btw. if anyone is using an ip  transit net your filter does not work ! [;)]

    greetz
      Claus  
  • 0 in reply to ClausP
    I'm not using MASQ or NAT, so I believe blocking only the ext addr would not be very helpful. 

    I have now tried blocking all internal dest addrs, but that isn't working either!

    I already have a similar rule for {netbios}, and it seems to work fine.
      
  • 0 in reply to BarryG
    OK, I just noticed something else...

    With the drop rule in place, the only blaster scans showing up are against the ips of the 3 nics in the ASL box (.1, .70, and .74)

    So, do I need to add more rules to drop these packets? 
    dest:ANY won't work?

    Thanks,
    Barry
      
  • 0 in reply to BarryG
    OK, apparently I needed to define more rules...

    A group with the addressess of all the nic's in the firewall seems to help... I probably should add another one for the broadcast and network addresses for each interface also.