1 |
On 10/13/2013 04:07 PM, Martin Vaeth wrote: |
2 |
>> |
3 |
>> I was just reiterating that there's not much benefit to save/restore if |
4 |
>> you're doing things properly (pontification alert!). |
5 |
> |
6 |
> For a laptop of a scientist like me this is not true at all - it must |
7 |
> often be connected in a different environment with different |
8 |
> local nets etc. |
9 |
|
10 |
Sure, but do the rules change? Is there a better ruleset that |
11 |
accomplishes the same thing with fewer (or universal) rules? How many |
12 |
rules do you have at the location requiring the most rules? |
13 |
|
14 |
Most laptops should be OK with the following: |
15 |
|
16 |
iptables -P INPUT DROP |
17 |
iptables -P FORWARD DROP |
18 |
iptables -P OUTPUT ACCEPT |
19 |
|
20 |
iptables -A INPUT -p ALL -i lo -j ACCEPT |
21 |
iptables -A INPUT -p ALL -m conntrack \ |
22 |
--ctstate ESTABLISHED,RELATED -j ACCEPT |
23 |
iptables -A INPUT -p ALL -m conntrack \ |
24 |
--ctstate INVALID -j DROP |
25 |
|
26 |
ALLOWED_ICMP="0 3 4 8 11 12" |
27 |
for icmp_type in $ALLOWED_ICMP; do |
28 |
iptables -A INPUT -p icmp --icmp-type $icmp_type -j ACCEPT |
29 |
done |
30 |
|
31 |
And creative setups should only require a few more rules. This all takes |
32 |
under (1/10) of a second on my laptop. |
33 |
|
34 |
|
35 |
> Also for other things (like portknocking using the recent module) |
36 |
> you need rather complex rules which are better rewritten by a script, |
37 |
> especially if the length of a portknocking sequence changes. |
38 |
> Like passwords, these sequences should better not stay the same for |
39 |
> too long... |
40 |
|
41 |
Port knocking is cute, but imparts no extra security. A better, secure |
42 |
way to achieve the same goal is with OpenVPN. And that doesn't require |
43 |
you to play games with your firewall. |
44 |
|
45 |
If you use your laptop at hotels, universities, and conferences, you'll |
46 |
have a much happier time connecting to OpenVPN on tcp/443 (which nobody |
47 |
can block) than you will trying to connect directly. |
48 |
|
49 |
|
50 |
>> Race conditions don't really seem that serious to me. |
51 |
> |
52 |
> Maybe, but I am not sure: |
53 |
> There might be situations where it might be possible to keep |
54 |
> a port open even when the rule is rewritten later on; then |
55 |
> you need an open system only once... |
56 |
> So, I could imagine that with some clever hacks an attacker |
57 |
> might keep ports open and then do another attack later on. |
58 |
> I am not an experienced hacker to know such attacks, but I |
59 |
> know that races can be very subtle and provide attack vectors |
60 |
> nobody has ever thought off. |
61 |
|
62 |
In this case, the absolute worst that could happen is that an attacker |
63 |
gains access to every open port on your system. While this is bad, it's |
64 |
not a clever new vulnerability: it's all of the old ones that were |
65 |
already there. |
66 |
|
67 |
If there are insecure daemons listening on public addresses, you should |
68 |
fix them instead of worrying about race conditions on the firewall. |
69 |
Otherwise, every machine on your LAN becomes an attack vector, and |
70 |
that's a much greater risk especially if your coworkers/friends use |
71 |
Windows. And if we're still talking about laptops, the "LAN" is usually |
72 |
"anybody nearby." |