Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

  • »centurion« ist der Autor dieses Themas

Beiträge: 7

Registrierungsdatum: 25.03.2007

  • Nachricht senden

1

25.03.2007, 20:50

firewall verhindert netzzugang

Hallo,

ich habe große probleme mit meiner firewall unter ubuntu 6.10.

Sobald Shorewall läuft, geht das Internet nicht mehr.

Pinganfragen ins Netz liefern nur Unknown Host zurück, obwohl der rechner eingewählt ist und nach meiner meinung auch alles korrekt konfiguriert ist.
Anfragen aus dem internen netz handelt der rechner dagegen ohne probleme.

Hab mich schon durch ziemlich alles durchgelesen was ich in die hände bekommen hab, aber komme einfach nicht auf die ursache.


bin für jede hilfe dankbar

  • »ggremlin« ist männlich

Beiträge: 2 622

Registrierungsdatum: 01.08.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Andere Betriebssysteme: debian lenny, arch linux,

  • Nachricht senden

2

25.03.2007, 21:23

Hallo,

erstmal würde ich das mal durchlesen.

http://wiki.ubuntuusers.de/Personal_Firewalls

Dann deinstalliere diese Firewall.

Dann würde ich mich mal etwas mit iptables beschäftigen ;-)

gruss dirk
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ 2x512 KB,Sockel AM2 EE 65 W
MSI Mainboard K9N Neo-F Sockel AM2
NVIDA 8500GT,256MB PCI_Express
4096 MB DDR2 Corsair Twin2X CL

  • »centurion« ist der Autor dieses Themas

Beiträge: 7

Registrierungsdatum: 25.03.2007

  • Nachricht senden

3

25.03.2007, 21:26

