Restarting Web Services and Scheduled Tasks with a Batch File

The following instructions and batch file allow you to schedule IIS to restart on a daily basis at 1:00A.M. It will also keep a log to show when the services were stopped and started in your %SystemRoot% folder. By modifying the remark (REM) sections of the batch file you can specify other commands to run while IIS is stopped.


Log on to the Windows NT computer as an administrator.
Make sure that the Task Scheduler service is set to automatically run by performing the following steps:


Click the Start button, point to Settings, click Control Panel, and then double-click Services.
Scroll to "Task Scheduler."
If the status does not say running, then click the Start button.
Click the Startup button.
Make sure the Startup Type is set to Automatic, and then click OK.
Click Close to exit the Services dialog box.
Open a command prompt session and type the following command:

at 1:00am /every:M,T,W,Th,F,S,Su "restart.bat"

Save the following text as a batch file named Restart.bat in your path: @echo off
cls
echo RESTART - A restart utility for IIS web services.
echo June 1998, Microsoft Corporation.
echo ****************************************>>%SystemRoot%\restart.log
echo Stop Date/Time:>>%SystemRoot%\restart.log
echo. | date | find /i "current">>%SystemRoot%\restart.log
echo. | time | find /i "current">>%SystemRoot%\restart.log
echo.>>%SystemRoot%\restart.log
echo Stopping Web Services...
echo.

set MSFTPSVC=0
set NNTPSVC=0
set SMTPSVC=0
set W3SVC=0
set BROKSVC=0
set LDAPSVC=0
set MSGBLDSVC=0
set IISERROR=0

:MSFTPSVC
net start | find /i "FTP Publishing Service">NUL
if errorlevel==1 goto NNTPSVC
set MSFTPSVC=1

:NNTPSVC
net start | find /i "Microsoft NNTP Service">NUL
if errorlevel==1 goto SMTPSVC
set NNTPSVC=1

:SMTPSVC
net start | find /i "Microsoft SMTP Service">NUL
if errorlevel==1 goto W3SVC
set SMTPSVC=1

:W3SVC
net start | find /i "World Wide Web Publishing Service">NUL
if errorlevel==1 goto BROKSVC
set W3SVC=1

:BROKSVC
net start | find /i "Site Server Authentication Service">NUL
if errorlevel==1 goto LDAPSVC
set BROKSVC=1

:LDAPSVC
net start | find /i "Site Server LDAP Service">NUL
if errorlevel==1 goto MSGBLDSVC
set LDAPSVC=1

:MSGBLDSVC
net start | find /i "Site Server Message Builder Service">NUL
if errorlevel==1 goto STOPIIS
set MSGBLDSVC=1

:STOPIIS
net stop iisadmin /y>>%SystemRoot%\restart.log
if errorlevel==1 goto STOPERROR
goto STOPPED

:STOPERROR
REM ********************
REM * Put any desired error-handling commands here.
REM * For example, if you have the NT Resource Kit,
REM * you could use the following command to stop
REM * IIS down the hard way:
REM * KILL.EXE INETINFO.EXE
REM ********************
set IISERROR=1

:STOPPED
REM ********************
REM * Put any desired commands to run while IIS is stopped here.
REM * For example, if you have the Windows NT Resource Kit,
REM * you could use the following command to pause
REM * the restart for one minute:
REM * SLEEP.EXE 60
REM ********************

:STARTIIS
echo -------------------->>%SystemRoot%\restart.log
echo Start Date/Time:>>%SystemRoot%\restart.log
echo. | date | find /i "current">>%SystemRoot%\restart.log
echo. | time | find /i "current">>%SystemRoot%\restart.log
echo.>>%SystemRoot%\restart.log
echo Starting web services...
echo.

if %W3SVC%==0 goto NOW3SVC
net start W3SVC>>%SystemRoot%\restart.log
if errorlevel==1 set IISERROR=1

:NOW3SVC
if %MSFTPSVC%==0 goto NOMSFTPSVC
net start MSFTPSVC>>%SystemRoot%\restart.log
if errorlevel==1 set IISERROR=1

:NOMSFTPSVC
if %NNTPSVC%==0 goto NONNTPSVC
net start NNTPSVC>>%SystemRoot%\restart.log
if errorlevel==1 set IISERROR=1

:NONNTPSVC
if %SMTPSVC%==0 goto NOSMTPSVC
net start SMTPSVC>>%SystemRoot%\restart.log
if errorlevel==1 set IISERROR=1

:NOSMTPSVC
if %BROKSVC%==0 goto NOBROKSVC
net start BROKSVC>>%SystemRoot%\restart.log
if errorlevel==1 set IISERROR=1

:NOBROKSVC
if %LDAPSVC%==0 goto NOLDAPSVC
net start LDAPSVC>>%SystemRoot%\restart.log
if errorlevel==1 set IISERROR=1

:NOLDAPSVC
if %LDAPSVC%==0 goto NOMSGBLDSVC
net start MSGBLDSVC>>%SystemRoot%\restart.log
if errorlevel==1 set IISERROR=1

:NOMSGBLDSVC
if %IISERROR%==0 goto EXIT

:ERROR
echo RESTART ERROR...>>%SystemRoot%\restart.log
echo One or more of the services could not be
restarted.>>%SystemRoot%\restart.log
echo Please check the Event Viewer logs for more
information.>>%SystemRoot%\restart.log

REM ********************
REM * Put any desired error-handling commands here.
REM * For example, if you have the Windows NT Resource Kit,
REM * you could use the following command to restart
REM * the server in two minutes:
REM * SHUTDOWN.EXE /L /R /T:120 /Y
REM ********************

:EXIT
set MSFTPSVC=
set NNTPSVC=
set SMTPSVC=
set W3SVC=
set BROKSVC=
set LDAPSVC=
set MSGBLDSVC=
set IISERROR=

猴年马月

呵呵,2004年是猴年(甲申年)，马月(庚午月)就是农历5月份，猴年马月就是从公历2004年6月18日开始到7月16日结束。猴年马月已经到了。平时等不到的做不到的,我们可以再去试试了!

