^^^^^^^^^^^^^
THIS

As part of your lesson's learned, your vulnerability analysis and potential remediation steps should probably have been done prior to this step of going live.  If it is publicly live, I am sure lots of people have already performed the test for you .

In a windows environment I occasionally get better results with the smb-os-discovery script in NMAP than simply using automated os detection.

Since rainbow tables are generated with SSIDs, I would suggest using a randomly generated SSID of sufficient length (depends on wireless vendor) and then a strong passphrase (randomly generated as well perhaps).  I would expect that to be good enough for home networks.

Personally, as long as you are using a "good" firewall (easy to administer, secure, works for you), then I would not go with a different vendor if the same group will be administering a lot of other equipment as well.  I do not think the overhead is worthwhile, and particularly not so if you use firewall management software from the same vendors (logging, configuration management, etc.).

1)  a-yes,b-maybe.  Most likely most protocols will work, but there are a lot of variables out there.

2)  Properly configured routers will only allow a source address they know, so it may kill the request right away.  Either way, if the packet does make it all the way to the internet with a spoofed source IP, the response (SA) will never make it back to you.  However, you can include a payload with a SYN packet, and with a specially constructed IP stack, you could use this for 1-way communication.

3)  If you really want "anonymous" traffic, rent a botnet and bombard them with packets.  It will be difficult to pick out the real traffic and if you use tech like VPN/Proxy/AnonEmail to work with the bot operators, it should be fairly difficult to track you down (at least until the bot operators are caught and start yapping).

You can actually specify the MAC in the vmx file in vmwware I believe.

Picks are like peckers....if you break it you are probably doing it wrong.  That being said, it is not hard to bend/break them while learning.

tturner - why do you need access to the idle host?  I think you just need to have an open tcp port to use for the idle scan to increment the IP ID, but you don't need anything further.  Or did I misunderstand and you meant access as being such?

steven1664 - I think the problem with your thinking on GSE being Level III, is that there are only 29 GSEs worldwide.  They have to fill more than 29 positions, so they have to have a fallback.  Perhaps a combination of a couple of certs would be more to your thinking, though?

In my previous life, I would have hired in a network technician with a couple of years experience around the 45k figure.  With no experience, but a great interview, I would probably go about 2 years of raises lower than that (~40k).  But, I must say our IT salaries in my part of the country are pretty low, but so is our cost of living.

Obviously you and Sil have had different experiences with the Fortinet products than have I.  We used quite a few (~50-60), mostly in the 60/60b/80c range with a few 300 as well.  We did not have much trouble out of them and often did not run bleeding edge code on them.  We did use IPSEC and SSLVPN without issue, and yes, the missing GUI for mac reservations was irritating, but not a show-stopper.

They also support routing, up to and including BGP (though I can say I never used BGP on one since ours were too small).  OSPF and RIP worked perfectly, though.  We used them for nearly all of our non-core routing without issue at our WAN sites.

All that being said, we also used a SA4500 SSLVPN from Juniper that was far ahead of Fortinet's SSLVPN offering.  That would stand to reason, though, since Fortinet's was  bolt-on to list a feature (though it was quite usable for small implementations).

Fortinet support was not so good, but to be honest, we rarely had reason to call them.  Support is definitely a weakness for them that they will have to work on in order to improve market share.  Additionally, I think QA in their software side is next in line to get spanked if they do not improve.

In my experience, for the products we were purchasing, Juniper could not compete on a bang-for-the-buck comparison.  When we demoed Fortinet initially, we compared them to the Pixs and the NetScreens (now Juniper) and chose them due to simplicity and cost (and I really do not like Cisco products outside of routers for the most part).  As I stated before, each to his/her own.

Each to their own re: Fortinet.  In my previous life we had > 50 of these units and the only issue we had out of any of them were early models CF cards going bad.  Otherwise they were rock solid.  Their support can be slow at times, but if it is an urgent ticket, calling will normally get things resolved more quickly than sending email.  However, I would have to agree that their support is a weakness, but stand by the statement that they are a solid product.

The Juniper SSGs are also a good product line, but they are not in the same price point.  It all depends on what you need and what your budget is.

Look at Fortinet.  They make a solid product at a competitive price.

SANS.edu as well...