关于修复WordPress固定链接的改变/迁移 (Change Permalink Migration)

当服务器迁移,需要更换WordPress地址路径时,或是导入了新数据时,会遇到固定链接 改变,文章ID也不正确的情况。

我们需要修正这个问题,以我一些经验为例:

 

例如,我在迁移服务器后,且又多次导入了几个时期分别备份的数据后:

(原URL):http://bohu.net/wp/2006/07/197,orz-and-wtf/  变成了 (新URL)http://bohu.net/blog/197

原文件夹是 wp 新文件夹为 blog

 

设置转发(Redirect)

那么首先设置web服务器的重定向类型(Redirect Type),一般web服务器都支持一下3种Redirect:
301 – Permanent(永久)
302 – Temporary(临时)
303 – Replaced (替换)
详细参数说明,查看 维基百科 HTTP状态码 :3xx重定向
用   303 ,  Replaced  redirected (303)  重定向 wp 到 blog,
Local URL Path Type Redirect URL
/wp 303 http://bohu.net/blog

 

303 – Replaced 顾名思义,就是可以替换URL中的地址,而且正确的响应所传递的参数。? 号之后的参数不会丢失。

如: http://bohu.net/blog/post.php?post=1234&action=edit  303 替换为 http://bohu.net/wp/post.php?post=1234&action=edit

这样设置之后 访问 bohu.net/wp 就可以 转到 bohu.net/blog 了。

 

手动修复ID

但是元文章ID是197, 现在变为了2553,你如果用插件修复固定连接的话那么,可以忽略这一部分。

我尝试手动修复了ID。先下载插件 ”ShowID

下载插件:ShowID for Post/Page/Category/Tag/Comment – http://ounziw.com/2010/02/05/showid/

启用之后就可以在文章列表看到每篇文章的 ID 了。我没找到自动更改ID的插件,进数据库自己修改的。

这样 http://bohu.net/blog/197 就可以恢复访问到了。

 

修复固定链接改变/迁移

但是之前的固定连接 ”197,orz-and-wtf“ 为两个参数组合的,所以原URL还不能直接访问。

需要使用插件转发到新固定连接,我最先用的是 ”Advanced Permalinks“

下载插件:Advanced Permalinks – http://urbangiraffe.com/plugins/advanced-permalinks/

可以完成转发效果,不过发现设置有点不太简单化,而且我的翻页有问题。

下面是附带解决固定连接修改后翻页的问题。

翻页有问题     有时候翻到第二页或其他页不能正常工作,地址如下:
 http://www.example.com/page/2/  http://www.example.name/category/categoryname/page/2/  http://www.example/year/month/day/page/2/  http://www.example/year/month/page/2/
    访问上面的任何一个链接,出现提示说: “Sorry, no posts match that criteria.”
    这是.htaccess造成的,删掉,重新生成就好了。

看到”Advanced Permalinks“已经是2年未更新了,最后还是更换了插件为 ”Permalink Finder“。

下载插件:Permalink Finder –  http://www.blogseye.com/

启用”Permalink Finder“Permalink-Finder Options”菜单,我按照默认设置。

这样就自动化完成修复固定链接的改变/迁移了。设置基本上不需要多少的改变。

 

了解 URI, URL, and URN