Gmail 注册成功。留念一下。

Java查BUG工具

Java环境下的查错工具findBugs
这里有文章介绍：
http://www-900.ibm.com/developerWorks/cn/java/j-findbug1/index.shtml
http://www-900.ibm.com/developerWorks/cn/java/j-findbug1/index.shtml

下载：
http://findbugs.sourceforge.net/

与 MS 的 FxCop 非常类似，FindBugs 使用 apache 的 BCEL 从 bytecode 级对 java 的 .class 文件进行基于规则的潜在问题分析，并能提供相当程度的修改建议。相比之下 FxCops 得利于 .NET 内建的强大 reflection 支持，并提供了数量更多的检测规则。但 FindBugs 对潜在问题的统计、分类和整体分析，使之使用上更为简单。值得称道的是 FindBugs 支持作为 ant 的自动任务执行，这样使其能够在自动每日构造中直接使用

与之类似的产品还有 Borland 前段时间收购的 Together 。其中提供了针对多种常见语言（如 C++ 和 Java 等）的 Audits 和 Metrics 功能。前者就类似上述代码潜在问题自动分析；后者则能够对代码设计上的一些问题从统计角度进行分析，如模块耦合度的量化等等。
此外MS 前段时间也收购了一家做静态代码安全性分析的公司，用于其自身代码安全性的自动验证。现有工程师可以培训，正在开发的代码可以停下来几个月整顿，但毕竟几千万行的历史遗留代码就不是靠人力能够解决的问题了，

如果有朝一日，这种静态分析工具能够将规则描述统一起来，并且辅以动态的分析手段，则应该能够获得更好的效果。

.NET 工具

Snippet Compiler是一个代码片断开发环境
Regulator 则是一个非常专注的正则表达式开发调试环境
CodeSmith 是一个基于模板的代码自动化生成工具
NUnit, NDoc 和 NAnt 我就不多说了，目前最好的开源测试用例、文档生成和自动构建工具。
FxCop 是一个久负盛名的静态代码分析工具，能够基于规则对二进制形式的 IL 代码进行潜在问题的分析，相关介绍也很多。
Lutz Roeder's .NET Reflector 是一个强大的逆向工程工具，属于绝对必备的工具之一，支持 .NET Framework 2.0 的最新版本 .NET Reflector 4.0。
还有一个 ASP.NET Version Switcher 工具，提供对 ASP.NET 当前使用 .NET 版本的切换工作。对同时需要提供 .NET Framework v1.0 和 v1.1 甚至 v2.0 支持的 ASP.NET 开发者来说，应该是非常有用的一个工具吧，免得每次要用 aspnet_regiis.exe 注册来注销去的.

iehttpheaders

http://www.blunck.info/iehttpheaders.html

终于不需要代理可以访问blogspot.com.

情理之中，意料之外，是戏；情理之外，意料之中，是计

有一句话说的好：情理之中，意料之外，是戏；情理之外，意料之中，是计。
由这句话可以充分的体现出来我们生活中的很多人生百态，有人在演戏，有人却在用计。但自始至终每个人都带了一个伪善的面具。
其实，最好的、最善长利用面具的人，应该是骗子。每个人都痛恨骗子，所以在小心翼翼的呵护自己，生怕被骗。可是真正能逃过被骗，还是需要需要利用面具，因为，俗话说的好，魔道相争，魔高一尺，道高一丈。
说来说去，还是回到了话题，学会带面具，哪怕是给人一个含泪微笑的面具，也要先擦掉眼角的泪。

WildPackets软件全集

WildPackets软件全集
================================================
WildPackets.AiroPeek.v2.0.2.rar
WildPackets.AiroPeek.NX.v2.02.rar
:目前最好的无线网络(WLAN:802.11*)数据分析软件

WildPackets.EtherPeek.NX.v2.1.rar
WildPackets.EtherPeek.v5.1.rar
WildPackets.RMONGrabber.v1.1.rar
:非常好用的以太网数据分析软件，比SnifferPro轻巧简单(NX是有专家系统的版本，类似sniffer的
:expert功能)RMONGrabber是利用RMON和SNMP协议进行远程抓包的peek插件，需要etherpeek和
:交换机硬件功能(SNMP+RMON II)支持。

WildPackets.TokenPeek.v4.5.0.rar
:很少见的令牌环网数据分析软件，具有和Etherpeek相同的界面和功能。

WildPackets.ProConvert.v2.6.0.rar
:非常好的网络数据存储包格式转换软件，支持在libpcap/sniffer/tcpdump/ethereal等几十种常见网络
:分析软件的cap包和Etherpeek/Airopeek的cap包之间作相互的转换( 任何类型的包都是可以双向转换
:的 )

WildPackets.NetSense.v4.2.0.rar
WildPackets.WebStats.v1.0.5.rar
WildPackets.Network.Calculator.v3.2.1.rar
:WildPackets网络扩展工具，NetSense是网络存储cap包的静态分析软件和专家系统；
:WebStats是Etherpeek的Web系统分析功能模块插件;
:其他还有一些小工具，例如NetworkCalculator,iNetUtils,包含在其他套件中;
:在EtherPeek中也包含一个小工具pktGrabber，可以做分布式抓包，或存储为本地文件，以供
:EtherPeek和NetSense进行分析。


下载地址:
=================================================

http://www.freedemon.org//Network//WildPackets//WildPackets.AiroPeek.NX.v2.02.rar
http://www.freedemon.org//Network//WildPackets//WildPackets.AiroPeek.v2.0.2.rar

http://www.freedemon.org//Network//WildPackets//WildPackets.EtherPeek.NX.v2.1.rar
http://www.freedemon.org//Network//WildPackets//WildPackets.EtherPeek.v5.1.rar
http://www.freedemon.org//Network//WildPackets//WildPackets.RMONGrabber.v1.1.rar

http://www.freedemon.org//Network//WildPackets//WildPackets.TokenPeek.v4.5.0.rar

