"Router Solicitation" As A Rules Order Test?

Discussion in 'other firewalls' started by FireDancer, Jul 27, 2003.

Thread Status:
Not open for further replies.
  1. FireDancer

    FireDancer Registered Member

    Joined:
    Jul 24, 2003
    Posts:
    316
    Hi all,

    I am new to fire walls and for a day now I have been reading and learning about RULES and where they should be.. ALOT of trial and error !!! I was reading from a link givin to me and for the life of me cant remember what link it was and im sorry for that.... anyways this link was talking about rules and order of rules and IF I inturpeted it right the rules said I could do a "Router Solicitation" to see if the rules worked that I have.
    Well let me tell you.... LOL this is exactly what I did following these rules....
    Once you have the DHCP server IP address, you can configure your rules.

    = = = = = = = = = = =
    Rule #1:
    Description: DHCP In/Out
    Protocol: UDP
    Direction: Both
    Local End Port:68
    Application: ANY (or your DHCP program)
    Remote End Port: 67
    Remote Address: DHCP Server IP
    Rule Valid: Always
    Action: Permit
    Logging: None
    = = = = = = = = = = =
    Rule #2:
    Description: DHCP
    Protocol: UDP
    Direction: Outgoing
    Local End Port:68
    Application: ANY (or your DHCP program)
    Remote End Port: 67
    Remote Address: 255.255.255.255
    Rule Valid: Always
    Action: Permit
    Logging: None
    = = = = = = = = = = =
    After this try to release and renew your IP with Rule Learning thing on just to make sure the rules work

    Is this a viable test? and if so maybe then I can decifer all of what I got on my Firewall log.
    I can make sence of it somewhat and every last thing in the logg was BLOCKED from TCP to UDP, ICMP, NETBIOS and even LAST RULE BLOCK ALL!!!

    My blocks came in the order of this maybe someone can look and give me some input as to what i am seeing and if order looks right... I am not sure this is even a valid test
    Regards,
    FireDancer
     

    Attached Files:

  2. FireDancer

    FireDancer Registered Member

    Joined:
    Jul 24, 2003
    Posts:
    316
    opps sorry wrong gif im reposting screen shot now :)
     

    Attached Files:

  3. BlitzenZeus

    BlitzenZeus Security Expert

    Joined:
    Feb 11, 2002
    Posts:
    451
    Location:
    Oregon, USA
    You should have just added to your previous thread... :D
    Previous Thread

    That is one communication you should block, and I have not known a situation you need to allow it. If you use a router, and your having connection problems with your router you might allow it as a test, however you shouldn't need to. If you want you can even make a special rule to block it, and not have the rule logging so it doesn't fill your logs.

    BTW, under administration, in the advanced area where you can edit your rules you should goto your Miscellaneous tab, and uncheck Log suspicous packets as this will fill your logs full of junk which is basically timed out communications for the most part.
     
  4. FireDancer

    FireDancer Registered Member

    Joined:
    Jul 24, 2003
    Posts:
    316
    BlitzenZues,

    Disabled "log suspicous packets" thanks for the info..
    was this a viable test or not? did it actually show that rules worked as it was stated in the post?

    Best Regards,

    FireDancer :D
     
  5. BlitzenZeus

    BlitzenZeus Security Expert

    Joined:
    Feb 11, 2002
    Posts:
    451
    Location:
    Oregon, USA
    Well in rule based firewalls they are processed from the beginning to the end, but the logs don't usually show it unless you have your allow rules logging. The first rule that matches will stop the filtering process for that packet.

    If you want to test certain rules, you can make all the rules that would be effected by the communication logging.

    Here are two examples:

    [_] Allow icmp 8 inbound
    [x] Allow icmp 0 outbound
    [x] Block all icmp
    -- You cannot be pinged, and the last rule would have logged the inbound icmp 8 communication.

    [x] Allow icmp 8 inbound
    [x] Allow icmp 0 outbound
    [x] Block all icmp
    - You can be pinged, and the first rule would have logged the inbound icmp 8 communication.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.