IPFilter

[Phil Daws_2]

Hi:

I have just installed the above and have a problem understanding how to inteprete SMNP traffic. The rule I have defined is as follows :

pass in quick on lan1 proto udp from any to ###.###.###.### port = 161 keep state

But I am finding the following entries in the logfile :

06/09/2002 11:49:36.593635 lan1 @0:22 p ###.###.71.3,161 -> ###.###.71.6,56825 PR udp len 20 111 IN

Now I was under the impression that the rule would accept a connection on port 161 and then when this is handed off to another port the IPFilter would keep a track of all further communication. The entry in the logfile seems otherwise. Am I missing something?

[Wodisch]

Hi Phil,

"state" is not that usefull on UDP, especially SNMP. and "SNMP-Traps" come in on UDP/162, UDP/161 is for get/set commands.

HTH,
Wodisch

[Phil Daws_2]

Thank you, but this does still not explain why the messages are appearing when I am allowing inbound SNMP?

[Craig Rants]

There is also a log first option that you should use with the keep state option that will keep this type of reverse traffic out of your logs. Look at the ipf.5 man page for the specific recommendation. I noticed that your log option was not in the ipf rule, so it would look like

pass in quick log first ...

GL,
C

[Phil Daws_2]

Okay understand that. But at the end of my ruleset I have :

pass in log on lan1 from any to ###.###.71.6 # Log all other traffic!

So as I define my ruleset it should log everything else. So based on the SNMP rule I have it should not log anything. As I said it seems that the initial connection on port 161 occurs, it hands off the connection to another port, and then IPfilter picks this up and reports it. All the requests are coming from Cisco switches.

[Craig Rants]

Lets just say that IPF/9000 does not work exactly the same as say ipf for Solaris or ipchains on Linux. I have the same frustration, and I was told by HP that the solution is the log first option with the keep state, I don't think that's what I should have to do, but ...

Also, beware of the version you are using, get the lastest possible 3.05.04, although the website says you are downloading 3.05.05, there are kernel panic issues with the earlier versions that have cause some of my servers to reboot.

Anything else let us know.

C

[Phil Daws_2]

This would be okay if I was logging SNMP traffic but as you can see from the rule it doesnt. The only rule for logging is the final one so that I can see what other traffic is coming in and add rules as necessary.

[Craig Rants]

Is your catch all logging rule the 22nd rule of group 0? Because that is the rule that is catching your traffic, "@0:22" is the indicator of this. This may be one of the little things that they have to work through on an young product.

C

[Phil Daws_2]

Here is our current ruleset with the bits '#' out :

pass out quick proto tcp from ###.###.71.6 to any keep state # Allow all outbound TCP traffic
pass out quick proto udp from ###.###.71.6 to any keep state # Allow all outbound UDP traffic
pass out quick proto icmp from ###.###.71.6 to any keep state # Allow all outbound ICMP traffic
pass in quick on lan1 proto icmp from any to ###.###.71.6 icmp-type echo # Allow Ping ICMP
pass in quick on lan1 proto icmp from any to ###.###.71.6 icmp-type echorep # Allow Ping ICMP
pass in quick on lan1 proto icmp from any to ###.###.71.6 icmp-type 11 # Allow Traceroute ICMP
pass in quick on lan1 proto tcp from any to ###.###.71.6 port = 2531 # HP Operations Java GUI
pass in quick on lan1 proto tcp from any to ###.###.71.6 port = 5555 # HP OmniBack
pass in quick on lan1 proto tcp from any to ###.###.71.6 port = 25 # SMTP Traffic
pass in quick on lan1 proto tcp/udp from ###.###.71.62 to ###.###.71.6 port = 53 # Allow DNS traffic from ns1.###.###
pass in quick on lan1 proto tcp/udp from ###.###.71.63 to ###.###.71.6 port = 53 # Allow DNS traffic from ns2.###.###
pass in quick on lan1 proto tcp/udp from ###.###.164.104 to ###.###.71.6 port = 53 # Allow DNS traffic from NT Primary DNS
pass in quick on lan1 proto tcp/udp from ###.###.164.116 to ###.###.71.6 port = 53 # Allow DNS traffic from NT Secondary DNS
pass in quick on lan1 proto tcp/udp from ###.###.164.132 to ###.###.71.6 port = 53 # Allow DNS traffic from Win2K ADS Primary
pass in quick on lan1 proto tcp/udp from ###.###.164.133 to ###.###.71.6 port = 53 # Allow DNS traffic from Win2K ADS Secondary
pass in quick on lan1 proto udp from any to ###.###.71.6 port = 161 keep state # Allow SNMP traffic
pass in quick on lan1 proto tcp/udp from any to ###.###.71.6 port = 6000 keep state # Allow X11 traffic
pass in quick on lan1 proto tcp from any to ###.###.71.6 port = 23 flags S keep state # Allow Telnet traffic
pass in quick on lan1 proto tcp from any to ###.###.71.6 port = 1529 flags S keep state # Allow OEM traffic
block in quick on lan1 proto 54 from any to ###.###.71.6 # Block Protocol 54
block in quick on lan1 proto icmp from any to ###.###.71.6 # Block all other ICMP traffic
block in quick on lan1 proto tcp/udp from any to ###.###.71.6 port = 137 # Block NetBios
block in quick on lan1 proto tcp/udp from any to ###.###.71.6 port = 513 # Block inbound rlogin
block in quick on lan1 proto tcp/udp from any to ###.###.71.6 port = 514 # Block inbound rsh
block in log quick on lan1 proto tcp/udp from any to ###.###.71.6 port = 53 # Block other DNS traffic
block in quick on lan1 proto tcp from any to ###.###.71.6 with short # Block short packets
pass in log first quick on lan1 from any to ###.###.71.6 # Log all other traffic!


Line 24 would point to the last line if you exclude the pass outs at the top. So it would seem like a little buglet that needs ironing out.

[harry d brown jr]

You have about 70 posts that you haven't responded to:
http://forums.itrc.hp.com/cm/TopSolutions/1,,BR669256!1!questions,00.html

live free or die
harry

[Phil Daws_2]

Think I have pretty much applied points to everything now! A few are still open questions though.

[Phil Daws_2]

I have tried to script my config file like yours using groups for each protocol. But when I try and load it I get the following error :

ioctl(add/insert rule): No such process

As soon as I take out the group entries it works fine ?