标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,767)
- DB2 (22)
- MySQL (77)
- Oracle (1,608)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (590)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
月归档:七月 2010
服务器遭攻击,oracle分析日志
今天公司服务器出现问题,经过启动日志功能,分析日志,大概确定是dos攻击
部分日志如下:
2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 121.204.33.120 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 114.41.216.107 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 221.15.37.5 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 114.41.216.107 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 114.41.216.107 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 114.41.216.107 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 114.41.216.107 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 222.81.14.4 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 180.126.191.98 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 117.15.210.226 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 121.204.33.120 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 112.122.131.60 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64 2010-07-02 10:55:22 W3SVC689347672 192.168.10.222 GET /index.shtml - 80 - 118.77.181.47 Mozilla/4.0(compatible;+MSIE+7.0;+Windows+NT+5.1;+SV1) 200 0 64
日志文件实在太多了,最后几分钟都就有20m左右,我们肉眼看上去,没有什么规律可寻的,我决定采用oracle数据帮我们分析
建表如下:
get varchar2(3000)–保存日志中的一条记录
ip varchar2(15)–保存日志中请求服务器的ip地址(分析的重点)
gettime varchar2(20) –保存时间(本来有date类型的,不知道为什么,和后面的proc中的程序有的冲突,我也不想改存储过程了,就先改了这个,有时间再想想程序)
第一步:通过net把.log 的日志文件中的数据导入到db的dos_gj中的get列中,程序如下:
string txt = Show_page("log.log"); string[] aba = txt.Replace("\r\n", "@").Split('@'); for (int i = 0; i < aba.Length; i++) { OracleHelper.ExecuteNonQuery(OracleHelper. ConnectionStringLocalTransaction, System.Data.CommandType.Text, "insert into dos_gj(get) values (:abc)", new OracleParameter("abc", aba[i])); }
//读取文件的 Show_page()函数就不放出来了
大概半个多小时,20m文件的数据,全部分条导入到数据中,统计,一共近20w条
第二步:使用proc对这些数据进行分析:
proc如下 :
create or replace procedure dos_fx is cursor c1 is select get from dos_gj; begin for c2 in c1 loop update dos_gj set ip=REGEXP_SUBSTR( get, '(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])(\.(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])){3} '), gettime=REGEXP_SUBSTR( get, '\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}') where get=c2.get; end loop; commit; end; exec dos_fx;
不知道什么原因,执行了快两个小时了,现在还是在执行中,我现在怀疑在oracle中cursor +正则表达式+update,执行效率正的很低啊,才20w条数据,执行了2个小时,还没有结果,郁闷,在等待中……
这些对oracle有点无语了,害的我现在还不能睡觉,等在电脑面前,早知道就用ms sql了,听说 2005也支持正则功能了。继续等待(2010年7月3日2:04:58),这个效率,这个速度有点无语哦,听说oracle速度很快,我还得好好学习 哦。等了两个多小时就是学艺不精的后果。
最后想想这个update table的思路不行,新建了一张,使用了新的存储过程(insert)
create or replace procedure dos_fx is cursor c1 is select get from dos_gj; begin for c2 in c1 loop insert into dos_gj_1(ip,gettime,get)values(REGEXP_SUBSTR( c2.get, '(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])(\.(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])){3} '), REGEXP_SUBSTR( c2.get, '^(\d{4})-(\d{2})-(\d{2}) (\d{2}:\d{2}:\d{2})'),c2.get); end loop; commit; end;
同上表,然后执行insert操作,考虑到sql dev占用内存太大,这次使用了pl/sql dev操作,结果使用了1分钟37秒就完成了近20w的数据的操作,这才是oracle的本色啊,O(∩_∩)O哈哈~。
现在想想,应该是刚刚前面的update那种操作导致了数据库死锁导致无限的等待。
好了,数据从log文件,到数据库里面,已经数据提取成功,剩下的就是相关统计的oracle了
统计ip攻击情况
不到一个小时的攻击的结果大概如上图,任务大概完成,先睡觉去,明天继续分析
发表在 Oracle
评论关闭