http://www.freedemon.org//Network//WildPackets//WildPackets.ProConvert.v2.6.0.rar
http://www.freedemon.org//Network//WildPackets//WildPackets.NetSense.v4.2.0.rar
http://www.freedemon.org//Network//WildPackets//WildPackets.WebStats.v1.0.5.rar
http://www.freedemon.org//Network//WildPackets//WildPackets.Network.Calculator.v3.2.1.rar

http://www.freedemon.org//Network//WildPackets//index.txt

永远不要奢望用户会很自觉的看使用手册

今天看到一关于搜索引擎的调查文章，有些部分觉得不错，就贴过来备忘
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
就搜索成功性而言，所有用户（包括偶尔使用或经验丰富的用户）对搜索结果满意的次数百分比仅为42%。尽管仅对经验丰富的用户来说这一数字可以达到50%，但这仍然意味着失败。
上述问题的部分原因是从本质上看搜索是一种输入输出流。大约有60%的被调查用户仅在搜索开始时键入一个单词，另外的20%用户键入了两个单词。只有1%的被调查用户使用了高级搜索功能，而使用引号或其他查询语法对搜索进一步优化的用户仅有3%。此外，调查还表明搜索结果页面中的第一条链接得到了51%的点击率，第二条获得了16%。从搜索引擎公司的数据库也得出了同样的结果，并由此产生了关于搜索的另一条定律：不要奢望用户使用比搜索引擎所提供基本工具技巧更多的手段来获取信息。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
其实作产品也一样，很多时候产品的开发人员都是振振有词，用户怎么不看我们写的使用手册啊，呵呵，说到底，只要供求关系不变，就永远不能这么去和客户较劲，只能从自身下功夫，让产品更易用，实施人员给客户培训得更到位，这才是比较明白或者说比较有效的解决办法。

设定阈值打补丁

一旦发现漏洞，人们通常的第一反应是——赶快打补丁。可是，权威人士告诉你：打补丁前要作衡量，通过设定阈值，最终达到科学地打补丁的目的。

　　软件的缺陷或漏洞随时都可能造成系统崩溃或者入侵，所以，一旦发现漏洞，人们通常的第一反应是——赶快打补丁。但是，几乎每天都有新的软件缺陷、漏洞被发现，伴随着无数相应的补丁或者临时解决办法，安装如此多的漏洞和补丁是需要占用大量资源的。另外，仓促推出的补丁有时未必安全，相反，或许还会引入稳定性、性能等方面的隐患。怎么办？看来，漏洞管理不是仅仅打补丁就够了，这里面隐藏着许多学问。权威人士告诉你：打补丁前要作衡量，建议通过漏洞的影响度、流行度、简易度乘积（IPS）与企业资产联系起来，以判断该漏洞的安全风险，设定阈值，最终达到科学地打补丁的目的。


　　补丁和漏洞管理 形成资源漏斗


　　先来看一组数字。根据Meta Group的报道，2002年全年共发现和公布了4192个漏洞。同时，实际统计表明，平均一个系统管理员全年共花费1920个工时，将4个补丁打到120台服务器上，即在一个服务器上打一个补丁的平均时间大约为4小时，其中包括备份安装测试等环节。假设该名系统管理员具有良好的技能训练，可以在20分钟内阅读研究完一个漏洞及其补丁解决方案，那么，4192个漏洞总共需要172个人天。再假设其中只有10％的漏洞适用于自己的网络环境，这样413个漏洞，每个相应的补丁部署在10台服务器上，共需要2065个人天（即同样配置的服务器数量为10个左右）。我们可以看到，这两个人天数字加在一起，差不多是10个全职安全管理员一年的工作量，这里还没有考虑对厂家发表的补丁进行测试和验证的过程，也没有考虑打补丁失败造成的二次资源消耗。可以看到，补丁和漏洞管理已经成为一个很大的资源漏斗，占用大量的系统管理员资源。

　　任何一名企业管理者对这些系统和安全隐患不能视而不见，但是，这样巨大的资源消耗也承受不起，必须找到更有效的解决途径，以填补这个巨大的“漏斗”，这些解决途径可以包括以下措施：

　　引入知识共享或者外部知识库（专业服务），减少漏洞和补丁学习过程消耗；建立有效的补丁管理流程和备份回卷计划；引入自动化的补丁和漏洞管理工具，加速布部过程。


　　补丁的风险成本


　　上面的数字说明打补丁对于任何一个企业来说，代价是非常昂贵的。这种成本包含有收集、了解、测试、部署、备份恢复以及风险等成本。但是，不打补丁的“成本”是数据失密、丢失、窜改、拒绝服务、系统恢复以及其它无形损失等。如果用一个简单的数学模型来表达以上有关打补丁的成本分析，即打补丁的最佳时机的话，就是下面的成本不等式：部署成本＋补丁失败概率×失败成本 <= 攻击入侵概率 × 攻击入侵成本。

　　通常我们使用三个数字来描述一个漏洞的安全风险特性：I(影响度，即攻击入侵成本)、P(流行度，即多大范围内传播了该漏洞)、S(简易度，即利用该漏洞的难易)。后两者的乘积（P×S）大约可以反映该漏洞导致攻击入侵的概率。不等式的右边I×P×S代表的是该漏洞对应的不打补丁成本，本质上反映的是补丁管理决定的防御强度（是否可以承受），参照图1的示意图。

　　在曲线的最高点，按照100％安全的要求，即使是IPS乘积为0的补丁（即风险极小）也必须完全部署。这时的代价极高，通常不符合安全风险管理的投资回报原则。

　　从上面的不等式，我们可以看出，左面的部署成本和补丁失败成本决定了“合算”的IPS强度。如果我们将部署成本降下来，通过测试将补丁失败的几率降下来，则可以在保证投资回报的前提下，将补丁引起的损失和成本降到最低，就可以提高IPS决定的防御强度。


　　寻找打补丁最佳时机


