| 1 |
Hallo, |
| 2 |
|
| 3 |
Am 25. März 2006 schrieb Bernd Wurst: |
| 4 |
> DROP ist böse[TM]. Wer immer diese Regeln benutzen will möge sich |
| 5 |
> kundig machen und selbst entscheiden ob DROP oder REJECT. |
| 6 |
|
| 7 |
ACK. Außerdem verursacht DROP auch potenziell mehr Last. Mit REJECT |
| 8 |
bekommt jemand, der einen Connect versucht, sofort gesagt "Ne Du, is |
| 9 |
nich!", bei DROP bekommt er keine Antwort. Daraufhin weiß die |
| 10 |
darüberliegende Schicht nicht, was genau das Problem war und sendet |
| 11 |
nach einer bestimmten Zeit noch einmal ein Paket, und wieder und |
| 12 |
wieder... Du bekommst also bei DROP mehr Anfragen auf Deinen Rechner. |
| 13 |
|
| 14 |
Und für die Client-Seite ist REJECT auch schöner. Wenn ich telnet xyz |
| 15 |
mache und die Pakete geDROPt werden, hängt telnet bis zum TCP-Timeout. |
| 16 |
Bei Reject weiß kommt sofort "Connection refused". |
| 17 |
|
| 18 |
Ich verstehe auch nicht, warum DROP so viel im Einsatz ist. Hab z.B. |
| 19 |
sshdfilter auf nem VServer im Einsatz, das war auch mit DROP |
| 20 |
geschrieben, hab ich erstmal auf REJECT geändert. |
| 21 |
|
| 22 |
Ich verwende übrigens immer -j REJECT --reject-with tcp-reset. Das |
| 23 |
simuliert das Verhalten wie wenn gar keine Firewall da wäre. |
| 24 |
|
| 25 |
Beweis: |
| 26 |
|
| 27 |
Habe auf meinem Server mal zwei Regeln angelegt ($IPT steht für den |
| 28 |
iptables-Aufruf): |
| 29 |
|
| 30 |
$IPT -A INPUT -i eth1 -p tcp --dport 53789 -j REJECT |
| 31 |
$IPT -A INPUT -i eth1 -p tcp --dport 53790 -j REJECT --reject-with tcp-reset |
| 32 |
|
| 33 |
Danach folgender Aufruf: |
| 34 |
|
| 35 |
dams@eddie ~ $ nmap -sT -p 53789-53791 192.168.1.3 |
| 36 |
|
| 37 |
Starting nmap 3.83.DC13 ( http://www.insecure.org/nmap/ ) at 2006-03-26 21:36 CEST |
| 38 |
Interesting ports on dwyane.heat.nba (192.168.1.3): |
| 39 |
PORT STATE SERVICE |
| 40 |
53789/tcp closed unknown |
| 41 |
53790/tcp closed unknown |
| 42 |
53791/tcp closed unknown |
| 43 |
|
| 44 |
Bis hierhin sieht noch alles gleich aus - ich hätte aber schon ein |
| 45 |
"filtered" bei Port 53789 erwartet. |
| 46 |
|
| 47 |
Aber tcpdump zeigt Unterschiede (Ich hab die Zeilen mal bissl |
| 48 |
vertauscht, damit mans sieht): |
| 49 |
|
| 50 |
21:36:17.754727 IP 192.168.1.6.45766 > 192.168.1.3.53789: S 4285641915:4285641915(0) win 5840 <mss 1460,sackOK,timestamp 1647181[|tcp]> |
| 51 |
21:36:17.754902 IP 192.168.1.3 > 192.168.1.6: ICMP 192.168.1.3 tcp port 53789 unreachable, length 68 |
| 52 |
21:36:17.754811 IP 192.168.1.6.43433 > 192.168.1.3.53790: S 4279155020:4279155020(0) win 5840 <mss 1460,sackOK,timestamp 1647181[|tcp]> |
| 53 |
21:36:17.755026 IP 192.168.1.3.53790 > 192.168.1.6.43433: R 0:0(0) ack 4279155021 win 0 |
| 54 |
21:36:17.754118 IP 192.168.1.6.40209 > 192.168.1.3.53791: S 4281854379:4281854379(0) win 5840 <mss 1460,sackOK,timestamp 1647181[|tcp]> |
| 55 |
21:36:17.754401 IP 192.168.1.3.53791 > 192.168.1.6.40209: R 0:0(0) ack 4281854380 win 0 |
| 56 |
|
| 57 |
Wie man sieht, sehen die Anfragen an Port 53790 und 91 gleich aus, 89 |
| 58 |
anders, woran man erkennen kann, dass da eine Firewall geantwortet hat. |
| 59 |
|
| 60 |
Nur mal so als Exkurs, falls es jemanden interessiert hat. ;) |
| 61 |
|
| 62 |
Ciao |
| 63 |
Sebastian |
| 64 |
|
| 65 |
-- |
| 66 |
Sebastian Damm |
| 67 |
Blog: http://blog.sdamm.de |
| 68 |
GPG-Encrypted mail welcome! ID: 0x64D96827 @ pgpkeys.pca.dfn.de |
| 69 |
Fingerprint: CB7F F23F D950 644D 838B 215A 550F 75EC 64D9 6827 |
Archives