概況
redis是一個key-value型數據庫,信息以鍵對應值的關系存儲在內存中,比memcache較大的優勢就在于其數據結構的多樣性。redis不算一個真正意義上的數據庫,因為redis是主要把數據存儲在內存中(當然可以把其存儲至硬盤上,這也是寫shell的必要條件之一),其“緩存”的性質遠大于其“數據存儲”的性質,其中數據的正刪改查也只是像變量操作一樣簡單。而mongodb卻是一個“存儲數據”的系統,增刪改查數據的時候有“與或非”條件,查詢數據的方式也能像SQL數據庫一樣靈活,這是redis所不具備的。
進入正題,對于redis可能造成的安全問題,提到了寫文件,下文將把方法作簡要分析。
redis安裝完成以后有自己的命令行,也就是redis-cli,其中包含的命令可以在:http://redis.io/commands 進行查閱。各個客戶端基本也就是依照這個命令去增刪改查。之前說了redis的數據主要保存在內存中,當與memcache不同之處在于,我們可以隨時執行“save”命令將當前redis的數據保存到硬盤上,另外redis也會根據配置自動存儲數據到硬盤上。
這不得不說到redis的持久化運作方案 http://redis.io/topics/persistence ,其中說到的一個RDB,一個AOF。RDB更像一個數據庫備份文件,而AOF是一個log日志文件。我們可以設置讓redis再指定時間、指定更改次數時進行備份,生成RDB文件;而設置AOF,可以在操作或時間過程后將“日志”寫入一個文件的最末,當操作越來越多,則AOF文件越來越大。
二者是相輔相成的,通過二者的配合我們能夠穩定地持久地將數據存儲于服務器上。
利用redis寫webshell
而我們就是利用這些儲存數據的操作,來進行任意文件寫入。
redis的配置中,有幾個關鍵項目:
dir,指定的是redis的“工作路徑”,之后生成的RDB和AOF文件都會存儲在這里。
dbfilename,RDB文件名,默認為“dump.rdb”
appendonly,是否開啟AOF
appendfilename,AOF文件名,默認為“appendonly.aof”
appendfsync,AOF備份方式:always、everysec、no
經過我的研究發現,我們可以將dir設置為一個目錄a,而dbfilename為文件名b,再執行save或bgsave,則我們就可以寫入一個路徑為a/b的任意文件:
?
當我們獲得了一個redis控制臺,我們可以調用config set/get等命令對redis的部分配置進行修改。
而恰好的是,我們可以通過config set來更改dir和dbfilename。也就是說我們可以不用修改redis.conf,也不用重啟redis服務就可以寫入任意文件:
config set dir /home/wwwroot/default/
config set dbfilename redis.php
set webshell “<?php phpinfo(); ?>“
save
當我們隨便set一個變量webshell的值為”<?php phpinfo(); ?>”后,即可對服務器進行getshell。可見已寫入:
?
導出的RDB實際上是一個二進制文件,但因為其中包含<?php phpinfo(); ?>,所以被解析了:
?
在前圖中,我們可以看到其實還生成了一個appendonly.aof,這個文件名能不能自定義呢?可惜的是,appendfilename的值并不能使用config set命令定義:
但僅有的一個dbfilename已經足夠了。
所以,以后如果掃到redis未授權訪問,先別急著提交烏云。看看服務器有沒有web服務,如果有,不妨試試能不能拿下webshell。
Mongodb與Redis應用指標對比
MongoDB和Redis都是NoSQL,采用結構型數據存儲。二者在使用場景中,存在一定的區別,這也主要由于二者在內存映射的處理過程,持久化的處理方法不同。MongoDB建議集群部署,更多的考慮到集群方案,Redis更偏重于進程順序寫入,雖然支持集群,也僅限于主-從模式。
?
Redis、Memcached與 MongoDB三者的區別
如果簡單地比較Redis與Memcached的區別,大多數都會得到以下觀點:
1 Redis不僅僅支持簡單的k/v類型的數據,同時還提供list,set,hash等數據結構的存儲。
2 Redis支持數據的備份,即master-slave模式的數據備份。
3 Redis支持數據的持久化,可以將內存中的數據保持在磁盤中,重啟的時候可以再次加載進行使用。
在Redis中,并不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別(我個人是這么認為的)。
Redis只會緩存所有的key的信息,如果Redis發現內存的使用量超過了某一個閥值,將觸發swap的操作,Redis根據“swappability = age*log(size_in_memory)”計算出哪些key對應的value需要swap到磁盤。然后再將這些key對應的value持久化到磁盤中,同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然,機器本身的內存必須要能夠保持所有的key,畢竟這些數據是不會進行swap操作的。
同時由于Redis將內存中的數據swap到磁盤中的時候,提供服務的主線程和進行swap操作的子線程會共享這部分內存,所以如果更新需要swap的數據,Redis將阻塞這個操作,直到子線程完成swap操作后才可以進行修改。
可以參考使用Redis特有內存模型前后的情況對比:
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M used
當從Redis中讀取數據的時候,如果讀取的key對應的value不在內存中,那么Redis就需要從swap文件中加載相應數據,然后再返回給請求方。這里就存在一個I/O線程池的問題。在默認的情況下,Redis會出現阻塞,即完成所有的swap文件加載后才會相應。這種策略在客戶端的數量較小,進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中,這顯然是無法滿足大并發的情況的。所以Redis運行我們設置I/O線程池的大小,對需要從swap文件中加載相應數據的讀取請求進行并發操作,減少阻塞的時間。
redis、memcache、mongoDB 對比
從以下幾個維度,對redis、memcache、mongoDB 做了對比,歡迎拍磚
1、性能
都比較高,性能對我們來說應該都不是瓶頸
總體來講,TPS方面redis和memcache差不多,要大于mongodb
2、操作的便利性
memcache數據結構單一
redis豐富一些,數據操作方面,redis更好一些,較少的網絡IO次數
mongodb支持豐富的數據表達,索引,最類似關系型數據庫,支持的查詢語言非常豐富
3、內存空間的大小和數據量的大小
redis在2.0版本后增加了自己的VM特性,突破物理內存的限制;可以對key value設置過期時間(類似memcache)
memcache可以修改最大可用內存,采用LRU算法
mongoDB適合大數據量的存儲,依賴操作系統VM做內存管理,吃內存也比較厲害,服務不要和別的服務在一起
4、可用性(單點問題)
對于單點問題,
redis,依賴客戶端來實現分布式讀寫;主從復制時,每次從節點重新連接主節點都要依賴整個快照,無增量復制,因性能和效率問題,
所以單點問題比較復雜;不支持自動sharding,需要依賴程序設定一致hash 機制。
一種替代方案是,不用redis本身的復制機制,采用自己做主動復制(多份存儲),或者改成增量復制的方式(需要自己實現),一致性問題和性能的權衡
Memcache本身沒有數據冗余機制,也沒必要;對于故障預防,采用依賴成熟的hash或者環狀的算法,解決單點故障引起的抖動問題。
mongoDB支持master-slave,replicaset(內部采用paxos選舉算法,自動故障恢復),auto sharding機制,對客戶端屏蔽了故障轉移和切分機制。
5、可靠性(持久化)
對于數據持久化和數據恢復,
redis支持(快照、AOF):依賴快照進行持久化,aof增強了可靠性的同時,對性能有所影響
memcache不支持,通常用在做緩存,提升性能;
MongoDB從1.8版本開始采用binlog方式支持持久化的可靠性
6、數據一致性(事務支持)
Memcache 在并發場景下,用cas保證一致性
redis事務支持比較弱,只能保證事務中的每個操作連續執行
mongoDB不支持事務
7、數據分析
mongoDB內置了數據分析的功能(mapreduce),其他不支持
8、應用場景
redis:數據量較小的更性能操作和運算上
memcache:用于在動態系統中減少數據庫負載,提升性能;做緩存,提高性能(適合讀多寫少,對于數據量比較大,可以采用sharding)
MongoDB:主要解決海量數據的訪問效率問題
評論
查看更多