|
||||||||||
Thanks for your answer. Sorry that I didn't answer earlier. I needed time to test some things. For your information: I use version 1.11. Manuel Kasper wrote: > There's an implicit default rule that allows connections from LAN to > m0n0wall itself regardless of the filter rule set. Is there any way to see ALL rules, including the implicit default rules? > I can't see why you should need to do that - if you've got the bad > guys on the LAN side, you have bigger things to worry about. Maybe true, but even if I had bigger things to worry about, this should not be neglected. A lot of intrusions come with a little help from the inside... I think it makes perfect sense to disable m0n0wall configuration for your LAN workstations and to enable m0n0wall for just a couple of workstations on your LAN. Imagine that an intruder somehow managed to break into a workstation from a sloppy colleague and install a keylogger... Even though the sloppy colleague may be a bigger thing to worry about, it would still be very handy to be able to shut his computer out from the firewall configuration. > The > anti-lockout rule doesn't apply to optional interfaces, so as long as > you don't have any rules on OPT1 that allow them, all connections > from OPT1 to m0n0wall itself will be blocked. This seemed to be true, until I defined a static route via OPT2: OPT2 ip: 232.232.232.232/28 static route: 216.216.216.0/24 via 232.232.232.224 on OPT2. Portscanning and pinging from 216.216.216.216 revealed that no connections were blocked (only rejected) and that it is possible to ping 232.232.232.232. Even when explicitly denying traffic. What's even worse: I can configure m0n0wall from 216.216.216.216 I have not tested this for OPT2 having an ip-adress within a private subnet (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/24), but it seems that when one configures a static route via an optional interface, m0n0wall opens its gates for the destination of that route... Maybe this is a bug? > That won't work. m0n0wall does stateful packet filtering, which means > that once a packet has been allowed by a filter rule, all packets in > the other direction that correspond to the same connection are > allowed, no matter what the ruleset says. I understand the concept of stateful packet filtering, and the default should, of course, be that corresponding packets are allowed. Still, I would like to be able to define explicit rules that ALWAYS deny certain traffic, even though they belong to an otherwise allowed connection. You may wonder why one would want this, but I think that explicitly defined rules should come before implicit rules. Will that be possible in the future? I would like to emphasize that I really like m0n0wall. The wishlist is very promising (I would really love to see the possibility of secondary networks on the WAN-interface) and it is very user friendly. I think it would be an even better product, especially for advanced users, when all explicitly defined rules would come before implicit rules. -Ivan |