Careful, I never said that I’d like to start a cult. Although they do have some appeal, if you’re the man at the top and followers see you as god. It brings many possibilities. But I don’t think I could ever get close to that. Don’t be fooled by “guru” written under my name, it’s just because I’m here for a long time and I posted a lot. With your posting rate, you’ll be guru too, before you know it.
But back to routers, networks and stuff…
I’m not much for outgoing filtering. I’m not saying that it would be completely bad, it has something to it, but… I’d put it like this: If you want to be completely secure, pull the plug. If that’s too much, only allow access to few selected addresses and ports. Then would be some other intermediate steps, and finally at the end is when you allow everything. It seems logical that the closer to beginning, the safer you are.
But think about what you want to protect against. When you infect your LAN from USB drive and you’d be worried about virus leaking some sensitive info from your computers, connect to some botnet control center and take orders, etc.., then outgoing filtering probably won’t help much. Sure, there might be a botnet depending on use of port 666, but if the authors are not stupid, they will rather use standard https port 443 with valid certificate and everything. Even if you have just the most simple requirement to “be able to browse the web”, you pretty much have to allow https unconditionally.
So in the end, outgoing filtering is not that much about you being safer, it’s more about being a nice guy and not letting your infected machines doing port scans, sending spam, etc. On the other hand, not everything uses just few ports (http(s), …), so the stricter filtering you use, the higher chance you have to break something for you. So you have to think about what’s more important for you, and find a balance.
About established connections, when I add these logging rules at the beginning:
/ip firewall filter
add action=log chain=forward connection-state=new protocol=tcp dst-port=666 log-prefix="state_new:"
add action=log chain=forward connection-state=new protocol=tcp src-port=666 log-prefix="state_new:"
add action=log chain=forward connection-state=established protocol=tcp dst-port=666 log-prefix="state_est:"
add action=log chain=forward connection-state=established protocol=tcp src-port=666 log-prefix="state_est:"
then new tcp connection will log this:
21:30:44 firewall,info state_new: forward: in:internal out:public, src-mac 02:06:05:f5:21:f3, proto TCP (SYN), 192.168.80.1:35878->1.2.3.4:666, len 60
21:30:44 firewall,info state_est: forward: in:public out:internal, src-mac 00:0c:42:32:5e:af, proto TCP (SYN,ACK), 1.2.3.4:666->192.168.80.1:35878, NAT 1.2.3.4:666->(5.6.7.8:35878->192.168.80.1:35878), len 60
21:30:44 firewall,info state_est: forward: in:internal out:public, src-mac 02:06:05:f5:21:f3, proto TCP (ACK), 192.168.80.1:35878->1.2.3.4:666, NAT (192.168.80.1:35878->5.6.7.8:35878)->1.2.3.4:666, len 52
...
In other words, first SYN packet is new connection, but as soon as first SYN,ACK comes back, the connection is established. And when you’re looking for something using L7 filters, it will only come later.
)