Cybersecurity

CTF Writeup: from_sqli_to_shell_i386

/

今天给单位的小年轻讲网络安全课程，用了 from_sqli_to_shell_i386 这个靶机。题目简单，iso 文件又小，很适合入门。 这个靶机上有一个网站。先找到网站的 SQL 注入点；然后通过 SQL 注入获取 admin 帐号密码；再使用 admin 用户登录，发现有文件上传的模块；通过文件上传漏洞上传木马文件，获取系统执行权限。Done 👌   贴一下详细的解题过程： 1. 先用下载到的 from_sqli_to_shell_i386.iso 文件新建一个虚拟机

CTF 流量分析

/

Wireshark 主窗口 注意，数据包详情面板中展示的信息是经过 Wireshark 解析并”格式化”过的，方便阅读。最下面的数据包字节面板里才是这个包的真实数据。 过滤器栏 在主窗口的过滤器栏中输入过滤指令来筛选数据。 常用过滤指令 ip 地址筛选 ip.addr == x.x.x.x 筛选 ip 地址为 x.x.x.x 的（包括源 ip 地址与目标

iptables基本用法

/

参考官方文档：https://wiki.centos.org/zh/HowTos/Network/IPTables。 注意 iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT 这句很重要！网上好多其他教程都漏了这句，这样会导致只能建立连接但无法通过该连接接收数据。   example： #!/bin/bash # # iptables 设置脚本 #

关于CSRF攻击

/

今天在某个技术群里有网友聊起CSRF攻击，就想起了以前写汤圆网时用到的“盐值”（unique_salt）与token。 一、什么是CSRF攻击及CSRF的防御 可以参考这篇文章：http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html 对于用户提交的涉及到修改数据的请求，最好都要考虑下防御CSRF。 二、加盐再散列（salt md5） 参考wiki：https://zh.wikipedia.org/wiki/%E7%9B%90_%28%E5%AF%86%E7%A0%81%E5%AD%A6%29 三、我曾经的解决方案 我也记不得我这个解决方法是哪里学来的了。=。=# 大概思路是这样： 1. 首先定义一个系统全局的salt值： $config[‘salt’] = ‘abcd1234’; 2. 然后在生成前端页面时，生成timestamp与token： $timestamp = time();

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

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.

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