ssh防暴力破解

/

前两天找小布要了一台美国的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 […]

spring mvc给freemarker传全局的值

/

通常spring mvc通过model给freemarker view传值，这是一个局部的概念，针对的是每个页面。有时候，我们会想给整个freemarker传一些全局的值。比如网站的url前缀，比如静态资源的路径，这些值在每个页面几乎都会需要用到，但我们不可能在每个model中传递这些值。 我们可以通过FreeMarkerViewResolver来给freemarker模板设置全局的值。 <beans:bean id="freemarkerResolver" class="org.springframework.web.servlet.view.freemarker.FreeMarkerViewResolver"> <!– 省略 –> <!– 传值给${request} –> <beans:property name="requestContextAttribute" value="request"/> <beans:property name="attributes"> <beans:props> <!–

redis安全配置

/

通常情况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.

在spring框架中发送邮件

/

spring封装了一个邮件发送类：org.springframework.mail.javamail.JavaMailSender，这个JavaMailSender底层实现依赖的是公开的JavaMail API。所以要让spring的JavaMailSender正常工作，就必须先导入JavaMail API的实现类，比如com.sun.mail:javax.mail。 发送的邮件有两种类型，一种是简单文本邮件，不支持html，即使邮件内容中出现html标签，对方邮箱收到邮件后显示的仍是原始文本；一种是富文本邮件，支持html，对方邮箱收到邮件后会解析html标签并渲染。 一、配置JavaMailSender <bean id="javaMailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl"> <property name="host" value="smtp.exmail.qq.com"/> <property name="port" value="25"/> <property name="username" value="your exmail name" />

spring中Constructor、@Autowired、@PostConstruct的顺序

/

其实从依赖注入的字面意思就可以知道，要将对象p注入到对象a，那么首先就必须得生成对象p与对象a，才能执行注入。所以，如果一个类A中有个成员变量p被@Autowired注解，那么@Autowired注入是发生在A的构造方法执行完之后的。 如果想在生成对象时候完成某些初始化操作，而偏偏这些初始化操作又依赖于依赖注入，那么就无法在构造函数中实现。为此，可以使用@PostConstruct注解一个方法来完成初始化，@PostConstruct注解的方法将会在依赖注入完成后被自动调用。 Constructor >> @Autowired >> @PostConstruct 举个例子: public Class AAA { @Autowired private BBB b; public AAA() { System.out.println("此时b还未被注入:

关于三层架构及事务的异常处理

/

我的个人理解，在三层架构的开发模式中。 dao层 负责对数据库进行增删查改基本操作。比如新建一个用户信息，更新一个用户信息。 每个dao层的方法都必须是单元操作，即不允许多次读写数据库，因此无需在dao层加事务处理。 在dao层无需手动去处理异常，异常由系统自动抛出，在service层捕获。 service层 负责组合dao层方法来处理业务逻辑。比如处理用户A转账给用户B，就需要两次调用dao层方法，一次是减少用户A的账户、一个是增加用户B的账户，这种业务逻辑就必须放在service层。 service层负责捕获dao层的异常，并判断是否向上抛出异常，是否回滚事务，或者还是在service层就处理掉异常，给上层返回处理结果。 通常，对于简单的业务逻辑，可以在service捕获并处理异常，然后给上层action层返回处理结果（成功or失败）即可。如果涉及到的业务复杂，并且涉及到多次的dao层写入操作，就必须回滚事务。注意，使用spring的aop事务的话，要么是在service层抛出异常触发aop事务回滚，要么就得手动回滚事务。如果异常在service层被捕获并处理掉，是不会触发事务回滚的。 action层 复杂调用service层方法，并捕获service层的异常，给用户输出可读的信息。 无需事务处理。

squid + stunnel >> 跨越长城，科学上网！

/

在上一篇文章《使用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搭建代理服务器

/

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代理与端口扫描

/

写爬虫总会有用到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

wtf! Redis Crackit，我被黑了 =。=#

/

先前学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

Scroll to Top