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

What part of “ANY” does ASL not understand?

BigO
I have been trying, without any luck, to create some packet filter rules to reduce the logging in the packet filter log.
If I create a rule similar to:
ANY -> Microsoft-SMB -> Reject -> ANY -> (Logging On) 
this works fine on all traffic between the 4 NICs on the ASL box but, alas, it does not capture any SMB packets from any external (internet) IP address.
I set the action to Reject so I can ensure the ASL box is seeing these ports. When I see that ASL is capturing these ports in the log I change the settings to Reject and turn off logging.
As all will know, ASL blocks these kind of ports/services by default but unfortunately they all turn up in the packet filter log and do the spam thing.
My question is, what part of “ANY” does ASL not understand? Why is the packet filter rule only seeing traffic across the ASL NICs?


This thread was automatically locked due to age.
Parents
  • 0
    When you're dropping from the log on version 4, ASL requires the target to be the interface (corollary: each interface needs a Drop rule).

    It is due to Linux ipfilter rule convention (but frankly it is counterintuitive, and they should attend to it). I'm not sure how this is handled in 5; someebody else who has strong experience with log dropping in 5, feel free to comment...
Reply
  • 0
    When you're dropping from the log on version 4, ASL requires the target to be the interface (corollary: each interface needs a Drop rule).

    It is due to Linux ipfilter rule convention (but frankly it is counterintuitive, and they should attend to it). I'm not sure how this is handled in 5; someebody else who has strong experience with log dropping in 5, feel free to comment...
Children
  • 0 in reply to SecApp
    Sorry, running v5.014.

    To clarify, I want to stop the logging of what is already dropped by default to make the packet filter log more readable.

    I initially set the rule to reject and have it log so that I can see, via the live log, that the rule I create is actually doing what I want it to do.
    When I see that the rule is working correctly I reconfigure it to drop and not to log, eliminating the non wanted entries in the packet filter log.
    This works with all unwanted traffic accross the NICs in ASL but does not pick up on packets that come from the outside (internet).

    I have tried setting the destination of the rule to External (Network), External (Broadcast), External (Address) and finally, ANY.
    None of these settings have stopped the log showing   "Dropped"  packets from internet sources to my ASL external address. 
    The same packet (Microsoft-SMB - 445 for example), if from any of the 3 networks (Internal, DMZ1 and DMZ2) is shown as  "Rejected"   which is what I would expect given the rule I have created.

    A question could be asked, why does Astaro see fit to log all of these dropped packets anyway? Is there a need? (other than to spam the packet filter log)

    Anyone know how I can stop all of this "dropped" packet logging (primarily SMB, netbios and Microsoft DCOM spam)?
  • 0 in reply to SecApp
    Okay, I do not know if I should be happy or mad.
    It's working now.   [:S]

    I restarted the ASL box and played with the rules again.
    The rule is now set with the destination of External (Address) and it is seeing the unwanted packets from the internet directed to my external interface.
    This is how I had it set before and it did not work then. Why has it just decided to start working now?

    Another question :-
    How long does it take for the ruleset to become active after a restart? I would have hoped immediately, but I question this after what I saw after this last restart.
    When I looked at the live packet filter log, all of the packets that were previously seen as "rejected" (before the restart) are now showing as "dropped".
    It was only after the change to one of the rules (the one that "now" sees the packet from external addresses) that the behaviour of "Rejecting" the packets came back for the other rules.
    This gets wierder and wierder every time!

    I like a lot of the new features in V5 but it is nowhere as stable/reliable as V4 in my opinion (and the WebAdmin is bloody slow, on a PIII 500 with 512MB - only 3 users).

    Can someone enlighten me on why what has been happening is happening?   
    Gert or Andreas, you moderate this area, any ideas?
  • 0 in reply to BigO
    It should always be the interface address.

    As stated by SecApp, it *IS* counterintuitive, Astaro should address this issue.

    Rules should be applied immediately.  On my platform usually takes a second or two before the rule kicks in.

    If you search the forums, this issue has come up many times.