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

Log entries showing when they shouldn't

dreed
ASL 6.004

My log shows dropped packets with a destination port of 445, but I'm dropping Microsoft-SMB (static definition) without logging, and this rule is near the top.  I don't understand why this traffic is being logged.  I created the rule so I don't have to see this crap in my log files.

I see many entries from various ip addresses, but here's what a sample log entry looks like:

13:06:38 24.86.30.122 2226 ->  445 TCP 48  118 CE DF SEQ=855761206 ACK=0 WINDOW=64240 SYN URGP=0 

Here's what my Rules look like:

http://www.reedkey.com/image/rules.JPG

Any advice?  Is this a bug?

Dan


This thread was automatically locked due to age.
  • 0
    Wow, I just typed up a very similar post also.
    [:P]
  • 0 in reply to BarryG
    I just read your post.  It seems that your problem occurs only when the DEST ip address doesn't exist.  But I'm seeing the dropped entries in my log for service 445 with a destination of the ip addr for my external interface.  My rule says to drop (without logging) 445 for ANY destination.   Yet there they are, bunches of them right in my log.
  • 0 in reply to dreed
    ASL's interfaces aren't part of ANY... you'll have to create another rule to deal with those.

    Barry
  • 0
    Your intent is good, but your implementation is a bit faulty. First, create a service group called something like MS-Drop for the chatty Microsoft netbios traffic that is being log dropped by the firewall anyway. Put sub-protocols 135 to 139 plus 445 in the service group.Then create two  drop rules in your filter list, right below the top rule that drops the broadcasts to the 255.255.255.255 address. One of these should drop the MS-Drop service group going to the Internal interface address, the other should drop the same service group going to the Internal network broadcast address.

    The reason you need to create  separate drop rules for the Internal interface and the Internal broadcast address, is due to the way the IPtables routing system works in Linux.

    I define three service groups on my ASL boxes. One for the protocols that I always want to drop, another containing all the protocols that I want to permit through to the Internal network, and a third with a more limited list of protocols that I wish to permit through to the DMZ network. I then use the service groups in my filter rules. That way I only need a few rules to accomplish everything that I want to do with my packet filters.
  • 0 in reply to BarryG
    BarryG, you are right -- sorta right, anyway.  When I switched the rule destination to the External Address, it dropped the packets correctly without logging them.  However, I know for a fact that "ANY" sometimes includes the External interface address because I have a rule that allows DHCP (UDP 67 --> 68) from my ISP's DHCP server to ANY (destination).  This works fine and my firewall (external address) receives the packets just fine as a DHCP client.

    So it appears that the following is true:  "ANY" does not include the external interface address when used on rules that DROP packets, but it does include the external interface address when used on rules that ALLOW packets.  I can't guarantee that this is true in all cases, but it sure seems to be the case for my set of rules.

    Here are my final rules and service definitions, new and improved:

       

       

    Thanks for the help guys, and I hope this helps someone else out there.

    Dan
  • 0 in reply to VelvetFog
    Velvetfog, my broadcast_all service group includes the 255.255.255.255 plus the broadcast addresses for both interfaces (external and internal).  Plus I was only having a problem with Microsoft spam on inbound WAN traffic.  Thanks for the tips.

    Dan
  • 0 in reply to dreed
    DHCP works because there is a hidden rule on ASL to accept DHCP on the EXT interface, IF you have it set to use DHCP.

    FWIW, In my 'crap' group, I also have:
    tcp 6129 - DameWare (worm?), which seems to be very active right now
    tcp 3127 - mydoom worm scanners

    Barry
  • 0 in reply to BarryG
    I have the same issue, only I am using ASL and have my box running in Transparent Mode.  What can I do to stop seeing these packets in the logs?????