apache阻止错误域名指向

大嘎好,半吊子运维又来了。

接服务商消息,说有一个域名没有备案,不处理的话可能要被通管局断网。

问同事结果搞不清楚,找不到那个域名的注册商了。

只好在服务器上暂时先处理一下。让对应的域名显示不出来

<VirtualHost xxx.xx.xx.xx:80>
ServerName xxx.com
ServerAlias xxxx.com

    <Directory "/xx/xx/xx/">

      Deny from all

    </Directory>
</VirtualHost>

或者再狠一点在最后加上全部禁止
#禁止所有非法域名  

<VirtualHost *:80>  

    ServerName 服务器ip  

    ServerAlias *  

    <Location />  

        Order Allow,Deny  

        Deny from all  

    </Location>  

</VirtualHost>  

ubuntu服务器用shadowsocks做代理

测试一下用 shadowsocks 来做代理服务器

登录ubuntu服务器

我的服务器是20.04版本,python 3.8

安装shadowsocks

$sudo pip3 install shadowsocks

Building wheels for collected packages: shadowsocks
Building wheel for shadowsocks (setup.py) … done
Created wheel for shadowsocks: filename=shadowsocks-2.8.2-py3-none-any.whl size=51658 sha256=451f745570ca87d3250df8d160a20ec76fca56f3f367d5e46587e5dda1f70623
Stored in directory: /home/xxx/.cache/pip/wheels/40/f7/14/208a189571d8a2279abb774182453d0d9356bdaf0299236350
Successfully built shadowsocks
Installing collected packages: shadowsocks
WARNING: The scripts sslocal and ssserver are installed in ‘/home/xxx/.local/bin’ which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use –no-warn-script-location.
Successfully installed shadowsocks-2.8.2

配置shadowsocks端口与密码等

$sudo vi /etc/shadowsocks.json 生成配置文件

{
“server”:”服务器内网ip(填公网ip好像不行)”,
“server_port”: 你自己的端口默认8838,
“local_port”:1080,
“password”:”你的密码”,
“timeout”:600,
“method”:”aes-256-cfb”
}

启动shadowsocks服务

$sudo /home/xxx/.local/bin/ssserver -c /etc/shadowsocks.json -d start

会出现一个错误 undefined symbol: EVP_CIPHER_CTX_cleanup

File “/home/xxx/.local/lib/python3.8/site-packages/shadowsocks/crypto/openssl.py”, line 52, in load_openssl
libcrypto.EVP_CIPHER_CTX_cleanup.argtypes = (c_void_p,)
File “/usr/lib/python3.8/ctypes/init.py”, line 386, in getattr
func = self.getitem(name)
File “/usr/lib/python3.8/ctypes/init.py”, line 391, in getitem
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /lib/x86_64-linux-gnu/libcrypto.so.1.1: undefined symbol: EVP_CIPHER_CTX_cleanup

该问题是由于在openssl 1.1.0中废弃了 EVP_CIPHER_CTX_cleanup() 函数而引入了 EVP_CIPHER_CTX_reset() 函数所导致的。

打到 python3.8/site-packages/shadowsocks/crypto/openssl.py, 将 EVP_CIPHER_CTX_cleanup 替换为 EVP_CIPHER_CTX_reset 一共有二处

重新启动服务,确认服务运行,注意需要在云服务器控制台打开对应端口

配置 Shadowsocks 服务器开机自动启动

运行 chmod +x /etc/rc.local 为启动脚本添加执行权限。
运行 vim /etc/rc.local 编辑启动脚本并添加如下内容:
/etc/rc.local

ssserver -c /etc/shadowsocks.json -d start

下载客户端,下载后解压

地址:https://github.com/shadowsocks/shadowsocks-windows/releases

添加一个服务器

关于系统代理– 全局模式/PAC模式

1、全局模式:你可能会遇到一些网站打不开,仍然无法访问,这个你可以试试选择【系统代理-全局模式】,这样使全部流量经过节点服务器。

2、PAC模式【推荐】:选择PAC模式,PAC文件网址列表走节点服务器,国内网址则走你自己使用的网络流量。

