运维烂笔头

一个 SA 老兵的工作日志

What is HSTS

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,[1] and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.

The HSTS Policy is communicated by the server to the user agent via an HTTPS response header field named “Strict-Transport-Security”.[2] HSTS Policy specifies a period of time during which the user agent should only access the server in a secure fashion.[3]

以上来自于维基百科

大概意思是说 HSTS 是一个 web 安全策略装置,用于保护 web 站点免受协议降级攻击和 cookie 劫持。

阅读全文 »

缘起

我厂办公室测试小机房有一些运算资源,但是其网络是不能直接上公网的,而是通过一个内部代理(内部域名是:proxy.xxxdev.com,端口 3128)来上公网的。

但是现在部署环境,多半需要在命令行下折腾,而且还多半需要不停的从公网下东西(安装),所以,怎样在命令行下(shell 里)使用代理来上公网就成了一个绕不开的话题……

阅读全文 »

缘起

起因自然是我厂某台 CentOS 7.x 的机器需要重置密码,然后我就想按老套路:重启进单用户,再重设密码。没想到 CentOS 7.x 的系统跟 CentOS 6.x 来说有了很大的变化,于是我又只好翻了下文档,重新学习了一下。以下是具体操作步骤:

阅读全文 »

缘起

这个项目的目的主要是为了解决 Linux
服务器在本地解析域名中碰到的几个问题:

  1. nameserver 中一部分有故障(包含宕机了)的问题
  2. nameserver 中一部分性能有问题的问题
  3. 有 HA,但有时候服务切换没有期望得那样准确、迅速

主要为了解决以上三个问题,于是有了内网域名解析优化的需求。

阅读全文 »

缘起

最近上面在开会嘛,职能部门也许是要展示下“肌肉”:“不是我搞不了你,我只是平时懒得鸟你。”我猜大概就是这么个原因吧,结果就是:最近这段时间大家的“科学上网”纷纷中招,不好使了。我司原来用的 SS 改良的版本,中招了,至于怎么解决的,不在本篇讨论的范围之内。

我主要说下家里的情况,家里原来也是 SS 方案,这段时间也不行了,通常是早上不通了,改下端口,然后到晚上又不行了,然后又改端口,搞了两次才是反应过来是被盯上了。心中大呼侥幸!这要是不封端口直接封 IP 我可咋整呀?!就冲这点来讲不得不说职能部门真是良心单位哈,值得点个赞!

现有资源

  • 米国 VPS 一台(Ubuntu 16.04)
  • 家里路由器一台(OpenWrt 14.07,bcrm63xx 架构)

以前也是这情况,不过以前跑的是 SS,据说 SSR 比 SS 更不容易被 ban,所以这次我的方案是用 SSR 替换掉原来的 SS。

阅读全文 »

方法一

1
curl qrenco.de/http:\/\/m.theyan.gs

系统输出:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
█████████████████████████████████
█████████████████████████████████
████ ▄▄▄▄▄ █ ▀▀▄ ██▀█ ▄▄▄▄▄ ████
████ █ █ ███ ▄▄▄████ █ █ ████
████ █▄▄▄█ █ ▄▄ █▀▄███ █▄▄▄█ ████
████▄▄▄▄▄▄▄█ █ ▀ █▄▀ █▄▄▄▄▄▄▄████
████ ▄ ██▄▄▀ ██ ▄▀▄ ▄▀█ ████
████▄▀█▀▀ ▄▄▄▀█▄█▀█ █▄ ▀ ▄█▄████
████▄▄▀▀▀▀▄ █ █▄ ▄█▀ █ ▄███▀ ████
████▄▄ ██▄▀ ▀ ▀ ▄ ▄█▄█▀ ▄▄█▄████
████▄▄▄▄█▄▄█ ▄▄██ ▄ ▄▄▄ █▀▄▀████
████ ▄▄▄▄▄ █▀▄▀▄█▀█▀ █▄█ ▄█▀ ████
████ █ █ ██▀ ▄ ▄█ ▄ ▄▄ ▀ ▄████
████ █▄▄▄█ █ █▀ ▄ ▀ █▀ ██▄▄████
████▄▄▄▄▄▄▄█▄████▄▄█▄█▄██▄██▄████
█████████████████████████████████
█████████████████████████████████

方法二

1
echo "http://m.theyan.gs" | curl -F-=\<- qrenco.de

得到的系统输出是:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
█████████████████████████████████
█████████████████████████████████
████ ▄▄▄▄▄ █ ▄▄ █ ██▀█ ▄▄▄▄▄ ████
████ █ █ ██▄█▀▀▄████ █ █ ████
████ █▄▄▄█ █ ▀▀▄ ▀▄███ █▄▄▄█ ████
████▄▄▄▄▄▄▄█ ▀▄█▄█▄▀ █▄▄▄▄▄▄▄████
████▄▄ █▀ ▄▀ ▄█▄ ▄▀▄ ▄▀█ ████
████▄▄ ██▄▄ ▄ ▀ █▄ █▄ ▀ ▄█▄████
█████▀▄▄▀█▄▀▄▄ ██ ▄▀ █ ▄███▀ ████
████▄▄ █ ▄▀ ▄▄█▀█▄█▄█▀ ▄▄█▄████
████▄▄▄▄██▄▄▀▄ ▄ ▄█▄ ▄▄▄ █▀▄▀████
████ ▄▄▄▄▄ █▀▄▄▀ ▄ ▀ █▄█ ▄██▄████
████ █ █ ██ ▄██ ▄ ▄▄ ▀▀▄████
████ █▄▄▄█ █ ▀▀▄█▀█ ▀ █▀ ██▄▄████
████▄▄▄▄▄▄▄█▄▄█▄▄▄██▄█▄██▄██▄████
█████████████████████████████████
█████████████████████████████████

检测结果

用二维码识别软件检测上面这两个二维码,发现都是:“http://m.theyan.gs”

缘起

我厂原来的权威 DNS 服务器放在阿里云上的(三个完全不同的节点每个节点一台),但现在这几个节点要撤了,所以这些个权威 DNS 服务器必须要要迁往别处了。

阅读全文 »

问题初现

最早发现问题时是在做一个测试,把某个域名解析到内网的几台机器上(10.0.0.9 和 10.0.0.119),结果用客户端(10.0.0.200 和 10.0.0.201,都由于特殊原因没有关掉 IPv6)去连接测试时发现,连接都跑到 10.0.0.119 上了,10.0.0.9 上几乎没有连接!

阅读全文 »

背景

老板有个移动办公的 APP 在公司使用无线网络时老报“超时”错误,于是就让解决这个问题。我们为了定位问题,做了几个测试:

  1. 使用办公无线网络使用此 APP,错误可以重复、稳定复现
  2. 使用 4G 或在家使用此 APP,没有任何问题
  3. 把手机用 usb 连上电脑,让数据走电脑的有线来访问服务器,结果发现 APP 没有问题
  4. 把手机连上办公室其他 wifi 设备,发现使用 APP 也没有问题

最后,还是要听手机上的网络数据包来分析问题。

阅读全文 »
0%