On Wed, 2021-02-24 at 21:32 +0900, Olaf Meeuwissen via Dng wrote:
> Do not uncomment the #allow-hotplug eth0 line. Doing so leads
> to a delay when booting.



Just a note about the above, allow-hotplug eth0 seems to be necessary
on your VM. As for the delay in booting, I've had that ever since
setting up the bridge for the VM. The delay seems to be when it is
setting up your bridge interface.

Relevant to that, I've noticed that if I'm not connected to the network
while booting (I use ethernet so it's real clear for me) networking
doesn't work on my VM (if I recall correctly, networking was also not
working on the host if I wasn't connected to a network upon boot).

My 2 cents on iptables is:

iptables -F will flush your ruleset, setting it back to default open
communications. If a firewall created other chains or rules, they may
survive a flush until the firewall is removed and the machine rebooted.

iptables -S will show your current ruleset. If you flushed your rules
and there is no firewall that's created other chains, the output of
this will usually be:
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT


I typically start with
iptables -P INPUT DROP
iptables -P FORWARD DROP (Note, if this is set to DROP, you must have
another rule in place to handle traffic that is forwarded directly to
your VM. You can do so by allowing traffic to a specific destination
IP)
iptables -P OUTPUT ACCEPT

Since we're dropping traffic on the INPUT chain, we need to ensure that
we can accept traffic from connections we initiated, so we use this
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

An example of allowing traffic to a specific source IP is:
iptables -A INPUT -s 192.168.1.54/32 -j ACCEPT

Allowing traffic to a specific destination looks like this:
iptables -A OUTPUT -d 192.168.1.54/32 -j ACCEPT

Aside from that, you can setup any rule pertaining to a specific port,
source IP, destination IP, range of source or destination IP's.
The only thing I wish I could tack onto it would be to specify programs
that are allowed or not allowed to communicate. I'm sure that's not
easy though.


That should give you the basics but as you go along, a websearch for
your specific question will yield results.

Personally I don't do web searches on ***gle for various good reasons.
I'm guessing I'm not alone.

Some alternatives to that are:
startpage.com (uses ***gle search engine but provides a layer of
anonymity between)
swisscows.com (requires javascript but claims to respect privacy)
duckduckgo.com (claims to offer anonymity but is hosted on amazon, so
not sure how much they can backup their claim)

None of those are perfect, but at least they're not trying to take over
the world like be evil alphabet soup.

Gabe