Mikael - I couldn't agree more. I can't think of any reasons why an NT firewall should be speaking NetBIOS, or be part of a domain. If it relies on other boxes for auth it's that much easier for it to be attacked remotely. This may interest some of you - it's my current process for reducing the services on NT preparatory to installing (in my case Gauntlet) NT firewall software. I've tried to make it non-NAI specific, but there may be bits I've missed. If anyone has tweaks and improvements, I'd love to hear them - email me directly, as first preference, and I'll revise the doc and make it available to the list (if there's interest). ACKNOWLEDGEMENTS: I drew on a (shorter) email to this list by Don Kelloway a few months ago, and a little on the "Building NT Bastion Hosts in Practice" (or whatever) by Stefan Norberg. Process documentation Building gauntlet on NT 1. Create one 2Gb partition. Format with NTFS. Create no other partitions. 2. Install NT as a STANDALONE server 3. In User Manager for Domains, rename the Administrator account. I use something random - root, boss, admin etc are probably bad choices. Set a strong password for the renamed account (over 10 characters, upper and lowercase, including numbers and non-alphanumerics (!@#$%^&*() etc). NT supports non-printing characters, which can be entered using ALT+[0-255] (eg ALT+212)) 4. Set IP addresses for all NICs. Only the external NIC should have a default gateway. 5. In the "Services" tab under the Network control panel, REMOVE every service except RPC Configuration. This includes the Server and Workstation services. 6. In the "Bindings" tab, unbind "WINS Client (TCP/IP)" from all the NICs EXCEPT the internal NIC. DNS will not start without the WINS Client for some strange reason. Note that whenever you open the Network Control Panel from now on, it will ask you if you want to install networking - just say no. This is because the Workstation service is missing. Note that I didn't have any success with unbinding _all_ the network protocols as Don Kelloway suggested - the FW software didn't consider that there were any NICs installed and it bailed. I'm not sure that many of the COTS firewalls actually use their own TCP/IP stack anyway - I think that may be an urban legend. We'll all just have to keep reading bugtraq and doing external audits. 7. In the Services control panel, set the startup option on these services to "Disabled" � DHCP Client � License Logging Service � Plug and Play � Spooler � TCP/IP NetBIOS Helper � Server � Workstation If you're paranoid, you can go ahead and disable to rest of 'em, but they won't start by themselves. All that should be running is � RPC � EventLog 8. At this stage an external port scan should turn up no open ports except 135 (RPC endpoint mapper) and maybe one or two around 1025-1030 (random Microsoft ports which seem to exist for no reason). 9. Next, Install DNS. Set up the DNS server. It should operate on all interfaces, act as a slave server, and forward to the upstream DNS. It should NOT have any entries for hosts in the internal network. Note that we do this for Gauntlet because it is an application proxy, and the easiest way to proxy DNS is to run a DNS server. If you hate MS DNS you can remove more services (RPC in the Network Control Panel). Personally, I think it's a lesser evil to run DNS on my firewall than to try and filter DNS traffic in and out of the network. 10. Run the "C2 Configuration Manager" which is included in the NT Resource Kit. Go into each security feature and select "Secure" or "C2". This will remove the OS/2 subsystem, Posix subsystem, change some password options etc. When this is complete, the only "open lock" icon should be the "Networking" feature, since we have some network services installed. Ignore the Registry Security, File System Security and Other Security Items. 11. In User Manager for Domains, go to Policy->Audit Policy and Audit the following: � Logon and Logoff (Success, Failure) � File and Object Access (Failure) � Use of User Rights (Failure) � User and Group Management (Success, Failure) � Security Policy Changes (Success, Failure) � Restart, Shutdown and System (Success, Failure) Don't Audit Process Tracking. That would be bad. When the firewall is first commissioned, clear all Event Logs. 12. Install SP5 At this stage, the only services that should be running are the above plus DNS. 13. Once this has all been verified, install your firewall. 14. On the C: drive, set security options. (For Gauntlet) Remove the "Everyone - Add & Read" default setting. The only entries in the permissions should be Administrators - Full Control and SYSTEM - Full Control. Gauntlet Specific: I do this step here because Gauntlet actually changes the file ACLs, thinking that it's making it more secure than the default Everyone - Full Control. However I actually had Everyone removed completely. 15. After the firewall has been installed, there may be some extra Services Installed. Gauntlet Specific: Most of the names of the new services start with "Gauntlet", but it will also re-enable the NTLM Security Support Provider, Protected Storage and the Schedule services. There will also be the DNS Service, which we installed ourselves. 16. Gauntlet Specific: Back in the Network Control Panel, unbind WINS Client from every NIC except the Internal one (on the Gauntlet Virtual Adapter, not on the physical NIC). 17. After all this is done, run SP5 again. (You can't run SP5 too often, IMO. In fact, feel free to just run SP5 after every step. Hell, why not every day?) Gauntlet Specific: Gauntlet enables the HTTP proxy by default, so you should now be able to get web access from inside the firewall by using the firewall as the default gateway. If this works, then DNS is working and the firewall is running. 18. The firewall is now ready for configuration. After this stage, we take a ghost image and store it on a CD. The external port scan turns up all the open ports we expected (53 for DNS, 21 for FTP etc, some random ones around 1025ish and (in this case) one on 7777 which is owned by the GauntletAuth Service. 19. Next, edit the BIOS, add an Administrator password and remove the floppy drive from the startup sequence. Otherwise, a simple Linux floppy with the NTFS drivers can be used to access the whole hard drive. Since the gauntlet config files are just text, this could easily compromise the firewall. This is probably just as true for any package since I think a lot of them are *nix ports, and the developers are used to using config files. Note that if someone has physical access to the hard drive, they could remove it, connect it to another system and make the changes, then reconnect it to the firewall. We could get around that by encrypting the whole HDD, but there have to be limits. If someone can get in, down your firewall, remove the HDD, boot it in a new system, change the config, reinstall the HDD, reboot the firewall (without the syskey disk - see next step) and bring it back up without you noticing then you have problems that a firewall isn't gonna fix. 20. Finally, run the "syskey" utility to encrypt the SAM database with strong encryption, and store the key on a floppy. The system will not start without the key floppy. The startup floppy should NOT be stored in the drive in the firewall, and a copy of the key should be stored on non-perishable media (a CD, encrypted on a HDD etc). 21. If the worst happens, the BIOS can be edited to allow startup from a floppy, and the ghost image of the Firewall just before the BIOS changes and the application of syskey can be used to restore the system. Phew. -- Ben Nagy Network Consultant, CPM&S Group of Companies PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520 > -----Original Message----- > From: Mikael Olsson [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 13 October 1999 3:40 AM > To: Tom Tomasovic > Cc: [EMAIL PROTECTED] > Subject: Re: FW: Firewall-1 On NT > > > > There's a problem with having a firewall speaking NetBIOS. > > NetBIOS has serious design flaws, which has been demonstrated > by several different people. One could argue that you should > not use it at all (use another networking protocol), but in > any case I for one would not want it anywhere near my firewall, > let alone inside its authentication mechanisms. > > In fact, I'd probably want to disable NetBIOS on all interfaces > of the firewall to keep it out of harm's way, along with removing > "Server" and "Workstation" and all the other services on it. > > You don't want unnecessary code running on your firewall. - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.]
