Linux 三种设置环境变量的方法
一、命令前置的临时环境变量 网上一搜一大把都是说 export 命令与 .bash_profile 文件的，却鲜有人提及可以在命令行语句前设置临时环境变量，并且该变量只对当前语句有效。 # usage: var=value [var2=value2 …] script var=value sh -c ‘echo $var’ # 打印 value […]
Linux
bbr还是要开的
之前试验过开bbr，但是可能以前的网络环境没那么糟糕，所以没有特别明显的差距。 今年由于新型冠状病毒肺炎（COVID-19）疫情，墙又开始大封锁。我把之前的gcp关掉重新开了一台，然后这台是没有开启过bbr的。今天ping值<15ms，无丢包的情况下，看youtube的480p都卡。然后尝试更新了linux内核，打开bbr。结果youtube 1080p丝般顺滑。。。震惊了！居然这么屌的嘛。 检查是否已开启 bbr (a) 执行如下命令，检查 bbr 是否可用： sudo sysctl net.ipv4.tcp_available_congestion_control 应该输出类似下面这样的信息（包括bbr，顺序无所谓）： net.ipv4.tcp_available_congestion_control = bbr cubic reno (b) 执行如下命令：
使用iptables统计端口流量
由于最近给google cloud上的一台ss服务新增了一个端口用户，所以想试试如何统计每个ss端口的流量。查了下，发现大部分都是用系统自带的iptables来实现。 1. 使用iptables监控端口流量 1、在iptables的INPUT链插入两条规则：监控8379,8380端口的tcp输入流量 注意 -I 与 -A 的区别，-I表示在规则链首部插入规则，-A表示在规则链尾部追加规则 由于这两条规则没有-j参数，即对匹配到的流量不执行任何目标动作（ACCEPT/DROP/REJECT），只做记录。所以不会影响原有规则 iptables -I INPUT -p tcp –dport 8379 iptables -I
注意！crontab的环境变量并非用户环境变量
今天发现爬虫脚本的一个问题：“直接在shell下运行的话，爬SIPO网站的数据得到的是中文；但是在crontab中启动的脚本爬出来的数据却是英文。”想了好半天，怀疑是环境的问题，然后一查，果然有好多人提到。原来crontab的环境变量跟用户的环境变量是不一致的！！！ 直接在用户shell下敲env命令，可以看到有一行LANG=zh_CN.UTF-8，而crontab默认的环境语言是英文的，所以可以在编辑crontab时加上语言这一行。如下： 2022.04.21 最近在 Oracle 云上搞了两台服务器，并且安装了 certbot 来自动更新证书，但每次 crontab 执行 /usr/bin/certbot renew –quiet 时都会报错。错误日志如下： certbot.errors.NoInstallationError: Could not find a
iptables基本用法
参考官方文档：https://wiki.centos.org/zh/HowTos/Network/IPTables。 注意 iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT 这句很重要！网上好多其他教程都漏了这句，这样会导致只能建立连接但无法通过该连接接收数据。 example： #!/bin/bash # # iptables 设置脚本 #
坑爹的ipv6 =。=#
因为老司机的墙外服务器快到期了（用的亚马逊首年免费的云服务器，真心感谢），所以找小布要了一台国外的vps，打算用来做老司机代理的墙外服务器。 昨晚把新服务器的环境都配好了，今天上线的时候发现翻墙速度超慢，但并不是所有网站都慢，比如用代理访问baidu这些倒没事，但一访问google、youtube这些墙外大厂就比蜗牛还慢。一开始我还以为是不是新服务器上stunnel或者squid的配置问题，但后来在新服务器上直接使用curl命令获取www.google.com也是超慢而curl www.hawu.me就没问题，这样推断一定是服务器本身问题。然后无意中使用wget www.google.com时，发现打印出来的输出有ipv6信息，心里打个激灵，卧槽难道是因为ipv6搞得鬼？使用curl -4 www.google.com发现果然网速正常了。然后检查ifconfig发现果然开启了ipv6。 使用wget（以及curl、squid）获取一个url地址，首先会对目标url进行域名解析，对于google这种大厂来说，域名解析会返回ipv6与ipv4地址，baidu的话，只返回ipv4地址。而由于本机系统开启了ipv6，那么wget这些程序默认会优先使用ipv6来与目标地址进行连接。但不幸的是通常我们服务器所处的网络环境（服务器到目标地址之间的路由环境）不支持ipv6，所以就会卡在这个ipv6连接上，直到超时后才会重新使用ipv4去建立连接。 既然猜到了故障原因，解决起来就很快了，要禁用ipv6，在/etc/sysctl.conf中添加如下两行： net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 然后重启系统即可。
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
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
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