路由跟踪显示的defense.gov (DoD Network) IP地址

今天在讨论板看到有人提到这个为什么阿里云主机跟踪路由会出现类似defense.gov或者DoD Network所有者的IP地址,搜索了网络发现有价值的信息不多,思科技术论坛上有这么一个帖子《An IP address of USA Department of Defense Network Information Center in debug output of a router》有网友提到由于历史原因,有些特殊的IP段是专门分配给军方使用的,不知是出于内网保密需要或者其他什么原因无法从公共互联网(Internet)上访问这些特殊的IP段,这些IP段因此被某些大型网络供应商来弥补内网IP地址的不足。我猜测可能因为使用这些IP地址段的军方似乎永远不会将其发布到公共网络上,所以将这些IP地址仅仅用于内网的用法也不会造成Internet外网混乱。

比如美国军方拥有的一部分IP地址段就有:6.0.0.0/8, 7.0.0.0/8, 11.0.0.0/8, 21.0.0.0/8, 22.0.0.0/8, 26.0.0.0/8, 28.0.0.0/8, 29.0.0.0/8, 30.0.0.0/8, 33.0.0.0/8, 55.0.0.0/8, 214.0.0.0/8, 215.0.0.0/8,这些IP地址虽然是公共IP但是基本上被用于军方内网,查询IP数据库显示defense.gov或者DoD Network所有,如果某个网络管理员仅仅将这些IP地址配置为内网IP并不发布出去的话,对于正常访问Internet互联网没有任何影响。当然如果你的内网网络和Internet互联网是物理隔离的话,分配IP地址是什么样的都不重要,最后看的还是网络基础设施的配置,比如路由表转发等等。

继续阅读

代理SMTPS 465端口完成邮件sendmail配置备忘

之前一直使用AWS SES (Simple Email Service)作为邮件发送后端,按照官方说明配置,测试下来能收到就以为配置没有问题了。直到最近某短信邮件联动端只提示收到短信而没有邮件,这才发现SES存在丢件情况,我是配置的QQ邮箱作为接收端,通过QQ邮箱的自助查询,找到了收件丢失的原因:对于AWS来说邮件是正常投递成功(这一点后台统计也有说明),关键在于QQ邮箱,其拒收了来自AWS的邮件,理由是:

Action: failed
Final-Recipient: rfc822;
Diagnostic-Code: smtp; 550 Ip frequency limited [******** = Blocked IP 54.240.7.20]. http://service.mail.qq.com/cgi-bin/help?subtype=1&id=20022&no=1000725
Status: 5.3.0

字面上看是因为该发信IP频率过高因此被屏蔽,可能是因为AWS SES和他人共享了发信IP导致的,当然,通过链接查询到的原因证实了猜想。

继续阅读

BIND9 DNS Challenge自动配置Letsencrypt通配符(Wildcard)HTTPS证书

不得不说Letsencrypt的免费SSL数字证书确实大力促进了加密HTTP(HTTPS)的普及,使用HTTPS的好处自然有很多,比如防止登录凭据等敏感信息被第三方窃取、防止电信运营商的ISP劫持等,Google Chrome和Mozilla Firefox也在逐步将明文HTTP标识为不安全,这也在一定程度上加快了HTTPS的推广。

但是由于一些条件限制,国内的HTTPS推广普及一直不温不火,虽然大部分主流网站已经采用了HTTPS,但是大量的中小型网站、政府门户依然使用的是明文HTTP,给个人信息带来安全隐患,不使用HTTPS的理由总是有千百种,比如虚拟主机限制、CDN限制、老旧浏览器兼容、服务器资源消耗等,但是我们不能因为这些缘故而放弃HTTPS带来的优势,从长远来看HTTPS的全面普及是势不可挡的。

继续阅读

100.64.0.1运营商级(Carrier-grade)NAT保留IP地址

在一次跟踪路由的网络操作时发现自己路由器下一跳路由节点的IP地址比较奇怪,是100.64.0.1。好奇促使我查询了这个IP地址的归属,结果是保留地址,到这里觉得比较奇怪了,按照常理以IPv4为例保留的IP地址一般为以下几种,常用于内网通讯或者特殊用途:

地址块起始结束备注
10.0.0.0/810.0.0.010.255.255.255局域网分配
172.16.0.0/12172.16.0.0172.31.255.255局域网分配
192.0.0.0/24192.168.0.0192.168.255.255局域网分配
169.254.0.0/16169.254.0.0169.254.255.255两台主机对等连接,当Windows获取不到IP地址的时候会自动分配此类地址
127.0.0.0/8127.0.0.0127.255.255.255回环(loopback)地址,表示本机
255.255.255.255/32255.255.255.255255.255.255.255广播地址

继续阅读

解决DNSMASQ内网地址无法解析No address (A) records available

部署DNSMASQ有一段时间了,最近发现一个奇怪现象,所有内网网站均无法解析,通过nslookup命令,得到如下结果:

Server:  192.168.24.6
Address:  223.5.5.5

*** No address (A) records available for oa.example.com

其中oa.example.com是内网域名,当然这里我只是举个例子:-) 域名管理员已经将该域名解析到一个私有内网地址上,外部DNS服务器均能正常解析这个域名,唯独部署了DNSMASQ的域名服务器无法解析。

