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

Packet Filter Log file question

Every day I average 5000 logs  from my ISP's DHCP server in a 24hr log file. I have tried to set it up so that these are not logged but have failed at every attempt. I submit my daily log files to a security web site and it would save me A LOT of time daily if I didn't have to clean out my ISP's DHCP server log. Any one have any ideas?? I am stumped here.. [:S]  


This thread was automatically locked due to age.
Parents
  • cschmit, please give us a sample of the log & explain what you have tried to do about the matter. It would be also useful to know about your settings, whether you need dhcp etc.  
  • Here is the sample of what I want to filter out:

    2003-Sep  1 00:07:09 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=364TOS=0x00 PREC=0x00 TTL=255 ID=23531 PROTO=UDP SPT=67 DPT=68 LEN=344
     
    2003-Sep  1 00:08:53 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=344 TOS=0x00 PREC=0x00 TTL=255 ID=23666 PROTO=UDP SPT=67 DPT=68 LEN=324 

    2003-Sep  1 00:08:53 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=344 TOS=0x00 PREC=0x00 TTL=255 ID=23667 PROTO=UDP SPT=67 DPT=68 LEN=324 

    2003-Sep  1 00:09:53 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=361 TOS=0x00 PREC=0x00 TTL=255 ID=23738 PROTO=UDP SPT=67 DPT=68 LEN=341 

    2003-Sep  1 00:09:53 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=361 TOS=0x00 PREC=0x00 TTL=255 ID=23740 PROTO=UDP SPT=67 DPT=68 LEN=341 

    2003-Sep  1 00:10:41 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=361 TOS=0x00 PREC=0x00 TTL=255 ID=23797 PROTO=UDP SPT=67 DPT=68 LEN=341 

    2003-Sep  1 00:10:41 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=361 TOS=0x00 PREC=0x00 TTL=255 ID=23799 PROTO=UDP SPT=67 DPT=68 LEN=341 

    2003-Sep  1 00:11:15 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=361 TOS=0x00 PREC=0x00 TTL=255 ID=23833 PROTO=UDP SPT=67 DPT=68 LEN=341 

    2003-Sep  1 00:11:15 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=361 TOS=0x00 PREC=0x00 TTL=255 ID=23835 PROTO=UDP SPT=67 DPT=68 LEN=341 

    2003-Sep  1 00:13:57 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=361 TOS=0x00 PREC=0x00 TTL=255 ID=24028 PROTO=UDP SPT=67 DPT=68 LEN=341 

    2003-Sep  1 00:13:57 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=361 TOS=0x00 PREC=0x00 TTL=255 ID=24030 PROTO=UDP SPT=67 DPT=68 LEN=341 

    2003-Sep  1 00:19:36 firewall kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:7b:8a:68:54:08:00 SRC=10.50.192.1 DST=255.255.255.255 LEN=361 TOS=0x00 PREC=0x00 TTL=255 ID=24462 PROTO=UDP SPT=67 DPT=68 LEN=341 



    I have tried creating a rule specific to this DHCP IP (10.50.192.1) to drop.I have actually tried several versions of this rule and nothing works. I still see this in my log files 5000+ times a day. 

    Yes I do run DHCP but for some reason my DHCP server never shows up in this log file. I have comfirmed with ISP that this is the address of their DHCP server.  
  • okay, so you tried something like

    isp_dhcp any any drop   or
    isp_dhcp dhcp any drop  ?

    did you try

    any any global_broadcast drop  ?

    where global broadcast equals to 255.255.255.255 (of course you would need to define isp_dhcp/10.50.192.1 and global broadcast into networks & dhcp/67-68 into services first)

    is this 10.50.192.1 also your gw on the external interface?  
  • isp_dhcp any any drop or
    isp_dhcp dhcp any drop

    Yep Tried both... nothing changed... [:(]

    any any global_broadcast drop

    This one I have not tired...will have to try it....

    No 10.50.192.1 is not my GW on my external....GW is a 24.94.x.x  
  • >No 10.50.192.1 is not my GW on my external....GW is a 24.94.x.x 
    okay, just checking if 10.50.192.1 was somehow necessary for you .. is it? for example, eth1 gets it's address from dhcp or anything like that?  
  • eth1 which is my external gets it's IP from it but nothing internal needs that IP..... 
  • Do this,

    Make a packetfilter rule that goes from the broadcast definition for your internal intefaces (internal_broadcast, dmz_broadcast, lan_broadcast etc..>), on any service going to anywhere, and drop it. Windows machines are noisy things and they will easily fill your logs with useless broadcasts, which by default are logged by the ASL's log/drop policy.

    Make a rule for each "internal" broadcast interface you may have (or group them together) and move the rules to the top. Your logs should now be 90% cleaner. 
  • I have done that Venom and that stoped all my internal broadcasts but that did not stop the DHCP broadcast from my ISP.... [:(] 
  • Just reverse the rule then,

    try from:

    external_broadcast

    and drop instead of log/drop (default)
    that should work. The internal drops only cover machines on your network, but your isp still broadcasts with .255 which can be dropped and not logged. 

    It looks like it's coming from 10.50.192.1  heading to 255.255.255.255, so you should be able to create a definition for 255.255.255.255 and make a rule that says from-any heading to 255 defintiion = drop and move it to the top.
  • Well that did it... thanks for all your help guys.. I really appreciate it...   
Reply Children
No Data