allow the minimum, deny everthing else

[ldvaden]

A friend just posted the following on an unrelated list:

          - share techniques
          - share data where possible
          - allow the minimum, deny everything else

Is anyone else interested in a joint effort to write MT RouterOS firewall filters for the forward chain in a WISP environment which accomplishes the third point?

best regards/ldv

[Chofex]

I would certainly help you, if I knew how!!
As you know (you’ve help me in another topic) I’m running many clients in a WDS mesh, and no IP traffic has come to be a pain in the neck.
So, I’m interested, but probably won’t be of much help…

Chofex

[sergejs]

You need to create rules on the chain=forward to filter router’s clients packets.
The last rule should be ‘ip firewall filter add chain=forward action=drop’ the previous rules should allows required services,
e.g. HTTP (80 TCP port number), DNS (53 UDP and TCP), etc.
it depends on services that should be ‘allowed’.

Firewall documentation and wiki examples provides with different configuration examples. Firewall rules configuration is not too complicated, you just need to know required services characteristics (used protocol, port, etc.).

[ldvaden]

@sergejs

Firewall documentation and wiki examples provides with different configuration examples. Firewall rules configuration is not too complicated, you just need to know required services characteristics (used protocol, port, etc.).

Hi Sergejs and thanks for your post.

I agree with you on

you just need to know required services characteristics (used protocol, port, etc.)

.

At the same time, I agree with Normis when he says most problems arise from configuration errors or less than optimal configurations.

My original question goes to how complete the services chain is at demo[2].mt.lv?

BTW, I think the wiki is a great source of information and thank those who have contributed, but the last time I looked, some of the stuff in this area wouldn’t pass a syntax check if cut and pasted so I would caution others to test in a lab environment first. IIRC I corrected a syntax error or two on the wiki so others wouldn’t encounter the same errors.

It is interesting to study the rules at demo.mt.lv and at demo2.mt.lv. Especially interesting (to me) is the different order of the three rules in the input chain having to do with (in alphabetical order) established/invalid/related connections

Why the diff in the order (read: can one get into trouble accepting established connections before checking for invalid connections or vice versa)?

best regards/ldv

[janisk]

@ldvaden

Why the diff in the order (read: can one get into trouble accepting established connections before checking for invalid connections or vice versa)?

best regards/ldv

i always set invalid before established: my reasoning is hat, i do not want to mess with invalid packages, so i get rid of them as soon as possible. Usually there are not many invalid packets down to none, but if some “smartguy” tries to do something not so smart - then his effort will end fast enough.

then should come established, to bring down the latency of established connections.

and at last related, as whole i have seen it is ftp data transfer.

[ldvaden]

@ldvaden

I agree with you on

@sergejs

you just need to know required services characteristics (used protocol, port, etc.)

.

At the same time, I agree with Normis when he says most problems arise from configuration errors or less than optimal configurations.

My original question goes to how complete the services chain is at demo[2].mt.lv?

While searching for the solution to a problem in which a small number of CPE couldn’t get DHCP addresses, a review of the literature by Google led me to http://support.microsoft.com/kb/190930 and thus
http://support.microsoft.com/kb/135464/EN-US/, which says in part:

If the routers on the network are configured to forward UDP broadcasts to UDP ports 137 and 138, then the election broadcasts that are intended to remain in the subnet are forwarded to other subnets.

This has also been seen with bridges or switches between two dissimilar network segments within the same subnet.

RESOLUTION
To stop the 8003 error messages, make sure the routers on the network are not forwarding UDP broadcasts, keeping browser elections on NetBT local to each subnet and enable WINS or lmhosts on the network for netbios name resolution.

NOTE: Switches configured for VLAN’s (virtual segmentation) have to be configured on a per VLAN basis to prevent UDP broadcast propagation.

I hope this informatio is as helpful to someone else as it was to us.

best regards/ldv

[ldvaden]

@sergejs

Firewall documentation and wiki examples provides with different configuration examples. Firewall rules configuration is not too complicated, you just need to know required services characteristics (used protocol, port, etc.).

According to http://service1.symantec.com/SUPPORT/ent-security.nsf/pfdocs/2005033011582148?Open&dtype=corp

Rtvscan
Rtvscan makes a request to Winsock for TCP port 2967 on IP-based networks. This is the only port needed for default client-to-server communication. On NetWare servers, Rtvscan.nlm listens on TCP port 2968.

Note: Some versions of the Administrator’s Guide erroneously state that Symantec AntiVirus uses port 2043. It actually uses port 2967.

On Windows computers, this value can be configured by using the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\INTEL\LANDesk\VirusProtect6\CurrentVersion\AgentIPPort

If the request for the static port fails, then Rtvscan uses a dynamic TCP port. This port is assigned by Winsock on that server and can be different each time that Rtvscan requests a port.