url-300x197

  • URI:Uniform Resource Identifier,统一资源标识符;(RFC 3986)
  • URL:Uniform Resource Locator,统一资源定位符;(RFC 1738
  • URN:Uniform Resource Name,统一资源名称。(RFC 1737

URI可被视为定位符(URL),名称(URN)或两者兼备。统一资源名(URN)如同一个人的名称,而统一资源定位符(URL)代表一个人的住址。换言之,URN定义某事物的身份,而URL提供查找该事物的方法。

用于标识唯一书目的ISBN系统是一个典型的 URN 使用范例。例如,ISBN 0-486-27557-4(urn:isbn:0-486-27557-4)无二义性地标识出莎士比亚的戏剧《罗密欧与朱丽叶》的某一特定版本。

为获得该资源并阅读该书,人们需要它的位置,也就是一个 URL 地址。在类Unix操作系统中,一个典型的URL地址可能是一个文件目录,例如file:///home/username/RomeoAndJuliet.pdf。该URL标识出存储于本地硬盘中的电子书文件。因此,URL和URN有着互补的作用。

URL方案分类图。URL(定位符)和URN(名称)方案属于URI的子类,URI可以为URL或URN两者之一或同时是URI和URN。技术上讲,URL和URN属于资源ID;但是,人们往往无法将某种方案归类于两者中的某一个:所有的URI都可被作为名称看待,而某些方案同时体现了两者中的不同部分。


URI 标准

RFC3986,即“Uniform Resource Identifier (URI):Generic Syntax”,是一个 Internet Standard。 Request for Comments (RFC) 系列是著名的档案式文档系列,该系列构成了 Internet Engineering Task Force (IETF) 标准过程的主干。 在数以千计的 RFC 中,只有很少的部分,比如   TCP (RFC793) 以及 Internet Mail 格式 (RFC821) 和协议 (RFC822), 提高了整个 Internet Standard 的发展水平。 RFC3986 在  2005 年 1 月也提高了这个水平。

按照 URI 标准,上面的第一个例子 —— http://www.cisco.com/en/US/partners/index.html —— 实际上是一个 URI,并且它由以下几个组成部分:

th

  • 方案名 (http)

url(uniformresourcelocator)

  • 域名 (www.cisco.com)
  • 路径 (/en/US/partners/index.html)

thCA1OQ0FA

IETF 达成共识,共同管理该方案。Official IANA Registry of URI Schemes(请参阅 参考资料)中包括一些大家所熟悉的方案,如 httphttpsmailto,还有其他许多您可能熟悉或不熟悉的方案。

URI 路径像一个典型的文件路径名。URI 按照 UNIX® 的惯例采用了正下划线 (a/b/c),因为在 20 世纪 80 年代后期设计 URI 的时候, 在 Internet 上, UNIX 文化比 PC 文化更流行。正是那个时候,出现了几个用于访问远程文件的流行表示法。其中一个是 Ange-ftp, 它是用来编辑远程文件的 emacs 的一个扩展。它用路径名将主机名和用户名结合起来,以获取像/jbrown@freddie.ucla.edu:~mblack/这样的结果。为了跨机器进行命名,为 Web 开发的 URI 语法(按照非标准的 Apollo Domain UNIX)使用了双下划线符号,但是它也引入了方案语法,这样,来自许多不同协议的命名约定得到了统一。其中的一些例子有:

  • mailto:mbox@domain
  • ftp://host/file
  • http://domain/path

这里介绍的第二个例子是 www.yahoo.com/sports,它不是一个真正的 URI。 它是对 http://www.yahoo.com/sports 的一种方便的简写,是一种受流行的 Web 浏览器用户界面  (UI) 支持的格式。然而,不要再犯在 XSLT 中遗漏方案这样的错误,如下所示:

<xsl:include href="exslt.org/math/min/math.min.template.xsl" />

因为它将不会按照您期望的那样工作,除非您真的 在 XSLT 样式表之后引用 exslt.org 目录中的一个文件。XSLT 的 href 属性采用了一个 URI 引用,它可能是绝对引用,也可能是相对引用。以一个方案和一个冒号开始的 URI 引用是绝对引用;否则,该引用就是相对引用。相对的 URI 引用更像一个文件路径。例如,../noarch/config.xsd 也是一个相对的 URI 引用。

国际化的资源标志符

HTML 中的 href 属性采用了 URI 引用,这样讲有些过于简单。URI 和 URI 引用都是从有限的 ASCII 字符集合中得出的,并且 HTML 比它们更加国际化。事实上,对遵循 RFC3986 的注释的请求是符合 RFC3987 标准,即 Internationalized Resource Identifiers (IRI) 标准(请参阅 参考资料)。此规范在 IETF 标准化过程中没有它的前辈走的远,但是技术本身已是相当成熟,并被广泛部署。除了能够使用所有 Unicode 字符,而不是仅仅能够使用 ASCII 字符之外,IRI 和 URI 是完全一样的。像 URI一样,每个 IRI 都有一个相应的编码,以防需要在只接受 URI 的协议(比如 HTTP)中使用 IRI。

用 xml:base 重写基本 URI

通常, URI 引用与在哪种文档中发现它有关。如果使用基本 URI http://exslt.org/math/min/math.min.template.xsl 查看一个文档,并看到了一个 URI 引用 ../../random/random.xml,那么引用将扩展为 http://exslt.org/random/random.xml。在 HTML 中,您可以把一个 base 元素放在文档顶端来重写基本 URI。XML Base 规范(请参阅 参考资料)在 XML 中也提供了同样的功能。

考虑一个既可以用 file:/my/doc 访问也可以用 http://my.domain/doc 访问的文档。通常,当通过文件系统访问文档时,您可能希望这些引用像 #part2 那样扩展为 file:/my/doc#part2;而通过 HTTP 访问文档时,您可能希望 #part2 扩展为 http://my.domain/doc#part2。但是在 Resource Description Framework (RDF) 模式中,为了使一些组件正常工作,展开的形式必须保持不变。 XML Base 使这种扩展变得容易(参见清单 1)。

清单 1. RDF 中的展开形式

				
<rdf:RDF
  xmlns="&owl;"
  xmlns:owl="&owl;"
  xml:base="http://www.w3.org/2002/07/owl"
  xmlns:rdf="&rdf;"
  xmlns:rdfs="&rdfs;"
>
...
    <Class rdf:about="#Nothing"/>

在这个例子中,无论您是在哪里找到的那个文件,#Nothing 引用均被扩展为 http://www.w3.org/2002/07/owl#Nothing

好了,关于 URI、IRI 和 URI 引用的介绍就到此结束了。

URL 和 URN

设计 URI 的目的是让它起到名称和定位器的作用。当 IETF 用它们实现标准化的时候,它们就成了通常所说的 Uniform Resource Locators,并且另一项关于 Uniform Resource Names 的独立的工作也已经开始了。

对于 Internet 主机,名称和位置都有单独的标准。主机名和域名有相同的语法(例如,zork1.example.edu)。这些主机名通过 Domain Name System (DNS) 协议和类似 192.168.300.21 的地址相连。当主机改变了在网络中的位置或重新编号之后,这种间接的做法允许主机保留其名称。

Web 中偶尔中断的链接使 Web 地址从外观上看更像是一个位置,而不是一个名称,并且在 IEIF 社区中也出现了不同的观点:

  • URI:RFC1630,发布于 1994 年 6 月,被称为“Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web”(请参阅 参考资料)。它是一个Informational RFC  —— 也就是说,它没有获得社区的任何认可。
  • URL:RFC1738,发布于 1994 年 12 月, 被称为“Uniform Resource Locators”(请参阅 参考资料)。它是一个 Proposed Standard —— 也就是说,它是一个共识过程的结果,虽然它还没有经过测试,并成熟到足以成为一个完整的 Internet Standard。
  • URN:RFC1737,发布于 1994 年 12 月,被称为“Functional Requirements for Uniform Resource Names”(请参阅 参考资料)。

1997 年,紧随 Proposed Standard RFC2141(即 URN Syntax)之后发布了 RFC1737,它指定了另一个方案 —— urn: —— 来加入 http:ftp:和其他协议中。

最终的 URI Standard (RFC3986) 在 1.1.3 小节“URI, URL, and URN”中澄清了这一区别:

URI 可以进一步分为定位器、名称,或者二者兼具。术语“Uniform Resource Locator” (URL) 涉及的是 URI 的子集,除识别资源外,它还通过描述其最初访问机制(比如它的网络“位置”)来提供定位资源的方法。 术语“Uniform Resource Name” (URN) 在历史上曾用于引用“urn”方案 [RFC2141] 下的 URI,这个 URI 需要是全球惟一的,并且在资源不存在或不再可用时依然保持不变,对于其他任何拥有名称的一些属性的 URI,都需要使用这样的 URI。

对于单独的方案,没有必要将其分为仅仅是一个 “名称”或者是一个“定位器”。 来自任意特定方案的 URI 实例可能有名称或定位器的特征,或两者兼而有之, 这通常取决于标识符分配中的持久性和命名机构对其关注程度, 而不取决于其他方案的质量。未来的规范和相关的文档应当使用通用术语“URI”,而不是使用有更多限制的条目“URL”和“URN” [RFC3305]。

http://www.ibm.com/developerworks/cn/xml/x-urlni.html

 

附录(梳理归类):

其中,URL,URN是URI的子集,其区别如下: Web上地址的基本形式是URI,它代表统一资源标识符,有两种形式: URL:目前URI的最普遍形式就是无处不在的URL或统一资源定位器。 URN:URL的一种更新形式,统一资源名称(URN, Uniform Resource Name)不依赖于位置,并且有可能减少失效连接的个数。但是其流行还需假以时日,因为它需要更精密软件的支持。

参考:http://www.cnlei.org/blog/article.asp?id=356

URN 站点 : http://purl.org/ | http://www.doi.org/demos.html

 

[文章部分内容引用地址] :

http://blog.sina.com.cn/s/blog_5c4a1a800100gxke.html

[分清 URI、URL 和 URN] http://www.ibm.com/developerworks/cn/xml/x-urlni.html

 

P.S. :  http://,https://,mms://,ftp://,rtsp://,ssl://,sftp://,pnm://,rtmp://等协议, 又如 thunder迅雷 , flashget快车 &&QQ旋风等.

thunder://类似的协议是base64编码加密。

 

URL Shortener Site List

来自:P.S. Let.Me.Show.You.The.Way作者:enet

 

短网址列表/ short URL List /短网址网站列表 /URL Shortener Site List

x.co
micurl.com
tinyurl.com
bit.ly
is.gd
goo.gl
flic.kr
icio.us
yhoo.it
tiny.cc
itee.in
sl.ly
url.ie
bu.tt
rfr.me
ity.im
lt.tl
p.ly
j.mp
to.ly
flaturl.com
url.cn
sinaurl.cn

Windows Internet 服务器安全配置

Windows Internet服务器安全配置

原理篇

我们将从入侵者入侵的各个环节来作出对应措施
一步步的加固windows系统.
加固windows系统.一共归于几个方面
1.端口限制
2.设置ACL权限
3.关闭服务或组件
4.包过滤
5.审计

我们现在开始从入侵者的第一步开始.对应的开始加固已有的windows系统.

 

1.扫描
这是入侵者在刚开始要做的第一步.比如搜索有漏洞的服务.
对应措施:端口限制
以下所有规则.都需要选择镜像,否则会导致无法连接
我们需要作的就是打开服务所需要的端口.而将其他的端口一律屏蔽

2.下载信息
这里主要是通过URL SCAN.来过滤一些非法请求
对应措施:过滤相应包
我们通过安全URL SCAN并且设置urlscan.ini中的DenyExtensions字段
来阻止特定结尾的文件的执行

3.上传文件
入侵者通过这步上传WEBSHELL,提权软件,运行cmd指令等等.
对应措施:取消相应服务和功能,设置ACL权限
如果有条件可以不使用FSO的.
通过 regsvr32 /u c:\windows\system32\scrrun.dll来注销掉相关的DLL.
如果需要使用.
那就为每个站点建立一个user用户
对每个站点相应的目录.只给这个用户读,写,执行权限,给administrators全部权限
安装杀毒软件.实时杀除上传上来的恶意代码.
个人推荐MCAFEE或者卡巴斯基
如果使用MCAFEE.对WINDOWS目录所有添加与修改文件的行为进行阻止.

4.WebShell
入侵者上传文件后.需要利用WebShell来执行可执行程序.或者利用WebShell进行更加方便的文件操作.
对应措施:取消相应服务和功能
一般WebShell用到以下组件
WScript.Network
WScript.Network.1
WScript.Shell
WScript.Shell.1
Shell.Application
Shell.Application.1
我们在注册表中将以上键值改名或删除
同时需要注意按照这些键值下的CLSID键的内容
从/HKEY_CLASSES_ROOT/CLSID下面对应的键值删除

5.执行SHELL
入侵者获得shell来执行更多指令
对应措施:设置ACL权限
windows的命令行控制台位于\WINDOWS\SYSTEM32\CMD.EXE
我们将此文件的ACL修改为
某个特定管理员帐户(比如administrator)拥有全部权限.
其他用户.包括system用户,administrators组等等.一律无权限访问此文件.

6.利用已有用户或添加用户
入侵者通过利用修改已有用户或者添加windows正式用户.向获取管理员权限迈进
对应措施:设置ACL权限.修改用户
将除管理员外所有用户的终端访问权限去掉.
限制CMD.EXE的访问权限.
限制SQL SERVER内的XP_CMDSHELL

7.登陆图形终端
入侵者登陆TERMINAL SERVER或者RADMIN等等图形终端,
获取许多图形程序的运行权限.由于WINDOWS系统下绝大部分应用程序都是GUI的.
所以这步是每个入侵WINDOWS的入侵者都希望获得的
对应措施:端口限制
入侵者可能利用3389或者其他的木马之类的获取对于图形界面的访问.
我们在第一步的端口限制中.对所有从内到外的访问一律屏蔽也就是为了防止反弹木马.
所以在端口限制中.由本地访问外部网络的端口越少越好.
如果不是作为MAIL SERVER.可以不用加任何由内向外的端口.
阻断所有的反弹木马.

8.擦除脚印
入侵者在获得了一台机器的完全管理员权限后
就是擦除脚印来隐藏自身.
对应措施:审计
首先我们要确定在windows日志中打开足够的审计项目.
如果审计项目不足.入侵者甚至都无需去删除windows事件.
其次我们可以用自己的cmd.exe以及net.exe来替换系统自带的.
将运行的指令保存下来.了解入侵者的行动.
对于windows日志
我们可以通过将日志发送到远程日志服务器的方式来保证记录的完整性.
evtsys工具(https://engineering.purdue.edu/ECN/Resources/Documents)
提供将windows日志转换成syslog格式并且发送到远程服务器上的功能.
使用此用具.并且在远程服务器上开放syslogd,如果远程服务器是windows系统.
推荐使用kiwi syslog deamon.

我们要达到的目的就是
不让入侵者扫描到主机弱点
即使扫描到了也不能上传文件
即使上传文件了不能操作其他目录的文件
即使操作了其他目录的文件也不能执行shell
即使执行了shell也不能添加用户
即使添加用户了也不能登陆图形终端
即使登陆了图形终端.拥有系统控制权.他的所作所为还是会被记录下来.

额外措施:
我们可以通过增加一些设备和措施来进一步加强系统安全性.
1.代理型防火墙.如ISA2004
代理型防火墙可以对进出的包进行内容过滤.
设置对HTTP REQUEST内的request string或者form内容进行过滤
将SELECT.DROP.DELETE.INSERT等都过滤掉.
因为这些关键词在客户提交的表单或者内容中是不可能出现的.
过滤了以后可以说从根本杜绝了SQL 注入
2.用SNORT建立IDS
用另一台服务器建立个SNORT.
对于所有进出服务器的包都进行分析和记录
特别是FTP上传的指令以及HTTP对ASP文件的请求
可以特别关注一下.

本文提到的部分软件在提供下载的RAR中包含
包括COM命令行执行记录
URLSCAN 2.5以及配置好的配置文件
IPSEC导出的端口规则
evtsys
一些注册表加固的注册表项.

实践篇

下面我用的例子.将是一台标准的虚拟主机.
系统:windows2003
服务:[IIS] [SERV-U] [IMAIL] [SQL SERVER 2000] [PHP] [MYSQL]
描述:为了演示,绑定了最多的服务.大家可以根据实际情况做筛减

1.WINDOWS本地安全策略 端口限制
A.对于我们的例子来说.需要开通以下端口
外->本地 80
外->本地 20
外->本地 21
外->本地 PASV所用到的一些端口
外->本地 25
外->本地 110
外->本地 3389
然后按照具体情况.打开SQL SERVER和MYSQL的端口
外->本地 1433
外->本地 3306
B.接着是开放从内部往外需要开放的端口
按照实际情况,如果无需邮件服务,则不要打开以下两条规则
本地->外 53 TCP,UDP
本地->外 25
按照具体情况.如果无需在服务器上访问网页.尽量不要开以下端口
本地->外 80
C.除了明确允许的一律阻止.这个是安全规则的关键.
外->本地 所有协议 阻止

2.用户帐号
a.将administrator改名,例子中改为root
b.取消所有除管理员root外所有用户属性中的
远程控制->启用远程控制 以及
终端服务配置文件->允许登陆到终端服务器
c.将guest改名为administrator并且修改密码
d.除了管理员root,IUSER以及IWAM以及ASPNET用户外.禁用其他一切用户.包括SQL DEBUG以及TERMINAL USER等等

3.目录权限
将所有盘符的权限,全部改为只有
administrators组 全部权限
system 全部权限
将C盘的所有子目录和子文件继承C盘的administrator(组或用户)和SYSTEM所有权限的两个权限
然后做如下修改
C:\Program Files\Common Files 开放Everyone 默认的读取及运行 列出文件目录 读取三个权限
C:\WINDOWS\ …