From owner-freebsd-ipfw Mon Oct 2 1:33:46 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id 6F83F37B66D; Mon, 2 Oct 2000 01:33:40 -0700 (PDT) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JUUX5JOVJS000LV1@research.kpn.com>; Mon, 2 Oct 2000 10:33:34 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Mon, 02 Oct 2000 10:33:33 +0100 Content-return: allowed Date: Mon, 02 Oct 2000 10:33:32 +0100 From: "Steehouder, R.J." Subject: IPv6 Firewall problem (with solution) To: "'freebsd-net@freebsd.org'" , "'freebsd-ipfw@freebsd.org'" Message-id: <59063B5B4D98D311BC0D0001FA7E45220369D2CB@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry if this is sightly off topic, but there is no FreeBSD-IPv6 mailing list that I know of. I have stumbled upon the following: The IPv6 firewall and IPv6 neighbor discovery don't work well together. In the system depicted below, Tembo acts as a firewall and gateway for Kima. Target is to only let traffic between Twiga and Kima through. +--+ +--+ +--+ | |-----+---| |---------| | +--+ | +--+ +--+ Twiga | Tembo Kima | +--+ Simba | |----(Internet / 6Bone / etc.) +--+ Twiga: FreeBSD 4.1-RELEASE Kima: Windows 2000 Tembo: FreeBSD 4.x-STABLE Simba: SISCO Router All network connections are IPv6. Simba is default router in the left network, Tembo in the right one. Firewall rules on Tembo: # link-local addresses add allow all from fe80::/64 to fe80::/64 # link-local multicast addresses add allow all from any to ff00::/12 # Twiga <-> Kima add allow all from Kima to Twiga add allow all from Twiga to Kima Problem: Some time after installing these rules, communication between Kima and Twiga stops. Why? Because neighbor discovery tells Tembo that Kima is no longer there (due to firewall restrictions Tembo cannot communicate with Kima using global addresses). Kima is therefore removed from the routing table and traffic stops. Solution Allow communications between Kima and Tembo: allow all from Kima to Tembo allow all from Tembo to Kima Using a static routes instead should work as well, but then what's the point of using autoconfiguration in IPv6. Between Tembo and Twiga this does not pose a problem, because there is a route via Simba (using Simba's link-local address). Simba is known, because of its router sollicitation messages on ff02:: multicast addresses. Twiga should also lose contact with Tembo (neighbor discovery fails), but since Simba has a static route to Tembo, it doesn't mind. Opening up the firewall/gateway to the networks poses a security risk. Maybe this situation should be documented somewhere in the firewall documentation? (If only to show people how to solve this problem when they get to it.) If anyone knows a better solution (one that doesn't expose the firewall), please tell me. Rogier Steehouder Stagiair KPN Research mailto:r.j.steehouder@kpn.com (If it bounces, try mailto:r.j.steehouder@student.utwente.nl) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Oct 2 12:54:24 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from forrie.net (forrie.net [64.20.73.233]) by hub.freebsd.org (Postfix) with ESMTP id 6166837B502 for ; Mon, 2 Oct 2000 12:54:22 -0700 (PDT) Received: from boomer.forrie.com (dhcp-north-71-168.navipath.net [64.20.71.168]) by forrie.net with id e92JsLv14762 for ; Mon, 2 Oct 2000 15:54:21 -0400 (EDT) Message-Id: <5.0.0.25.2.20001002154554.01bfe310@64.20.73.233> X-Sender: forrie@64.20.73.233 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 02 Oct 2000 15:47:40 -0400 To: freebsd-ipfw@freebsd.org From: Forrest Aldrich Subject: 4.1.1 Kernel ipfw, brought to its knees Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was working with our security person here at work, with my ipfw config. I ran into some problems, which I'm still trying to figure out. So, he offered to at least scan the machine. He did a basic nmap scan... brought the machine to its knees. I had ICMP bandwidth limitation enabled. All except the RST (which isn't recommended for web servers). The machine is rendered unusable. I've never seen this happen to a FreeBSD box. Our 2.2.8 systems withstand this better than this. ? Forrest To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Oct 2 20:59:12 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from stratus.cloudfactory.org (cloudfactory.org [205.179.129.18]) by hub.freebsd.org (Postfix) with ESMTP id 12B0737B502 for ; Mon, 2 Oct 2000 20:59:11 -0700 (PDT) Received: from localhost (terrac@localhost) by stratus.cloudfactory.org (8.8.8/8.8.7) with ESMTP id UAA15667 for ; Mon, 2 Oct 2000 20:59:07 -0700 Date: Mon, 2 Oct 2000 20:59:06 -0700 (PDT) From: TeRrAc To: FreeBSD IPFW list Subject: IPFW + NAT, how do I slick this puppy up? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a freebsd 4.0 stable system running IPFW, NAT and DHCP. I want to make this machine as slick as possible. One thing that is currently buggered is that I do not have the rc.firewall file setup to automatically load my rules. My ruleset is minor.. extremely minor. It just allows everything from one side to the other. I want to be able to allow all traffic out, but notunsolicited traffic back in (if that makes any sense. Here is my ruleset.. 00001 3550449 1697415913 divert 8668 ip from any to any via fxp0 00010 5466534 2771367031 allow ip from any to any 65535 360 38536 deny ip from any to any Another problem that I have, and this is all my doing... is whenever the logical network segments share the same physical network I get messages on the console like: Sep 27 19:22:19 hostname /kernel: arp: 10.0.0.52 is on fxp1 but got reply from xx:xx:xx:xx:xx:xx on fxp0 I think I know what that means, but aside from putting the physical cables on different hubs/switches I don't know how to fix it. That last question leads me into my next bit. which is If I want to have both NAT'd and real-world IP'd machines on the same physical network, how would I go about doing this? Ok.. thats all my BSD greivences for this month.. otherwise I am simply in love with the BSD way of doing things.. Very cool, puts linux to shame for an ease of administration box. t e r r a c " and they call *ME* strange " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Oct 2 21:12:39 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from optimus.troysplace.net (phineas.troysplace.net [210.215.3.33]) by hub.freebsd.org (Postfix) with ESMTP id 07AD137B503 for ; Mon, 2 Oct 2000 21:12:35 -0700 (PDT) Received: (from troy@localhost) by optimus.troysplace.net (8.11.0/8.11.0) id e9349pW20092; Tue, 3 Oct 2000 14:09:51 +1000 (EST) (envelope-from troy) Date: Tue, 3 Oct 2000 14:09:51 +1000 From: Troy Bell To: TeRrAc Cc: FreeBSD IPFW list Subject: Re: IPFW + NAT, how do I slick this puppy up? Message-ID: <20001003140951.A20062@optimus.troysplace.net> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from terrac@cloudfactory.org on Mon, Oct 02, 2000 at 08:59:06PM -0700 X-PGP-Key-ID: 1024D/A3101D4C 2000-09-26 X-PGP-Fingerprint: 19D1 8450 A807 F7CF 98A1 2D97 B232 3E0B A310 1D4C X-PGP-Public-Key-URL: http://troysplace.net/troybell.asc Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline TeRrAc wrote: > I have a freebsd 4.0 stable system running IPFW, NAT and DHCP. I want to > make this machine as slick as possible. One thing that is currently > buggered is that I do not have the rc.firewall file setup to automatically > load my rules. My ruleset is minor.. extremely minor. It just allows > everything from one side to the other. I want to be able to allow all > traffic out, but notunsolicited traffic back in (if that makes any > sense. Here is my ruleset.. > 00001 3550449 1697415913 divert 8668 ip from any to any via fxp0 > 00010 5466534 2771367031 allow ip from any to any > 65535 360 38536 deny ip from any to any Add this to /etc/rc.conf: firewall_enable="YES" firewall_type="/usr/local/etc/ipfw.rules" Then create a ruleset using the above file. For example, your file might look something like: add 00005 divert 8668 ip from any to any via fxp0 add 00010 allow ip from any to any I can email you a more robust rulset to work with off-list that might get you started on a neat little firewall for yourself if you like ;) I'm sure one of the other guys will provide a decent answer to your other problem. Kind regards, -- Troy Bell troy@troysplace.net Systems Administrator http://troysplace.net/ Twisted mind? No, just bent in several strategic places :) http://ars.userfriendly.org/cartoons/?id=20000928 --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE52VwOsjI+C6MQHUwRAmX0AJ4z1UGbzp6rI8BuuwBQNNmWzFwgyQCaAjAO qoQ5Pf2cCcHQvKN/GSjvfcY= =btfS -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Oct 2 23:31:48 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 8034A37B502 for ; Mon, 2 Oct 2000 23:31:46 -0700 (PDT) Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 2 Oct 2000 23:30:26 -0700 Received: (from cjc@localhost) by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e936Va268081; Mon, 2 Oct 2000 23:31:36 -0700 (PDT) (envelope-from cjc) Date: Mon, 2 Oct 2000 23:31:36 -0700 From: "Crist J . Clark" To: Forrest Aldrich Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: 4.1.1 Kernel ipfw, brought to its knees Message-ID: <20001002233136.O25121@149.211.6.64.reflexcom.com> Reply-To: cjclark@alum.mit.edu References: <5.0.0.25.2.20001002154554.01bfe310@64.20.73.233> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <5.0.0.25.2.20001002154554.01bfe310@64.20.73.233>; from forrie@forrie.com on Mon, Oct 02, 2000 at 03:47:40PM -0400 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Oct 02, 2000 at 03:47:40PM -0400, Forrest Aldrich wrote: > I was working with our security person here at work, with my ipfw > config. I ran into some problems, which I'm still trying to figure out. > > So, he offered to at least scan the machine. He did a basic nmap scan... > brought the machine to its knees. I had ICMP bandwidth limitation > enabled. All except the RST (which isn't recommended for web servers). > > The machine is rendered unusable. I've never seen this happen to a > FreeBSD box. Our 2.2.8 systems withstand this better than this. > > ? I agree: ? What type of nmap scan? Was the scan local? What type of connection to the ROW do you have? What was running on the machine when the scan was run? What does "unusable" mean? Were any errors generated? Do you have a specific question? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Oct 2 23:42:17 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id D355237B66C for ; Mon, 2 Oct 2000 23:42:14 -0700 (PDT) Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 2 Oct 2000 23:40:04 -0700 Received: (from cjc@localhost) by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e936fHt68149; Mon, 2 Oct 2000 23:41:17 -0700 (PDT) (envelope-from cjc) Date: Mon, 2 Oct 2000 23:41:17 -0700 From: "Crist J . Clark" To: TeRrAc Cc: FreeBSD IPFW list Subject: Re: IPFW + NAT, how do I slick this puppy up? Message-ID: <20001002234116.P25121@149.211.6.64.reflexcom.com> Reply-To: cjclark@alum.mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from terrac@cloudfactory.org on Mon, Oct 02, 2000 at 08:59:06PM -0700 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Oct 02, 2000 at 08:59:06PM -0700, TeRrAc wrote: > I have a freebsd 4.0 stable system running IPFW, NAT and DHCP. I want to > make this machine as slick as possible. One thing that is currently > buggered is that I do not have the rc.firewall file setup to automatically > load my rules. My ruleset is minor.. extremely minor. It just allows > everything from one side to the other. I want to be able to allow all > traffic out, but notunsolicited traffic back in (if that makes any > sense. Here is my ruleset.. > 00001 3550449 1697415913 divert 8668 ip from any to any via fxp0 > 00010 5466534 2771367031 allow ip from any to any > 65535 360 38536 deny ip from any to any Just, gateway_enable="YES" natd_enable="YES" natd_interface="fxp0" firewall_enable="YES" firewall_type="open" Does what you have there at boot. > Another problem that I have, and this is all my doing... is whenever the > logical network segments share the same physical network I get messages > on the console like: > Sep 27 19:22:19 hostname /kernel: arp: 10.0.0.52 is on fxp1 but got reply > from xx:xx:xx:xx:xx:xx on fxp0 > I think I know what that means, but aside from putting the physical > cables on different hubs/switches I don't know how to fix it. That /is/ how you fix it. Putting more than one interface of a single host on one collision domain is a misconfiguration. The messages are pointing this out in an indirect way. There also is no point in trying to close up your firewall. If everything is on one LAN, the firewall is not really protecting any machines from the outside. > That last question leads me into my next bit. which is If I want to have > both NAT'd and real-world IP'd machines on the same physical network, how > would I go about doing this? Are you saying that you don't want to do NAT for the "real world" IP addresses behind the firewall/NAT machine? See the 'unregistered_only' flag in ipfw(8). Just do regular old static routing for the registered IPs. But partition yourself to two physical networks before you bother trying to upgrade all of this. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 3 9:21:19 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from forrie.net (forrie.net [64.20.73.233]) by hub.freebsd.org (Postfix) with ESMTP id 7219D37B502 for ; Tue, 3 Oct 2000 09:21:05 -0700 (PDT) Received: from boomer.forrie.com (dhcp-north-71-168.navipath.net [64.20.71.168]) by forrie.net with id e93GKwv23064; Tue, 3 Oct 2000 12:20:59 -0400 (EDT) Message-Id: <5.0.0.25.2.20001003120347.020eb050@64.20.73.233> X-Sender: forrie@64.20.73.233 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 03 Oct 2000 12:14:29 -0400 To: cjclark@alum.mit.edu From: Forrest Aldrich Subject: Re: 4.1.1 Kernel ipfw, brought to its knees Cc: freebsd-ipfw@FreeBSD.ORG In-Reply-To: <20001002233136.O25121@149.211.6.64.reflexcom.com> References: <5.0.0.25.2.20001002154554.01bfe310@64.20.73.233> <5.0.0.25.2.20001002154554.01bfe310@64.20.73.233> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_876755==_" Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --=====================_876755==_ Content-Type: text/plain; charset="us-ascii"; format=flowed The nmap scan was a basic nmap ping. No options. Yes, the scan was local (on our LAN 100mbit). Nothing special was running on this machine, other than packet filters and appropriate kernel config options. It was just installed (FreeBSD-4.1.1) yesterday from the releng4 server snapshot archive, and cvsup'd. The only errors I saw generated in the log were that from tcp_log_in_vain setting. Glad I had at least that set, so I could know what was going on. I also noted many syslogd -s processes running at one point, and I tried killing those off to see if that would help. It just got worse. We performed this as a "qa" test, to see how FreeBSD would stand up to an attack, without third-party utilities. Unusable means, the system froze... literally. I couldn't get any prompt response, no connections, nothing. So, given that we're using FreeBSD on our infrastructure, we're very concerned about this. We were experimenting with the rc.firewall config, as some of the options were new (the dns update acl, for example). We did run into some weird problems (and it's probably configuration error on our part) with regard to connectivity. I'm attaching, for this named machine, the KERNEL config and the /etc/rc.firewall config for your persual. Input or suggestions about the config would be welcomed. Thanks, _F At 11:31 PM 10/2/2000 -0700, Crist J . Clark wrote: >On Mon, Oct 02, 2000 at 03:47:40PM -0400, Forrest Aldrich wrote: > > I was working with our security person here at work, with my ipfw > > config. I ran into some problems, which I'm still trying to figure out. > > > > So, he offered to at least scan the machine. He did a basic nmap scan... > > brought the machine to its knees. I had ICMP bandwidth limitation > > enabled. All except the RST (which isn't recommended for web servers). > > > > The machine is rendered unusable. I've never seen this happen to a > > FreeBSD box. Our 2.2.8 systems withstand this better than this. > > > > ? > >I agree: ? > >What type of nmap scan? Was the scan local? What type of connection to >the ROW do you have? What was running on the machine when the scan was >run? What does "unusable" mean? Were any errors generated? > >Do you have a specific question? >-- >Crist J. Clark cjclark@alum.mit.edu --=====================_876755==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="forrienet" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.11 2000/09/22 10:01:48 nyan Exp $ machine i386 cpu I686_CPU ident OURMACHINE maxusers 256 #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=10000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies options KBD_INSTALL_CDEV # install a CDEV entry in /dev # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs device isa # device eisa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 # device fd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering #options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # SCSI Controllers # device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices # device amd # AMD 53C974 (Teckram DC-390(T)) # device isp # Qlogic family # device ncr # NCR/Symbios Logic # device sym # NCR/Symbios Logic (newer chipsets) # options SYM_SETUP_LP_PROBE_MAP=0x40 # Allow ncr to attach legacy NCR devices when # both sym and ncr are configured # device adv0 at isa? # device adw # device bt0 at isa? # device aha0 at isa? # device aic0 at isa? # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # RAID controllers interfaced to the SCSI subsystem # device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID # device dpt # DPT Smartcache - See LINT for options! # RAID controllers # device ida # Compaq Smart RAID # device amr # AMI MegaRAID # device mlx # Mylex DAC960 family #device twe # 3ware Escalade # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) # device apm0 at nexus? disable flags 0x20 # Advanced Power Management # PCCARD (PCMCIA) support # device card # device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000 # device pcic1 at isa? irq 11 port 0x3e2 iomem 0xd4000 disable # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 # device sio2 at isa? disable port IO_COM3 irq 5 # device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer # device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device fxp # Intel EtherExpress PRO/100B (82557, 82558) # device tx # SMC 9432TX (83c170 ``EPIC'') # device vx # 3Com 3c590, 3c595 (``Vortex'') # device wx # Intel Gigabit Ethernet Card (``Wiseman'') # PCI Ethernet NICs that use the common MII bus controller code. # device miibus # MII bus support # device dc # DEC/Intel 21143 and various workalikes # device rl # RealTek 8129/8139 # device sf # Adaptec AIC-6915 (``Starfire'') # device sis # Silicon Integrated Systems SiS 900/SiS 7016 # device ste # Sundance ST201 (D-Link DFE-550TX) # device tl # Texas Instruments ThunderLAN # device vr # VIA Rhine, Rhine II # device wb # Winbond W89C840F # device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. # device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 # device ex # device ep # device fe0 at isa? port 0x300 # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attatement needed # and resources will always be dynamically assigned by the pccard code. # device wi # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP # mode (the factory default). If you set the switches on your ISA # card for a manually chosen I/O address and IRQ, you must specify # those paremeters here. # device an # Xircom Ethernet # device xe # The probe order of these is presently determined by i386/isa/isa_compat.c. # device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 # device le0 at isa? port 0x300 irq 5 iomem 0xd0000 # device lnc0 at isa? port 0x280 irq 10 drq 0 # device cs0 at isa? port 0x300 # device sn0 at isa? port 0x300 irq 10 # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device sl 1 # Kernel SLIP pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" pseudo-device gif 4 # IPv6 and IPv4 tunneling pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface # device ohci # OHCI PCI->USB interface device usb # USB Bus (required) # device ugen # Generic # device uhid # "Human Interface Devices" # device ukbd # Keyboard # device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # USB Ethernet, requires mii # device aue # ADMtek USB ethernet # device cue # CATC USB ethernet # device kue # Kawasaki LSI USB ethernet ################################################## # # FIREWALL SUPPORT # ################################################## # # Internet family options: # # TCP_COMPAT_42 causes the TCP code to emulate certain bugs present in # 4.2BSD. This option should not be used unless you have a 4.2BSD # machine and TCP connections fail. # # MROUTING enables the kernel multicast packet forwarder, which works # with mrouted(8). # # IPFIREWALL enables support for IP firewall construction, in # conjunction with the `ipfw' program. IPFIREWALL_VERBOSE sends # logged packets to the system logger. IPFIREWALL_VERBOSE_LIMIT # limits the number of times a matching entry can be logged. # # WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" # and if you do not add other rules during startup to allow access, # YOU WILL LOCK YOURSELF OUT. It is suggested that you set firewall_type=open # in /etc/rc.conf when first enabling this feature, then refining the # firewall rules in /etc/rc.firewall after you've tested that the new kernel # feature works properly. # # IPFIREWALL_DEFAULT_TO_ACCEPT causes the default rule (at boot) to # allow everything. Use with care, if a cracker can crash your # firewall machine, they can get to your protected machines. However, # if you are using it as an as-needed filter for specific problems as # they arise, then this may be for you. Changing the default to 'allow' # means that you won't get stuck if the kernel and /sbin/ipfw binary get # out of sync. # # IPDIVERT enables the divert IP sockets, used by ``ipfw divert'' # # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding # packets without touching the ttl). This can be useful to hide firewalls # from traceroute and similar tools. # # TCPDEBUG is undocumented. # # options TCP_COMPAT_42 #emulate 4.2BSD TCP bugs options MROUTING # Multicast routing options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about # dropped packets options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity # options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default # options IPV6FIREWALL #firewall for IPv6 # options IPV6FIREWALL_VERBOSE # options IPV6FIREWALL_VERBOSE_LIMIT=100 # options IPV6FIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT #divert sockets # options IPFILTER #ipfilter support # options IPFILTER_LOG #ipfilter logging options IPSTEALTH #support for stealth forwarding options TCPDEBUG # Statically Link in accept filters options ACCEPT_FILTER_DATA options ACCEPT_FILTER_HTTP # The following options add sysctl variables for controlling how certain # TCP packets are handled. # # TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This # prevents nmap et al. from identifying the TCP/IP stack, but breaks support # for RFC1644 extensions and is not recommended for web servers. # # TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. # This is useful on systems which are exposed to SYN floods (e.g. IRC servers) # or any system which one does not want to be easily portscannable. # # WE RUN A WEB SERVER, SO WE DIDN'T ENABLE THIS # options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN options TCP_RESTRICT_RST #restrict emission of TCP RST # ICMP_BANDLIM enables icmp error response bandwidth limiting. You # typically want this option as it will help protect the machine from # D.O.S. packet attacks. # options ICMP_BANDLIM # DUMMYNET enables the "dummynet" bandwidth limiter. You need # IPFIREWALL as well. See the dummynet(4) manpage for more info. # BRIDGE enables bridging between ethernet cards -- see bridge(4). # You can use IPFIREWALL and dummynet together with bridging. options DUMMYNET options BRIDGE --=====================_876755==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="rc.firewall" # # $Id: rc.firewall,v 1.1 2000/09/28 13:24:35 forrie Exp forrie $ # # $Log: rc.firewall,v $ # Revision 1.1 2000/09/28 13:24:35 forrie # Initial revision # # ############ # Setup system for firewall service. # $FreeBSD: src/etc/rc.firewall,v 1.30.2.6 2000/09/21 07:44:53 ru Exp $ # Suck in the configuration variables. if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi ############ # Define the firewall type in /etc/rc.conf. Valid values are: # open - will allow anyone in # client - will try to protect just this machine # simple - will try to protect a whole network # closed - totally disables IP services except via lo0 interface # UNKNOWN - disables the loading of firewall rules. # filename - will load the rules in the given filename (full path required) # # For ``client'' and ``simple'' the entries below should be customized # appropriately. ############ # # If you don't know enough about packet filtering, we suggest that you # take time to read this book: # # Building Internet Firewalls # Brent Chapman and Elizabeth Zwicky # # O'Reilly & Associates, Inc # ISBN 1-56592-124-0 # http://www.ora.com/ # # For a more advanced treatment of Internet Security read: # # Firewalls & Internet Security # Repelling the wily hacker # William R. Cheswick, Steven M. Bellowin # # Addison-Wesley # ISBN 0-201-6337-4 # http://www.awl.com/ # if [ -n "${1}" ]; then firewall_type="${1}" fi ############ # Set quiet mode if requested # case ${firewall_quiet} in [Yy][Ee][Ss]) fwcmd="/sbin/ipfw -q" ;; *) fwcmd="/sbin/ipfw" ;; esac ############ # Flush out the list before we begin. # ${fwcmd} -f flush ############ # Network Address Translation. All packets are passed to natd(8) # before they encounter your remaining rules. The firewall rules # will then be run again on each packet after translation by natd # starting at the rule number following the divert rule. # # For ``simple'' firewall type the divert rule should be put to a # different place to not interfere with address-checking rules. # case ${firewall_type} in [Oo][Pp][Ee][Nn]|[Cc][Ll][Ii][Ee][Nn][Tt]) case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add 50 divert natd all from any to any via ${natd_interface} fi ;; esac esac ############ # If you just configured ipfw in the kernel as a tool to solve network # problems or you just want to disallow some particular kinds of traffic # then you will want to change the default policy to open. You can also # do this as your only action by setting the firewall_type to ``open''. # # ${fwcmd} add 65000 pass all from any to any ############ # Only in rare cases do you want to change these rules # ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 # If you're using 'options BRIDGE', uncomment the following line to pass ARP #${fwcmd} add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 # Prototype setups. # case ${firewall_type} in [Oo][Pp][Ee][Nn]) ${fwcmd} add 65000 pass all from any to any ;; [Cc][Ll][Ii][Ee][Nn][Tt]) ############ # This is a prototype setup that will protect your system somewhat # against people from outside your own network. ############ # set these to your network and netmask and ip net="192.0.2.0" mask="255.255.255.0" ip="192.0.2.1" # Allow any traffic to or from my own net. ${fwcmd} add pass all from ${ip} to ${net}:${mask} ${fwcmd} add pass all from ${net}:${mask} to ${ip} # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established # Allow IP fragments to pass through ${fwcmd} add pass all from any to any frag # Allow setup of incoming email ${fwcmd} add pass tcp from any to ${ip} 25 setup # Allow setup of outgoing TCP connections only ${fwcmd} add pass tcp from ${ip} to any setup # Disallow setup of all other TCP connections ${fwcmd} add deny tcp from any to any setup # Allow DNS queries out in the world ${fwcmd} add pass udp from any 53 to ${ip} ${fwcmd} add pass udp from ${ip} to any 53 # Allow NTP queries out in the world ${fwcmd} add pass udp from any 123 to ${ip} ${fwcmd} add pass udp from ${ip} to any 123 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. ;; [Ss][Ii][Mm][Pp][Ll][Ee]) ############ # This is a prototype setup for a simple firewall. Configure this # machine as a named server and ntp server, and point all the machines # on the inside at this machine for those services. ############ # set these to your outside interface network and netmask and ip oif="fxp0" onet="64.20.71.0" omask="255.255.255.0" oip="64.20.71.209" # set these to your inside interface network and netmask and ip # iif="ed1" # inet="192.0.2.16" # imask="255.255.255.240" # iip="192.0.2.17" # Stop spoofing # dual interface # ${fwcmd} add deny all from ${inet}:${imask} to any in via ${oif} # ??? Not sure how to do this for a single interface. # ${fwcmd} add deny all from ${onet}:${omask} to any in via ${oif} # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP # address set to 192.0.2.1 then an incoming packet for it after being # translated by natd(8) would match the `deny' rule above. Similarly # an outgoing packet originated from it before being translated would # match the `deny' rule below. case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add divert natd all from any to any via ${natd_interface} fi ;; esac # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} # Allow TCP through if setup succeeded # ${fwcmd} add pass tcp from any to any established ${fwcmd} add pass tcp from any to any established # Allow TCP through if setup succeeded, higher ports needed by # ACTIVE FTP, not PASSIVE ${fwcmd} add pass tcp from any to ${oip} 1024-65535 setup # Allow IP fragments to pass through ${fwcmd} add pass all from any to any frag ################### # # Primary Services # ################### # Allow setup of incoming email ${fwcmd} add pass tcp from any to ${oip} 25 setup # Allow access to IMAP ${fwcmd} add pass tcp from any to ${oip} 143 setup # Allow access to POP ${fwcmd} add pass tcp from any to ${oip} 110 setup # Allow access to our DNS ${fwcmd} add pass tcp from any to ${oip} 53 setup ${fwcmd} add pass udp from ${oip} to any ${fwcmd} add pass udp from any to ${oip} 1024-65535 # ${fwcmd} add pass udp from any to ${oip} 53 # ${fwcmd} add pass udp from ${oip} 53 to any # Allow access to our WWW ${fwcmd} add pass tcp from any to ${oip} 80 setup # SSL ${fwcmd} add pass tcp from any to ${oip} 443 setup # Allow RESTRICTED access to RPC ${fwcmd} add pass tcp from ${onet}:${omask} to ${oip} 111 setup # Allow RESTRICTED access to PING (icmp types 0,8) # ${fwcmd} add pass icmp from any to any icmptypes 0,8 ${fwcmd} add pass icmp from ${oip} to any icmptypes 0,8 ${fwcmd} add pass icmp from ${onet}:${omask} to ${oip} icmptypes 0,8 ${fwcmd} add pass icmp from 216.67.14.5 to ${oip} icmptypes 0,8 # Allow access to our IDENTD ${fwcmd} add pass tcp from any to ${oip} 113 setup # Allow access to our SSH ${fwcmd} add pass tcp from any to ${oip} 22 setup ${fwcmd} add pass tcp from any 22 to ${oip} setup # Allow access to our FTP (ftp and ftp-data) # this is further restricted through xinetd ${fwcmd} add pass tcp from any to ${oip} 20 setup ${fwcmd} add pass tcp from any to ${oip} 21 setup # Allow access to NTP ${fwcmd} add pass udp from any 123 to ${oip} ${fwcmd} add pass udp from ${oip} to any 123 # Reject&Log all setup of incoming connections from the outside ${fwcmd} add deny log tcp from any to any in via ${oif} setup # Not sure about this, but it enables FTP # Allow setup of any other TCP connection # ${fwcmd} add pass tcp from any to any setup # ${fwcmd} add pass tcp from any to any 1024-65535 setup # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. # Ours is DEFAULT TO DENY ;; [Uu][Nn][Kk][Nn][Oo][Ww][Nn]) ;; *) if [ -r "${firewall_type}" ]; then ${fwcmd} ${firewall_flags} ${firewall_type} fi ;; esac --=====================_876755==_ Content-Type: text/plain; charset="us-ascii"; format=flowed --=====================_876755==_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 3 9:47:39 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 2ACEB37B503 for ; Tue, 3 Oct 2000 09:47:38 -0700 (PDT) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 777941C73; Tue, 3 Oct 2000 12:47:37 -0400 (EDT) Date: Tue, 3 Oct 2000 12:47:37 -0400 From: Bill Fumerola To: Forrest Aldrich Cc: cjclark@alum.mit.edu, freebsd-ipfw@FreeBSD.ORG Subject: Re: 4.1.1 Kernel ipfw, brought to its knees Message-ID: <20001003124737.U38472@jade.chc-chimes.com> References: <5.0.0.25.2.20001002154554.01bfe310@64.20.73.233> <5.0.0.25.2.20001002154554.01bfe310@64.20.73.233> <20001002233136.O25121@149.211.6.64.reflexcom.com> <5.0.0.25.2.20001003120347.020eb050@64.20.73.233> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <5.0.0.25.2.20001003120347.020eb050@64.20.73.233>; from forrie@forrie.com on Tue, Oct 03, 2000 at 12:14:29PM -0400 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Oct 03, 2000 at 12:14:29PM -0400, Forrest Aldrich wrote: > So, given that we're using FreeBSD on our infrastructure, we're very > concerned about this. add 'options DDB' into your kernel, hit ctrl-alt-esc when this happens, type 'trace' and send that output. for bonus hacker points, setup savecore and panic the machine when this happens and use gdb to debug this. make sure your shiney new kernel was config'd with 'config -g' thanks. -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 3 10:26:44 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from radius.wavefire.com (radius.wavefire.com [139.142.95.252]) by hub.freebsd.org (Postfix) with SMTP id 9796B37B66E for ; Tue, 3 Oct 2000 10:26:34 -0700 (PDT) Received: (qmail 27108 invoked from network); 3 Oct 2000 17:26:33 -0000 Received: from ccliii.caniserv.com (HELO dbitech) (darcyb@139.142.95.253) by radius.wavefire.com with SMTP; 3 Oct 2000 17:26:33 -0000 Message-Id: <3.0.32.20001003103017.019e19f0@mail.ok-connect.com> X-Sender: darcyb@mail.ok-connect.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 03 Oct 2000 10:30:17 -0700 To: freebsd-ipfw@FreeBSD.ORG From: Darcy Buskermolen Subject: Re: 4.1.1 Kernel ipfw, brought to its knees Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Try the same test without log_in_vain turned on. You may be trying to trouble shoot 2 problems in one, I've had bad experances with syslog and heave load in the past. At 12:14 PM 10/3/00 -0400, Forrest Aldrich wrote: >The nmap scan was a basic nmap ping. No options. > >Yes, the scan was local (on our LAN 100mbit). Nothing special was running >on this machine, other than packet filters and appropriate kernel config >options. It was just installed (FreeBSD-4.1.1) yesterday from the releng4 >server snapshot archive, and cvsup'd. > >The only errors I saw generated in the log were that from tcp_log_in_vain >setting. Glad I had at least that set, so I could know what was going >on. I also noted many syslogd -s processes running at one point, and I >tried killing those off to see if that would help. It just got worse. > >We performed this as a "qa" test, to see how FreeBSD would stand up to an >attack, without third-party utilities. > >Unusable means, the system froze... literally. I couldn't get any prompt >response, no connections, nothing. > >So, given that we're using FreeBSD on our infrastructure, we're very >concerned about this. > >We were experimenting with the rc.firewall config, as some of the options >were new (the dns update acl, for example). We did run into some weird >problems (and it's probably configuration error on our part) with regard to >connectivity. > >I'm attaching, for this named machine, the KERNEL config and the >/etc/rc.firewall config for your persual. Input or suggestions about the >config would be welcomed. > > >Thanks, > > >_F > > > > >At 11:31 PM 10/2/2000 -0700, Crist J . Clark wrote: >>On Mon, Oct 02, 2000 at 03:47:40PM -0400, Forrest Aldrich wrote: >> > I was working with our security person here at work, with my ipfw >> > config. I ran into some problems, which I'm still trying to figure out. >> > >> > So, he offered to at least scan the machine. He did a basic nmap scan... >> > brought the machine to its knees. I had ICMP bandwidth limitation >> > enabled. All except the RST (which isn't recommended for web servers). >> > >> > The machine is rendered unusable. I've never seen this happen to a >> > FreeBSD box. Our 2.2.8 systems withstand this better than this. >> > >> > ? >> >>I agree: ? >> >>What type of nmap scan? Was the scan local? What type of connection to >>the ROW do you have? What was running on the machine when the scan was >>run? What does "unusable" mean? Were any errors generated? >> >>Do you have a specific question? >>-- >>Crist J. Clark cjclark@alum.mit.edu > >Attachment Converted: "C:\Program Files\Eudora32\attach\forrienet" > >Attachment Converted: "C:\Program Files\Eudora32\attach\rc1.fir" > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 4 1:44:30 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id ADCDC37B502 for ; Wed, 4 Oct 2000 01:44:26 -0700 (PDT) Received: (from bonnetf@localhost) by bart.esiee.fr (8.10.1/8.10.1) id e948fY018759 for freebsd-ipfw@FreeBSD.ORG; Wed, 4 Oct 2000 10:41:34 +0200 (MEST) From: Frank Bonnet Message-Id: <200010040841.e948fY018759@bart.esiee.fr> Subject: Simple NAT machine ? To: freebsd-ipfw@FreeBSD.ORG Date: Wed, 04 Oct 2000 10:41:33 MEST X-Mailer: Elm [revision: 212.5] Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG HI I want to setup a simple NAT machine that will act for some clients of our LAN to access a router for Internet access. Do I have to also configure firewalling capabilities or not to do so ? Thanks -- Frank Bonnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 4 1:55:59 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 1AADF37B502 for ; Wed, 4 Oct 2000 01:55:57 -0700 (PDT) Received: (from bonnetf@localhost) by bart.esiee.fr (8.10.1/8.10.1) id e948s6Z18857; Wed, 4 Oct 2000 10:54:06 +0200 (MEST) From: Frank Bonnet Message-Id: <200010040854.e948s6Z18857@bart.esiee.fr> Subject: Re: Simple NAT machine ? To: bonnetf@bart.esiee.fr Date: Wed, 04 Oct 2000 10:54:06 MEST Cc: freebsd-ipfw@FreeBSD.ORG In-Reply-To: <200010040841.e948fY018759@bart.esiee.fr>; from "Frank Bonnet" at Oct 04, 2000 10:41 am X-Mailer: Elm [revision: 212.5] Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > HI > > I want to setup a simple NAT machine that will > act for some clients of our LAN to access a router > for Internet access. > > Do I have to also configure firewalling > capabilities or not to do so ? > > Thanks Ooops Sorry ! I just found the NATD documentation at www.freebds.org please ignore my preceding message ... -- Frank Bonnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Oct 6 9:19:49 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from sentry.granch.com (sentry.granch.com [212.109.197.55]) by hub.freebsd.org (Postfix) with ESMTP id 6909837B66D for ; Fri, 6 Oct 2000 09:19:43 -0700 (PDT) Received: from sentry.granch.ru (IDENT:shelton@localhost [127.0.0.1]) by sentry.granch.com (8.9.3/8.9.3) with ESMTP id XAA06755 for ; Fri, 6 Oct 2000 23:17:15 +0700 (NOVST) Message-ID: <39DDFB0B.22E04412@sentry.granch.ru> Date: Fri, 06 Oct 2000 23:17:15 +0700 From: "Rashid N. Achilov" Reply-To: achilov@granch.ru Organization: Granch Ltd. X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Where I was wrong? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a some FreeBSD box, connected to two different ISPs and my own private network. For example first ISP is 10.0.0.0/24, second 10.0.1.0/24 and my own network is 10.0.2.0/24, and FreeBSD router has: 10.0.0.1 to first ISP (10.0.0.2 other side, interface fxp0), 10.0.1.1 to second (10.0.1.2 other side, interface rl0) and 10.0.2.1 to private (interface ed0). My box in private is 10.0.2.2 and there are some other Windozes... Default gateway to all is 10.0.1.2 (second ISP other side) I wish I could forward all traffic from 10.0.2.2 to first ISP. I made this rule: ipfw add 100 fwd 10.0.0.2 ip from 10.0.2.2 to any out xmit rl0 and next rule to stop all other to Internet ipfw add 200 deny log tcp from 10.0.2.0/24 to any 80 And now I deny too! Why? Where I'm wrong? If I add next rule ipfw add 150 allow ip from 10.0.2.2.to any all, of course, OK, but why rule 100 don't work as I'd like? Please explain me... -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), Brainbench ID: 28514 Granch Ltd. lead engineer, e-mail: achilov@granch.ru tel/fax (383-2) 24-2363 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Oct 6 15: 4:13 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 6B96937B66E for ; Fri, 6 Oct 2000 15:04:11 -0700 (PDT) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id QAA26638; Fri, 6 Oct 2000 16:04:05 -0600 (MDT) Date: Fri, 6 Oct 2000 16:04:05 -0600 (MDT) From: Nick Rogness To: achilov@granch.ru Cc: freebsd-ipfw@freebsd.org Subject: Re: Where I was wrong? In-Reply-To: <39DDFB0B.22E04412@sentry.granch.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 6 Oct 2000, Rashid N. Achilov wrote: > > ipfw add 100 fwd 10.0.0.2 ip from 10.0.2.2 to any out xmit rl0 Hmmm, take out the "out via rl0". > > and next rule to stop all other to Internet > > ipfw add 200 deny log tcp from 10.0.2.0/24 to any 80 > > And now I deny too! Why? Where I'm wrong? > WHat does the deny log entry look like? Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Oct 6 21:19:51 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id C486437B502 for ; Fri, 6 Oct 2000 21:19:49 -0700 (PDT) Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 6 Oct 2000 21:18:33 -0700 Received: (from cjc@localhost) by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e974Jko66288; Fri, 6 Oct 2000 21:19:46 -0700 (PDT) (envelope-from cjc) Date: Fri, 6 Oct 2000 21:19:46 -0700 From: "Crist J . Clark" To: achilov@granch.ru Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: Where I was wrong? Message-ID: <20001006211946.O25121@149.211.6.64.reflexcom.com> Reply-To: cjclark@alum.mit.edu References: <39DDFB0B.22E04412@sentry.granch.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <39DDFB0B.22E04412@sentry.granch.ru>; from shelton@sentry.granch.ru on Fri, Oct 06, 2000 at 11:17:15PM +0700 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 06, 2000 at 11:17:15PM +0700, Rashid N. Achilov wrote: > I have a some FreeBSD box, connected to two different ISPs and my own > private network. For example first ISP is 10.0.0.0/24, second > 10.0.1.0/24 and my own network is 10.0.2.0/24, and FreeBSD router has: > 10.0.0.1 to first ISP (10.0.0.2 other side, interface fxp0), 10.0.1.1 to > second (10.0.1.2 other side, interface rl0) and 10.0.2.1 to private > (interface ed0). My box in private is 10.0.2.2 and there are some other > Windozes... > > Default gateway to all is 10.0.1.2 (second ISP other side) > > I wish I could forward all traffic from 10.0.2.2 to first ISP. I made > this rule: > > ipfw add 100 fwd 10.0.0.2 ip from 10.0.2.2 to any out xmit rl0 The 'fwd' command probably does not do what you think. Read ipfw(8) again. I don't understand what you want to do when you say you wish to 'forward all traffic to the first ISP.' Are we just talking about routing here? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Oct 6 22:50:43 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 11FBD37B671 for ; Fri, 6 Oct 2000 22:50:40 -0700 (PDT) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id XAA69748; Fri, 6 Oct 2000 23:50:32 -0600 (MDT) Date: Fri, 6 Oct 2000 23:50:32 -0600 (MDT) From: Nick Rogness To: cjclark@alum.mit.edu Cc: achilov@granch.ru, freebsd-ipfw@FreeBSD.ORG Subject: Re: Where I was wrong? In-Reply-To: <20001006211946.O25121@149.211.6.64.reflexcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 6 Oct 2000, Crist J . Clark wrote: > On Fri, Oct 06, 2000 at 11:17:15PM +0700, Rashid N. Achilov wrote: > > I have a some FreeBSD box, connected to two different ISPs and my own > > private network. For example first ISP is 10.0.0.0/24, second > > 10.0.1.0/24 and my own network is 10.0.2.0/24, and FreeBSD router has: > > 10.0.0.1 to first ISP (10.0.0.2 other side, interface fxp0), 10.0.1.1 to > > second (10.0.1.2 other side, interface rl0) and 10.0.2.1 to private > > (interface ed0). My box in private is 10.0.2.2 and there are some other > > Windozes... > The 'fwd' command probably does not do what you think. Read ipfw(8) > again. > > I don't understand what you want to do when you say you wish to > 'forward all traffic to the first ISP.' Are we just talking about > routing here? He is trying to do source address/policy routing. AFAIK, fwd is the only way I know how to do that with FBSD...unless someone has a better way to do this type of source routing? Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message