Annotation of wikisrc/nsps.mdwn, revision 1.2
1.1 jdf 1: # NetBSD Security Processes and Services
2:
3: This document covers secure processes and services for NetBSD Operating
4: Systems and Networks. Most of the information in this document can
5: easily be translated to other BSD systems, however.
6:
7: # Overview
8:
9: ## Setup Example
10:
11: Simply writing this document without some sort of consistent example
12: would be quite difficult, so for the sake of easy discussion, the
13: following is what we want to accomplish:
14:
15: Internal Network clients, hosts, internal servers
16: 172.16.0.0
17:
18: |
19: |
20:
21: NetBSD Firewall fxp0 172.16.14.1
22: Server with SSH Open ------------------
23: ep0 216.68.250.60
24:
25: |
26: |
27:
28: Internet Connection gateway switch/
29: Provider Network router
30: 216.68.250.65
31:
32: |
33: |
34:
35: Big Bad Internet insert cloud here
36:
37: This is a pretty common setup for many organizations, to be connected
38: via a service providers network out onto the internet.
39:
40: The purpose of this firewall is to allow the clients on the 172.16.0.0
41: network to interact with the internet.
42:
43: ## The Desired Setup of the Firewall
44:
45: In a nutshell we want the firewall to be able to pass certain traffic in
46: and out, however, we only want one available service *at* the firewall
47: itself, that service is Secure Shell. Following is a matrix of how this
48: particular installation is to look:
49: <table>
50: <tr>
51: <th>Service</th>
52: <th>Connect to Firewall</th>
53: <th>Pass In</th>
54: <th>Pass Out</th>
55: </tr>
56: <tr>
57: <th>DNS</th>
58: <td>NO</td>
59: <td>YES</td>
60: <td>YES</td>
61: </tr>
62: <tr>
63: <th>SMTP</th>
64: <td>NO</td>
65: <td>YES</td>
66: <td>YES</td>
67: </tr>
68: <tr>
69: <th>HTTP</th>
70: <td>NO</td>
71: <td>YES</td>
72: <td>YES</td>
73: </tr>
74: <tr>
75: <th>FTP</th>
76: <td>NO</td>
77: <td>YES</td>
78: <td>YES</td>
79: </tr>
80: <tr>
81: <th>SSH</th>
1.2 ! jdf 82: <td>YES</td>
1.1 jdf 83: <td>YES</td>
84: <td>YES</td>
85: </tr>
86: </table>
87:
88: It is important to note here that we need to be able to pass DNS, SMTP,
89: FTP and HTTP traffic, however, we only really *want* the SSH service to
90: be able to establish a connection to the firewall. The reason noting
91: this now is important is because the rules in IPFILTER for making a
92: connection and passing traffic are nearly identical.
93:
94:
95: ## More than one way to . . .
96:
97: The setup used throughout this document is an example, there is
98: definitely more than one way to do this, for example:
99:
100: private network firewall DMZ with public firewall uplink
101: web, ftp, etc.
102: servers
103:
104: The DMZ would have publicly accessible web servers, ftpd servers etc. In
105: our example, we do not require the DMZ since we are not hosting any web
106: servers or running a DNS server that will participate with the rest of
107: the internet.
108:
109: # Configuring Secure Shell
110:
111: NetBSD ships with a Secure Shell implementation based on OpenBSD's. The
112: default configuration of Secure Shell is done quite well, and there is
113: little an administrator needs to actually do in most cases. Turning on
114: the Secure Shell daemon is required, however. For posterity, we are
115: going to take a short look at configuring it.
116:
117: ## The Client Side Configuration File
118:
119: The ssh client's configuration file is located in `/etc/ssh/ssh_config` and in
120: `~/.ssh/config` for single users.
121: The options contained in it are named intuitively and are rather verbose.
122: Documentation can be found in the ssh_config(5) manpage.
123:
124: ## The Server Configuration File
125:
126: The server side of SSH is configured via `/etc/ssh/sshd_config`. The defaults
127: are set to high security levels by default. To enable the ssh server, put the
128: line `sshd=yes` into `/etc/rc.conf` and run
129:
130: /etc/rc.d/sshd restart
131:
132: to start the server daemon and create any host keys if they are not already
133: present.
134:
135: One item to take note of is that the server config does not allow X11 forwarding
136: by default, which of course on a firewall is a **good thing**. To enable it the
137: administrator must change the following lines:
138:
139: StrictModes no
140: X11Forwarding yes
141:
142: Again, there is little to nothing the administrator needs to do with the Secure
143: Shell setup unless they wish to alter the default config.
144:
145: # Configuring IPFILTER
146:
147: NetBSD ships with IPfilter as its default firewall and packet filtering
148: software.
149:
150: ## Understanding The ipf.conf File
151:
152: The file that controls firewall rules for ipfilter is `/etc/ipf.conf` for IPv4
153: and `/etc/ipf6.conf` for IPv6. In this section we will go over the settings we
154: need and how I chose to implement them.
155:
156: Basically, ipfilter operates on two basic principles:
157:
158: 1. match the current line
159: 2. the last line supersedes previous ones
160:
161: Following is a very rudimentary `ipf.conf` file:
162:
163: pass in on any all
164: block in on any all
165:
166: According to the first line, on any interface, all traffic may be
167: passed. On the second line, however, all traffic on any interface is
168: blocked.
169:
170: ## The Syntax
171:
172: For the most part, ipfilter syntax is generally easy to follow, it is almost
173: natural. To pass in certain traffic, one says pass in, to pass out, pass out.
174: The interface can be specified or it can be all by saying something like:
175:
176: pass out on all . . .
177:
178: If one wanted to specify the interface:
179:
180: pass out on ep0 . . .
181:
182: So far so good, now lets look at the configuration we need for our firewall,
183: first we already know we want SSH traffic to be able to pass and connect:
184:
185: # sshd in from any
186: pass in quick on ep0 proto tcp from any to 216.68.250.60/32 port = 22 keep state
187:
188: You have probably already noticed some very new syntax here, let us take a look
189: at that now before we go any further.
190:
191: ### The quick Keyword
192:
193: The `quick` keyword overrides any previous settings. It is most convenient when
194: large and complex firewalls are built with up to 100 rules in them. In our case
195: it is not so, however, we are including to be absolutely sure that the rule will
196: be processed.
197:
198: ### The proto Keyword
199:
200: The `proto` keyword dictates, you guessed it, the protocol. In the case of
201: this firewall the protocol is always TCP.
202:
203: ### The port Keyword
204:
205:
206: The `port` keyword can be either the port number or the name as defined in
207: `/etc/services`, for posterity I have mixed and matched in this file.
208:
209: ### The keep state Keyword
210:
211: The `keep state` keywords ensure packet checking from end to end within
212: the firewall and here is why, if you look closely at all of the rules,
213: they all use the `quick` keyword, so they circumvent previous rules and
214: hence checking on both sides of the firewall *may* not take place.
215:
216: ## Example Entries
217:
218: Now lets look at the rest of the file in sections since we have a
219: slightly better idea of what we are looking at.
220:
221: ### Blocking Reserved & Local Machine Addresses
222:
223:
224: There are certain address classes we already know should not pass at all
225: through our firewall. The addresses are those specified as internal only
226: addresses and the localhost address (not the interface addresses):
227:
228: * 127.0.0.0/8 (the localhost)
229: * 192.168.0.0/16 (reserved for internal networks, see
230: [RFC 1918](tools.ietf.org/html/rfc1918))
231: * 172.16.0.0/12 (reserved for internal networks, see RFC 1918)
232: * 10.0.0.0/8 (reserved for internal networks, see RFC 1918)
233: * 169.254.0.0/16 (IANA use)
234: * 192.0.2.0/24 (netblock for documentation authors)
235: * 204.152.64.0/23 (Sun Microsystems cluster interconnects)
236: * 224.0.0.0/3 (class D and E multicasts)
237:
238: It is important to note here that on one interface, fxp0, we want to be
239: able to pass in and out on the 172.16.0.0 network (since our internal
240: network is 172.16..0.0). To do this we can use the following rules:
241:
242: block in quick on any from 192.168.0.0/16 to any
243: block in quick on any from 10.0.0.0/8 to any
244: block in quick on any from 127.0.0.0/8 to any
245: block in quick on any from 0.0.0.0/8 to any
246: block in quick on any from 169.254.0.0/16 to any
247: block in quick on any from 192.0.2.0/24 to any
248: block in quick on any from 204.152.64.0/23 to any
249: block in quick on any from 224.0.0.0/3 to any
250:
251: In this table you will notice the 172.16.0.0/12 is omitted (even though
252: it should be blocked at least on ep0), you will see why in the next part
253: of the file.
254:
255: ### Paranoia Block
256:
257: Next we will cut off all traffic to ep0, hence we do not need to explicitly
258: close off 172.16.0.0 from it.
259:
260: # block all
261: block in quick on ep0 all
262:
263: ### Make the Firewall Act like an Internet Client
264:
265: Next we want to make the firewall have the capability of acting like an internet
266: client, this is pretty simple:
267:
268: # pass out as if we were a single internet client
269: pass out quick on ep0 proto tcp from 216.68.250.60/32 to any keep state
270: pass out quick on ep0 proto udp from 216.68.250.60/32 to any keep state
271: pass out quick on ep0 proto icmp from 216.68.250.60/32 to any keep state
272:
273: ### Passing the Rest
274:
275: Now we ant to add all of the protocols we want to pass. It should be important
276: to note that if you have any of these services enabled **on the firewall** then
277: their port will be accessible **on the firewall**.
278: It is usually a safer bet *not to have anything but ssh, ipfilter and ipnat
279: running on it*, the exception this might be (as in my home setup) you simply do
280: not have the hardware to spare and must have DNS and/or other server processes
281: running on it as well.
282:
283: # dns stuff
284: pass in log proto tcp from any to any port = 53 keep state
285: pass in log proto udp from any to any port = 53 keep state
286:
287: # pass thru www and ftp
288: pass in log proto tcp from any to any port = www keep state
289: pass in proto tcp from any to any port = ftp keep state
290: pass in proto tcp from any to any port = ftp-data keep state
291: pass in proto tcp from any port = ftp-data to any port > 1023 keep state
292: pass in log proto icmp all keep state
293:
294: ## IP Filter for Dial Ups
295:
296: Dial up connections offer somewhat of a challenge for ipfilter in that most dial
297: up interfaces are assigned a different IP address each time the user makes the
298: connection.
299:
300: In dial up or any dynamic address situation, the rules must be written in a
301: slightly less secure manner. In other words, rules cannot use the internet side
302: IP address, however, even just using the interface is normally enough to
303: guarantee pretty good security. As an example, here is one of the rules that
304: uses an IP address:
305:
306: # pass out as if we were a single internet client
307: pass out quick on ep0 proto tcp from 216.68.250.60/32 to any keep state
308: pass out quick on ep0 proto udp from 216.68.250.60/32 to any keep state
309: pass out quick on ep0 proto icmp from 216.68.250.60/32 to any keep state
310:
311: For our dial up connection we will have to change the ruleset to this:
312:
313: # pass out as if we were a single internet client
314: pass out quick on ep0 proto tcp from any to any keep state
315: pass out quick on ep0 proto udp from any to any keep state
316: pass out quick on ep0 proto icmp from any to any keep state
317:
318: Now what good does this do us now? Well, first, any ports that are still blocked
319: are *still* inaccessible. Second, if a service is not turned on and no inbound
320: proxying is enabled, all of this traffic is just passing through. There is no
321: way for anyone to connect to the firewall except via ssh.
322:
323: # Configuring IPNAT
324:
325: Network Address Translation (NAT) is part of IPfilter, which comes by default
326: with the NetBSD release. The job of NAT is to take a source IP address and
327: translate it to another out a different network interface. This is also known
328: as masquerading.
329:
330: Luckily for you (as the exhausted reader) and I (the exhausted author)
331: configuring NAT is pretty simple, especially with the example we are using.
332:
333: ## What our /etc/ipnat.conf needs to look like
334:
335: It is very simple:
336:
337: map ep0 172.16.0.0/16 -> 216.68.250.60/32 proxy port ftp ftp/tcp
338: map ep0 172.16.0.0/16 -> 216.68.250.60/32 portmap tcp/udp 10000:20000
339: map ep0 172.16.0.0/16 -> 216.68.250.60/32
340:
341: First we are proxying ftp thru the ep0 interface. The next line says go ahead
342: and map all tcp/udp traffic right on through the interface and assign each out
343: bound "connection" a port from 10000 to 20000 and finally the last line says,
344: just plain map from 172.16.0.0/16 to 216.68.250.60/32. For our purposes this is
345: all we need so the rest of this document is of limited interest to those of you
346: in a crunch trying to get a firewall up.
347:
348: ## Other Nifty Stuff
349:
350: A few items of interest for the curious, we can also map *into* the local
351: network as well:
352:
353: map fxp0 216.68.250.60/32 -> 172.16.14.1/32 (add whatever service here)
354:
355: This might be handy to connect to a specific server inside (such as a web
356: server) or if you recall the DMZ example before, we may wish to translate *into*
357: the DMZ from the world. Additionally it can be used as a poor man's router to
358: link internal networks together - but there are much better was of doing that.
359:
360: Instead of this, however, most administrators would locate the web server within
361: a DMZ and use ipfilter to ensure only http and ssh connections can be made to
362: the system.
363:
364: If you look closely you will see all outbound connections map to a single IP
365: address, what if you wanted to be able to map to more? You can do so by simply
366: changing the single address to a network:
367:
368: map ep0 172.16.0.0/16 -> 216.68.250.0/24
369:
370: Finally, the portmap range can be adjusted to whatever you feel is necessary.
371:
372: ## IPNAT With Dial Up Networking
373:
374: Many home users use dial up connections to access the internet. Many dial up
375: connections are assigned a dynamic IP address every time the user connects. At
376: first glance it may appear that some method for putting this new address into
377: `/etc/ipnat.conf` is required. Luckily, that is not so. Take note of how
378: addresses can be shown on the internet side of the `ipnat.conf` file. Actually
379: entire subnets can be used like so:
380:
381: map ep0 172.16.0.0/16 -> 216.68.0.0/16
382:
383: What this is saying is that addresses from 172.16.0.0 can be assigned any
384: address on 216.68.0.0's network. Keeping that in mind, on a dial up connection
385: you know you will be given one and one address, so the following entries
386: effectively do the same:
387:
388: map ppp0 172.16.0.0 -> 0/32 proxy port ftp ftp/tcp
389: map ppp0 172.16.0.0 -> 0/32 portmap tcp/udp 40000:60000
390: map ppp0 172.16.0.0 -> 0/32
391:
392: Here we are saying map anything on 172.16.0.0 to one single address, the address
393: the interface will have.
394:
395:
396: # Activating Services
397:
398: At this point, in theory, we are ready to start everything up. All of the
399: services we will need running are:
400:
401: * ipfilter
402: * ipnat
403: * ipmon
404: * sshd
405:
406: Additionally, we need to make sure that ip forwarding is enabled in the kernel.
407:
408: ## Turning on IP Forwarding
409:
410: To turn on IP forwarding use the sysctl facility:
411:
412: sysctl -w net.inet.ip.forwarding=1
413:
414: To have it turned on at bootup append the following text to `/etc/sysctl.conf`:
415:
416: net.inet.ip.forwarding=1
417:
418: ## /etc/defaults/rc.conf and /etc/rc.conf
419:
420: NetBSD's default rc settings are all kept in `/etc/defaults/rc.conf`. To make
421: upgrades safer, override settings in `/etc/rc.conf` instead of
422: `/etc/defaults/rc.conf`.
423:
424: ### What we need in /etc/rc.conf
425:
426: Basically, we can yank the contents of `/etc/defaults/rc.conf` and drop them
427: right into `/etc/rc.conf`:
428:
429: # cat /etc/defaults/rc.conf >>/etc/rc.conf
430: # vi /etc/rc.conf
431:
432: Note the double `>` here to avoid overwriting the contents of `/etc/rc.conf` as
433: shipped! Here is what `/etc/rc.conf` would look like after editing:
434: #
435: # see rc.conf(5) for more information.
436: #
437: # Use program=YES to enable program, NO to disable it. program_flags are
438: # passed to the program on the command line.
439: #
440:
441: # Load the defaults in from /etc/defaults/rc.conf (if it's readable).
442: # These can be overridden below.
443: #
444: if [ -r /etc/defaults/rc.conf ]; then
445: . /etc/defaults/rc.conf
446: fi
447:
448: # If this is not set to YES, the system will drop into single-user mode.
449: #
450: rc_configured=YES
451:
452: # Add local overrides below
453: #
454: ipfilter=YES
455: ipnat=YES
456: ipmon=YES ipmon_flags="-sn"
457: sshd=YES
458:
459: On i386 (PC) systems you will also see the wscons framework enabled:
460:
461: wscons=YES
462:
463: ## Activating the Services
464:
465: Next we have to activate the services, we can do this one of two ways:
466:
467: 1. reboot the system
468: 2. start using the rc scripts by hand
469:
470: I prefer doing the latter first just to make sure everything is setup right,
471: then I do a reboot to make sure all of the services will start up properly
472: during the bootup sequence.
473:
474: ### Starting Services "by hand"
475:
476: To start any service it is quite simple:
477:
478: # /etc/rc.d/[service_name] start
479:
480: Additionally, a service may be stopped:
481:
482: # /etc/rc.d/[service_name] stop
483:
484: or restarted:
485:
486: # /etc/rc.d/[service_name] restart
487:
488: So for this firewall, here is the order we need to start the services:
489:
490: # /etc/rc.d/sshd start
491: # /etc/rc.d/ipfilter start
492: # /etc/rc.d/ipnat start
493: # /etc/rc.d/ipmon start
494:
495: In reality, when sshd and ipmon start is arbitrary, however, ipfilter
496: must be enabled before ipnat.
497:
498: # Additional Products
499:
500: The NetBSD release comes ready to roll with a host of advanced networking
501: capabilities. However, an administrator may wish to use additional or
502: alternative software. This section looks at other software that can run on
503: NetBSD the administrator may find of interest.
504:
505: ## Portsentry
506:
507: The portsentry utility is a great tool. In a nutshell, portsentry
508: watches your system for scans and connection attempts and then will take
509: action to block a possible attacker. The main weakness portsentry has is
510: that it takes one connection attempt for portsentry to determine that
511: the host attempting to connect is hostile, so, if the first attempt is
512: successful, you are still out of luck.
513:
514: ### Getting Portsentry
515:
516: Portsentry can be retrieved and installed using the
517: [pkgsrc](http://www.NetBSD.org/docs/software/packages.html) system:
518:
519: # cd /usr/pkgsrc/security/portsentry
520: # make && make install
521:
522: or using binary packages with pkgin:
523:
524: # pkgin install portsentry
525:
526: ### Configuring Portsentry
527:
528: On NetBSD, portsentry is configured in `/usr/pkg/etc/portsentry.conf`.
529:
530: ### Port Configurations
531:
532: In the configuration file there are three sets of ports shown, of these, one for
533: tcp and one for udp must be selected by uncommenting the line, the default is to
534: use the "middle" sets, they should look something like this:
535:
536: # Un-comment these if you are really anal:
537: TCP_PORTS="1,7,9,11,15,70,79,80,109,110,111,119,138,139,143,512,513,514,515,540,
538: 635,1080,1524,2000,2001,4000,4001,5742,6000,6001,6667,12345,12346,20034,30303,32
539: 771,32772,32773,32774,31337,40421,40425,49724,54320"
540: #UDP_PORTS="1,7,9,66,67,68,69,111,137,138,161,162,474,513,517,518,635,640,641,66
541: 6,700,2049,32770,32771,32772,32773,32774,31337,54321"
542: #
543: # Use these if you just want to be aware:
544: #TCP_PORTS="1,11,15,79,111,119,143,540,635,1080,1524,2000,5742,6667,12345,12346,
545: 20034,31337,32771,32772,32773,32774,40421,49724,54320"
546: UDP_PORTS="1,7,9,69,161,162,513,635,640,641,700,32770,32771,32772,32773,32774,31
547: 337,54321"
548: #
549: # Use these for just bare-bones
550: #TCP_PORTS="1,11,15,110,111,143,540,635,1080,524,2000,12345,12346,20034,32771,32
551: 772,32773,32774,49724,54320"
552: #UDP_PORTS="1,7,9,69,161,162,513,640,700,32770,32771,32772,32773,32774,31337,543
553: 21"
554:
555: #### Advanced Stealth Detection
556:
557: The number of ports portsentry should monitor in advanced mode, all of the ports
558: below the listed number(s) are monitored this way:
559:
560: ADVANCED_PORTS_TCP="1023"
561: ADVANCED_PORTS_UDP="1023"
562:
563: Additionally in this section portsentry can be told certain items to exclude
564: (such as loud NetBIOS services):
565:
566: # Default TCP ident and NetBIOS service
567: ADVANCED_EXCLUDE_TCP="113,139"
568: # Default UDP route (RIP), NetBIOS, bootp broadcasts.
569: ADVANCED_EXCLUDE_UDP="520,138,137,67"
570:
571: #### Configuration Files
572:
573: Where files live, on NetBSD this is under `/usr/pkg/*`:
574:
575: # Hosts to ignore
576: IGNORE_FILE="/usr/pkg/etc/portsentry.ignore"
577: # Hosts that have been denied (running history)
578: HISTORY_FILE="/usr/pkg/etc/portsentry.history"
579: # Hosts that have been denied this session only (temporary until next restart)
580: BLOCKED_FILE="/usr/pkg/etc/portsentry.blocked"
581:
582: #### Response Options
583:
584: This section is pretty straightforward just as it says in the file:
585:
586: # 0 = Do not block UDP/TCP scans.
587: # 1 = Block UDP/TCP scans.
588: # 2 = Run external command only (KILL_RUN_CMD)
589:
590: BLOCK_UDP="1"
591: BLOCK_TCP="1"
592:
593: #### Dropping Routes
594:
595: This is the kill route option, the one used for NetBSD is already uncommented:
596:
597: # Generic BSD (BSDI, OpenBSD, NetBSD, FreeBSD)
598: KILL_ROUTE="/sbin/route add $TARGET$ 333.444.555.666"
599:
600: It should be noted that some can actually modify firewall tables, for example,
601: the FreeBSD packetfilter option:
602:
603: # For those of you running FreeBSD (and compatible) you can
604: # use their built in firewalling as well.
605: #
606: #KILL_ROUTE="/sbin/ipfw add 1 deny all from $TARGET$:255.255.255.255 to any"
607:
608: If another type of firewall is being used on your system, it may be possible to
609: add in something like this to your portsentry configuration.
610:
611: #### TCP Wrappers
612:
613: This section is the text that gets put into `/etc/hosts.deny`.
614:
615: #
616: KILL_HOSTS_DENY="ALL: $TARGET$"
617:
618: #### External Commands
619:
620: Here, any external command (or script etc.) may be called.
621:
622: #KILL_RUN_CMD="/some/path/here/script $TARGET$ $PORT$"
623:
624: As an example, altering the firewall could be here as well.
625:
626: #### Scan Trigger Value
627:
628: This is the number of port connects that portsentry allows before an alarm goes
629: up, the default is 0, 1 is usually pretty safe as well (to keep down the false
630: alarms).
631:
632: #### Port Banner
633:
634: This is a message that can be sent back to the person who tripped portsentry,
635: unless they are using a very verbose tool it usually ends up in a logfile on
636: their system (on NetBSD it ends up in `/var/log/messages`.
637:
638: #PORT_BANNER="** UNAUTHORIZED ACCESS PROHIBITED *** YOUR CONNECTION ATTEMPT HAS
639: BEEN LOGGED. GO AWAY."
640:
641: ## NMAP
642:
643: The nmap utility is a portscanner. It can scan one host, a network or
644: combinations therein. It is currently in the pkgsrc tree.
645:
646: ### Getting and Installing NMAP
647:
648:
649: Use [pkgsrc](http://www.NetBSD.org/docs/software/packages.html):
650:
651: # cd /usr/pkgsrc/net/nmap
652: # make && make install
653:
654: or, using binary packages with pkgin:
655:
656: # pkgin install nmap
657:
658: ### Using nmap
659:
660: The [nmap](http://insecure.org/) utility has **a lot** of options, we will look
661: at three examples:
662:
663: 1. scanning one host
664: 2. scanning several hosts
665: 3. scanning a NetBSD firewall
666:
667: #### Scanning One Host
668:
669: For this example we will use a pretty insecure system on an internal network:
670:
671: # nmap -P0 172.16.14.12
672:
673: Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
674: Interesting ports on marie.ipsosasi.net (172.16.14.12):
675: (The 1504 ports scanned but not shown below are in state: closed)
676: Port State Service
677: 7/tcp open echo
678: 9/tcp open discard
679: 13/tcp open daytime
680: 19/tcp open chargen
681: 21/tcp open ftp
682: 23/tcp open telnet
683: 37/tcp open time
684: 111/tcp open sunrpc
685: . . .
686:
687: #### Scanning A Network
688:
689: Now let's look at a whole bunch of machines!
690:
691: % nmap -P0 172.16.14.0/24 > nmap.out
692:
693: Whenever it is either done (which could be awhile) or interrupted/stopped take a
694: peek at the file where all of the information was dumped, following is a sample
695: from the network I scanned:
696:
697: Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
698: All 1523 scanned ports on (172.16.14.0) are: closed
699: Interesting ports on somename.blah.net (172.16.14.1):
700: (The 1521 ports scanned but not shown below are in state: filtered)
701: Port State Service
702: 23/tcp open telnet
703: 68/tcp closed bootpc
704:
705: All 1523 scanned ports on somename.blah.net (172.16.14.2) are: closed
706: Interesting ports on somename.blah.net (172.16.14.3):
707: (The 1520 ports scanned but not shown below are in state: closed)
708: Port State Service
709: 23/tcp open telnet
710: 79/tcp open finger
711: 80/tcp open http
712:
713: Interesting ports on somename.blah.net (172.16.14.4):
714: (The 1513 ports scanned but not shown below are in state: closed)
715: Port State Service
716: 7/tcp open echo
717: 9/tcp open discard
718: 19/tcp open chargen
719: . . .
720:
721: #### Scanning a NetBSD Firewall
722:
723: Last but definitely not least, lets nail a firewall:
724:
725: Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
726:
727: Interesting ports on (216.68.250.60):
728: (The 1522 ports scanned but not shown below are in state: filtered)
729: Port State Service
730: 22/tcp open ssh
731:
732: Nmap run completed -- 1 IP address (1 host up) scanned in 772 seconds
733:
734: Now that is more like it.
735:
736:
737: # Examples
738:
739: * [[ipf.conf|http://netbsd.org/docs/network/nsps/examples/ipf.conf]]
740: * [[ipnat.conf|http://netbsd.org/docs/network/nsps/examples/ipnat.conf]]
741: * [[rc.conf|http://netbsd.org/docs/network/nsps/examples/rc.conf]]
742: * [[sysctl.conf|http://netbsd.org/docs/network/nsps/examples/sysctl.conf]]
743: * [[portsentry.conf|http://netbsd.org/docs/network/nsps/examples/portsentry.conf]]
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb
![[BACK]](/icons/back.gif){kind=icon}
Return to nsps.mdwn CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [NetBSD Developer Wiki] / wikisrc