　　通常认为，对于发现的漏洞和补丁应该尽快安装部署。但是，按照美国USENIX组织发表的一个针对CVE漏洞和补丁的研究数字表明，大概有18％左右的补丁会稍后进行重新发布，即出现了所谓的补丁的补丁，即意味着，在第一时间安装上的补丁，有18％的可能会带来新的缺陷或安全漏洞。随着时间的推移，补丁本身的安全性和稳定性会上升，由此造成的损失风险相应降低。

　　如图2所示，我们必须在早打带来的补丁失败风险与晚打带来的入侵攻击风险之间进行平衡，选择较好的时机。从对实际CVE漏洞和补丁的研究来看，新发表的补丁大概需要2周到4周左右的时间稳定下来，换句话说，在补丁发表后两周，考虑尽快部署可能是较为稳妥的时间。如果不满足这样的时间延迟，则需要自己建立更强大快速的安全实验室，专门来研究测试补丁。将大规模部署补丁的时间延迟提早到1周以内。


　　自动化打补丁 降低部署成本


　　从前面的不等式我们看出，降低部署成本、减小补丁失败成本，可以提高补丁管理决定的安全防御强度。降低部署成本的有效办法就是“自动化”，建立覆盖全网的自动化补丁知识库和管理系统，集中收集、建立、分发补丁包。这样的自动化系统可以带来下面所列的明显收益：将整个补丁分发过程的时间窗口减小到极低；将每服务器/每补丁数小时的工时成本降到很低，即分发安装费用降到接近零，只剩下制作软件分发包、检查测试补丁安装结果的“工时”成本；保证全网在补丁配置管理方面的一致性。另外，减小补丁失败成本的办法是对补丁进行有效测试，具体做法可以是购买专业厂家的服务，也可以建立自己的安全实验室。这样的投资对于分布式的大企业来说，具有非常高的投资回报率。

　　补丁本身的特点注定补丁管理不可能有很好的预见性，但是作为管理者，在流程和手段上，却不能不预见到补丁管理的特性和意义，及其实施中的具体问题。所有的补丁分发与管理工具只是帮助加速或者自动化相应的策略和过程，提高效率和质量而已，但是不可能改变逻辑。如果补丁管理流程本身是混乱的，那么自动化的后果也肯定是混乱的。

　　补丁管理相关策略和流程的设计需要充分考虑以下相关的重要流程环节，包括：

　　企业的安全策略：漏洞或者缺陷是对安全的威胁，安全策略应该覆盖针对漏洞和补丁的相应策略，补丁和漏洞管理流程则应该与上述策略相适应。

　　变更和发布管理：补丁的制作、测试、批准和部署应该纳入标准的变更和发布流程。如果当前尚没有完整的变更和发布流程，则在补丁管理流程中应该明确定义补丁的优先级或者分类、制作、测试、批准和部署以及验证等相关职位、职责和时间。

　　配置管理：按照ITIL的最佳实践，完整一致的中心配置管理数据库（CMDB）是保持高水平IT服务管理的保障。定义补丁和漏洞相关的配置管理条目，并通过流程保证及时正确地更新。

　　资产管理：如果已经具备了资产管理体系和流程，补丁和漏洞应该与具体的资产和相关业务优先级对应起来，正确设计不同关键性资产的特定流程。

　　备份恢复和业务连续性管理：补丁部署的前后都会与企业的备份恢复以及业务连续性管理有关，需要充分参考、在必要时修改更新备份恢复和业务连续性计划。

　　紧急响应：所有的补丁管理流程必须设计相应的紧急响应流程。从前面的数字，我们知道，即使是官方正式发表的补丁，也有相当的概率会出现自身新的缺陷或漏洞，与企业系统的应用关联在一起，补丁的漏洞是绝对不可忽略的。流程中必须保证这样的恢复和紧急响应环节。

　　管理层应该综合考虑相关的各个方面，充分借鉴在IT服务管理或者ITIL方面的实践经验，或者借助于外部的专业服务，设计与整体IT基础设施管理系统相匹配的补丁管理策略和操作流程。同时，在应用前面的自动化补丁管理系统之前，应该充分调查研究具体的IT环境和整个补丁生命周期的各种问题，设计较为周密的补丁管理策略和流程，至少应该明确定义补丁管理的使用范围、补丁优先级、补丁分发包的制作和测试、批准与分发安装、安装后测试、备份恢复计划等。

　　补丁管理是当前IT系统管理中越来越繁杂的内容。补丁全部不打，安全风险太大；什么补丁都打，一方面成本很高，另外补丁本身带来的风险也不可忽略。本文建议：通过漏洞的影响度、流行度、简易度乘积（IPS）与资产联系起来判断该漏洞的安全风险，设定阈值。一般情况下，留出2周左右的测试时间，尤其是对于电信、银行等关键性应用场合。部署自动化的补丁管理工具可以大幅减小漏洞收集和补丁部署成本，从而在相同投入情况下，提高补丁管理带来的安全强度。补丁管理必须建立相应的流程，该流程应充分参考借鉴ITIL的最佳实践，融入到整体的IT基础设施管理体系中去。

选择合适的UI，而不是选择“先进”的

通常所说的B/S并不能和“先进”画等号。那些在技术改造道路上将目光瞄准在把Windows Application迁移到Web Application的，是值得再反复思量的。最近我就接触了三个例子，充分说明了一个道理：不要盲目跟风，不要盲目的上Web Application，不要盲目的转向.NET或者J2EE。

例子1，航空订票系统

今天上午去公司的Travel Desk订星期五回上海的飞机票，结果很让我高兴：买到了5折的。要知道，前两个月，7折都是很罕见的。订票的时候，我仔细观察了一下那个终端：是在Windows上开了一个绿色的字符终端，直接敲命令查询航班，返回结果也是一行行的字符输出。返回的结果我是看不懂的，但Travel Desk的人就能看懂：他一眼就能看出有多少折扣，还有没有位子。而我只看到一串不知道什么意义的英文字符。

