Very cool site showing DNS operation: How DNS works.
Netsparker is the only False-positive-free web application security scanner, it’s worth pointing at your application. it’s at: Netsparker security tool
If you’re looking for secure alternatives to the applications you use – vist: www.privacytools.io
A great summary PDF of the OWASP top 10 risks: Attacking Web
Applications by Sasha Goldshtein.
After the Heartbleed vulnerability, it’s worth checking that any sites you use have actually fixed their security issues and reissued fresh certificates. A tool for doing this is to use the DigiCert SSL Installation Diagnostics Tool. This will identify any offending sites.
For when you can’t spin up a console: network-tools.com
Updated to to add a few more command line switches.
wget.exe --recursive --spider --bind-address=localhost --verbose http://localhost --random-wait --no-directories --server-response
Wget has lots of options but this is the simplest configuration for spidering a website.
wget.exe --spider --bind-address=localhost --verbose http://localhost --recursive
I’ve been talking to a contact who has been experiencing some connection issues with a large scale SQL Server implementation. The database is serving as the back-end to a well used Internet site. They reported that during the course of normal operation that they’d received dropped TCP connections and difficulty in achieving automatic failover at the database layer. They’d investigated the possibility of running without database connection pooling enabled. I advised that this was not a suitable idea. Afterwards this support article was found: support.microsoft.com/kb/328476
The article advises:
Note that Microsoft strongly recommends that you always use pooling with the SQL Server drivers. Using pooling greatly improves overall performance on both the client side and SQL Server side when you use the SQL Server drivers. Using pooling also considerably reduces network traffic to the computer that is running SQL Server. For example, a sample test that used 20,000 SQL Server connection opens and closes with pooling enabled used about 160 TCP/IP network packets, for a total of 23,520 bytes of network activity. With pooling disabled, the same sample test generated 225,129 TCP/IP network packets, for a total of 27,209,622 bytes of network activity.
The moral of the story – connection pooling is advised and think carefully before turning off.