-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathPOSIX Permissions and Stateful Firewalls.html
1642 lines (1208 loc) · 161 KB
/
POSIX Permissions and Stateful Firewalls.html
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
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!-- saved from url=(0081)https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html -->
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="robots" content="index,nofollow"></head><body dir="ltr" lang="en">10
<title>POSIX Permissions and Stateful Firewalls</title>
<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="./POSIX Permissions and Stateful Firewalls_files/common.css">
<link rel="stylesheet" type="text/css" charset="utf-8" media="screen" href="./POSIX Permissions and Stateful Firewalls_files/screen.css">
<div id="page" dir="ltr" lang="en">
<h1>POSIX Permissions and Stateful Firewalls</h1>
<div class="author">Created by: Peter A. H. Peterson and Dr. Peter Reiher, UCLA {pahp, reiher}@cs.ucla.edu, with Dr. Tanya Crenshaw, UP {[email protected]}<br>
</div>
<div class="due-date">Due: Thursday, October 13th, 2011 11:59PM via CourseWeb</div>
<div class="table-of-contents">
<div class="table-of-contents-heading">Contents</div>
<ol type="1">
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#overview">Overview</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#reading">Required Reading</a>
<ol>
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#posix">POSIX Permissions</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#criticisms">Criticisms</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#sudo">sudo and Alternatives</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#permtools">Software Tools</a>
<ol>
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#adduser">adduser, chfn, passwd</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#addgroup">addgroup</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#usermod">usermod</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#chown">chown, chgrp</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#chmod">chmod</a>
</li></ol>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#firewalls">Firewalls</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#policy">Policy Design</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#nettools">Firewall and Network Testing Tools</a>
<ol>
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#netfilter">iptables</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#nmap">nmap</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#ifconfig">ifconfig</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#telnet">telnet</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#netcat">netcat</a>
</li></ol>
</li></ol>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#intro">Introduction</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#assignment">Assignment Instructions</a>
<ol>
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#setup">Setup</a>
<ol>
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#saving">Saving your work</a></li>
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#restoring">Restoring your work</a></li>
</ol>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#tasks">Tasks</a>
<ol>
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#homedirsec">Home Directory Security</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#ballotbox">The Ballot Box</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#tpsreports">The TPS Reports Directory</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#sudoprobs">sudo Problems</a>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#firewall">Firewall Configuration</a>
</li></ol>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#tips">Tips and Tricks</a>
<ol>
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#ambiguity">Resolving ambiguities</a></li>
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#envvars">Using environment variables</a></li>
<li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#fwtest">Testing your firewall</a></li>
</ol>
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#glitches">What Can Go Wrong</a>
</li></ol>
<!-- <li><a href="#extra">Extra Credit (optional section)</a> -->
</li><li><a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#submission">Submission Instructions</a>
</li></ol>
</div>
<span class="anchor" id="overview"></span>
<h2>Overview</h2>
<p>The purpose of this exercise is to introduce you to filesystem and network access control schemes and the "principle of least privilege" through the use of POSIX filesystem permissions and <tt>iptables</tt> firewalls.
</p><p>After this exercise, you will:
</p><ol type="1"><li>understand the POSIX permissions structure including SUID and SGID bits
</li><li>understand the essence of the sudo utility and how to configure and use it securely.
</li><li>be able to apply that knowledge to configure permissions in multiple scenarios, such as:
<ol type="1"><li>shared system directories
</li><li>user home directories and private directories
</li><li>privileged system directories
</li><li>unprivileged temporary directories
</li><li>editing important configuration files
</li><li>restarting system processes
</li><li>potential privilege escalation problems
</li></ol></li><li>understand the basics of stateful firewalls
</li><li>be able to apply that knowledge to configure a basic firewall in Linux using iptables.
</li></ol><p><span class="anchor" id="posix"></span><span class="anchor" id="unix"></span>
<span class="anchor" id="reading"></span>
</p><h2>Required Reading</h2>
<h3>POSIX Permissions</h3>
<span class="anchor" id="posix"></span>
<p>The Portable Operating System Interface, or POSIX, is IEEE standards family <strong>IEEE 1003.1</strong> and represents an attempt to formalize the API for variants of the Unix operating system. POSIX specifies standards for the kernel APIs (including many internal functions like permissions, threads, networking, and interprocess communication), commands, required utilities and user-level APIs (including many utilities and scripting tools like awk, echo, ed, sh, vi, basic I/O, and more), and a conformance test that can be run on many platforms. POSIX is very widely disseminated and has been in use for almost 20 years, but is a closed standard (i.e. proprietary). As a result, it is expensive to be certified; this has resulted in many free operating systems such as FreeBSD and Linux being substantially compliant but not officially able to use the moniker "POSIX Compliant". An alternative to POSIX is the <a class="http" href="http://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>, developed by the Austin Group. Unfortunately, it is also proprietary and expensive.
</p><p>The expense has not been prohibitive for motivated commercial vendors however, and POSIX has been extremely influential in coalescing and standardizing those elements that are characteristically UNIX-like. Furthermore, POSIX is a standard that influences software design and operating system implementations in seemingly unlikely places -- for example, Windows NT and its derivatives (2000, XP, and beyond) can be "POSIX compliant" with the addition of software packages and the enabling of certain features. This broad influence -- existing before the public explosion of the Internet -- has helped to make software and systems similar in fundamental ways. This, in turn, simplifies many portability and interoperability problems.
</p><p>One of the enduring legacies of Bell Labs UNIX and the POSIX standard are traditional Unix file system permissions, which are a simple system of permissions stored in the file system and and kernel and evaluated to mediate access to system resources. Additionally, since devices are files in Unix, file system permissions also mediate control over many aspects of the operating system.
</p><p>In most Unix and Unix-like operating systems, the permission system is extremely simple. Each file has <tt>read</tt>, <tt>write</tt>, and <tt>execute</tt> permissions set for each of three groups of users called "access classes". The three classes are <tt>user</tt> (owner), <tt>group</tt>, and <tt>other</tt>; each access class represents one or more users in the following way:
</p><ul><li><p>Users each have unique user identifiers (userids or UIDs, listed in <tt>/etc/passwd</tt>) that only they control.
</p></li><li><p>Groups are arbitrary collections of users. Each group has its own group identifier (groupid or GID, defined in <tt>/etc/group</tt>). Often, every user on the system has a personal group used for sharing data with a limited set of other users.
</p><ul><li><p>Example: the <tt>group</tt> class <tt>cdrom</tt> usually contains a list of all users granted permission to access the system's CD-rom drive.
</p></li><li><p>Example: the user <tt>sonny</tt> has a group <tt>sonny</tt> by default; the user <tt>cher</tt> can be added as a member of group <tt>sonny</tt> so that they can share resources between themselves but no one else.
</p></li></ul></li><li><p>Finally, the membership of the <tt>other</tt> class for each file is dependent on the <tt>user</tt> and members of the <tt>group</tt> class -- <strong>the</strong> <tt>other</tt> <strong>class does not represent "all users!"</strong> Specifically, the <tt>other</tt> class represents "everyone that is <em>not</em> the <tt>user</tt> (owner) of the file and <em>or</em> a member of the file's <tt>group</tt> class." This fact allows us to express more meaningful permissions by strictly dividing all system users into three non-overlapping sets.
</p><ul><li><p>A more precise way of stating this is to say that <tt>other</tt> represents the the list of all users on the system, minus the union of the <tt>user</tt> and <tt>group</tt> classes.
</p></li><li><p>Example: There are three users on a system: <tt>sonny</tt>, <tt>cher</tt>, and <tt>donovan</tt>. <tt>sonny</tt> owns a file whose group access class is set to the group <tt>sonny</tt>, which contains the user <tt>cher</tt>. The <tt>other</tt> class consists only of <tt>donovan</tt>, because he is not the owner nor in the group <tt>sonny</tt>.
</p></li></ul></li></ul><p>Each access class is encoded by 3 bits. Each bit present grants an additional permission from the set <tt>read</tt>, <tt>write</tt>, and <tt>execute</tt>. When you list files in long form (with the option <tt>-l</tt>), you will see the permissions written out in the leftmost column as a bitstring with the letters <tt>r</tt>, <tt>w</tt>, and <tt>x</tt> in the order <tt>user</tt>, <tt>group</tt>, and <tt>other</tt>:
</p><p>Here's what it looks like "in the wild":
</p><p>
</p><pre>$ ls -alh
-rw-r--r-- 1 pahp console 18K May 16 2006 gpl.txt
drwx------ 5 pahp console 512 May 21 2006 john-1.7.2/
lrwxrwxrwx 1 pahp console 25 Sep 13 20:45 labs -> /proj/some/link/
-rwxr--r-- 1 pahp console 171 Sep 9 09:18 loadimage.sh*
drwxrwxrwx 1 pahp console 512 Sep 13 20:45 worldwriteable/
^ ^ ^ ^--- other permissions
| | '------- group permissions
| '---------- user permissions
'------------ file type: d=directory, l=symbolic link, - means regular file
</pre>
<p>Here's an example bitstring split into components:
</p><p>
</p><pre> d rwx rwx rwx
type user group other
</pre>
<p>In the above example, the owner of the file <tt>gpl.txt</tt> has read and write permission because the <tt>owner</tt> part of the bitstring is set to <tt>rw-</tt>. The owner (<tt>pahp</tt>) cannot execute this file, but that doesn't matter because it's just a text file. The group class <tt>console</tt> can read the file, as can the members of the other class -- everyone else.
</p><p>The directory <tt>john-1.7.2</tt> is only accessible by the owner and nobody else. Notice the <tt>d</tt> in the first place; this means that the file is a directory.
</p><p>The file <tt>labs</tt> is a "<a class="http" href="http://en.wikipedia.org/wiki/Symbolic_link">symbolic link</a>" (sometimes called "soft link") to the directory <tt>/proj/some/link/</tt>. Symbolic links are a special kind of file that is a pointer to a disk location (a "pathname" which may or may not exist). Permissions on symbolic links do not work as their <tt>lrwxrwxrwx</tt> permissions might lead you believe.
</p><p>In addition to the 9 bits required to store the <tt>user</tt>, <tt>group</tt>, and <tt>other</tt> permissions of a file, there are three kinds of "additional permissions" that are rarely used but are extremely important to understand. The additional permissions are known as the <em>setuid bit</em>, <em>setgid bit</em>, and <em>sticky bit</em>. Each special bit has a different function depending on where it is used:
</p><p>When the the special bits are used on regular files:
</p><ul><li><p>The setuid bit on an executable file means that the file will run as the userid of the file's <em>owner</em> as opposed to the userid of the user executing the file. This is done to allow users to perform tasks that temporarily require the user to be someone else, such as changing passwords or restarting a service. Any program with the UID bit set must be carefully written so as to block all misuse. Innumerable vulnerabilities have stemmed from setuid <strong>root</strong> programs with security holes that allowed users to execute other commands as root.
</p></li><li><p>The setgid bit on an executable file is like the setuid bit, except that the process gains the effective user of the file's <em>group</em>, not its owner or the user executing the file.
</p></li><li>The "sticky bit" was used in the olden days to tell the kernel to keep an executable's image in memory so that it would not have to be reloaded from disk. This was commonly done with programs such as editors that were used regularly but had a significant load time. Modern systems use the "sticky bit" for other uses.
</li></ul><p>When the special bits are used on directories, they have different meanings altogether. Search online to discover what those meanings are on Linux systems.
</p><p>Every file has permissions of some kind set for the each of the three classes, using the three types of basic permissions: <tt>read</tt>, <tt>write</tt>, and <tt>execute</tt> (and the three special bits). These permissions have a default value (based on the system umask) when the file is created. Permissions can be changed with command line utilities such as <tt>chmod</tt> and <tt>chown</tt>, which are discussed <a href="https://education.deterlab.net/file.php/7/PermissionsFirewalls_UCLA/Exercise.html#permtools">later in this document</a>.
</p><p>These permissions are fairly self explanatory when applied to files, but when applied to directories their meanings are <strong>not always intuitive</strong>. In particular, permissions set on a directory <strong>do not always apply to that directory's contents</strong>, and the concepts of "read", "write", and "execute" as they pertain to directories is not obvious. (It helps to think of a directory as a file which contains links to other files, rather than as a nested series of containers -- experiment on DETER to determine how they really interact!)
</p><p>Furthermore, while the special bits are commonly overlooked, they have important meanings with <strong>incredible significance</strong> in terms of security. You are encouraged to play with these permissions and read other materials in order to fully understand how they are interpreted.
</p><p><span class="anchor" id="criticisms"></span>
</p><h3>Criticisms</h3>
<p>Traditional Unix permissions date back to the early 1970s. While simple and inexpensive to implement and evaluate, they have long been criticized for being out of date and woefully inexpressive compared to the power of other access control systems. Other systems (such as Microsoft Windows and other ACL models for Unix) have more than three access groups, nested groups, explicit deny lists, the ability to specify write permissions for changing, creating, and deleting (with Unix permissions they are largely the same), the ability to consider arbitrary state in evaluating the ACLs (such as time of day, network address, etc.), the ability to make files invisible to unprivileged users, and many other features that traditional Unix permissions lack.
</p><p>Another important and oft-criticized fact is that Unix permissions do not exactly reflect the current state of the permissions configuration on the system. For example, while Unix checks the file permissions at the moment a file is <em>opened</em>, it only checks those permissions <em>once</em> for each <tt>open</tt> system call. This means that the permissions are only tested when you <em>first open the file for reading, writing, or executing</em>, <strong>not</strong> each time you access or modify the file's contents via an open file descriptor. If a user opens a file, and immediately thereafter all permissions on that file for that user are removed, the user with the open file descriptor will <em>still</em> have access to the resource according to the permissions set <em>when the file was opened</em>, even if the <em>current</em> permissions deny reading, writing, or execution.
</p><p>Furthermore, the traditional Unix permissions and authentication system assigns group membership and other credentials at login time and <em>never</em> checks them again -- this means that system password, login permission, group membership details in <tt>/etc/group</tt> and other details changed <em>after</em> you log in are <strong>not</strong> reflected in your processes until you log out and log back in or the process with those credentials is restarted. For example, this means that any change to a user group is fully applied only when all affected processes have been restarted. Another example is that if an attacker steals a password and logs in to a system before that account is disabled or the password is changed, the attacker will still have that level of authentication until he or she logs out.
</p><div class="infobox">
<p>
<img src="./POSIX Permissions and Stateful Firewalls_files/idea.png">
This is an example of a <i>time-of-check vs. time-of-use</i> (TOCTOU) problem.
</p></div>
<p>These design decisions were made to limit the space occupied by and CPU cycles spent evaluating system permissions. As long as the semantics of the system (including the above criticisms) are fully understood, it can be an effective, acceptably secure solution for many purposes. In fact, in some ways, its simplicity and even naivete make it more transparent and easily understandable when compared to more complex systems. For these and many other reasons, the traditional Unix file permissions are still in wide use, over 40 years after their initial deployment.
</p><p><span class="anchor" id="sudo"></span>
</p><h3>sudo and Alternatives</h3>
<p>Some applications simply require stronger guarantees, finer granularity, or other features that the traditional permissions cannot express. For those applications, users have many alternatives. <tt>sudo</tt> is one simple extension to traditional Unix permissions that has become very popular.
</p><p><strong>sudo</strong> is a setuid root application with its own ACL (stored in <tt>/etc/sudoers</tt>) that specifies, with fine granularity, tasks that users and groups can perform as root. For example, sudo could be used to allow a user to act as root in order to kill processes with a specific name. The user would otherwise have no additional privileges. This is an example of a perfect use for setuid root programs -- granting strongly-constrained privileges to unprivileged users.
</p><p>However, sudo is a double edged sword. On the one hand, it greatly enhances the expressiveness of Unix permissions without actually changing the permissions system. On the other hand, if improperly configured, it offers <strong>easy access to root</strong>. For more information on sudo and the sudoers ACL format, please see the manpages for sudo and sudoers (the configuration file), or other sudo-related material online (in particular regarding sudo exploits).
</p><p>Beyond sudo, two broader and more revolutionary alternatives for Linux permissions include SELinux and grsecurity, while other options exist including LDAP, Novell eDirectory, and other permissions systems for other operating systems. (We won't be using any of these.)
<span class="anchor" id="permtools"></span>
</p><h3>Software Tools</h3>
<p>
<span class="anchor" id="adduser"></span>
</p><p>
</p><h4>adduser, chfn, passwd: add users to a system</h4>
<p>
<tt>adduser</tt> is the tool available for adding users to the system. To create a new user, execute:
</p><p>
</p><pre>$ adduser username
</pre>
<p>
<tt>adduser</tt> will copy files from the <tt>/etc/skel</tt> directory to become the new homedir of the new user in the <tt>/home/</tt> directory. You can specify a different home directory or automatically add the new user to groups; those options can be found in the <tt>adduser</tt> manpage.
</p><p>
<tt>adduser</tt> does not set any <tt>finger</tt> information for the user (this is not strictly necessary anyway), but the tool <tt>chfn</tt> will do that:
</p><p>
</p><pre>$ sudo chfn jimbo
Changing finger information for jimbo.
Name []: ...
</pre>
<p>
By default, the user is created with a "locked out" account with no password set. To set the password, use the command <tt>passwd</tt>:
</p><p>
</p><pre>$ sudo passwd jimbo
Changing password for user jimbo.
New Unix password:
Retype new Unix password:
passwd: all authentication tokens updated successfully.
</pre>
<p>
<tt>passwd</tt> will complain if it doesn't like the password you enter, but will accept anything with enough prodding.
</p><p>
Once an account is created, you can log into it in a number of ways:
</p><ol type="1"><li><p>
If logged in to the system where you created the account, you can execute <tt>ssh newuser@localhost</tt> to reconnect locally as the new user with the new password.
</p></li><li><p>
If local, you can also use the <tt>su</tt> command <tt>su newuser</tt> to change to that user. This does not always update all access credentials, however. This method can also be used to become root by entering <tt>sudo su -</tt>.
</p></li><li><p>
If logged in to <tt>users.deterlab.net</tt>, you can ssh to the node as the new user.
</p></li></ol><p>
<span class="anchor" id="addgroup"></span>
</p><p>
</p><h4>groupadd: add groups to a system</h4>
<p>
<tt>groupadd</tt> adds a new group to the system with a unique ID (by default). Example:
</p><p>
</p><pre>$ groupadd newgroup
</pre>
<p>
See <tt>man groupadd</tt> for more information.
</p><p>
<span class="anchor" id="usermod"></span>
</p><p>
</p><h4>usermod: modify a user</h4>
<p>
<tt>usermod</tt> can be used to modify many details of a preexisting user account. For more information, see <tt>man usermod</tt>.
</p><p>
<span class="anchor" id="chown"></span>
</p><p>
</p><h4>chown, chgrp: change ownership of a file</h4>
<p>
<tt>chown</tt> stands for <strong>ch</strong>ange <strong>own</strong>ership and is (unsurprisingly) used to change the owner and group of a file.
</p><p>
The syntax is very simple. To change the owner of a file, execute:
</p><p>
</p><pre>$ chown newowner filename
</pre>
<p>
To change the owner and group classes of a file, execute:
</p><p>
</p><pre>$ chown newowner:newgroup filename
</pre>
<p>
<tt>chgrp</tt> stands for <strong>ch</strong>ange <strong>gr</strong>ou<strong>p</strong> and works very similarly to <tt>chown</tt>. To change the group of a file, execute:
</p><p>
</p><pre>$ chgrp newgroup filename
</pre>
<p>
Recursive and other options exist; see <tt>man chown</tt> or <tt>man chgrp</tt> for more information.
</p><p>
<span class="anchor" id="chmod"></span>
</p><p>
</p><h4>chmod: change the mode of a file</h4>
<p>
chmod stands for <strong>ch</strong>ange <strong>mod</strong>e and is used to change the permissions mode of a file. Earlier, we discussed how the POSIX ACL has three access classes. User (or owner), group, and other (or world). The permissions mode for each access class can be changed by the <tt g="">chmod</tt> command.
</p><p>
There are two ways to use <tt>chmod</tt>; one is an <em>absolute numeric mode</em> and the other is a <em>symbolic mode</em>.
</p><p>
</p><h5>chmod: absolute -- setting the permissions explicitly</h5>
<p>
In the absolute mode, <tt>chmod</tt> takes a file mode in 3 or 4 digits, each of which represents the absolute permission mode for one access class expressed in octal, where each number is a sum of the permission bits. Each permission has a unique value: <tt g="">read</tt> permission is <tt class="backtick">4</tt>, <tt class="backtick">write</tt> permission is <tt class="backtick">2</tt>, and <tt class="backtick">execute</tt> permission is <tt class="backtick">1</tt>. These values represent the position of the permission in a 3-bit value.
</p><p>
For example, the mode <tt g="">777</tt> means "full permissions" because all bits are set in each access class. Similarly, <tt class="backtick">000</tt> means "no permissions" because all bits are unset in each access class.
</p><p>
The 3-digit mode <tt g="">777</tt> is the equivalent to the 4-digit mode <tt class="backtick">0777</tt> where the leading <tt class="backtick">0</tt> represents the "special" permission class of setuid, setgid, and sticky. Likewise, the modes <tt class="backtick">000</tt> and <tt class="backtick">0000</tt> are equivalent and represent the absence of permission. (The owner of the file and root still have the ability to change the file's mode by virtue of their ownership and superuser status.) Finally, if the 3-digit mode is used, <tt class="backtick">chmod</tt> always assumes that the special access class is <tt class="backtick">0</tt>. Therefore, if you set an suid-root file to mode <tt class="backtick">777</tt>, <tt class="backtick">chmod</tt> assumes that you meant mode <tt class="backtick">0777</tt>, which would take away the special permissions. This is consistent if you remember that octal modes represent <em>absolute permissions</em> and <em>the special group class is assumed to be <tt class="backtick">0</tt> if a 3-digit mode is provided.</em>
</p><p>
The following is a table to help calculate permission modes:
</p><div><table style="width: 200px"><tbody><tr> <td colspan="12" style="text-align: center;"><p>
<strong>chmod absolute values</strong> </p></td>
</tr>
<tr> <td colspan="3" style="text-align: center;">
<p>
special<em> </em> </p></td>
<td colspan="3" style="text-align: center;"><p>
user<em> </em> </p></td>
<td colspan="3" style="text-align: center;"><p>
group<em> </em> </p></td>
<td colspan="3" style="text-align: center;"><p>
other<em> </em> </p></td>
</tr>
<tr> <td>
<p>
<strong>s</strong> </p></td>
<td><p>
<strong>g</strong> </p></td>
<td><p>
<strong>t</strong> </p></td>
<td><p>
<strong>r</strong> </p></td>
<td><p>
<strong>w</strong> </p></td>
<td><p>
<strong>x</strong> </p></td>
<td><p>
<strong>r</strong> </p></td>
<td><p>
<strong>w</strong> </p></td>
<td><p>
<strong>x</strong> </p></td>
<td><p>
<strong>r</strong> </p></td>
<td><p>
<strong>w</strong> </p></td>
<td><p>
<strong>x</strong> </p></td>
</tr>
<tr> <td>
<p>
4 </p></td>
<td><p>
2 </p></td>
<td><p>
1 </p></td>
<td><p>
4 </p></td>
<td><p>
2 </p></td>
<td><p>
1 </p></td>
<td><p>
4 </p></td>
<td><p>
2 </p></td>
<td><p>
1 </p></td>
<td><p>
4 </p></td>
<td><p>
2 </p></td>
<td><p>
1 </p></td>
</tr>
</tbody></table></div>
<p>
For example, full access is <tt g="">0777</tt>, which represents:
</p><div><table><tbody><tr> <td colspan="3" style="text-align: center;"><p>
special<em> </em> </p></td>
<td colspan="3" style="text-align: center;"><p>
user<em> </em> </p></td>
<td colspan="3" style="text-align: center;"><p>
group<em> </em> </p></td>
<td colspan="3" style="text-align: center;"><p>
other<em> </em> </p></td>
</tr>
<tr> <td>
<p>
<strong>s</strong> </p></td>
<td><p>
<strong>g</strong> </p></td>
<td><p>
<strong>t</strong> </p></td>
<td style="background-color: #ff8080"><p>
<strong>r</strong> </p></td>
<td style="background-color: #ff8080"><p>
<strong>w</strong> </p></td>
<td style="background-color: #ff8080"><p>
<strong>x</strong> </p></td>
<td style="background-color: #80ff80"><p>
<strong>r</strong> </p></td>
<td style="background-color: #80ff80"><p>
<strong>w</strong> </p></td>
<td style="background-color: #80ff80"><p>
<strong>x</strong> </p></td>
<td style="background-color: #8080ff"><p>
<strong>r</strong> </p></td>
<td style="background-color: #8080ff"><p>
<strong>w</strong> </p></td>
<td style="background-color: #8080ff"><p>
<strong>x</strong> </p></td>
</tr>
<tr> <td>
<p>
4 </p></td>
<td><p>
2 </p></td>
<td><p>
1 </p></td>
<td style="background-color: #ff8080"><p>
4 </p></td>
<td style="background-color: #ff8080"><p>
2 </p></td>
<td style="background-color: #ff8080"><p>
1 </p></td>
<td style="background-color: #80ff80"><p>
4 </p></td>
<td style="background-color: #80ff80"><p>
2 </p></td>
<td style="background-color: #80ff80"><p>
1 </p></td>
<td style="background-color: #8080ff"><p>
4 </p></td>
<td style="background-color: #8080ff"><p>
2 </p></td>
<td style="background-color: #8080ff"><p>
1 </p></td>
</tr>
<tr> <td colspan="3" style="text-align: center;">
<p>
0 </p></td>
<td colspan="3" style="text-align: center; ; background-color: #ff8080"><p>
<strong>7</strong> </p></td>
<td colspan="3" style="text-align: center; ; background-color: #80ff80"><p>
<strong>7</strong> </p></td>
<td colspan="3" style="text-align: center; ; background-color: #8080ff"><p>
<strong>7</strong> </p></td>
</tr>
</tbody></table></div>
<p>
There are no special bits set, so the <tt g="">special</tt> octal digit is <tt class="backtick">0</tt>, while all three bits in each other class are set. Each set of bits totals 7 (4 + 2 + 1), so the mode is <tt class="backtick">0777</tt>.
</p><p>
Another example is mode <tt g="">2755</tt>, which represents <tt class="backtick">setgid</tt> (2), plus "full access" for <tt class="backtick">user</tt> (4 + 2 + 1) and <tt class="backtick">write</tt> and <tt class="backtick">execute</tt> (4 + 1) access for both the <tt class="backtick">group</tt> and <tt class="backtick">other</tt> class.
</p><div><table><tbody><tr> <td colspan="3" style="text-align: center;"><p>
special<em> </em> </p></td>
<td colspan="3" style="text-align: center;"><p>
user<em> </em> </p></td>
<td colspan="3" style="text-align: center;"><p>
group<em> </em> </p></td>
<td colspan="3" style="text-align: center;"><p>
other<em> </em> </p></td>
</tr>
<tr> <td>
<p>
<strong>s</strong> </p></td>
<td style="background-color: #808080"><p>
<strong>g</strong> </p></td>
<td><p>
<strong>t</strong> </p></td>
<td style="background-color: #ff8080"><p>
<strong>r</strong> </p></td>
<td style="background-color: #ff8080"><p>
<strong>w</strong> </p></td>
<td style="background-color: #ff8080"><p>
<strong>x</strong> </p></td>
<td style="background-color: #80ff80"><p>
<strong>r</strong> </p></td>
<td><p>
<strong>w</strong> </p></td>
<td style="background-color: #80ff80"><p>
<strong>x</strong> </p></td>
<td style="background-color: #8080ff"><p>
<strong>r</strong> </p></td>
<td><p>
<strong>w</strong> </p></td>
<td style="background-color: #8080ff"><p>
<strong>x</strong> </p></td>
</tr>
<tr> <td>
<p>
4 </p></td>
<td style="background-color: #808080"><p>
2 </p></td>
<td><p>
1 </p></td>
<td style="background-color: #ff8080"><p>
4 </p></td>
<td style="background-color: #ff8080"><p>
2 </p></td>
<td style="background-color: #ff8080"><p>
1 </p></td>
<td style="background-color: #80ff80"><p>
4 </p></td>
<td><p>
2 </p></td>
<td style="background-color: #80ff80"><p>
1 </p></td>
<td style="background-color: #8080ff"><p>
4 </p></td>
<td><p>
2 </p></td>
<td style="background-color: #8080ff"><p>
1 </p></td>
</tr>
<tr> <td colspan="3" style="text-align: center; ; background-color: #808080">
<p>
<strong>2</strong> </p></td>
<td colspan="3" style="text-align: center; ; background-color: #ff8080"><p>
<strong>7</strong> </p></td>
<td colspan="3" style="text-align: center; ; background-color: #80ff80"><p>
<strong>5</strong> </p></td>
<td colspan="3" style="text-align: center; ; background-color: #8080ff"><p>
<strong>5</strong> </p></td>
</tr>
</tbody></table></div>
<p>
Absolute modes are applied like this:
</p><p>
</p><pre>$ chmod 0755 somefile.sh
</pre>
<p>
Absolute mode is great for setting things to be exactly what you want, or imposing a radically different order onto a file or directory, but it's not very good for adding the sticky bit to a file. For that kind of work (or if the octal modes just confuse you) the symbolic mode is well suited.
</p><p>
</p><h5>chmod: symbolic -- more user-friendly</h5>
<p>
The symbolic mode works pretty much the way you would expect. To add the <tt g="">execute</tt> bit to the <tt class="backtick">user</tt> class, you would execute a command like this:
</p><p>
</p><pre>$ chmod u+x somefile.sh
</pre>
<p>
Or to add <tt g="">execute</tt> to all three classes:
</p><p>
</p><pre>$ chmod ugo+x somefile.sh
</pre>
<p>
To make a file <tt g="">setuid</tt>:
</p><p>
</p><pre>$ chmod u+s somefile.sh
</pre>
<p>
To remove all permissions:
</p><p>
</p><pre>$ chmod ugo-rwxsgt somefile.sh
</pre>
<p>
Some people are so put off by the absolute mode that they never learn it -- you'll find with experience that both methods of setting permissions can be expeditious depending on the situation. More information is available in the <tt g="">chmod</tt> manpage.
</p><p>
Regardless of how you set permissions, it is critical that you use the "principle of least privilege" and only grant the privileges that are necessary for proper operation.
</p><p><span class="anchor" id="firewalls"></span>
</p><h2>Firewalls</h2>
<h3>Stateless Firewalls</h3>
<p>In the late 1980s, the Internet was just beginning to grow beyond its early academic and governmental applications into the commercial and personal worlds. The <a class="http" href="http://en.wikipedia.org/wiki/Morris_worm">Great Internet Worm</a> in November of 1988 infected around 6,000 hosts (roughly 10% of the Internet) in the first major infection of its kind and helped to focus research and awareness on securing computers from unauthorized access. It was in this environment that the first firewalls were written about and developed at Digital Equipment Corporation (DEC) and Bell Labs (AT&T).
</p><p>The first functional firewalls inspected individual packet headers without regard for established connections, other packets, or their contents. These kind of firewalls became known as "packet filters" because they literally filtered the packets one by one according to a set of criteria, not unlike a quality control inspector on an assembly line. For TCP and UDP, these criteria could be reduced essentially to the source and destination addresses and ports in the packet header. For example, a packet filter could reject or drop any packets destined for port 23 (telnet) on host 10.10.10.10 from any address other than 10.10.10.11. This kind of filter could rapidly and inexpensively inspect and classify packets without using much space (although they were not very "smart").
</p><p>Unsurprisingly, simple packet filters are not adequate for many applications, such as the <a class="http" href="http://en.wikipedia.org/wiki/Ftp">File Transfer Protocol</a> (FTP), because these protocols open additional connections on random ports that can not be anticipated or recognized by the firewall since it does not understand or consider the state of any connection.
</p><p>This kind of simple "packet filter" ultimately became known as a "stateless firewall".
</p><h3>Stateful Firewalls</h3>
<p>"Stateful firewalls" arrived not long after "stateless firewalls". Stateful firewalls keep tables of network connections and states in memory in order to determine if a packet is part of a preexisting network connection, the start of a new and legitimate connection, or an unwanted or unrelated packet. This kind of firewall can recognize, for example, that a new connection on a random high port from a host with a preexisting FTP connection is a related connection and should be allowed. Another difference is that while a stateless firewall will allow all packets from acceptable hosts to an open port, a stateful firewall can be configured to allow packets to that port only if a legitimate TCP connection (or some other protocol) has already been established in some acceptable way. Understanding protocol state essentially gives stateful firewalls vastly more criteria in deciding whether to accept or reject a packet, which translates into finer granularity.
</p><p>The cutting edge of firewall design today is what is called an "application-layer firewall", which is a firewall that performs "deep packet inspection". This means that the firewall is capable of looking not just at the header of the packets and the state of the connection, but at the payload of the packet in context of what the application processing the packets will do. For example, an application-layer firewall could be used to block Java applets from HTTP traffic by inspecting the packets and stripping Java code or dropping the packets entirely. In order to do this, it must understand what applet code looks like within the payload portion of any HTTP traffic stream. An application-layer firewall essentially has total control over the network stream, although this control comes at a significant expense in terms of CPU time and software complexity.
</p><p>Most firewalls in use today lie somewhere between the stateful firewall and the application-layer firewall. These firewalls function essentially as a stateful firewall, but may understand enough of a few applications to perform some application-layer tasks. It is also common to couple a primarily stateful firewall (such as netfilter/iptables) with separate application layer firewalls for individual applications.
</p><p><span class="anchor" id="policy"></span>
</p><h3>Firewall Policy Design</h3>
<p>People imagine many different things when they hear the term "<a class="http" href="http://en.wikipedia.org/wiki/Firewall">firewall</a>" in the context of computer networking. Some envision an impenetrable wall of flame <em>[at least I did --ed.]</em>. A Hollywood screenwriter might envision Harrison Ford battling kidnappers. A mechanic might envision the wall between the engine and passenger compartment of a car. Yet mysteriously, every firewall is illustrated as a boring, red brick wall, typically with no fire in sight.
</p><p>Actually, the brick wall isn't that strange -- the name "firewall" comes from the brick walls in buildings placed to stop the spread of a fire from one area to another. But no matter who you are or what you see in your minds eye, the conventional wisdom is that firewalls are used to "keep the bad stuff out," whether you're protecting your desktop PC at home, your office LAN, or the Pentagon. However, those of us in the field of computer security often see firewalls more as a means of keeping things <em>in</em> rather than keeping them <em>out</em>.
</p><p>In one sense, these are two sides of the same coin -- but how you design something is (often unconsciously) directly related to how you view the problem, and this can lead to very different design choices when developing a firewall. The goal of "keeping things out" is by definition, exclusively concerned with keeping external attackers "outside" the system, with no regard for what is inside that is worth protecting, and without considering threats (intentional or unintentional) that are <em>already</em> inside, like malicious or foolish employees. This is only half the picture. In contrast, "keeping things in" by definition concerns itself with what is "inside" like sensitive data, privileged access, etc., and encourages the designer to consider <em>all</em> threats -- both internal and external -- against the protected resource.
</p><p>Practically speaking, these two goals often result in different default policies. The goal of "keeping things out" often results in a policy that by default allows anything not considered to be a threat. This is called a <strong>default allow</strong> policy, and the classic example of this kind of firewall allows <strong>all</strong> outbound traffic, but only allows "untrusted" inbound traffic to special services, such as a web server (which is then responsible for its own security). This is better than nothing, but is hardly secure. If an attacker can trick someone inside into opening a <a class="http" href="http://en.wikipedia.org/wiki/Trojan_horse_(computing)">trojan horse</a>, the malicious software can exploit the liberal egress policy by making connections to a malicious host on the Internet, which can be used to send messages to the now-compromised system. Incidentally, this is how the firewalls on most home routers are designed.
</p><p>On the other hand, the "keeping things in" policy usually results in a policy that by default <em>denies everything</em>, and allows only what is necessary for the proper functioning of a system. This embodies the principle of "<a class="http" href="http://en.wikipedia.org/wiki/Principle_of_least_privilege">least privilege</a>" and in the context of a firewall is called a <strong>default deny</strong> policy. A firewall configured this way allows only the handful of things that are strictly required. This limits inbound traffic as before, but also only allows outbound traffic to carefully chosen targets. For example, this might only allow oubound traffic to a secured mail server, ssh server, and the few web servers required for an employee to accomplish their job. This drastically limits the means by which traffic can enter <em>or</em> leave the network, and if an employee executes a trojan as in the last example, that malicious software will not be able to contact its evil master because the malicious Internet host will almost certainly not be in the list of allowed outbound connections.
</p><p>The obvious downside to a "default deny" firewall policy is maintenance and inconvenience -- it is harder to install in the first place, and any new network service or traffic type on the network must be explicitly allowed or it will not function. Allowing all outbound traffic significantly cuts down on this kind of maintenance -- at the cost of security.
<span class="anchor" id="tools"></span>
</p><h3>Firewall and Network Testing Tools</h3>
<span class="anchor" id="netfilter"></span>
<h4>iptables: set and clear rules in netfilter</h4>
<p>
<a class="http" href="http://en.wikipedia.org/wiki/Iptables">iptables</a> is actually the user space tool for administering the <tt>netfilter</tt> functions and tables in the Linux kernel, but the entire <tt>netfilter</tt> and <tt>iptables</tt> package is commonly referred to simply as <tt>iptables</tt>. <tt>iptables</tt> has several built-in tables of rules (such as <tt>filter</tt> and <tt>nat</tt>) , several built-in "chains" (which are sets of network traffic including the built-in INPUT, OUTPUT, and FORWARD for inbound, outbound, and routed traffic), a set of powerful loadable modules of matching stateful filters, the typical set of stateless criteria (such as source, destination, and interface), and a set of targets that represent what to do with a matching packet. These options allow sophisticated firewalls to be defined.
</p><p>
<tt>iptables</tt> can be intimidating and confusing at first glance even for veteran sysadmins, but especially to users who are not used to configuring firewalls at all or are used to configuring firewalls through a GUI. <tt class="backtick">iptables</tt> expressive plugins further complicate the syntax. A typical <tt>iptables</tt> command looks something like this:
</p><p>
</p><pre>$ iptables -t filter -A INPUT -m state --state NEW -p tcp -s 192.168.0.1 --dport 23 -j REJECT
</pre>
<p>
Upon closer inspection, <tt>iptables</tt> is revealed to be merely a command whose arguments define a single rule for packet filtering based on a number of possible criteria. <tt>iptables</tt> takes those arguments translates them one command at a time into priority-ordered filter rules in the Linux kernel. Thinking of <tt>iptables</tt> as a command with arguments can help demystify <tt>netfilter</tt> and the process of designing firewalls with <tt>iptables</tt> -- let's break down the above <tt class="backtick">iptables</tt> command and translate it into English:
</p><div><table style="width: 800px"><tbody><tr> <td colspan="2" style="text-align: center;"><p>
<strong>iptables command arguments</strong> </p></td>
</tr>
<tr> <td>
<p>
<strong>command/argument</strong> </p></td>
<td><p>
<strong>translation</strong> </p></td>
</tr>
<tr> <td>
<p>
<tt class="backtick">iptables</tt> </p></td>
<td><p>
<em>We're going to use the iptables tool to insert a new rule into netfilter.</em> </p></td>
</tr>
<tr> <td>
<p>
<tt class="backtick">-t filter</tt> </p></td>
<td><p>
<em>This rule is going to go in the filter table, which is the built-in packet filtering table. This rule will apply only to:</em> </p></td>
</tr>
<tr> <td>
<p>
<tt class="backtick">-A INPUT</tt> </p></td>
<td><p>
<em>packets that have been put into the <tt>INPUT</tt> chain either by the kernel or by some previous rule and which:</em> </p></td>
</tr>
<tr> <td>
<p>
<tt class="backtick">-m state --state NEW</tt> </p></td>
<td><p>
<em>represent a new connection,</em> </p></td>
</tr>
<tr> <td>
<p>
<tt class="backtick">-p tcp</tt> </p></td>
<td><p>
<em>are Transmission Control Protocol (TCP) packets,</em> </p></td>
</tr>
<tr> <td>
<p>
<tt class="backtick">-s 192.168.0.1</tt> </p></td>
<td><p>
<em>are from the host 192.168.0.1,</em> </p></td>
</tr>
<tr> <td>
<p>
<tt class="backtick">--dport 23</tt> </p></td>
<td><p>
<em>and are destined for port 23.</em> </p></td>
</tr>
<tr> <td>
<p>
<tt class="backtick">-j REJECT</tt> </p></td>
<td><p>
<em>Reject any matching packet. Processing of all packets matching this rule will instantly jump to the built-in target REJECT, which means that the packet will be rejected by the kernel with some kind of network error message.</em> </p></td>
</tr>
</tbody></table></div>
<p>
A few other examples:
</p><p>
</p><pre>$ iptables -p tcp --syn --dport 23 -m connlimit --connlimit-above 2 -j REJECT
</pre>
<p>
This rule (from <tt>man iptables</tt>) allows 2 telnet connections per client host. Note that this rule uses the <tt>connlimit</tt> matching module, and rejects additional connections.
</p><p>
</p><pre>$ iptables -A INPUT -i lo -j ACCEPT
$ iptables -A OUTPUT -o lo -j ACCEPT
</pre>
<p>
These rules accepts any inbound or outbound traffic on the internal loopback network device (an internal, logical network adapter the kernel uses for network communication internal to the computer) regardless of state, protocol, source, or destination address. The <tt>-i lo</tt> and <tt>-o lo</tt> arguments specify the "input interface" and "output interface" the packet arrived on.
</p><p>
</p><pre>$IPTABLES -t filter -A INPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -t filter -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
</pre>
<p>
These rules accept all INBOUND and OUTBOUND traffic regardless of interface, address, port or protocol. They use the <tt>state</tt> matching module, but accept all NEW, RELATED, and ESTABLISHED packets (which is basically all traffic). This rule is basically like having no firewall at all!
</p><p>
<strong>NEW, RELATED, ESTABLISHED</strong>
</p><p>
Think of your firewall as a security checkpoint in a big office building. There's usually two lines -- one for people with IDs, and one for people without IDs. If someone already has an ID, they can skip the long line, and go through. If they don't, they have to wait to get an ID card or visitor's pass. This is analogous to the distinction between <strong>NEW</strong> traffic versus <strong>RELATED</strong> or <strong>ESTABLISHED</strong> traffic (which you usually see together). Traffic marked <strong>NEW</strong> doesn't have an ID badge yet, because it is the first packet of a new stream of traffic. On the other hand, a packet of a <strong>RELATED</strong> or <strong>ESTABLISHED</strong> stream is part of something that by definition has already come through the firewall in the past. In other words, the firewall has already given that stream a "badge" (which is really an entry in an internal firewall data structure).
</p><p>
Among other things, this means that firewalls are typically structured so that the first section passes all accepted <strong>RELATED,ESTABLISHED</strong> traffic first, and then carefully allows only certain kinds of <strong>NEW</strong> traffic. Why do it in that order?
</p><p>
While this brief introduction to <tt>iptables</tt> should point you in the right direction, there are other features of <tt>iptables</tt> not included here that you may want to use for the exercise. There are many HOWTOs, tips, and tutorials online in addition to the <tt>iptables</tt> manpage; the exercise manual assumes that in order to complete the <tt>iptables</tt> exercise, you will need to <a class="http" href="http://www.google.com/">do some research</a> on your own.
<span class="anchor" id="nmap"></span>
</p><h4>nmap: network mapping port scanner</h4>
<p>
<a class="http" href="http://en.wikipedia.org/wiki/Nmap">Nmap</a> (<a class="http" href="http://www.insecure.org/">homepage</a>) is a very popular "<a class="http" href="http://en.wikipedia.org/wiki/Port_scanner">port scanner</a>" that can be used to determine what kind of services are running on a remote or local host, perform <a class="http" href="http://en.wikipedia.org/wiki/Passive_OS_Fingerprinting">OS fingerprinting</a>, and many other tasks. Nmap is capable of performing many tasks in a "stealth mode" designed to not raise the suspicion of the victim, but some tasks require more obvious techniques.
</p><p>
Nmap is incredibly powerful, but the basic functionality of the application is easy to use:
</p><p>
</p><pre>$ sudo nmap yahoo.com
Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-22 21:33 PDT
Warning: Hostname yahoo.com resolves to 2 IPs. Using 216.109.112.135.
Interesting ports on w2.rc.vip.dcn.yahoo.com (216.109.112.135):
Not shown: 1694 filtered ports
PORT STATE SERVICE
25/tcp open smtp
80/tcp open http
443/tcp open https
Nmap finished: 1 IP address (1 host up) scanned in 29.990 seconds
$ sudo nmap www.somehost.edu -P0
Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-22 21:34 PDT
Interesting ports on dns.somehost.edu (33.xx.111.1):
Not shown: 1677 filtered ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
443/tcp open https
2048/tcp open dls-monitor
2049/tcp closed nfs
2053/tcp open knetd
2064/tcp closed dnet-keyproxy
2065/tcp open dlsrpn
2067/tcp open dlswpn
2068/tcp open advocentkvm
2105/tcp open eklogin
2106/tcp open ekshell
2108/tcp open rkinit
2111/tcp open kx
2112/tcp open kip
2120/tcp open kauth
2121/tcp open ccproxy-ftp
2201/tcp open ats
2232/tcp open ivs-video
2241/tcp closed ivsd
Nmap finished: 1 IP address (1 host up) scanned in 32.385 seconds
</pre>
<p>
See the Nmap manpage or online documentation for advanced features.
</p><p>
<span class="anchor" id="ifconfig"></span>
</p><h4>ifconfig: configure Linux network devices</h4>
<p>
<a class="http" href="http://en.wikipedia.org/wiki/Ifconfig">ifconfig</a> is the network interface configurator in Linux. It is most commonly used by users to see network addresses and statistics, but can also be used to enable and disable interfaces, set configuration options such as network addresses, and more.
</p><p>
For the purposes of this exercise, <tt class="backtick">ifconfig</tt> will be used to determine what network addresses are running on what interfaces.
</p><p>
To see the current interface configurations:
</p><p>
</p><pre>$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:00:5A:00:01:B3
inet addr:64.81.0.256 Bcast:64.81.40.255 Mask:255.255.255.0
inet6 addr: fe80::200:5aff:fe00:1b3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1826346 errors:0 dropped:0 overruns:0 frame:0
TX packets:1887951 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:691689933 (659.6 MiB) TX bytes:1037280707 (989.2 MiB)
Interrupt:58
eth1 Link encap:Ethernet HWaddr 00:13:D4:04:44:CA
inet addr:10.10.10.10 Bcast:10.10.10.255 Mask:255.255.0.0
inet6 addr: fe80::213:d4ff:fe04:44ca/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1165519 errors:0 dropped:0 overruns:0 frame:0
TX packets:1549057 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:428484191 (408.6 MiB) TX bytes:1780325755 (1.6 GiB)
Interrupt:50
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:5808042 errors:0 dropped:0 overruns:0 frame:0
TX packets:5808042 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6895907043 (6.4 GiB) TX bytes:6895907043 (6.4 GiB)
</pre>
<p>
Note that <tt class="backtick">eth0</tt>'s address is 64.81.0.256, while <tt>eth1</tt>'s address is 10.10.10.10. This means that the two interfaces are on different networks.
<span class="anchor" id="telnet"></span>
</p><h4>telnet: cleartext remote shell</h4>
<p>
<a class="http" href="http://en.wikipedia.org/wiki/Telnet">TELNET</a> (TELe-NETwork) is a cleartext remote terminal protocol. On its face, telnet is very simple; the user issues commands over a TCP socket, and the server replies with the results of those commands and waits for more input. In practice, this is complicated with various network and terminal emulation layers. Still, telnet is one of the simplest and oldest network protocols still in use. Due to its cleartext nature and low level access to the system, telnet is incredibly insecure -- it was common in the past for system administrators to log in as root using telnet on a hub network connection that could be sniffed by any sufficiently prepared attacker.
</p><p>
Thanks to the advent of Secure Shell (ssh), active use of telnet servers has died off except for some specialized uses. One place where telnet lives on is debugging ASCII-based network services. For example, web pages can be retrieved by telnetting to HTTP servers, and emails can be sent by telnetting to SMTP servers.
</p><p>
Telnetting to a suspected open port is still one of the fastest ways to see if a service is available or reachable.
</p><p>
Here are a few sample uses of telnet:
</p><p>
</p><pre>$ telnet yahoo.com 80
Trying 66.94.234.13...
Connected to yahoo.com.
Escape character is '^]'.
GET /
...
<html><head> ...[web page data] ...
</body>
</html>
Connection closed by foreign host.
</pre>
<p>
</p><pre>$ telnet mailserver.net 25
Trying 216.0.1.1...
Connected to mailserver.net.
Escape character is '^]'.
220 mailserver.net ESMTP Postfix (Ubuntu)
HELO sender.net
250 sender.net
MAIL FROM: [email protected]
250 Ok
RCPT TO: [email protected]
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: test mail message
test message
.
250 Ok: queued as 152CFB8802A
^]
telnet> Connection closed.
You have mail in /var/mail/me
</pre>
For this exercise, you will use <tt>telnet</tt> to test if a TCP port is open on a remote host. Telnetnetting to an IP and port (see above) should return a "connected" message if it is possible to connect to a running server.
<span class="anchor" id="nc"></span>
<h4>netcat: a network swiss army knife</h4>
<p>
netcat (often <tt class="backtick">nc</tt> on some systems) is a Unix utility for creating and using TCP and UDP sockets. In a very simplified way, <tt class="backtick">netcat</tt> is like a telnet client and server without any built in protocol or terminal emulation. Another way of putting it is that <tt class="backtick">netcat</tt> is the bare essentials for creating a TCP or UDP socket and client, with hooks for using standard in and standard out for IO.
</p><p>There are too many cool uses of netcat to describe here. For the purposes of this exercise, we'll use netcat to create "fake" TCP or UDP servers that we can use to test firewall configurations.
</p><h5>Creating fake TCP/UDP servers with netcat</h5>
<p>
Starting a fake listening server (a program that will accept connections on a port) is as simple as running:
</p><p>
</p><pre>$ sudo nc -l 80 # we need sudo because 80 is a privileged port
</pre>
<p>