从纯粹的技术人员的角度来看，这种Client端显然是应该被淘汰的：操作不是GUI的而是Cmd Line的，查询是通过命令字符串而不是一个友好的Query Builder界面，返回结果也很不friendly。但我觉得这样的界面是很好的，因为它的用户已经习惯了用这样的界面，而且根据我的观察，Travel Desk的人操作起来很快，他们也能毫无困难的理解那些我无法理解的返回结果。所以，如果我是技术主管，我一定会反对任何把这种界面升级到GUI的提议。我的信条是：没有充足的理由，不要改动正用得好好的东西；没有充足的理由，不要引入新东西。

例子2，银行

根据我的观察以及我的一个同事跟我的转述，很多银行柜台上的服务员是纯粹通过数字键盘来操作他们的终端的。我同事说，他们的终端应用程序也是字符界面的，通过菜单访问。例如，第一层菜单是（假设的）：1-企业业务；2-个人业务。如果选了“1-个人业务”，第二层菜单是：1-开户；2-提款；3-存款；4-改密码。以此类推。久而久之，柜员脑子里面记住了很多数字串和功能的对应，例如“1-3-2-4”就是功能A，“2-5-1-1”是功能B，...，这样记熟了以后，操作起来非常非常快，远远比鼠标快。

当然，我也看到过有一些银行的柜员终端是Win32 Application。我觉得他们的操作速度没有“1-3-2-4”那种快。所以，如果我是银行的技术主管，我始终会坚持用那种字符界面加数字键盘操作。没有任何理由把柜员的终端改成Web Application——那多慢啊。

例子3，一个电厂监控系统

我们公司在北京有一个partner，做的产品是电厂和各种生产监控系统。他们的产品真的很不错。例如，可以在一个Win32 App的界面上看到一个很形象的大图，图上错落有致的排放着工厂里面所有的锅炉、管线、仪表等，每个锅炉或者管线边上都实时显示控制参数，例如锅炉的温度。如果温度过热，还可以变成红颜色。我问他们是怎么做的，他们说这是他们花了四五年时间积累下来的，都是用ActiveX开发的。

那天我去的目的之一是看看能不能有推广.NET技术的契合点。但看了他们的系统演示以后，我觉得如果我是技术主管，我坚决反对把那些积累了四五年的ActiveX控件升级到.NET——升级麻烦，也没必要。

--

最近这几个例子让我觉得，如果不根据实际情况一味单纯推.NET或者J2EE或者其他什么新东西，是对客户的一种不负责任。

IDS测试

一篇有关IDS测试方面技术文章的节选，仅仅是个人理解。初稿，估计错误和错字还不少。
欢迎提出建议
---------------------------------------------------
三. 如何进行关键IDS指标的量化测试
考虑到目前主流IDS厂商还是使用模式匹配的方式进行，因此，进行所谓行为异常方式的测试手段基本不太可行，而且考虑到需要对用户日常行为的建模和分析，这种测试的周期也会很长。
因此，目前我们通常使用攻击测试集来检查IDS的漏报情况，而误报则需要采用流量仿真或者现实环境测试的方式进行。
3.1 测试规则集
在近年的一些测试中，一些用户使用blade进行测试。由于blade内置了数百条攻击代码的特征，使得非专用的用户也能进行误报和规则涵盖方面的测试。但是我们并不认为blade是合适的IDS测试规则集（可参见下面的说明），只是相对而言，目前只有它可用而已。另外，测试规则集通常用于漏报率检测中，而不适用于误报率检测。
我们认为：一个合理的攻击代码测试集应该满足如下条件：
1. 广泛性：应该具备相当的攻击代码数量，并涵盖主流操作系统和主要应用。
2. 重要性：测试代码集中，应该以测试严重和重要级别的安全漏洞的代码为主，毕竟利用严重漏洞的攻击行为是用户最为关心的部分。
3. 时效性：选择的攻击代码应该是在2年内被发布出来的攻击代码特征。上面谈到的blade包含了不少3年前的攻击测试代码，而最新的测试代码比例又有限
4. 适用性：攻击代码能够确定在满足条件的情况下起到该有的攻击效果。一些攻击测试代码并不能起到真正攻击成功的作用，而仅仅只能用于测试是否存在漏洞。
规则测试集并不是exploit代码的集合，因为在实际测试中，测试者通常不可能搭建起完整支持测试这些exploit的环境。为了方便在各种环境下测试，多数情况下是采用tcpdump录制的完整的攻击过程中发生的流量，并在测试时使用tcpreplay进行回放发送。Tcpreplay完美的模拟了实际攻击过程中发生的流量和会话，很适合用于进行IDS的测试。另外，这种测试方法也不会出现私有攻击测试程序外流的问题。
3.2 误报率的测试
误报的定义：在IDS进行监控分析时，将正常的访问行为或者有意伪造的攻击行为（典型的是使用stick工具，而攻击实际并未发生）报告为攻击行为的情况，称之为误报。
常见可能引起误报的原因通常都是由于IDS规则撰写不严密或者错误引起，也有一些误报与产品使用的检测技术有一定关系。
例如：某IDS的规则描述中，没有进行了相应的协议分析，就人为连接某个特定端口的行为就是发生了利用某种后门的攻击行为。基于单包模式匹配的IDS引擎更容易出现误报的情况，针对IDS产品攻击的stick攻击就是利用早期nids引擎这方面的缺陷，制造大量的攻击告警噪音（误报），甚至拖垮IDS的探测引擎。
误报的测试比较难于进行，因为实验室中很难模拟出真实的网络环境，而无法触发比较完整的误报情况。因此，我认为可行的方式包括：条件有些的情况下，使用sniffer捕获真实环境下的100G左右的数据，如果可能建议在不同的应用环境下进行捕获，典型的我认为应该包括(当然可以分得更为细致)：
 互联网混合应用－多平台虚拟主机或者IDC出口的流量是合适的。
 OA应用－企业内网环境下的正常流量。
 电信骨干－多业务承载平台上的流量。
