Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 1128 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...
  • 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.
Reply
  • 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.
Children
No Data