现在用户在输入url访问网站的时候通常不会再去敲http://www这样的前缀，而习惯直接敲域名。http会由浏览器自动添加，但www就必须由站长们来配置了。 首先需要在dns解析上配置对根域名的域名解析： 然后修改nginx的配置: # 301 redirect non-www to www server{ server_name hawu.me; return 301 $scheme://www.$host$request_uri; # return 301 等效于下面这句 # […]
前两天找小布要了一台美国的vps，打算部署我的代理项目。检查系统日志/var/log/secure的时候，发现几乎每秒都有ssh连接失败的记录，这明显是有黑客在对主机尝试暴力破解ssh密码。 (⊙o⊙)…额，以前我自己也都没留意过这个日志，赶紧去看了下我自己的阿里云，发现也有一些ssh登录失败的记录，好在没有小布这台这么密集。这也吓的我赶紧查了一下怎么样有效地防止服务器被暴力破解。 一、封杀多次验证失败的ip 你可以自己写个脚本扫描ssh登录日志，判断某个ip多次尝试登录失败后，将其写入/etc/hosts.deny或iptables来拒绝该ip的访问。不过本着避免重复制造轮子原则，网上有不少开源的脚本程序帮忙做这件事了，比如fail2ban、denyhost。 二、使用认证登录而不是账号密码登录 当手头的服务器多起来的时候，你会发现，使用ras认证的方式进行ssh免密码登录是多么方便。同时认证登录也比简单的密码更安全。因此一个非常有效的防暴力破解的方法就是设置ssh认证登录，然后关闭ssh账号密码登录。亚马逊主机默认就是这么干的，不允许ssh的账号密码登录，只允许非root用户进行认证登录，root账号必须由非root账号认证登录后使用su – 来提权。 1. 将本地机器的ssh公钥（通过ssh-keygen生成，在$HOME/.ssh/目录下）写到服务器的~/.ssh/authorized_keys文件中： # funway-macbook_air ssh-rsa AAABXB*** *** *** ***VMAJLB your-email@163.com 另外，建议将.ssh目录与authorized_keys文件的读写权限设置为如下（并非权限越高越好，我试过在centos 7生成的authorized_keys默认权限为664，反而无法登录，提示Permission
通常情况redis服务器总是放在内网并只允许内部服务器访问的，所以redis生来就不怎么关注安全问题，默认的redis-server配置允许任何访问。但总会有某些情况下，我们需要将redis暴露给外网，这时候就需要给redis-server加上些安全措施，你总不会希望有其他人能访问你的redis-server吧。 1. 设置防火墙 在redis服务器的防火墙（或者iptables）上设置只允许受信任的主机访问redis端口。这是最基本的安全策略。 2. 绑定本地网卡 修改redis.conf文件，添加 bind 127.0.0.1 这样做使得redis-server只接受本地访问。即使有外部主机通过了防火墙，也无法访问redis-server。 注意，bind指令不能绑定除本地网卡ip外的其他ip。也就是说，不能通过bind外部主机的ip来允许外部主机的访问，这只能通过防火墙来实现。 3. 添加密码验证 修改redis.conf文件，添加 requirepass your-password redis的执行效率非常快，外部设备每秒可以测试相当多数量的密码，所以密码要尽量长尽量复杂。 redis的密码是明文存储在redis.conf文件，因此不需要管理员记住。所以可以使用相当长的密码。 密码验证的目标是提供第二层的安全保障。这样当防火墙失效的话，外部主机在没有密码的情况下仍然不能访问redis。 4.
在上一篇文章《使用squid搭建代理服务器》里，我们知道单单使用墙外的squid代理是不可能实现翻墙的，因为墙内主机到墙外squid之间发送的请求会被GFW监控到。即使是https，报文正文虽然是加密的，但报头是不加密的，依然会被GFW墙掉。 既然如此，如果我们从墙内到墙外squid之间的数据包是加密过的，那不就可以瞒过GFW了？这就需要用到stunnel！ Stunnel 是一个自由的跨平台软件，用于提供全局的TLS/SSL服务。针对本身无法进行TLS或SSL通信的客户端及服务器，Stunnel可提供安全的加密连 接。该软件可在许多操作系统下运行，包括Unix-like系统，以及Windows。Stunnel依赖于某个独立的库，如OpenSSL或者 SSLeay，以实现TLS或SSL协议。 ——百度百科 ps：除了stunnel外，比较有名的开源隧道软件还包括：由代理软件varnish-cache的母公司提供的hitch（前身是stud），国内VPN厂商曲径提供的qtunnel 一、squid + stunnel 翻墙大法 squid+stunnel翻墙大法的原理如下图： 用户将tcp包发给stunnel client；stunnel client将包加密，发送给stunnel server；stunnel server解密后发送给squid；squid将包中的http请求进行转发，然后再将请求结果返回给stunnel server；stunnel server加密发给stunnel
squid是一款高效的http代理服务器程序，而且更经常被用来做缓存服务器。官网：http://www.squid-cache.org；还有一位大牛翻译的squid中文权威指南。 一、安装squid 我的安装环境：Ubuntu 14.04.2 LTS sudo apt-get install squid3 可以使用squid3 -v 检查安装好的squid 二、squid配置 squid默认配置文件为/etc/squid/squid.conf 2.1 基本配置 # http_port 设置监听端口，默认为3128 http_port
写爬虫总会有用到http代理的时候，通常的做法都是直接去代理网站（比如快代理，米扑代理）找代理ip来用，但是这些http代理的原理是什么？代理网站是怎么扫描到这么多代理ip的？这两个问题一直困扰着我，可能以前也查过相关资料，但没记住=。=# 今天还是把这个记下来吧，好记性不如烂笔头不是嘛。 一、http代理原理 参考：https://imququ.com/post/web-proxy.html python实现简单的http代理：https://github.com/abhinavsingh/proxy.py 著名的开源http代理程序有：squid、harproxy、varnish。关于squid的用法可以参考我的下一篇文章《使用squid搭建代理服务器》 从知乎上摘抄了一份对比图，对比了这些开源代理的特性，可以了解一下。 二、端口扫描 代理网站如何扫描到那些可用的代理ip，最直接的方法就是使用暴力穷举： 扫描所有ipv4公网地址（ipv4地址数量有255*255*255*255大概42亿个，其中公网ip大概占20多亿个）； 对每个公网ip进行端口扫描（最常用的是TCP SYN扫描），确认该ip下有哪些端口号对外开放（一台主机的端口数量是65535个）； 然后再对这几个端口分别进行http代理测试，确认是否可用。 端口扫描的原理其实就是对该[ip: port]尝试进行TCP三次握手，参考：http://zenoh.iteye.com/blog/1264915 下面是一段python实现的最简单的端口扫描脚本： #!/usr/bin/env python from socket
先前学redis时候是放在亚马逊的云主机上部署的redis-server，因为亚马逊云的默认安全策略是禁止所有端口的外网访问，要想从外网访问云主机，必须手动在安全策略开启所需端口，这能有效防止无意识的端口暴露。而阿里云的默认安全策略则是允许所有端口的外网访问权限，简直日了狗了，以前从没注意过。 昨天想着要重构下我的betspider爬虫，将一些实时数据放到redis缓存中，所以在阿里云也开了redis-server。redis的默认配置是允许所有远程连接，并且无需密码。 这种情况下：阿里云无安全策略，所有端口暴露给外网；redis-server无需密码登陆、允许远程连接。那么就相当于将我的redis-server暴露在所有人面前，谁都可以访问到。活生生的Redis Crackit肉鸡。 Redis Crackit漏洞： 黑客远程访问redis服务，清空redis数据库后写入他自己的ssh登录公钥，然后将redis数据库备份为/root/.ssh/authotrized_keys。 这就成功地将自己的公钥写入到ssh的authotrized_keys，无需密码直接root登录被黑的主机。大写的SAD. 事情的经过是这样的，应该是今天中午的时候吧大概，正好用phpRedisAdmin查看我的redis-server，发现里面有一个很陌生的key，值为“ssh-ras xxxx”一大串字符串，当时我还没反应过来这是什么玩意，就奇怪了一下怎么莫名其妙多了一个key，然后随手就把他删除了，这个时候，应该就是黑客正在作案的时候，还真巧=。=# 后来，再登录的时候，发下root目录下多了一个奇怪的脚本get.sh，内容是下载xx程序后台执行，然后删除程序文件。想了一会觉得特别不对劲，卧槽难道我被黑了，赶紧history检查历史命令，发现没有什么异常，估计这时候history记录已经被黑客清理干净了，但却忘删get.sh这个脚本文件了。 后来正好看手机短信，发现有条未读的阿里云短信，说我的服务器在荷兰（89.248.162.167）处登录，可能是黑客入侵。what the hell，我居然现在才看到短信！！！ 当时想了好一会儿，卧槽怎么回事，怎么会被黑了，赶紧改密码，日了狗了。到底怎么回事。咦，我的redis好像没有做访问控制，可以被所有人访问到呀，是不是redis有漏洞？赶紧百度一下，what the fuck！果然是redis的漏洞，靠！赶紧停redis-server。 处理方法： 修改redis配置文件，打开被注释的bind
昨天玩了一下docker，感觉官方Get Started教程里面那个whalesay的例子实在是太渣，没有一点实际用途。解释了image跟container的关系，但完全没有体现container与本地进程的关系。 在实际应用场景上，我感觉docker应该更经常会用在部署nginx、memcache这些无需持久化到本地文件的服务进程上面，一个container就相当于一个进程，随用随起，而且不受本机环境限制。docker应该还可以用在Online Judge这样的在线编程系统上，不用再担心恶意代码搞坏本机系统了。不知道Quantopian这些在线交易策略的后台是不是也用docker给每个用户一个container来跑他们的策略，有点意思嘿嘿。另外docker用来做测试环境也特方便，比如本文要做的redis集群，实际应用肯定是将每个redis-server部署在不同的服务器上，穷酸点的可以部署在不同虚拟机上，但用docker可以很方便的在一台机器起好几个redis-server进程。 1. 下载安装docker 2. 直接去docker hub拉取redis官方镜像 # docker pull redis 使用docker images可以列出当前所有的docker镜像。 docker镜像与容器的实际存储目录一般都在/var/lib/docker下面，关于docker的底层存储结构，这个应该得花大时间才能有所心得了。 3. 从redis镜像启动一个容器 # docker
按照kafka的官方文档（http://kafka.apache.org/documentation.html#quickstart）试了一下，解压程序包后运行 $bin/zookeeper-server-start.sh config/zookeeper.properties & 结果一上来就报错，无法分配内存。 从错误输出来看，这个zookeeper-server要求申请536870912字节（512MB）内存 =。=#。。 日了狗了我的亚马逊主机总共才1GB物理内存而且还没建swap分区，free看了一下大概就剩200MB左右的可用内存。检查这个命令的两个文件，发现在zookeeper-server-start.sh中有个定义export KAFKA_HEAP_OPTS=”-Xmx512M -Xms512M”。上来就要jvm去申请512MB的最小空间，把这个Xms改成16M后zookeeper就启动正常了。 然后做下一步启动kafka-esrver $bin/kafka-server-start.sh config/server.properties & 同样遇到这个问题，修改kafka-server-start.sh中的Xms配置（这个更狠，要了1GB的初始内存） 重新启动kafka-server，这回又显示如下错误：OutOfMemoryError 这回是jvm已经启动，在kafka的程序内部分配内存时候出错了。看来除了在启动jvm前就申请了大内存，在kafka程序内部又申请了大内存。 先去检查作为启动参数的server.properties文件，里面关于size的配置都不大，不至于OutOfMemory。 再检查kafka的源码，定位到KafkaServer.scala的589行附近。
今天在单位遇到一个问题，有一台服务器文件系统的磁盘使用率超过80%，因此打算清理一下没用的文件。 使用df检查发现/home目录占用了105G，而用du命令检查/home目录只占用了64G，整整差了41G！即使df与du命令的检查结果是可能会存在些许不同，但相差了这么多，明显是有问题了。通常导致这个问题的原因，当一个文件被删除后，在目录中已经不可见了，所以du就不会再统计它了。然而如果此时还有进程持有这个已经被删除了的文件的句柄，那么这个文件就不会真正在磁盘中被删除，这样df仍旧会统计这个被删除了的文件。 我们可以使用lsof命令(list open files)来检查被打开的文件，并grep下是否已经deleted（很不幸，检测是否deleted这个，并不是所有系统的lsof都支持的，我的mac就不会。 那样的话只能自己写个脚本一个一个文件去检查是否还在目录中了） 检查结果如上图，这两个pid为8363、8364的jsvc进程打开了已经被删除的日志文件catalina.out.8，而且这个文件有40G之大！ =。=# 我怀疑是这个系统的开发人员以为写个定时任务删除了过期日志文件就好了，结果在程序中又没有关闭这个文件句柄，还接着往这个文件里面倒数据。。。 解决办法一是重启对应的进程，释放该文件句柄；二是使用命令清空文件$cat /dev/null > filename。