一方面可以用于在实验室环境下进行流量仿真，另一方面，在IDS的性能测试中，还可以用来进行真实背景流量的生成。
另外一种方式可能效果更好，但是需要特殊的环境。我们可以考虑在真实环境下搭建一个NIDS测试平台（流量在待测IDS的负载范围内），同时加载全部待测NIDS探测引擎。

两种方式相比，各有优缺点：
 仿真测试可重复性高，多个产品进行测试可以线性进行，而不影响测试公正。用于专门的产品测评机构是最为合适的方式。但是测试结果受仿真采样的影响很大，不合适的采样流量或者采样空间太小，测试结果可能和实际应用结果有较大偏离。
 真实环境测试必须进行并行进行，如果采用线性方式，顺序放置IDS引擎轮流测试，由于真实环境的随时变化，发生的流量也不同，可能引起测试结果偏差和争议。优点是在真实环境中，可以进行足够的流量采样，更贴近与用户应用的真实指标，此方法用在具体的项目选型中是比较好的。

无论采用真实环境测试还是进行流量仿真环境的误报率测试，测试时均需要采用同一策略
具体测试步骤建议如下：
【略】

误报率=（确认误报条数＋争议误报条数x权重）/告警总数x100%

注1：考虑到各个IDS产品的可检测数目指标不同，如果都全部加载规则，在误报测试中就有可能对检测规则集较大的产品不公正 －因为规则数目越多的产品，在同等NIDS实现技术情况下，出现误报的可能性越大，因此加载全部检测规则的方式应该用于漏报测试中。
注2：【略】
注3：【略】
3.3 漏报率的测试
和误报率指标不同，我们认为漏报率的测试应该有两个指标：绝对漏报率和相当漏报率。
1.绝对漏报：使用规则测试集发起确定的攻击流量，但IDS系统未能报告此攻击
产生绝对漏报的原因包括：
 IDS没有检测此攻击的规则。
 IDS有关此攻击的规则制作错误，无法正确判断攻击，放过了攻击代码
但是有一点需要指出的是，部分基于异常检测技术的IDS能够对未知（即此IDS并没有专门针对此攻击的检测规则）进行告警，只要能够报告出异常（未指明具体的攻击名称），我们也可认为是一个成功准确的告警。
因此，很容易我们可以知道：
绝对漏报率＝漏报规则数的目/测试规则总数目 x100%

注：任何一个IDS系统都不能保证其全部规则是基于攻击原理检测，因此肯定会出现绝对漏报的情况。

2.相对漏报：正常网络环境下能够准确报告攻击的发生，但是在某些特定情况下无法正常告警的漏报情况。
产生相对漏报的原因主要是以下几种
 IDS引擎实现有问题，无法进行完整的TCP重组，使得利用TCP分片发送攻击frageroute发起的攻击可以逃过IDS的检测。如果能够利用此类工具使得某种IDS系统无法检测到攻击，那么应该来说，此种IDS具有重大的技术缺陷，在这些情况下，漏报可以说是100%。
 攻击测试使用URL编码工具Whisker对CGI的攻击代码进行等效变形，如果IDS引擎编写没有考虑到这些编码或者等效因素，将产生漏报。
 测试代码使用ADMmutate对溢出攻击的shellcode进行编码，仅仅依靠shellcode特征检测的IDS可能发生漏报。
 因为性能原因，虽然正常情况下能够报告此攻击，但是在一定流量压力下，IDS引擎开始丢包，无法重组会话或者遗漏关键的特征报文而漏报此攻击行为。因此，测试相对漏报时，必须要有流量背景作为漏报率的参考值。

从目前的主流IDS技术来看，没有一个产品能够做得100%无绝对漏报，即使是相对漏报率，同样也不可能达到0%，严格来说，如果采用逃避，部分IDS甚至可能完全不能检测真正有效的攻击。

由于上面一些可能造成逃避IDS技术的存在，相对漏报率比较难于衡量。例如，某种IDS在正常环境下漏报率假如是20%，但是由于引擎设计问题，一旦加入fragroute技术的攻击测试时，可能一条也无法报警，也就是说漏报率为100%，那么最终指标如何计算？
针对这种情况，我们建议测试时分别考虑，同样给出两个测试结果。分别是不加入变形测试时，不同流量背景下的标准相对误报率；另一个是使用3种IDS逃避技术情况下的严格相对漏报率。标准相对误报率的测试比较容易进行。此处不详细描述，对于严格相对漏报率的测试，建议步骤如下：
1． 背景流量的选择，虽然可以使用包发生器（如smartbit和IXIA等）产生背景流量，但是又可能引入复杂的包大小因素（详见IDS性能测试章节），建议从简化的角度来进行，使用在误报率测试中使用的标准背景流量，通过多台主机使用tcprelay参数控制发送速率，产生不同的背景流量级别。
【略】

某流量压力下严格相对误报率=(fragroute技术实际总报告条数/测试规则数目x参数数目)x33%+(Whiske技术实际总报告条数/测试规则数目x参数数目)x33%
+(ADMmutate技术实际总报告条数/测试规则数目x参数数目)x33%

也就是说，实际考核IDS的漏报率指标应该为：
某流量负载下，不加入变形或者分片等逃避IDS检测的技术
标准漏报率＝绝对漏报率x标准相对漏报率
严格漏报率＝绝对漏报率x严格相对漏报率

最终的漏报率指标表可能如下：
Xx产品漏报指标 标准漏报率 严格漏报率
10%流量压力 绝对漏报率x标准相对漏报率 绝对漏报率x严格相对漏报率
25%流量压力
50%流量压力
75%流量压力
95%流量压力


大多数情况下，误报率和漏报率是相互矛盾的，为了降低误报率，那么规则需要特别严格，一不小心就有可能增加了漏报的情况，提高漏报率；为了降低漏报率而放宽规则的严密性或者加入异常检测技术，又往往带来误报率的上升。另外，任何希望同时降低误报率和漏报率的努力，都会带来大量的开发投入，多数情况下还会造成性能的下降。因此入侵检测系统都是需要根据自身的特点和设计目标在误报率和漏报率中选择一个平衡。

