File:  [NetBSD Developer Wiki] / wikisrc / nsps.mdwn
Revision 1.2: download - view: text, annotated - select for diffs
Sat May 25 21:37:03 2013 UTC (6 years, 7 months ago) by jdf
Branches: MAIN
CVS tags: HEAD
Semantical cosmetics.

    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>
   82: 		<td>YES</td>
   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