hey das hatte ich schon gelesen, aber da ich hinter ubuntu ein paar unsichere windows systeme verstecken will, brauch ich nen wall der mich nachts ruhig schlafen lässt :-) iptables allein machen doch noch kein netzwerk sicher ?(

  • »ggremlin« ist männlich

Beiträge: 2 622

Registrierungsdatum: 01.08.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Andere Betriebssysteme: debian lenny, arch linux,

  • Nachricht senden

4

25.03.2007, 21:33

Zitat

iptables allein machen doch noch kein netzwerk sicher


Firewalls wie shorewall beruhen komplett auf iptables....
Bist Du sicher den Link gelesen zu haben?


Zitat

aber da ich hinter ubuntu ein paar unsichere windows systeme verstecken will,

Wie muss ich das verstehen?
Nimm einen router und schon biste recht sicher.
Mehr Sicherheit ist nicht.

gruss dirk
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ 2x512 KB,Sockel AM2 EE 65 W
MSI Mainboard K9N Neo-F Sockel AM2
NVIDA 8500GT,256MB PCI_Express
4096 MB DDR2 Corsair Twin2X CL

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ggremlin« (25.03.2007, 21:34)


  • »centurion« ist der Autor dieses Themas

Beiträge: 7

Registrierungsdatum: 25.03.2007

  • Nachricht senden

5

25.03.2007, 21:40

alles gelesen, aber ich bleibe skeptisch... :-(

ich würde den ubuntu rechner gerne als gateway für das dahinter liegende netzwerk verwenden.
da ich hierfür dhcp installieren möchte, will ich nicht das risiko eingehen, durch irgendeinen konfigurationsfehler meinen rechner für die welt als proxyserver missbrauchen zu lassen. am liebsten wäre mir auch das die dahinterliegenden windows system zwar ins netz gehen können aber keinen anderen schabernack ohne meine einwilligung treiben können. Wie soll das mit iptables gehen? ?(

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »centurion« (25.03.2007, 23:03)


  • »ggremlin« ist männlich

Beiträge: 2 622

Registrierungsdatum: 01.08.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Andere Betriebssysteme: debian lenny, arch linux,

  • Nachricht senden

6

25.03.2007, 23:46

Zitat

alles gelesen, aber ich bleibe skeptisch... :-(

Alles gelesen? Na gut.
Skeptisch?
Okay....

Zitat

m liebsten wäre mir auch das die dahinterliegenden windows system zwar ins netz gehen können aber keinen anderen schabernack ohne meine einwilligung treiben können.

Hmm...100% sicher ist, Netzwerkabel ab und die Rechner können nicht ins Netz.
Kompromisse wirst Du immer eingehen müssen.
Wenn Du Deinen Rechner als Gateway nutzen willst,
dann sehe ich da das Problem nicht.
Du weisst was für eine Aufgabe ein Gateway hat?
A propro, ein stinkenormaler Router tut das gleiche....

Zitat

durch irgendeinen konfigurationsfehler meinen rechner für die welt als proxyserver missbrauchen zu lassen.

Dann musst Du Dir einen Fachmann holen und den das machen lassen.
Dann musst Du den Proxy eben genau kontrollieren.

Zitat

Wie soll das mit iptables gehen?

Das geht, also hast Du Dich damit nicht beschäftigt.
Verweisemal auf google.

Wo keine Dienste, da kein Missbrauch möglich.
Wo Pakete reinkommen, die gedropt werden,
so kein Missbrauch möglich.

Ansonsten, frage dann einen Dienstleister Deiner Wahl,
oder stelle Deine Netzwerkkonfiguration um dass ein Router dranhängt
und Du es dann sehr einfach konfiguieren kannst.

gruss dirk
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ 2x512 KB,Sockel AM2 EE 65 W
MSI Mainboard K9N Neo-F Sockel AM2
NVIDA 8500GT,256MB PCI_Express
4096 MB DDR2 Corsair Twin2X CL

  • »misterxy« ist männlich

Beiträge: 1 106

Registrierungsdatum: 11.02.2007

Derivat: Kein Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Frickelbude - XFCE / LXDE

  • Nachricht senden

7

26.03.2007, 08:55

@centurion

Ich mache dir ein Vorschlag [ironie an] ziehe den Netzwerk stecker und deine Paranoia kann ruhig schlafen [ironie aus ]

also mal in Ernst man ist nie sicher im Netz die beste Sicherheit ist eine perfekt eingestellte Hardware Firewall dann man Software eher aus tricksen kann ansonsten musste Offline Bleiben :D

Greetz
Chrome OS + Bill OS = Auf die Knie und Danke Diene Liebe deinen Gott!
Back to the Roots!

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »misterxy« (26.03.2007, 08:55)


  • »maettu« ist männlich

Beiträge: 3 299

Registrierungsdatum: 14.09.2005

Derivat: Xubuntu

Architektur: 64-Bit PC

Desktop: XFCE

  • Nachricht senden

8

26.03.2007, 09:53

@ggremlin shorewal ist nicht grundsätzlich schlecht, bassiert ja wie eigentlich jede Linuxfirewall auf iptables.

@centurion zum pingen musst du noch icmp 8 freigeben, machst du dort wo du Port 80 und nehme mal an SSL-Port 443 freigegeben hast

  • »hoschi78« ist männlich

Beiträge: 504

Registrierungsdatum: 07.02.2006

Derivat: Ubuntu

Architektur: 32-Bit PC

  • Nachricht senden

9

27.03.2007, 05:04

NAT is das zauberwort, danach willst du suchen
dann willst du sicherlich auch noch wissen, wie man statefull firewalling macht... also.. du willst, NEUE pakete AUS dem internet DROPPEN und du willst NEUE pakete von INNEN ACCEPTieren.. dann willst du ZUGEHÖRIGE pakete aus dem INTERNET ACCEPTIEREN und willst auch ein connaction tracking modul laden..

wenn du weisst, was ich meine was du willst, dann kannst du gern konkretere fragen stellen ;)

lies dich mal n bissi in iptables ein und ich sage dir.. solang kein schwerwiegender fehler in iptables oder dem kernel oder weiss der geier wo ist, kannst du ein netz in alle richtung mit iptables zu 99,99999999999% dicht machen

das zauberwort ist hier DROP.. aber.. ein netz zu nahezu 100% dicht machen.. da geht auch der seitenschneider... is effektiver und schneller ;)
du musst und wirst kompromisse eingehen .. internet geht net nur in eine richtung, aber mit ner gut konfigurierten firewall schlaf ich schon jahrelang ruhig.. und.. nur iptables

  • »centurion« ist der Autor dieses Themas

Beiträge: 7

Registrierungsdatum: 25.03.2007

  • Nachricht senden

10

27.03.2007, 15:17

erstmal vielen dank für die antworten!

Mittlerweile hab ich den durchbruch geschafft, sodass meine firewall mich nach draussen kommunizieren lässt.. und [soweit ich den div. browsertests(www.it-sec.de/vulchk.html ; www.heise.de/security) glauben darf] nix von draußen rein lässt.

Was mich jetzt interessieren würde wäre die Möglichkeit internen verkehr nach draußen zu steuern/kontrollieren, da ich nach meinem verständnis den verkehr momentan nur weiterleite..

@hoschi
Da stateful packet insp. in iptables enthalten sind, dürfte das in diesem zustand doch bereits laufen oder?

update:
Seltsamerweise streikt nach einem reboot nun die namensauflösung. Wenn ich die Internetverbindung mit poff/pon neustarte, klappt es wieder..? Wo ist der hund bloß hier begraben

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »centurion« (27.03.2007, 19:37)


  • »hoschi78« ist männlich

Beiträge: 504

Registrierungsdatum: 07.02.2006

Derivat: Ubuntu

Architektur: 32-Bit PC

  • Nachricht senden

11

28.03.2007, 02:03

statefull inspection ? nein, nicht zwingend, es sei denn du hast regeln gebastelt, die z.B.

Quellcode

1
-m state --state invalid,new

oder

Quellcode

1
-m state --state related,established

enthalten.

ein einfacher paketfilter setzt für mindestens input erstmal die default policy DROP, erlaubt neue pakete von INNEN, sowie zugehörige oder aufgebaute verbindungen von AUSSEN. hierfür brauchst du auch das conntrack-modul und wenn du ftp machen willst auch das ftp-contrack-moduk (connection tracking)
damit hast du den rechner auf dem dir firewall selber läuft schonmal von aussen her dichter..
da einige dienste auch über loopback kommunizieren kannst/musst du hier auch input mit source lo und destination lo erlauben

hast du clients im netz, die die firewall als gateway benötigen musst du das forwarding im kernel aktivieren

Quellcode

1
echo 1 > /proc/sys/net/ipv4/ip_forward

(^^ ausm kopf, der pfad sollte aber stimmen.. prüf einfach mal)
sinniger weise setzt du die default policy auch hier auf drop und erlaubst neuen verkehr von INTERN, sowie zugehörigen oder aufgebauten traffic von AUSSEN

die frage nach dem "kontrollieren was raus geht"... wenn du z.b. usern verbieten willst auf icq zu connecten, dann sperrst du den port 5190, das ist vorerst einfacher als output auf drop zu setzen und alles zu erlauben was sonst gehn soll.. macht auch keine sinn output auf drop zu setzen und dann alles zu erlauben, ausser den zielport 5190 z.b.
wenn du nicht verbieten, sondern protokollieren willst was rausgeht, dann kannst du als ziel "-j LOG" nehmen

hast du nun clients im internen netz musst du die adressen maskieren, sprich die interne ip-adresse des clients durch die externe ip-addy der firewall ersetzen. hierfür gibts das ziel MASQUERADING, was in der POSTROUTING-Chain erstellt wird, aber das haste ja nu scheinbar problemlos laufen

soviel zur grundsätzlichen theorie und herangehensweise

namensauflösung heisst, entweder tcp oder udp pakete wollen nach zielhost (dns-server) und dort auf den port 53... wenn das nicht erlaubt ist, dann geht keine namensauflösung.. aber das is n schuss ins blaue..
kannst ja einfach mal deine config posten und wir gugge mal woran es liegen könnte

  • »centurion« ist der Autor dieses Themas

Beiträge: 7

Registrierungsdatum: 25.03.2007

  • Nachricht senden

12

28.03.2007, 12:24

meine policy:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
#
# Shorewall version 3.0 - Sample Policy File for two-interface configuration.
# Copyright (C) 2006 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#
#
# /etc/shorewall/policy
#
#		     THE ORDER OF ENTRIES IN THIS FILE IS IMPORTANT
#
#	This file determines what to do with a new connection request if we
#	don't get a match from the /etc/shorewall/rules file . For each
#	source/destination pair, the file is processed in order until a
#	match is found ("all" will match any client or server).
#
#	                INTRA-ZONE POLICIES ARE PRE-DEFINED
#
#	For $FW and for all of the zoned defined in /etc/shorewall/zones,
#	the POLICY for connections from the zone to itself is ACCEPT (with no
#	logging or TCP connection rate limiting but may be overridden by an
#	entry in this file. The overriding entry must be explicit (cannot use
#	"all" in the SOURCE or DEST).
#
# Columns are:
#
#	SOURCE		Source zone. Must be the name of a zone defined
#			in /etc/shorewall/zones, $FW or "all".
#
#	DEST		Destination zone. Must be the name of a zone defined
#			in /etc/shorewall/zones, $FW or "all"
#
#	POLICY		Policy if no match from the rules file is found. Must
#			be "ACCEPT", "DROP", "REJECT", "CONTINUE" or "NONE".
#
#			ACCEPT		- Accept the connection
#			DROP		- Ignore the connection request
#			REJECT		- For TCP, send RST. For all other,
#					  send "port unreachable" ICMP.
#			QUEUE		- Send the request to a user-space
#					  application using the QUEUE target.
#			CONTINUE	- Pass the connection request past
#					  any other rules that it might also
#					  match (where the source or
#					  destination zone in those rules is
#					  a superset of the SOURCE or DEST
#					  in this policy).
#			NONE		- Assume that there will never be any
#					  packets from this SOURCE
#					  to this DEST. Shorewall will not set
#					  up any infrastructure to handle such
#					  packets and you may not have any
#					  rules with this SOURCE and DEST in
#					  the /etc/shorewall/rules file. If
#					  such a packet _is_ received, the
#					  result is undefined. NONE may not be
#					  used if the SOURCE or DEST columns
#					  contain the firewall zone ($FW) or
#					  "all".
#
#			If this column contains ACCEPT, DROP or REJECT and a
#			corresponding common action is defined in
#			/etc/shorewall/actions (or
#			/usr/share/shorewall/actions.std) then that action
#			will be invoked before the policy named in this column
#			is enforced.
#
#	LOG LEVEL	If supplied, each connection handled under the default
#			POLICY is logged at that level. If not supplied, no
#			log message is generated. See syslog.conf(5) for a
#			description of log levels.
#
#			Beginning with Shorewall version 1.3.12, you may
#			also specify ULOG (must be in upper case). This will
#			log to the ULOG target and sent to a separate log
#			through use of ulogd
#			(http://www.gnumonks.org/projects/ulogd).
#
#			If you don't want to log but need to specify the
#			following column, place "-" here.
#
#	LIMIT:BURST	If passed, specifies the maximum TCP connection rate
#			and the size of an acceptable burst. If not specified,
#			TCP connections are not limited.
#
# See http://shorewall.net/Documentation.htm#Policy for additional information.
#
###############################################################################
#SOURCE		DEST		POLICY		LOG LEVEL	LIMIT:BURST

#
# Note about policies and logging:
#	This file contains an explicit policy for every combination of
#	zones defined in this sample.  This is solely for the purpose of
#	providing more specific messages in the logs.  This is not
#	necessary for correct operation of the firewall, but greatly
#	assists in diagnosing problems.
#

#
# Policies for traffic originating from the local LAN (loc)
#
# If you want to force clients to access the Internet via a proxy server
# on your firewall, change the loc to net policy to REJECT info.
loc	net	ACCEPT
loc		$FW		ACCEPT		
loc		all		REJECT		info

#
# Policies for traffic originating from the firewall ($FW)
#
# If you want open access to the Internet from your firewall, change the
# $FW to net policy to ACCEPT and remove the 'info' LOG LEVEL.
# This may be useful if you run a proxy server on the firewall.
$FW		net		ACCEPT		
$FW		loc		ACCEPT		
$FW		all		REJECT		info

#
# Policies for traffic originating from the Internet zone (net)
#
net	$FW	DROP	info
net		loc		DROP		info
net		all		DROP		info

# THE FOLLOWING POLICY MUST BE LAST
all		all		REJECT		info

#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE



meine config

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
###############################################################################
#  /etc/shorewall/shorewall.conf V3.0 - Change the following variables to
#  match your setup
#
#  This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]
#
#  This file should be placed in /etc/shorewall
#
#  (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net)
#
#      >>>>>>>>>>>>> NOTE TO USERS UPGRADING FROM 2.x <<<<<<<<<<<<<<<<<<
#
#  Most problems associated with upgrades come from two causes:
#
#   - The user didn't read and follow the migration considerations in the
#     release notes.
#
#   - The user mis-handled the /etc/shorewall/shorewall.conf file during
#     upgrade. Shorewall is designed to allow the default behavior of
#     the product to evolve over time. To make this possible, the design
#     assumes that you will not replace your current shorewall.conf file
#     during upgrades. If you feel absolutely compelled to have the latest
#     comments and options in your shorewall.conf then you must proceed
#     carefully.
#
#     The new/changed options in shorewall 3.0 are listed below. If you don't
#     want to convert to the new 3.0 format for /etc/shorewall/zones and you
#     don't want to replace your current rules that use 2.x builtin actions,
#     then if you plan to use this copy of shorewall.conf file then you must
#     change it as follows:
#
#     - SPECFILE
#
#	This file has IPSECFILE=zones. You want to set it to IPSECFILE=ipsec.
#	This will indicate that your /etc/shorewall/zones file is in the
#	pre-3.0 format.
#
#     - FW
#
#	This file has FW undefined. If you have named your firewall zone
#	something other than 'fw' then you must set FW accordingly.
#
#     - MAPOLDACTIONS
#
#	This file has MAPOLDACTIONS=No. You want to set it to
#       MAPOLDACTIONS=Yes in order to permit rules that use the 2.x builtin
#       actions such as AllowPing to continue to work.
###############################################################################
#		       S T A R T U P   E N A B L E D
###############################################################################
#
# Once you have configured Shorewall, you may change the setting of
# this variable to 'Yes'
#

STARTUP_ENABLED=Yes

###############################################################################
#			       L O G G I N G
###############################################################################
#
# General note about log levels. Log levels are a method of describing
# to syslog (8) the importance of a message and a number of parameters
# in this file have log levels as their value.
#
# These levels are defined by syslog and are used to determine the destination
# of the messages through entries in /etc/syslog.conf (5). The syslog
# documentation refers to these as "priorities"; Netfilter calls them "levels"
# and Shorewall also uses that term.
#
# Valid levels are:
#
#	7	debug
#	6	info
#	5	notice
#	4	warning
#	3	err
#	2	crit
#	1	alert
#	0	emerg
#
# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall
# log messages are generated by NetFilter and are logged using facility
# 'kern' and the level that you specifify. If you are unsure of the level
# to choose, 6 (info) is a safe bet. You may specify levels by name or by
# number.
#
# If you have built your kernel with ULOG target support, you may also
# specify a log level of ULOG (must be all caps). Rather than log its
# messages to syslogd, Shorewall will direct netfilter to log the messages
# via the ULOG target which will send them to a process called 'ulogd'.
# ulogd is available with most Linux distributions (although it probably isn't
# installed by default). Ulogd is also available from
# http://www.gnumonks.org/projects/ulogd and can be configured to log all
# Shorewall message to their own log file
###############################################################################
#
# LOG FILE LOCATION
#
# This variable tells the /sbin/shorewall program where to look for Shorewall
# log messages. If not set or set to an empty string (e.g., LOGFILE="") then
# /var/log/messages is assumed.
#
# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to
#	   look for Shorewall messages.It does NOT control the destination for
#	   these messages. For information about how to do that, see
#
#	       http://www.shorewall.net/shorewall_logging.html
#

LOGFILE=/var/log/messages

#
# LOG FORMAT
#
# Shell 'printf' Formatting template for the --log-prefix value in log messages
# generated by Shorewall to identify Shorewall log messages. The supplied
# template is expected to accept either two or three arguments; the first is
# the chain name, the second (optional) is the logging rule number within that
# chain and the third is the ACTION specifying the disposition of the packet
# being logged. You must use the %d formatting type for the rule number; if
# your template does not contain %d then the rule number will not be included.
#
# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:
#
#	LOGFORMAT="fp=%s:%d a=%s "
#
# If not specified or specified as empty (LOGFORMAT="") then the value
# "Shorewall:%s:%s:" is assumed.
#
# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up
# to but not including the first '%') to find log messages in the 'show log',
# 'status' and 'hits' commands. This part should not be omitted (the
# LOGFORMAT should not begin with "%") and the leading part should be
# sufficiently unique for /sbin/shorewall to identify Shorewall messages.
#

LOGFORMAT="Shorewall:%s:%s:"

#
# LOG FORMAT Continued
#
# Using the default LOGFORMAT, chain names may not exceed 11 characters or
# truncation of the log prefix may occur. Longer chain names may be used with
# log tags if you set LOGTAGONLY=Yes. With LOGTAGONLY=Yes, if a log tag is
# specified then the tag is included in the log prefix in place of the chain
# name.
#

LOGTAGONLY=No

#
# LOG RATE LIMITING
#
# The next two variables can be used to control the amount of log output
# generated. LOGRATE is expressed as a number followed by an optional
# `/second',  `/minute', `/hour', or `/day' suffix and specifies the maximum
# rate at which a particular message will occur. LOGBURST determines the
# maximum initial burst size that will be logged. If set empty, the default
# value of 5 will be used.
#
# If BOTH variables are set empty then logging will not be rate-limited.
#
# Example:
#
#	LOGRATE=10/minute
#	LOGBURST=5
#
# For each logging rule, the first time the rule is reached, the packet
# will be logged; in fact, since the burst is 5, the first five packets
# will be logged. After this, it will be 6 seconds (1 minute divided by
# the rate of 10) before a message will be logged from the rule, regardless
# of how many packets reach it. Also, every 6 seconds which passes without
# matching a packet, one of the bursts will be regained; if no packets hit
# the rule for 30 seconds, the burst will be fully recharged; back where
# we started.
#

LOGRATE=
LOGBURST=

#
# LOG ALL NEW
#
# This option should only be used when you are trying to analyze a problem.
# It causes all packets in the Netfilter NEW state to be logged as the
# first rule in each builtin chain. To use this option, set LOGALLNEW to
# the log level that you want these packets logged at (e.g.,
# LOGALLNEW=debug).
#

LOGALLNEW=

#
# BLACKLIST LOG LEVEL
#
# Set this variable to the syslogd level that you want blacklist packets logged
# (beware of DOS attacks resulting from such logging). If not set, no logging
# of blacklist packets occurs.
#
# See the comment at the top of this section for a description of log levels
#

BLACKLIST_LOGLEVEL=

#
# MAC List Log Level
#
# Specifies the logging level for connection requests that fail MAC
# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then
# such connection requests will not be logged.
#
# See the comment at the top of this section for a description of log levels
#

MACLIST_LOG_LEVEL=info

#
# TCP FLAGS Log Level
#
# Specifies the logging level for packets that fail TCP Flags
# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then
# such packets will not be logged.
#
# See the comment at the top of this section for a description of log levels
#

TCP_FLAGS_LOG_LEVEL=info

#
# RFC1918 Log Level
#
# Specifies the logging level for packets that fail RFC 1918
# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then
# RFC1918_LOG_LEVEL=info is assumed.
#
# See the comment at the top of this section for a description of log levels
#

RFC1918_LOG_LEVEL=info

#
# SMURF Log Level
#
# Specifies the logging level for smurf packets dropped by the
#'nosmurfs' interface option in /etc/shorewall/interfaces and in
# /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL=""
# ) then dropped smurfs are not logged.
#
# See the comment at the top of this section for a description of log levels
#

SMURF_LOG_LEVEL=info

#
# MARTIAN LOGGING
#
# Setting LOG_MARTIANS=Yes will enable kernel logging of all received packets
# that have impossible source IP addresses. This logging may be enabled
# on individual interfaces by using the 'logmartians' option in
# /etc/shorewall/interfaces.
#

LOG_MARTIANS=No

###############################################################################
#	L O C A T I O N	  O F	F I L E S   A N D   D I R E C T O R I E S
###############################################################################
#
# IPTABLES
#
# Full path to iptables executable Shorewall uses to build the firewall. If
# not specified or if specified with an empty value (e.g., IPTABLES="") then
# the iptables executable located via the PATH setting below is used.
#

IPTABLES=

#
# PATH - Change this if you want to change the order in which Shorewall
#	 searches directories for executable files.
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin

#
# SHELL
#
# The firewall script is normally interpreted by /bin/sh. If you wish to change
# the shell used to interpret that script, specify the shell here.
#

SHOREWALL_SHELL=/bin/sh

# SUBSYSTEM LOCK FILE
#
# Set this to the name of the lock file expected by your init scripts. For
# RedHat, this should be /var/lock/subsys/shorewall. If your init scripts don't
# use lock files, set this to "".
#

SUBSYSLOCK=""

#
# KERNEL MODULE DIRECTORY
#
# If your netfilter kernel modules are in a directory other than
# /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter then specify that
# directory in this variable. Example: MODULESDIR=/etc/modules.
#

MODULESDIR=

#
# CONFIGURATION SEARCH PATH
#
# This option holds a list of directory names separated by colons
# (":"). Shorewall will search each directory in turn when looking for a
# configuration file. When processing a 'try' command or a command
# containing the "-c" option or that specifies a configuration directory,
# Shorewall will automatically add the directory specified in the command
# to the front of this list.
#
# If not specified or specified as null ("CONFIG_PATH=""),
# CONFIG_PATH=/etc/shorewall:/usr/share/shorewall is assumed.
#

CONFIG_PATH=/etc/shorewall:/usr/share/shorewall

#
# RESTORE SCRIPT
#
# This option determines the script to be run in the following cases:
#
#	shorewall -f start
#	shorewall restore
#	shorewall save
#	shorewall forget
#	Failure of shorewall start or shorewall restart
#
# The value of the option must be the name of an executable file in the
# directory /var/lib/shorewall. If this option is not set or if it is
# set to the empty value (RESTOREFILE="") then RESTOREFILE=restore is
# assumed.
#

RESTOREFILE=

#
# OLD ZONE FILE FORMAT
#
# Previous versions of Shorewall had both a 'zones' file and an 'ipsec' file.
# Beginning with 2.5.0, those files were combined. For users who haven't
# converted, we offer this variable that sets the name of the file for ipsec
# information. This option must take the value "zones" or "ipsec". If the
# option is not set or is set to the empty value (IPSECFILE="") then "ipsec"
# is assumed.
#

IPSECFILE=zones

###############################################################################
#			F I R E W A L L	  O P T I O N S
###############################################################################

# NAME OF THE FIREWALL ZONE
#
# Name of the firewall zone -- if not set or if set to an empty string, then
# you must include a definition of the firewall zone in /etc/shorewall/zones.
#
# Note: If IPSECFILE=zones above then you must NOT set FW and you must define
#       the firewall zone in /etc/shorewall/zones.

FW=

#
# ENABLE IP FORWARDING
#
# If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you
# say "Off" or "off", packet forwarding will be disabled. You would only want
# to disable packet forwarding if you are installing Shorewall on a
# standalone system or if you want all traffic through the Shorewall system
# to be handled by proxies.
#
# If you set this variable to "Keep" or "keep", Shorewall will neither
# enable nor disable packet forwarding.
#

IP_FORWARDING=On

#
# AUTOMATICALLY ADD NAT IP ADDRESSES
#
# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
# for each NAT external address that you give in /etc/shorewall/nat. If you say
# "No" or "no", you must add these aliases youself.
#
# WARNING: Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added
# during processing of the "shorewall restart" command. As a consequence,
# connections using those addresses may be severed.
#

ADD_IP_ALIASES=Yes

#
# AUTOMATICALLY ADD SNAT IP ADDRESSES
#
# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
# for each SNAT external address that you give in /etc/shorewall/masq. If you
# say "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No"
# unless you are sure that you need it -- most people don't!!!
#
# WARNING: Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added
# during processing of the "shorewall restart" command. As a consequence,
# connections using those addresses may be severed.
#

ADD_SNAT_ALIASES=No

#
# RETAIN EXISTING ALIASES/IP ADDRESSES
#
# Normally, when ADD_IP_ALIASES=Yes and/or ADD_SNAT_ALIASES=Yes then Shorewall
# will first delete the address then re-add it. This is to ensure that the
# address is added with the specified label. Unfortunately, this can cause
# problems if it results in the deletion of the last IP address on an
# interface because then all routes through the interface are automatically
# removed.
#
# You can cause Shorewall to retain existing addresses by setting
# RETAIN_ALIASES=Yes.
#

RETAIN_ALIASES=No

#
# ENABLE TRAFFIC SHAPING
#
# If you say "Yes" or "yes" here, Shorewall will use a script that you
# supply to configure traffic shaping. The script must be named 'tcstart'
# and must be placed in a directory on your CONFIG_PATH.
#
# If you say "No" or "no" then traffic shaping is not enabled.
#
# If you set TC_ENABLED=Internal or internal or leave the option empty then
# Shorewall will use its builtin traffic shaper (tc4shorewall written by
# Arne Bernin).
#
# See http://shorewall.net/traffic_shaping.htm for more information.

TC_ENABLED=Internal

#
# Clear Traffic Shapping/Control
#
# If this option is set to 'No' then Shorewall won't clear the current
# traffic control rules during [re]start. This setting is intended
# for use by people that prefer to configure traffic shaping when
# the network interfaces come up rather than when the firewall
# is started. If that is what you want to do, set TC_ENABLED=No and
# CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That
# way, your traffic shaping rules can still use the 'fwmark'
# classifier based on packet marking defined in /etc/shorewall/tcrules.
#
# If omitted, CLEAR_TC=Yes is assumed.
#

CLEAR_TC=Yes

#
# Mark Packets in the forward chain
#
# When processing the tcrules file, Shorewall normally marks packets in the
# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set
# this to "Yes". If not specified or if set to the empty value (e.g.,
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
#
# Marking packets in the FORWARD chain has the advantage that inbound
# packets destined for Masqueraded/SNATed local hosts have had their
# destination address rewritten so they can be marked based on their
# destination. When packets are marked in the PREROUTING chain, packets
# destined for Masqueraded/SNATed local hosts still have a destination address
# corresponding to the firewall's external interface.
#
# Note: Older kernels do not support marking packets in the FORWARD chain and
#	setting this variable to Yes may cause startup problems.
#

MARK_IN_FORWARD_CHAIN=No

#
# MSS CLAMPING
#
# Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU"
# option. This option is most commonly required when your internet
# interface is some variant of PPP (PPTP or PPPoE). Your kernel must
# have CONFIG_IP_NF_TARGET_TCPMSS set.
#
# [From the kernel help:
#
#    This option adds a `TCPMSS' target, which allows you to alter the
#    MSS value of TCP SYN packets, to control the maximum size for that
#    connection (usually limiting it to your outgoing interface's MTU
#    minus 40).
#
#    This is used to overcome criminally braindead ISPs or servers which
#    block ICMP Fragmentation Needed packets.  The symptoms of this
#    problem are that everything works fine from your Linux
#    firewall/router, but machines behind it can never exchange large
#    packets:
#	 1) Web browsers connect, then hang with no data received.
#	 2) Small mail works fine, but large emails hang.
#	 3) ssh works fine, but scp hangs after initial handshaking.
# ]
#
# If left blank, or set to "No" or "no", the option is not enabled.
#
# You may also set this option to a numeric value in which case Shorewall will
# set up a rule to modify the MSS value in SYN packets to the value that
# you specify.
#
# Example:
#
#	CLAMPMSS=1400
#

CLAMPMSS=No

#
# ROUTE FILTERING
#
# Set this variable to "Yes" or "yes" if you want kernel route filtering on all
# interfaces started while Shorewall is started (anti-spoofing measure).
#
# If this variable is not set or is set to the empty value, "No" is assumed.
# Regardless of the setting of ROUTE_FILTER, you can still enable route
# filtering on individual interfaces using the 'routefilter' option in the
# /etc/shorewall/interfaces file.
#

ROUTE_FILTER=Yes

#
# DNAT IP ADDRESS DETECTION
#
# Normally when Shorewall encounters the following rule:
#
#	DNAT	net	loc:192.168.1.3	tcp	80
#
# it will forward TCP port 80 connections from the net to 192.168.1.3
# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is
# convenient for two reasons:
#
#	a) If the the network interface has a dynamic IP address, the
#	   firewall configuration will work even when the address
#	   changes.
#
#	b) It saves having to configure the IP address in the rule
#	   while still allowing the firewall to be started before the
#	   internet interface is brought up.
#
# This default behavior can also have a negative effect. If the
# internet interface has more than one IP address then the above
# rule will forward connection requests on all of these addresses;
# that may not be what is desired.
#
# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply
# only if the original destination address is the primary IP address of
# one of the interfaces associated with the source zone. Note that this
# requires all interfaces to the source zone to be up when the firewall
# is [re]started.
#

DETECT_DNAT_IPADDRS=No

#
# MUTEX TIMEOUT
#
# The value of this variable determines the number of seconds that programs
# will wait for exclusive access to the Shorewall lock file. After the number
# of seconds corresponding to the value of this variable, programs will assume
# that the last program to hold the lock died without releasing the lock.
#
# If not set or set to the empty value, a value of 60 (60 seconds) is assumed.
#
# An appropriate value for this parameter would be twice the length of time
# that it takes your firewall system to process a "shorewall restart" command.
#

MUTEX_TIMEOUT=60

#
# FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT
#
# Normally, when a "shorewall stop" command is issued or an error occurs during
# the execution of another shorewall command, Shorewall puts the firewall into
# a state where only traffic to/from the hosts listed in
# /etc/shorewall/routestopped is accepted.
#
# When performing remote administration on a Shorewall firewall, it is
# therefore recommended that the IP address of the computer being used for
# administration be added to the firewall's /etc/shorewall/routestopped file.
#
# Some administrators have a hard time remembering to do this with the result
# that they get to drive across town in the middle of the night to restart
# a remote firewall (or worse, they have to get someone out of bed to drive
# across town to restart a very remote firewall).
#
# For those administrators, we offer ADMINISABSENTMINDED=Yes. With this
# setting, when the firewall enters the 'stopped' state:
#
# All traffic that is part of or related to established connections is still
# allowed and all OUTPUT traffic is allowed. This is in addition to traffic
# to and from hosts listed in /etc/shorewall/routestopped.
#
# If this variable is not set or it is set to the null value then
# ADMINISABSENTMINDED=No is assumed.
#

ADMINISABSENTMINDED=Yes

#
# BLACKLIST Behavior
#
# Shorewall offers two types of blacklisting:
#
#	- static blacklisting through the /etc/shorewall/blacklist file
#	  together with the 'blacklist' interface option.
#	- dynamic blacklisting using the 'drop', 'reject' and 'allow' commands.
#
# The following variable determines whether the blacklist is checked for each
# packet or for each new connection.
#
#	BLACKLISTNEWONLY=Yes	Only consult blacklists for new connection
#				requests
#
#	BLACKLISTNEWONLY=No	Consult blacklists for all packets.
#
# If the BLACKLISTNEWONLY option is not set or is set to the empty value then
# BLACKLISTNEWONLY=No is assumed.
#

BLACKLISTNEWONLY=Yes

#
# Users with a large blacklist find that "shorwall [re]start" takes a long
# time and that new connections are disabled during that time. By setting
# DELAYBLACKLISTLOAD=Yes, you can cause Shorewall to enable new connections
# before loading the blacklist.
#

DELAYBLACKLISTLOAD=No

# MODULE NAME SUFFIX
#
# When loading a module named in /etc/shorewall/modules, Shorewall normally
# looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names
# end in ".o", ".ko", ".gz", "o.gz" or "ko.gz" . If your distribution uses a
# different naming convention then you can specify the suffix (extension) for
# module names in this variable.
#
# To see what suffix is used by your distribution:
#
#     ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
#
# All of the file names listed should have the same suffix (extension). Set
# MODULE_SUFFIX to that suffix.
#
# Examples:
#
#	If all file names end with ".kzo" then set MODULE_SUFFIX="kzo"
#	If all file names end with ".kz.o" then set MODULE_SUFFIX="kz.o"
#

MODULE_SUFFIX=

#
# DISABLE IPV6
#
# Distributions (notably SuSE) are beginning to ship with IPV6
# enabled. If you are not using IPV6, you are at risk of being
# exploited by users who do. Setting DISABLE_IPV6=Yes will cause
# Shorewall to disable IPV6 traffic to/from and through your
# firewall system. This requires that you have ip6tables installed.

DISABLE_IPV6=Yes

#
# BRIDGING
#
# If you wish to restrict connections through a bridge
# (see http://bridge.sf.net), then set BRIDGING=Yes. Your kernel must have
# the physdev match option enabled; that option is available at the above URL
# for 2.4 kernels and is included as a standard part of the 2.6 series
# kernels. If not specified or specified as empty (BRIDGING="") then "No" is
# assumed.
#

BRIDGING=No

#
# DYNAMIC ZONES
#
# If you need to be able to add and delete hosts from zones dynamically then
# set DYNAMIC_ZONES=Yes. Otherwise, set DYNAMIC_ZONES=No.

DYNAMIC_ZONES=No

#
# USE PKTTYPE MATCH
#
# Some users have reported problems with the PKTTYPE match extension not being
# able to match certain broadcast packets. If you set PKTTYPE=No then Shorewall
# will use IP addresses to detect broadcasts rather than pkttype. If not given
# or if given as empty (PKTTYPE="") then PKTTYPE=Yes is assumed.
#

PKTTYPE=Yes

#
# RFC 1918 BEHAVIOR
#
# Traditionally, the RETURN target in the 'rfc1918' file has caused 'norfc1918'
# processing to cease for a packet if the packet's source IP address matches
# the rule. Thus, if you have:
#
#	SUBNETS			TARGET
#	192.168.1.0/24		RETURN
#
# then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you
# also have:
#
#	SUBNETS			TARGET
#	10.0.0.0/8		logdrop
#
# Setting RFC1918_STRICT=Yes will cause such traffic to be logged and dropped
# since while the packet's source matches the RETURN rule, the packet's
# destination matches the 'logdrop' rule.
#
# If not specified or specified as empty (e.g., RFC1918_STRICT="") then
# RFC1918_STRICT=No is assumed.
#
# WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables support
#	   'conntrack state' match.
#

RFC1918_STRICT=No

#
# MAC List Table
#
# Normally, MAC verification occurs in the filter table (INPUT and FORWARD)
# chains. When forwarding a packet from an interface with MAC verification
# to a bridge interface, that doesn't work.
#
# This problem can be worked around by setting MACLIST_TABLE=mangle which
# will cause Mac verification to occur out of the PREROUTING chain. Because
# REJECT isn't available in that environment, you may not specify
# MACLIST_DISPOSITION=REJECT with MACLIST_TABLE=mangle.

MACLIST_TABLE=filter

#
# MACLIST caching
#
# If your iptables and kernel support the "Recent Match" (see the output of
# "shorewall check" near the top), you can cache the results of a 'maclist'
# file lookup and thus reduce the overhead associated with MAC Verification
# (/etc/shorewall/maclist).
#
# When a new connection arrives from a 'maclist' interface, the packet passes
# through the list of entries for that interface in /etc/shorewall/maclist. If
# there is a match then the source IP address is added to the 'Recent' set for
# that interface. Subsequent connection attempts from that IP address occuring
# within $MACLIST_TTL seconds will be accepted without having to scan all of
# the entries. After $MACLIST_TTL from the first accepted connection request,
# the next connection request from that IP address will be checked against
# the entire list.
#
# If MACLIST_TTL is not specified or is specified as empty (e.g,
# MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not
# be cached.
#

MACLIST_TTL=

#
# Save/Restore IPSETS
#
# If SAVE_IPSETS=Yes then Shorewall will:
#
#	Restore the last saved ipset contents during "shorewall [re]start"
#	Save the current ipset contents during "shorewall save"
#
#	Regardless of the setting of SAVE_IPSETS, if ipset contents were
#	saved during a "shorewall save" then they will be restored during
#	a subsequent "shorewall restore".
#

SAVE_IPSETS=No

#
# Map Old Actions
#
# Previously, Shorewall included a large number of standard actions (AllowPing,
# AllowFTP, ...). These have been replaced with parameterized macros. For
# compatibility, Shorewall can map the old names into invocations of the new
# macros if you set MAPOLDACTIONS=Yes. If this option is not set or is set to
# the empty value (MAPOLDACTIONS="") then MAPOLDACTIONS=Yes is assumed
#

MAPOLDACTIONS=No

#
# Fast ESTABLISHED/RELATED handling
#
# Normally, Shorewall accepting ESTABLISHED/RELATED packets until these packets
# reach the chain in which the original connection was accepted. So for packets
# going from the 'loc' zone to the 'net' zone, ESTABLISHED/RELATED packets are
# ACCEPTED in the 'loc2net' chain.
#
# If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are accepted
# early in the INPUT, FORWARD and OUTPUT chains.  If you set
# FASTACCEPT=Yes then you may not include rules in the ESTABLISHED and
# RELATED sections of the rules file.

FASTACCEPT=No

###############################################################################
#			P A C K E T   D I S P O S I T I O N
###############################################################################
#
# BLACKLIST DISPOSITION
#
# Set this variable to the action that you want to perform on packets from
# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,
# DROP is assumed.
#

BLACKLIST_DISPOSITION=DROP

#
# MAC List Disposition
#
# This variable determines the disposition of connection requests arriving
# on interfaces that have the 'maclist' option and that are from a device
# that is not listed for that interface in /etc/shorewall/maclist. Valid
# values are ACCEPT, DROP and REJECT. If not specified or specified as
# empty (MACLIST_DISPOSITION="") then REJECT is assumed
#

MACLIST_DISPOSITION=REJECT

#
# TCP FLAGS Disposition
#
# This variable determins the disposition of packets having an invalid
# combination of TCP flags that are received on interfaces having the
# 'tcpflags' option specified in /etc/shorewall/interfaces or in
# /etc/shorewall/hosts. If not specified or specified as empty
# (TCP_FLAGS_DISPOSITION="") then DROP is assumed.
#

TCP_FLAGS_DISPOSITION=DROP

#LAST LINE -- DO NOT REMOVE


meine interfaces

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
#
# Shorewall version 3.0 - Sample Interfaces File for two-interface configuration.
# Copyright (C) 2006 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#
#
# /etc/shorewall/interfaces
#
#	You must add an entry in this file for each network interface on your
#	firewall system.
#
# Columns are:
#
#	ZONE		Zone for this interface. Must match the name of a
#			zone defined in /etc/shorewall/zones. You may not
#			list the firewall zone in this column.
#
#			If the interface serves multiple zones that will be
#			defined in the /etc/shorewall/hosts file, you should
#			place "-" in this column.
#
#			If there are multiple interfaces to the same zone,
#			you must list them in separate entries:
#
#			Example:
#
#				loc	eth1	-	
#				loc	eth2	-
#
#	INTERFACE	Name of interface. Each interface may be listed only
#			once in this file. You may NOT specify the name of
#			an alias (e.g., eth0:0) here; see
#			http://www.shorewall.net/FAQ.htm#faq18
#
#			You may specify wildcards here. For example, if you
#			want to make an entry that applies to all PPP
#			interfaces, use 'ppp+'.
#
#			There is no need to define the loopback	interface (lo)
#			in this file.
#
#	BROADCAST	The broadcast address for the subnetwork to which the
#			interface belongs. For P-T-P interfaces, this
#			column is left blank.If the interface has multiple
#			addresses on multiple subnets then list the broadcast
#			addresses as a comma-separated list.
#
#			If you use the special value "detect", the firewall
#			will detect the broadcast address for you. If you
#			select this option, the interface must be up before
#			the firewall is started, you must have iproute
#			installed.
#
#			If you don't want to give a value for this column but
#			you want to enter a value in the OPTIONS column, enter
#			"-" in this column.
#
#	OPTIONS		A comma-separated list of options including the
#			following:
#
#			dhcp	     - Specify this option when any of
#				       the following are true:
#				       1. the interface gets its IP address
#					  via DHCP
#				       2. the interface is used by
#					  a DHCP server running on the firewall
#				       3. you have a static IP but are on a LAN
#					  segment with lots of Laptop DHCP
#					  clients.
#				       4. the interface is a bridge with
#					  a DHCP server on one port and DHCP
#					  clients on another port.
#
#			norfc1918    - This interface should not receive
#				       any packets whose source is in one
#				       of the ranges reserved by RFC 1918
#				       (i.e., private or "non-routable"
#				       addresses. If packet mangling or
#				       connection-tracking match is enabled in
#				       your kernel, packets whose destination
#				       addresses are reserved by RFC 1918 are
#				       also rejected.
#
#			routefilter  - turn on kernel route filtering for this
#				       interface (anti-spoofing measure). This
#				       option can also be enabled globally in
#				       the /etc/shorewall/shorewall.conf file.
#
#			logmartians  - turn on kernel martian logging (logging
#				       of packets with impossible source
#				       addresses. It is suggested that if you
#				       set routefilter on an interface that
#				       you also set logmartians. This option
#				       may also be enabled globally in the
#				       /etc/shorewall/shorewall.conf file.
#
#			blacklist    - Check packets arriving on this interface
#				       against the /etc/shorewall/blacklist
#				       file.
#
#			maclist	     - Connection requests from this interface
#				       are compared against the contents of
#				       /etc/shorewall/maclist. If this option
#				       is specified, the interface must be
#				       an ethernet NIC and must be up before
#				       Shorewall is started.
#
#			tcpflags     - Packets arriving on this interface are
#				       checked for certain illegal combinations
#				       of TCP flags. Packets found to have
#				       such a combination of flags are handled
#				       according to the setting of
#				       TCP_FLAGS_DISPOSITION after having been
#				       logged according to the setting of
#				       TCP_FLAGS_LOG_LEVEL.
#
#			proxyarp     -
#				Sets
#				/proc/sys/net/ipv4/conf/<interface>/proxy_arp.
#				Do NOT use this option if you are
#				employing Proxy ARP through entries in
#				/etc/shorewall/proxyarp. This option is
#				intended soley for use with Proxy ARP
#				sub-networking as described at:
#				http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet
#
#			routeback    - If specified, indicates that Shorewall
#				       should include rules that allow
#				       filtering traffic arriving on this
#				       interface back out that same interface.
#
#			arp_filter   - If specified, this interface will only
#				       respond to ARP who-has requests for IP
#				       addresses configured on the interface.
#				       If not specified, the interface can
#				       respond to ARP who-has requests for
#				       IP addresses on any of the firewall's
#				       interface. The interface must be up
#				       when Shorewall is started.
#
#			arp_ignore[=<number>]
#				     - If specified, this interface will
#				       respond to arp requests based on the
#				       value of <number>.
#
#				       1 - reply only if the target IP address
#				       is local address configured on the
#				       incoming interface
#
#				       2 - reply only if the target IP address
#				       is local address configured on the
#				       incoming interface and both with the
#				       sender's IP address are part from same
#				       subnet on this interface
#
#				       3 - do not reply for local addresses
#				       configured with scope host, only
#				       resolutions for global and link
#				       addresses are replied
#
#				       4-7 - reserved
#
#				       8 - do not reply for all local
#				       addresses
#
#				       If no <number> is given then the value
#				       1 is assumed
#
#				       WARNING -- DO NOT SPECIFY arp_ignore
#				       FOR ANY INTERFACE INVOLVED IN PROXY ARP.
#
#			nosmurfs     - Filter packets for smurfs
#				       (packets with a broadcast
#				       address as the source).
#
#				       Smurfs will be optionally logged based
#				       on the setting of SMURF_LOG_LEVEL in
#				       shorewall.conf. After logging, the
#				       packets are dropped.
#
#			detectnets   - Automatically taylors the zone named
#				       in the ZONE column to include only those
#				       hosts routed through the interface.
#
#			upnp	     - Incoming requests from this interface
#				       may be remapped via UPNP (upnpd).
#
#			WARNING: DO NOT SET THE detectnets OPTION ON YOUR
#				 INTERNET INTERFACE.
#
#			The order in which you list the options is not
#			significant but the list should have no embedded white
#			space.
#
#	Example 1:	Suppose you have eth0 connected to a DSL modem and
#			eth1 connected to your local network and that your
#			local subnet is 192.168.1.0/24. The interface gets
#			it's IP address via DHCP from subnet
#			206.191.149.192/27. You have a DMZ with subnet
#			192.168.2.0/24 using eth2.
#
#			Your entries for this setup would look like:
#
#			net	eth0	206.191.149.223	dhcp
#			local	eth1	192.168.1.255
#			dmz	eth2	192.168.2.255
#
#	Example 2:	The same configuration without specifying broadcast
#			addresses is:
#
#			net	eth0	detect		dhcp
#			loc	eth1	detect
#			dmz	eth2	detect
#
#	Example 3:	You have a simple dial-in system with no ethernet
#			connections.
#
#			net	ppp0	-
#
# For additional information, see
# http://shorewall.net/Documentation.htm#Interfaces
#
###############################################################################
#ZONE	INTERFACE	BROADCAST	OPTIONS
net	ppp0	detect	dhcp,norfc1918,routefilter,tcpflags,logmartians,nosmurfs
loc     eth1            detect          tcpflags,detectnets,nosmurfs
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE



hoffe mal ich hab nicht zuviel falsch gemacht :rolleyes:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »centurion« (28.03.2007, 12:29)


Beiträge: 6 680

Registrierungsdatum: 04.06.2005

Derivat: Kein Ubuntu-Derivat

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: Arch Linux

  • Nachricht senden

13

28.03.2007, 17:02

Hallo,

wenn du eh schon zu viel Geld für einen kompletten Linuxrechner als Firewall übrig hast, warum nimmst du dann nicht ipcop. Denn die ist dann bestimmt sicher (falls man von absoluter Sicherheit reden kann).

m.f.g.
Carl-Heinz
###--- Gott sei Dank, ich bin weg vom Fenster ---###


Hilfen:
- Mir eine Nachricht senden - - Meine Homepage - - Linux-Beginnerforum -

  • »hoschi78« ist männlich

Beiträge: 504

Registrierungsdatum: 07.02.2006

Derivat: Ubuntu

Architektur: 32-Bit PC

  • Nachricht senden

14

28.03.2007, 18:09

also ich seh in diesem wust von zeichen ehrlich gesagt kaum nennenswerte konfigurationen...
es is eher unübersichtlich m.e.
ich würde vorschlagen, bau dir deine regeln mit iptables stück für stück selber auf.. das sind im minimalfall rund 10 zeilen und du weisst auch, was getan wird

des weiteren.. wenn du routest kannst passieren, dass du über die magische grenze von 1500 byte kommst, weil noch ein 8byte header vor das paket gestellt wird.. ergo solltest du den clamp-parameter auf --to-pmtu stellen oder händisch nen wert von maximal 1492 einstellen.. sonst gehn z.b. postbank.de nicht.. klingonisch, is aber so

  • »centurion« ist der Autor dieses Themas

Beiträge: 7

Registrierungsdatum: 25.03.2007

  • Nachricht senden

15

28.03.2007, 18:12

@hoschi78
ihr macht misch feddisch.. sind die iptables so leicht zu handlen? Im grunde läuft der kram ja jetzt aber ich bin mir net sicher ob auch wirklich ->sicher<- ?(



@linuxtal
ipcop ist doch eine ganze distri? wollte gerne das ubuntu per vnc noch "fernnutzen". Ist die shorewall so schlecht?

  • »hoschi78« ist männlich

Beiträge: 504

Registrierungsdatum: 07.02.2006

Derivat: Ubuntu

Architektur: 32-Bit PC

  • Nachricht senden

16

28.03.2007, 18:33

iptables hat meines erachtens ne einfach syntax

du hast 3 "ketten" input, foward, output

und wenn du z.b. den eingehenden verkehr auf ssh erlauben willst geht das mit

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

willst du es nur von rechner 123.123.123.123 erlauben wäre das

iptables -A INPUT -p TCP -s 123.123.123.123 --dport 22 -j ACCEPT

also.. ich find das recht einfach struktiruert, aber klar.. auch hier muss man sich einlesen

  • »centurion« ist der Autor dieses Themas

Beiträge: 7

Registrierungsdatum: 25.03.2007

  • Nachricht senden

17

03.04.2007, 22:10

nunja dann werd ich mich mal an paar freien tagen wieder ans lesen machen, bis dahin hoffe ich das die fw ihren dienst einigermaßen tut. danke für die hilfe!

  • »misterxy« ist männlich

Beiträge: 1 106

Registrierungsdatum: 11.02.2007

Derivat: Kein Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Frickelbude - XFCE / LXDE

  • Nachricht senden

18

03.04.2007, 23:59

Also ich habe mich damit einwenig aus einander gesetzt mit diesen Thema und bin bei Guarddog [http://wiki.ubuntuusers.de/Guarddog] hängen geblieben kann so ähnlich einstellen wie Sygate und mit einwenig Übung sein System wirklich gut Abdichten somit unberechtigten /unbefugten Traffic weitgehend verhindern

Greetz
Chrome OS + Bill OS = Auf die Knie und Danke Diene Liebe deinen Gott!
Back to the Roots!