另外，我们可以看到，如果严格按照上面的方式进行测试，需要较长的周期和大量的准备和事后分析工作，通常个人、甚至小的公司都无法组织一次全面测试。

---------------------------------------------------

在国外近年的一些测试中，我们看到真正专业的一些测试方法和过程，而不是目前在国内很多产品选型测试中各个厂商各显神通去影响测试方案。如果有哪位朋友有资源组织一次公正的第三方测试或者希望开发规范的IDS测试方案，欢迎和我联系。

构建免受fso威胁虚拟主机

构建免受fso威胁虚拟主机
现在绝大多数的虚拟主机都禁用了 ASP 的标准组件：FileSystemObject，因为这个组件为 ASP 提供了强大的文件系统访问能力，可以对服务器硬盘上的任何文件进行读、写、复制、删除、改名等操作（当然，这是指在使用默认设置的 Windows NT / 2000 下才能做到）。但是禁止此组件后，引起的后果就是所有利用这个组件的 ASP 将无法运行，无法满足客户的需求。
　　如何既允许 FileSystemObject 组件，又不影响服务器的安全性（即：不同虚拟主机用户之间不能使用该组件读写别人的文件）呢？这里介绍本人在实验中获得的一种方法，下文以 Windows 2000 Server 为例来说明。
　　在服务器上打开资源管理器，用鼠标右键点击各个硬盘分区或卷的盘符，在弹出菜单中选择“属性”，选择“安全”选项卡，此时就可以看到有哪些帐号可以访问这个分区（卷）及访问权限。默认安装后，出现的是“Everyone”具有完全控制的权限。点“添加”，将“Administrators”、“Backup Operators”、“Power Users”、“Users”等几个组添加进去，并给予“完全控制”或相应的权限，注意，不要给“Guests”组、“IUSR_机器名”这几个帐号任何权限。然后将“Everyone”组从列表中删除，这样，就只有授权的组和用户才能访问此硬盘分区了，而 ASP 执行时，是以“IUSR_机器名”的身份访问硬盘的，这里没给该用户帐号权限，ASP 也就不能读写硬盘上的文件了。
　　下面要做的就是给每个虚拟主机用户设置一个单独的用户帐号，然后再给每个帐号分配一个允许其完全控制的目录。
　　如下图所示，打开“计算机管理”→“本地用户和组”→“用户”，在右栏中点击鼠标右键，在弹出的菜单中选择“新用户”：
op_stop(); ;op_start();
　　在弹出的“新用户”对话框中根据实际需要输入“用户名”、“全名”、“描述”、“密码”、“确认密码”，并将“用户下次登录时须更改密码”前的对号去掉，选中“用户不能更改密码”和“密码永不过期”。本例是给第一虚拟主机的用户建立一个匿名访问 Internet 信息服务的内置帐号“IUSR_VHOST1”，即：所有客户端使用 http://xxx.xxx.xxxx/ ;访问此虚拟主机时，都是以这个身份来访问的。输入完成后点“创建”即可。可以根据实际需要，创建多个用户，创建完毕后点“关闭”：
op_stop(); ;op_start();
现在新建立的用户已经出现在帐号列表中了，在列表中双击该帐号，以便进一步进行设置：
op_stop(); ;op_start();
在弹出的“IUSR_VHOST1”（即刚才创建的新帐号）属性对话框中点“隶属于”选项卡：
op_stop(); ;op_start();
刚建立的帐号默认是属于“Users”组，选中该组，点“删除”：
op_stop(); ;op_start();
　　现在出现的是如下图所示，此时再点“添加”：
op_stop(); ;op_start();
在弹出的“选择 组”对话框中找到“Guests”，点“添加”，此组就会出现在下方的文本框中，然后点“确定”：
op_stop(); ;op_start();
　　出现的就是如下图所示的内容，点“确定”关闭此对话框：
op_stop(); ;op_start();
　　打开“Internet 信息服务”，开始对虚拟主机进行设置，本例中的以对“第一虚拟主机”设置为例进行说明，右击该主机名，在弹出的菜单中选择“属性”：
op_stop(); ;op_start();
　　弹出一个“第一虚拟主机 属性”的对话框，从对话框中可以看到该虚拟主机用户的使用的是“F:\VHOST1”这个文件夹：
op_stop(); ;op_start();
　　暂时先不管刚才的“第一虚拟主机 属性”对话框，切换到“资源管理器”，找到“F:\VHOST1”这个文件夹，右击，选“属性”→“安全”选项卡，此时可以看到该文件夹的默认安全设置是“Everyone”完全控制（视不同情况显示的内容不完全一样），首先将最将下的“允许将来自父系的可继承权限传播给该对象”前面的对号去掉：
op_stop(); ;op_start();
此时会弹出如下图所示的“安全”警告，点“删除”：
op_stop(); ;op_start();
　　此时安全选项卡中的所有组和用户都将被清空（如果没有清空，请使用“删除”将其清空），然后点“添加”按钮。
op_stop(); ;op_start();
　　将如图中所示的“Administrator”及在前面所创建的新帐号“IUSR_VHOST1”添加进来，将给予完全控制的权限，还可以根据实际需要添加其他组或用户，但一定不要将“Guests”组、“IUSR_机器名”这些匿名访问的帐号添加上去！
op_stop(); ;op_start();
　　再切换到前面打开的“第一虚拟主机 属性”的对话框，打开“目录安全性”选项卡，点匿名访问和验证控制的“编辑”：
op_stop(); ;op_start();
　　在弹出的“验证方法”对方框（如下图所示），点“编辑”：
op_stop(); ;op_start();
　　弹出了“匿名用户帐号”，默认的就是“IUSR_机器名”，点“浏览”：
op_stop(); ;op_start();
　　在“选择 用户”对话框中找到前面创建的新帐号“IUSR_VHOST1”，双击：
op_stop(); ;op_start();
　　此时匿名用户名就改过来了，在密码框中输入前面创建时，为该帐号设置的密码：
op_stop(); ;op_start();
　　再确定一遍密码：
op_stop(); ;op_start();
　　OK，完成了，点确定关闭这些对话框。
　　经此设置后，“第一虚拟主机”的用户，使用 ASP 的 FileSystemObject 组件也只能访问自己的目录：F:\VHOST1 下的内容，当试图访问其他内容时，会出现诸如“没有权限”、“硬盘未准备好”、“500 服务器内部错误”等出错提示了。
　　另：如果该用户需要读取硬盘的分区容量及硬盘的序列号，那这样的设置将使其无法读取。如果要允许其读取这些和整个分区有关的内容，请右键点击该硬盘的分区（卷），选择“属性”→“安全”，将这个用户的帐号添加到列表中，并至少给予“读取”权限。由于该卷下的子目录都已经设置为“禁止将来自父系的可继承权限传播给该对象”，所以不会影响下面的子目录的权限设置。