开始时并没有介意,而是通过硬绑定的方式在DNSMASQ的配置文件中将内网地址映射到oa.example.com,配置方式如下:

address=/oa.example.com/192.168.25.4

继续阅读

iptables劫持并拦截DNS查询53端口实现转向(Redirect)

企业内网中经常会有这样的需求,比如说业务服务器的IP地址为192.168.6.25,大家也就习惯于访问这个地址了,运维也很厚道的将某个域名解析到这个IP地址,这样大家也就不必记住繁琐的IP地址,同时运维也很方便的将业务服务器由192.168.6.25的主机迁移到192.168.6.26的主机而无需通知客户端更改地址,这也是域名发挥的作用,好了,现在问题来了:-)

客户说我们企业很小,不想另外购买域名,好吧,每年五十几块也是一笔费用,而且购买域名后还需要有人维护,比如要记得续费什么的,略麻烦。同样的还觉得将内网地址公布到外网上不是安全的行为。

经过我的询问得知该企业拥有一台自建的DNS服务器,为全网提供DNS查询,那这事情就好办多了,对DNS服务器软件硬绑定指定的域名到IP地址的记录(由于是我们自己的DNS服务器,这里的域名可以任意设置,当然最好设置为公网上没有的域名地址以避免冲突)。

继续阅读

检测并修复OpenSSL Heartbleed漏洞

这个漏洞已经出来好长时间了,自己也一直没有能够引起重视,今天看到有一款扫描检测工具CROWDSTRIKE HEARTBLEED SCANNER可以检查主机是否存在此类漏洞,然后就下载下来试了试,结果本博客直接躺枪。想想还是别拖着了,遂动手修复,其实修复的过程很简单,这里简要说明如下:

由于我使用的是Debian系统,所以这里主要记录的是Debian系统下的OpenSSL升级。

对于图省事的朋友来说,下面的命令可以轻松解决大多数问题:

sudo apt-get update
sudo apt-get upgrade

这两句命令其中第二句将升级系统中所有可更新的软件,但是有过之前惨痛的服务器升级经历后我觉得还是不能轻举妄动,所以再查阅网络后我采取特定升级的方法:

sudo apt-get update
sudo apt-get install openssl libssl1.0.0

继续阅读

网络安全与个人隐私

最近又开始瞎忙起来了,现在正好在迁移服务器数据,网速龟慢,上次和同事讨论如何神不知鬼不觉的发帖子,一般技术宅肯定是找各种代理,然后用代理作为中转,这样真实的IP就会被隐藏,但是某些部门通过技术手段依旧可以追踪到你,因为他们可以知道你是什么时候登录的代理。好吧,问题在这里就复杂了,其实国外的项目Tor就是为匿名访问而诞生的,其主要的原理就是通过多个复杂节点分散流量达到混淆隐藏真实主机的目的,可惜的是因为某些原因Tor在国内无法正常使用。也想到通过肉鸡进行二次乃至多次代理来加大追踪难度,但是这实际上也导致自己操作变得困难,想想目前的网速,得不偿失,最后讨论的结果是:到地摊上购买一张匿名的手机卡(貌似现在都是实名的了),然后买个能上网的手机(便宜一点,最好非智能机),然后到某处蹭个WiFi,然后用手机上网发帖,完事后销毁手机和卡,这样看来确实天衣无缝,但是同事的一句话给我泼了冷水:你有没有考虑过公共场所星罗密布的监控探头?好吧,看来这条路子也是有风险的。

继续阅读

无线路由器安全与DNS设置

前一段时间央视曝光多家路由器存在后门和漏洞,不乏有Cisco(思科)、NetGear(网件)这样的大牌子,话说Cisco路由器的品质确实给我留下了深刻的印象,这里我就路由器安全随便谈谈自己的一些想法吧。

不可否认的是某些厂家出于某些利益需要在路由器系统里确实预留了控制的后门,这些后门一旦被黑客发现的确会造成毁灭性的破坏,对于这样的安全问题我们只能寄希望于那些良心路由器厂家,或者你也可以参考我前面的文章自己用Raspberry Pi树莓派搭建个自己的无线路由器。当然大多数情况下我们可能杞人忧天了,无线路由器最大的安全问题却是弱密码或者默认密码问题,比如TP-Link经典的admin和admin,所以购买路由器后第一件事就是修改出厂的默认密码,大多数路由器设置被恶意篡改就是因为默认密码没有更改而被XSS,这里建议路由器厂家采取CSRF TOKEN防范这类恶意构造攻击。另外对于无线路由器来说,无线密码也是骇客最爱破解的弱项之一,我曾经就使用12345678这样的弱密码连接过周围的无线热点,这类弱密码设置了也和没有设置一样,建议立即修改,另外不建议采用纯数字位数低的无线密码,因为这类密码也很容易被软件暴力破解,对于无线来说如果你连接的设备允许的话,可以选择关闭SSID(不广播),这样别人就看不见无线名字了,也不会动了破解的心思。

继续阅读

浅议Web在线交易系统涉及的安全场景

之前一次课程的作业,我想存着还不如贴出来供大家拍砖。当然很多是一些个人想法,可能叙述得比较乱,不当之处还望批评指正。

现有的简单的在线交易场景如下图所示:

简单在线交易流程示意图

其中涉及到的数据安全和个人隐私主要有:客户账户和密码,信用卡及相关个人信息。

继续阅读