为了做好运维面试路上的助攻手,特整理了上百道 【运维技术栈面试题集锦】 ,让你面试不慌心不跳,高薪offer怀里抱!
这次整理的面试题,小到shell、MySQL,大到K8s等云原生技术栈,不仅适合运维新人入行面试需要,还适用于想提升进阶跳槽加薪的运维朋友。
本份面试集锦涵盖了
- 174 道运维工程师面试题
- 128道k8s面试题
- 108道shell脚本面试题
- 200道Linux面试题
- 51道docker面试题
- 35道Jenkis面试题
- 78道MongoDB面试题
- 17道ansible面试题
- 60道dubbo面试题
- 53道kafka面试
- 18道mysql面试题
- 40道nginx面试题
- 77道redis面试题
- 28道zookeeper
总计 1000+ 道面试题, 内容 又全含金量又高
- 174道运维工程师面试题
1、什么是运维?
2、在工作中,运维人员经常需要跟运营人员打交道,请问运营人员是做什么工作的?
3、现在给你三百台服务器,你怎么对他们进行管理?
4、简述raid0 raid1raid5二种工作模式的工作原理及特点
5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?
6、Squid、Varinsh和Nginx有什么区别,工作中你怎么选择?
7、Tomcat和Resin有什么区别,工作中你怎么选择?
8、什么是中间件?什么是jdk?
9、讲述一下Tomcat8005、8009、8080三个端口的含义?
10、什么叫CDN?
11、什么叫网站灰度发布?
12、简述DNS进行域名解析的过程?
13、RabbitMQ是什么东西?
14、讲一下Keepalived的工作原理?
15、讲述一下LVS三种模式的工作过程?
16、mysql的innodb如何定位锁问题,mysql如何减少主从复制延迟?
17、如何重置mysql root密码?
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
2、 运维安全漏洞占比明显
自从某云离去以后,不得不说国内互联网安全态势的共享逐步走向了封闭,不过借此机缘,也涌现了很多商业公司。
即便是现在留下的某天某法某眼,能查询到的统计分析数据其实也很有限。即便是某旦,其用户体验也不够好,统计分析功能无法差强人意。剩下的,各种研究报告也从来没有把运维安全问题列入单独的统计范畴,所以这里借用2016年CNVD的统计,可以发现明显属于运维安全问题的网络设备漏洞和操作系统漏洞,占比已超过20%,加上应用程序漏洞中包括的各种应用版本漏洞,相信归属于运维安全领域的漏洞比例将极其可观。
3、运维安全漏洞利用性价比高
针对运维安全漏洞的攻击属于典型的“一两拨千金”,其ROI非常高:投入小、容易发现与利用、造成危害特别大。
根据微软的DREAD模型来衡量运维安全漏洞风险如下:
三、常见运维安全陋习
运维安全事件频发,一方面固然是因为运维或安全规范空白或者没有落地,另一方面也在于运维人员缺乏强烈的运维安全意识,在日常工作中存在这样那样的安全陋习导致。
下面列出了14种坑,大家可以试试对号入座,仔细想想曾几何时自己是否也踩过同样的坑?
1、修改iptables后没有还原配置,甚至清空关闭iptables
出于测试需要临时清空iptables可以理解,但是很多人会忘记还原,也没有设置自动还原机制。
iptables -F
2、脚本没有检查“*”、空格、变量
如果我们认可“不光用户的输入是不可信的,自己的输入也是不可信”,这样的坑就会少踩。
rm -rf /
v
a
r
1
/
var1/
var1/var2
3、服务启动默认监听全部地址
绝大部分应用默认配置便是如此,在没有有效访问控制的清空下开启监听所有地址,离危险也就不远了。
bind-address 0.0.0.0
4、给文件开放过大的权限时,任何人都能读写
这个跟phpinfo有点像,能给入侵者推一把。
chmod 777 $dir || chmod 666 $script
5、用root启动服务
对于大多数运维人员而言,一上机器就切到root,后面用root启动服务仿佛一气呵成。
#nohup ./server &
6、嫌麻烦不配认证,也不配访问控制
这个跟监听任意地址比较像,通常也是默认配置使然,使用者也没有意识去加固。
#requirepass test
7、单机安装docker之后忽略检查iptables,导致docker修改iptables开放外网
docker技术给我们带来的便利自不必言,但是docker带来的安全风险却一点也不少。而且,docker daemon默认是能控制宿主iptables的,如果docker daemon使用tcp socket或者启动的容器可被外部访问,则连宿主一同沦陷也不在话下。
8、sudo授权过大,导致自定义脚本提权
如果攻击者可修改脚本内容则提权易如反掌。
sudo script.sh
参考链接:
script.sh:http://script.sh
9、给开发或者QA授权root权限,他搞事你背锅?
一直以来我们强调RBAC,但是运维太忙,开发测试人员需求太多时,很多运维人员会直接授权他们root权限,而他们对系统级访问控制不甚了了,因此造成的漏洞非常“可观”。
dev@pro-app-01:/home/dev$su
root@pro-app-01:/home/dev#whoami
root
10、key/token/ssh私钥保存在txt文件里,也有把个人ssh私钥放在服务器的
op@pro-app-01:/home/op$ls ~/.ssh
id_rsa id_rsa.pub
11、把工作上的代码对外发布
连着遇到实习生把项目代码提交github了,回复的理由是git配错了。虽然不知真假,但我认为,至少他们是安全意识不足。
git remote add origin https://github.com/secondwatchCH/EFS.gitgit push origin master
12、个人home目录那么敏感,也有人拿来直接托管服务,至少.bash_history泄露是跑不了
dev@pro-app-01:/home/dev$python -m HTTPSimpleServer
13、应用选型时没有考虑安全风险
Apache Struts Version:Struts 2.5 - Struts 2.5.12 #线上业务使用受S2-052影响的S2版本
14、对软件供应链安全没有概念
从xcode事件到pip官方发现恶意ssh库,都在向我们昭示一个道理:软件供应链安全风险极大。目前比较运维人员中比较常见问题有:
- ssh客户端或者开发IDE从百度网盘下载
- 两眼一闭,把github/pypi/dockerhub等网站下载的应用/库/镜像直接用到生产环境
- 未清理默认口令或者默认配置
四、常见运维安全问题
前面我们谈到了运维操作上、思路上的一些陋习,或者安全意识不足的问题,下面结合漏洞分析和响应过的情况来看,常见的运维安全问题主要可分为下面几种:
1、敏感端口对外开放
db或者cache属于敏感应用,通常部署在内网,但是如果部署的机器有内外网ip,且默认监听地址为0.0.0.0的话,则敏感端口会对外开放。如 MySQL / MongoDB / Redis / rsync / docker daemon api 等端口对外开放。
2、敏感应用无认证、空口令或者弱口令
同上,如果敏感应用使用默认配置,则不会开启认证,MySQL / MongoDB / Redis / rsync / supervisord rpc / Memcache 等应用无认证。有时贪图测试方便,配置了弱口令或空口令,则认证形同虚设。
3、敏感信息泄露,如代码备份、版本跟踪信息、认证信息泄露
web.tar.gz/backup.bak / .svn/.git / config.inc.php / test.sql 等信息泄露随处可见,人人知道危险,但是始终时不时会有人会踩坑。
4、应用默认配置未清除
jenkins script / apache server-status等默认功能未清理,例如下图可直接执行命令:
5、应用系统打开debug模式
Django debug模式开启暴露uri路径,phpinfo()暴露服务器信息甚至webroot等,之后攻击者便可借此进一步渗透,很多白帽子应当有此同感,发现了sql注入但是写不了webshell,如果能遇上个phpinfo()那是再好不过的事情了。
6、应用漏洞未及时升级
越是通用的应用,就越经常爆出漏洞。有句话说的好:不是因为黑客这个世界才不安全,而是因为不安全才会有了黑客,黑客去揭开那层假象,我们才发现有那么多不安全。于是Struts2、OpenSSL、Apache、Nginx、Flash等等CVE接踵而来。
7、权限管理松散
不遵循最小权限原则,给开发提供root权限或者给业务账号授权admin权限。
8、DDoS攻击
DDoS攻击对于运维人员而言,是再熟悉不过的安全问题了。我们都知道通过占满带宽、耗尽资源等方式可让服务器无法响应正常请求,说到底是资源对抗的一种攻击方式。如果仅依赖服务器资源去抗,去过滤,如下图,在大流量、高并发之下,只会引来雪崩:
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
资源对抗的一种攻击方式。如果仅依赖服务器资源去抗,去过滤,如下图,在大流量、高并发之下,只会引来雪崩:
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!