我们应该如何面试程序员/技术人员？

看到我在GTEC的同事的一封email，说的是他在面试别人的时候一些心得。其中有这么一段话，写得非常好：

在以后的面试中，建议大家认真阅读应聘者的简历，在应聘者擅长的领域里去问问题，去了解应聘者在软件技术支持方面的潜力。避免问一些只有我们自己才可能知道答案的技术问题，并以能不能答得上来为标准进行取舍。

我曾经犯过这样的错误。我在GTEC工作最初的大半年时间里面，我学了很多很多微软的东西，包括编程的、包括产品的，长进极大。也同样是在那段时间前后，我发现我对几乎所有的被我面试的人（大部分是大四或者研二的实习生）的comment都是“技术很一般”或者类似评语。突然有一天我发现了这个情况，当时就想通了一个道理：我当初应聘微软时的水平，未必比现在那些被我评价为“技术一般”的应聘者的水平高。

我还犯过一个错误。去年（可能是前年了，忘了），当时我们招实习生，为开发一些内部的Web平台招。最后剩下两个，A和B。A在面试时对ASP.NET、CSharp以及SQL的一些中等级别的技术问题答得很不错；B只对ASP有经验，对.NET还刚刚入门。当时我选择了A，选择的理由是技术不错，来之能战。而B去了另外一个team，也是做ASP.NET的开发。结果我发现，开始工作后，与A的交流非常困难，缺乏commitment和accountability，对take ownership的理解也很差，缺乏主动性，技术上遇到了阻碍也不向别人咨询；而B在另一个team融入得非常好，交给他的工作总是能按时完成，.NET的技术也很快补上了，至少足够用了。

从这个错误里面我学到的东西是：千万别太看重技术。技术是可以学的，没有任何技术是一两个月学不会的——那时候我头一次到CSDN答帖子做支持的时候，刚刚接触C#才两个礼拜；相比之下，人品、commitment & accountability、沟通能力、提问技巧、quick learning等，却是无法在几个月内迅速改变的。类似的，如果招一个Consultant，也应该更看重对行业的了解，而不是看重对产品的了解。产品知识容易学，行业经验积累就难了。

因此，面试程序员/技术人员的时候，最关键（也是最难的）是看应聘者的“人品”（广义的）。尤其是对于像微软这种公司来说，更是如此。因为如果单论技术，恐怕任何应聘者的技术都是不qualified的。比如说，测试方面，本来嘛，微软产品组的测试就已经做的非常好了，在整个业界是领先的，而且大大领先于国内软件业的测试水平，因此，从国内招人招不到合格的测试工程师是很正常的——反之倒是不正常的：如果国内高水平的测试工程师很多，那么国内的软件测试水平也不会是现在这个样子了。同样道理，对于一些微软的技术来说（比如Windows操作系统，比如.NET，一些具体的实现，比如CLR上的），微软产品组和技术支持部门的人一定是最牛的，因为本身这些技术就是他们自己公司的同事搞出来的，他们能够比外部获得多得多的资料（包括文档、问题集、培训材料等）。因此，如果觉得来应聘的人对操作系统或者程序语言的原理懂得不多，那是很正常的。

还是回到我同事那段话："建议大家认真阅读应聘者的简历，在应聘者擅长的领域里去问问题，去了解应聘者在软件技术支持方面的潜力。避免问一些只有我们自己才可能知道答案的技术问题，并以能不能答得上来为标准进行取舍"。

别让老板毁了你的一生

一、 在大公司就职很容易被优越的环境腐蚀，大公司的待遇和名气很容易让在职的员工产生一种惰性，喝酒、娱乐等成为这些高薪员工的第一消遣方式，时间久了，为了保持自己的“地位”就开始与上级的领导进行一些“礼”尚往来，这招也确实有效果，让一个人在一个高职位 任期延长一两年甚至近十年，可就是这短短的几年，就容易毁了你一生；

二、 大公司很容易让人产生一种飘飘然的感觉，大的公司，因为每年有整体的广告宣传以及多年的老用户、老顾客的支持，稍微的努力，成功的机会要比自己新开一家公司容易的多，为此很多在大公司业绩好的人都有一种飘飘然的感觉，认为自己的能力很高，结果在日新月异的 市场中自己的能力开始悄然的下降，自己却浑然不觉；

三、 在一家公司就职（不论公司的大小），如果超过3年，还在一个职位上，你就有可能在日后的职业生涯中面临更困难的抉择，除非你的工作性质是一般的普通职员，不需要更深入的了解市场。如果是市场营销和策划这些职位，你必须赶紧的反思自己，否则，可能你会让你的 老板给“毁”了。社会对人才的需求是知识面越广泛越好，能力越强越好（当然前提是你先有自己的一技之长），在一个公司耗的久了，容易让人对外面的世界恐惧，如此形成恶性循环，就可怕喽！

正确的面对自己目前的公司和老板的发展思路，更要明确的分析自己目前的工作现状，你一定要给自己制定一个良好的个人发展规划，万不可疏忽，万不可耽误，因为市场往往和你的老板一样的“无情”。