3、关于PAC更新,你可以直接从 GFWList (由第三方维护)更新 PAC 文件,或者你可以手动编辑本地pac文件。需要更新PAC:依次操作:PAC ->从GFW List更新PAC (等待更新完毕后)->使用本地PAC->启动系统代理。

然后就可以使用了

参考文章:https://blog.lingyf.com/build-shadowsocks-server-to-cross-gfw/

5.2. 启用 TCP BBR(本次未做)

TCP BBR 是 Google 开发的拥塞控制算法,该算法可实现更高的带宽和更低的互联网流量延迟:

运行 vim /etc/sysctl.conf 编辑内核配置文件并添加如下内容:/etc/sysctl.conf

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

运行 sysctl -p 重新加载内核配置文件。 运行 sysctl net.ipv4.tcp_available_congestion_control 确认 BBR 已启用:

现在用什么方式相对稳定?能不能不买域名?

是不是只能 V2Ray + WebSocket + TLS + Nginx

AEAD 

拯救被墙的服务器 https://itlanyan.com/recovery-blocked-ip/

V2Ray高级技巧:流量伪装 https://itlanyan.com/v2ray-traffic-mask/

trojan教程 https://itlanyan.com/trojan-tutorial/

V2Ray教程 – tlanyan.htm https://itlanyan.com/v2ray-tutorial/

centos下二个安全更新(CVE-2021-3156,CVE-2020-1971 )操作

大嘎好,半吊子运维又出现了。

今天收到邮件,说是有二个漏洞。本来阿里云可以在控制台内修复,可惜要收费,这笔钱估计老板不大愿意出。所以只能人肉来搞一下子。

$yum update sudo

$yum update openssl

坐等下次的周报看一下还有没有安全漏洞还在不在。

Sudo 堆缓冲区溢出致本地提权漏洞(CVE-2021-3156) 存在EXP权限提升

漏洞描述

Sudo是linux系统管理指令,是允许系统管理员让普通用户执行一些或者全部的root命令的一个工具,如halt,reboot,su等等。
Sudo 1.8.2-1.8.31p2和1.9.0-1.9.5p1版本存在缓冲区溢出漏洞。攻击者可通过“sudoedit -s”和以单个反斜杠字符结尾的命令行参数利用该漏洞获得系统root权限。

基本信息

  • CVE编号: CVE-2021-3156
  • 漏洞类型: 权限提升
  • 危险等级: 中危
  • 披露时间: 未知

OpenSSL 安全漏洞 拒绝服务

漏洞描述

OpenSSL是Openssl团队的一个开源的能够实现安全套接层(SSLv2/v3)和安全传输层(TLSv1)协议的通用加密库。该产品支持多种加密算法,包括对称密码、哈希算法、安全散列算法等。 OpenSSL 1.1.1版本和1.0.2版本存在安全漏洞,该漏洞源于空指针解引用和崩溃可能会导致拒绝服务攻击。

基本信息

  • CVE编号: CVE-2020-1971
  • 漏洞类型: 拒绝服务
  • 危险等级: 低危
  • 披露时间: 未知

PHP ‘_gd2GetHeader()’函数整数溢出漏洞

大嘎好,半吊子运维又出现了。

登录阿里云发现一个新的安全警告。

中危 PHP ‘_gd2GetHeader()’函数整数溢出漏洞 存在EXP 拒绝服务

漏洞描述

PHP(PHP:Hypertext Preprocessor,PHP:超文本预处理器)是PHP Group和开放源代码社区共同维护的一种开源的通用计算机脚本语言。 PHP的‘_gd2GetHeader()’函数中存在整数溢出漏洞,攻击者可利用该漏洞造成堆缓冲区溢出。

基本信息

  • CVE编号: CVE-2016-5766
  • 漏洞类型: 拒绝服务,缓冲区溢出
  • 危险等级: 中危
  • 披露时间: 未知

修复建议

目前厂商已经发布了升级补丁以修复此安全问题,补丁获取链接:
https://bugs.php.net/bug.php?id=72339

参考链接

稍微看了一下,登录到服务器,进行更新

