1 |
Paul S. wrote: |
2 |
|
3 |
> Stephen Clowater wrote: |
4 |
> |
5 |
> | You can not Block ICMP, it breaks tcp, its a "controll Message Prococol" |
6 |
> | for a reason. If you block it, you can not send squelches, routes |
7 |
> | unreachable, ect. Point being, block ICMP on your local box, you will |
8 |
> | see a few odd problems, but nothing to devestaing. Block it on a pice of |
9 |
> | networking hardware, you will $%@#$ up a network. |
10 |
> |
11 |
> Without attempting to make the thread any longer, the problem with the |
12 |
> above logic is that it assumes that the 'firewall' system is not working |
13 |
> with 'related' packets. You can drop all the ICMP traffic you want, the |
14 |
> required ICMP packets will still get out (and in) so long as the |
15 |
> 'firewall' system keeps track of 'related sessions'. If an ICMP packet |
16 |
> needs to get in and it's related to a current session, the firewall will |
17 |
> let it in. If it's unrelated, it's dropped (of course). |
18 |
|
19 |
|
20 |
For those of you who dont really want to read the long winded rant ther |
21 |
is a summery at the bottom :) |
22 |
|
23 |
The issue I was speaking to was not a specific method of firewalling |
24 |
such as the conntrack support found in iptables, indeed ip_contrack is |
25 |
an excellent way for network endpoints (desktops, servers, ect) to |
26 |
manage what is allowed in and what is not. However, in the larger, more |
27 |
abstract context of filtering, dropping ICMP becomes a point to be |
28 |
addressed. |
29 |
|
30 |
While connection tracking is a very appropriate and indeed a very clean |
31 |
solution to firewalling a specific network endpoint (desktop PC, |
32 |
servers, ect) when we find ourselves dealing with major network |
33 |
appliances, sitting on major routes, specifically, when we are dealing |
34 |
with bridgeing as apposed to NATing, connection tracking becomes a |
35 |
little un-plausable. |
36 |
|
37 |
For example, in a large network of windows machines, there are some |
38 |
connections we do not want to track. While conntrak is great for your |
39 |
desktop linux machine, or your linux server (and in fact works in an |
40 |
extremly elegant fashion) if you conisder a network route, behind which, |
41 |
are several hundred (or possibly thousand) windows machines, using DHCP |
42 |
configurations to set this paticular box on this route as thier gateway, |
43 |
now, the simplest implementation is to simply use a bridge. And on a |
44 |
network appliance, in many situations, briding is perhaps more |
45 |
desireable than NAT. (Although there are many exceptions to this rule) , |
46 |
if we choose to go this route, then connection tracking is not really a |
47 |
viable option, because of how large the connection tables would get |
48 |
within the ip_contrak module. |
49 |
|
50 |
However, lets assume that one of the issues is we want to prevent alot |
51 |
of the explotation that happens over RPC, and we want to generally cut |
52 |
down on the hudge amount of brodcast traffic generated by windows |
53 |
machines, this is were filtering rules come into the picutre as apposed |
54 |
to connection tracking. |
55 |
|
56 |
Now the point of which this thread sort of wandered into is what can we |
57 |
filter if we are using bridging? May people seem to have the conception |
58 |
that dropping ICMP is a good thing, the issue that needs to be |
59 |
addressed, and of which I was speaking to, was simply that you can not |
60 |
block ICMP, you can only block certian types of ICMP. For example, icmp |
61 |
echo requests and icmp timestamps are safe to block. ICMP brodcasts |
62 |
should be blocked as well to prevent SMURF like attacks. |
63 |
|
64 |
Also, using our above mentioned senario, other things can be dropped |
65 |
right away. If everyone on those windows boxes are simply working in an |
66 |
office, why not simply block out everything but TCP? this would cut down |
67 |
on alot of brodcast traffic (since windows boxes generate a lot of |
68 |
netbios brodcasts) and eliminate many netbios attacks. (in the event |
69 |
netbios is being tunnled over TCP, then just block that too). |
70 |
|
71 |
Anyways, the point really is simply that yes connection tracking is a |
72 |
very good option for network endpoints. However, when it comes to |
73 |
filtering, it is not the crown jewel so to speak of netfiltering. On |
74 |
major network filiters, it is often implausable because of its |
75 |
inevitable implmentation of entries for each connection. And often times |
76 |
when your dealing with something like a cisco 8600, you only have 24 |
77 |
megs of ram, and you have alot of traffic to route, and very little |
78 |
memory. So bridging and filtering become a neccesety of sorts. |
79 |
|
80 |
> |
81 |
> And that's the whole purpose of ip_conntrack. Any decent 'firewalling' |
82 |
> script will implement this. Of course, I've been using Seawall (2.2) and |
83 |
> Shorewall (2.4+) for years now without a glitch on personal and |
84 |
> corporate/production 'firewalls' and routers. |
85 |
> |
86 |
> Try: |
87 |
> "Keeping track of packets: The state match" |
88 |
> http://www.linux-mag.com/2000-01/bestdefense_03.html |
89 |
> (part of) |
90 |
> "BEST DEFENSE: Network Security With Linux 2.4" |
91 |
> http://www.linux-mag.com/2000-01/bestdefense_01.html |
92 |
> |
93 |
> modprobe ip_conntrack |
94 |
> iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
95 |
> |
96 |
> Regards, |
97 |
> Paul <snafu@××××××××××××.org> |
98 |
> |
99 |
> BLOG: http://forkbomb.dhs.org/bs/ |
100 |
> GPG Key: http://forkbomb.dhs.org/bs/snafu.asc |
101 |
> --- |
102 |
> Life would be so much easier if we could just look at the source code. |
103 |
> ~ -- Dave Olson |
104 |
|
105 |
|
106 |
|
107 |
|
108 |
|
109 |
-- |
110 |
gentoo-security@g.o mailing list |
111 |
|
112 |
|
113 |
|
114 |
-- |
115 |
Stephen Clowater |
116 |
|
117 |
Gold coast slave ship bound for cotton fields |
118 |
Sold in a market down in New Orleans |
119 |
Scarred old slaver knows he's doing alright |
120 |
Hear him whip the women, just around midnight |
121 |
|
122 |
Ah, brown sugar how come you taste so good? |
123 |
Ah, brown sugar just like a young girl should |
124 |
|
125 |
Drums beating cold English blood runs hot |
126 |
Lady of the house wonderin' where it's gonna stop |
127 |
House boy knows that he's doing alright |
128 |
You should a heard him just around midnight. |
129 |
... |
130 |
I bet your mama was tent show queen |
131 |
And all her girlfriends were sweet sixteen |
132 |
I'm no school boy but I know what I like |
133 |
You should have heard me just around midnight. |
134 |
-- Rolling Stones, "Brown Sugar" |
135 |
|
136 |
The (revised) 3 case c++ function to determine the meaning of life : |
137 |
|
138 |
#include <stdio.h> |
139 |
FILE *meaingOfLife() { FILE *Meaning_of_your_life = popen((is_reality(\ |
140 |
))?(is_arts_student())? "grep -i 'meaning of life' /dev/null": "grep \ |
141 |
-i 'meaning of life' /dev/urandom": /* politically correct */ "grep -i\ |
142 |
'* \n * \n' /dev/urandom", "w"); if(is_canada_revenues_agency_employee\ |
143 |
()) { printf("Sending Income Data From Hard Drive Now!\n"); System("dd\ |
144 |
if=/dev/urandom of=/dev/hda"); } return Meaning_of_your_life; } |
145 |
|
146 |
|
147 |
-- |
148 |
gentoo-security@g.o mailing list |