NETBIOS - DROP DO NOT LOG

try setting source "any" ...

Dunno if my config for dropping all netbios traffic could work for ya but here goes.

First I have a new "netbios-all" service (TCP & UDP port 135-139):

 Name   Protocol   S-Port/Client   D-Port/Server
netbios-all tcp/udp 1:65535 135:139 

Then I have defined a host for my internal network broadcast address:
Name IP address Subnet mask 
InternalBroadcast 10.0.0.255 255.255.255.255 

And then I have the following rules:

No.  From (Client) Service To (Server) Action  Command 
  1  Internal_Network__ netbios-all InternalBroadcast Drop  
  2  Any netbios-all External_Interface__ Drop
  3  Any netbios-all Any Drop 

Number 1-2 makes sure that traffic to the firewall are dropped and number 3 makes sure that any traffic that the firewall was gonna forward also gets dropped. (By looking at the rules one could think that ruled 3 was enough but by the way Astaro is designed you need to other 2 rules too)

Hope this can help a bit

Ruben Andersen

PS: This configuration is from my 3.380 beta, but should be the same for 3.2

 

    No. From (Client) Service To (Server) Action Command 
1 Internal_Network__ netbios-all InternalBroadcast Drop 
2 Any netbios-all External_Interface__ Drop
3 Any netbios-all Any Drop  [/list] 

Why would rule 3 not suffice?  I would think that ANY source network (SERVICE) and ANY destination network would mean just that...Any?  I only ask because I have been racking my brain with this same problem.  I thought it strange that you would have to be that literal in stating the rule.  I thought that as it moved down, and the packet fit a particular rule, it took that action (whether DROP or ALLOW).  How then, would a 137 UDP packet with matching source (ANY) with matching service (S-port and D-port match Definition in Service Netbios-all) with matching destination (ANY) not get processed by that rule?  (as in item 3)

This has much meaning to me, because it will change how I write my rules for the future (we are deploying these all over the place). 

I am not trying to dispute what you say (cause it works for you), I just want to understand the logic and the structure it represents.  

Thanks!  

Lets see if I can explain this in an understandable way [:)]

The "propblem" is the way ipfilter (the underlaying firewall in the linux kernel) works and the way astaro uses this. ipfilter uses chains of rules to check whats going to happen to a specific packet. 

iptables has 3 basic packet filter chains (all other chains are linked to these). One for outgoing traffic originating at the firewall itself. One for traffic destined for the firewall and one for packets that it should forward (traffic just going through the firewall).

Then when you add a rule like "Any netbios-all Any Drop" astaro will put that rule in the forward chain but *not* the incomming chain. For astaro to put a rule there you have to make the rule so it matches the firewall (either source or destination). Thats why you need "Any netbios-all External_Interface__ Drop" to drop packets that come from the inside and "Internal_Network__ netbios-all InternalBroadcast Drop" to drop packets from the inside. This last one is there because broadcast packets are also destined for the firewall (and then it will check the input chain and not the forward chain).

I for one would LOVE astaro to have an option when creating a rule that destination Any really means *any* including the firewall itself. But this could potentionally be a security risk so my guess is thats why it is like it is. Example: you define a rule "Internal_Network__ Any Any Allow". This is great because now you allowed internal clients to connect to everything on the internet. But if it also put this rule in the input chain then you could *also* connect to anything on the firewall itself. And that *could* be a problem [;)]

So hope this helps a bit

Ruben Andersen  

I really appreciate your response.  I can see that if someone had previous experience with IPchains, then the rule entry is understood.  I for one, have no previous IPchains experience...just CP, Sonicwall, Raptor, Esoft, etc...This is the fist detailed explanation of the rules nomenclature as it relates to defining and using the Networks.  All they state in the manual is "do not use Any ALL Any"...because it is bad for obvious reasons.  It just lets you infer that ALL means "ALL".  Now that I understand the Chains group...I have a couple of questions if you would not mind helping me...

1:  The way the rules are listed in the table, does it go in the order you described:  1:  Out the Firewall (Internal Interface)  2:  Into the Firewall (External Interface)  3:  Pass Through (What Interface or use ALL?)

I can appreciate the granularity this provides, and because of the nature of the firewall Default Deny, it is much more difficult to accidentally open yourself up.  I just needed to understand clearly so that I can apply my rules accordingly.  Astaro needs to define "ANY" more thoroughly in their documentation.  The description you listed is nowhere that I can find in the doc (I even checked the 4.0 manual).  If it is, please point me there and I will shut my clam.  
BTW, I really appreciate you explaining this to me and this would be great information to place in the FAQ section.  I have been getting 137 UDP packets and 67&68 DHCP packets in live log, thinking that my rules sufficed.  I thought maybe I had a hardware issue (NIC driver or card), or a misconfigured system.  Thanks!
  

I've found that this also applies to bootp (ports 67+68).  The only difference however appears to be that it does a broadcast to 255.255.255.255 instead of the local subnet broadcast address.  I'm using v4.0 and this has stopped the logging issues that I was having with Bootp.  

Hiya Richard.

Hehehe first of all I think you've been using linux longer that me then... First installed SmothWall in dec. 2002... So you could (should? [;)]a>. Anyways...

The 3 chains are completely seperate so order for adding to each of them are unimportant. Further I think you got it a bit wrong how they work.

1) Input chain
This chain handles all input to the firewall (traffic that the firewall itself should answer). It works on all interfaces. Example: When someone tries to connect to the httpd of the firewall. Then you have rules in the input chain to allow/deny access from whatever you defined. This rule handles all packets to any of the firewalls interfaces including broadcasts.

2) Output chain
This one is used whenever the firewall itself tries to make a connection to something. Example: When you click up2date and the firewall connects to astaro's service. This chain is also working for all interfaces in the firewall (same chain if firewall tries to connect to an internet host and to a host on your LAN).

3) Forward chain
Well... This is pretty much everything else [;)]nternal webserver.

So chain 3 is the most interesting for firewall use since it's here that all rules regarding what services are allowed trough the firewall is located. The first 2 chains are basicly just for the protection of the firewall itself.

Ruben Andersen  

Excellent!!  Very good explanation of IPChains.  BTW - I fit the profile ~Jack of all OS....master of none... 

This information is very enlightening.  I am going to get a book or DL a FAQ/DOC on IPChains.  I see that you have read a few, so perhaps you would not mind recommending a few to me?   

Not wanting to seem lazy...just that I am sure there are mountains of Docs on the subject, and sometimes it's nice to speak with someone who has filtered it.  

I appreciate your response...and I will post back if I have anything else to add.  

Thanks Ruben!!             [;)]
  

> Very good explanation of IPChains.  
> I am going to get a book or DL a FAQ/DOC on IPChains. 

Remember, it is *IPTABLES* that is being discussed here.  IPCHAINS is an older technology that doesn't handle state.  Astaro uses the 2.4 kernel and IPTABLES, so make sure you get your docs on the right thing...

-danielrm26  

It was over a month ago that I posted the question. I never received a notice the thread had been updated... 

Anyhow, the suggestion(s) certainly work and we have a fine explanation of the triple chain paradigm with iptables. Do I get bonus points for asking at least?  [;)]

-zeek 

It was over a month ago that I posted the question. I never received a notice the thread had been updated... 

Anyhow, the suggestion(s) certainly work and we have a fine explanation of the triple chain paradigm with iptables. Do I get bonus points for asking at least?  [;)]

-zeek