#yum update gd
Loaded plugins: fastestmirror
Repository base is listed more than once in the configuration
Repository updates is listed more than once in the configuration
Repository extras is listed more than once in the configuration
Repository centosplus is listed more than once in the configuration
Loading mirror speeds from cached hostfile

  • base: mirrors.163.com
  • epel: mirror.sjtu.edu.cn
  • extras: mirrors.163.com
  • remi-safe: mirrors.tuna.tsinghua.edu.cn
  • updates: mirrors.aliyun.com
    Resolving Dependencies
    –> Running transaction check
    —> Package gd.x86_64 0:2.0.35-26.el7 will be updated
    —> Package gd.x86_64 0:2.0.35-27.el7_9 will be an update
    –> Finished Dependency Resolution

Dependencies Resolved

================================================================================

Package Arch Version Repository Size

Updating:
gd x86_64 2.0.35-27.el7_9 updates 146 k

Transaction Summary

Upgrade 1 Package

Total download size: 146 k

Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
gd-2.0.35-27.el7_9.x86_64.rpm | 146 kB 00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Updating : gd-2.0.35-27.el7_9.x86_64 1/2
Cleanup : gd-2.0.35-26.el7.x86_64 2/2
Verifying : gd-2.0.35-27.el7_9.x86_64 1/2
Verifying : gd-2.0.35-26.el7.x86_64 2/2

Updated:
gd.x86_64 0:2.0.35-27.el7_9

Complete!

保险起见,重启一下,正好现在没有人用

#reboot

然后登录应用系统,貌似一切正常哦。

打完,收工。

ssl安全证书过期导致网站https访问出现不安全问题

大嘎好,半吊子运维又出现了。

一个网站,用得好好的,忽然说不安全了。登上去一看,果然不安全。

显示NET::ERR_CERT_DATE_INVALID

赶紧登录到服务器上看一看是怎么肥事

得知是nginx的搭的服务器

nginx -t 看一下

再看一下 /etc/nginx/nginx.conf, 啥也没有,再仔细瞄一下原来放在 include /etc/nginx/conf.d/*.conf;

server
{
listen 80;

            listen [::]:80;

            server_name sub.xxx.com;

            location / {
                    return 301 https://sub.xxx.com$request_uri;
            }
    access_log /data/logs/www.log main;
            error_log /data/logs/www_error.log error;

}

server
{
listen 443 ssl http2;
server_name sub.xxx.com;
index index.php index.html;
root /data/wwwroot/xxxxxx;

    location / {
        rewrite ^/$ /index.php last;
        if (!-e $request_filename) {
            rewrite "^/(.*)$" /index.php/$1 last;
        }
    }

    location ~ ^(.+\\.php)(.*)$ {

        fastcgi_connect_timeout 300;
        fastcgi_send_timeout 300;
        fastcgi_read_timeout 300;

        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fcgi.conf;
    }
    location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
    {
        expires      30d;
        access_log off;
    }

    location ~ .*\.(js|css)?$
    {
        expires      12h;
        access_log off;
    }
    location /_log {
       autoindex on;
       autoindex_localtime on;
    }
    access_log /data/logs/www.log main;
            error_log /data/logs/www_error.log error;
            ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_certificate /etc/letsencrypt/live/sub.xxx.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/sub.xxx.com/privkey.pem; # managed by Certbot

}

看来用的是Let’s Encrypt免费SSL证书,这个证书有个麻烦一点的地方就是90天过期,看来自从上次更新之后已经有90天了,所以过期了。

找到原因就好办了,将证书续期一下完事。

发现原来运维使用了 certbot ,那就更简单了。

# certbot certificates 看一下,果然有相应的证书

那就用certbot 更新一下证书 renew ,成功完成。

如果显示不成功,需要先暂停 nginx (systemctl stop nginx.service)

# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/sub.xxx.com.conf


Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for sub.xxx.com
Waiting for verification…
Cleaning up challenges


new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/sub.xxx.com/fullchain.pem



Processing /etc/letsencrypt/renewal/xxx.com.conf


Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for xxx.com
Waiting for verification…
Cleaning up challenges


new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/xxx.com/fullchain.pem



Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/sub.xxx.com/fullchain.pem (success)
/etc/letsencrypt/live/xxx.com/fullchain.pem (success)


参考文章: https://www.liaosam.com/use-cron-service-and-certbot-for-renewal-of-letsencrypt-ssl-certificates.html