Windows Server Core 管理与 PowerShell 笔记(二)———— 导航文件系统 这里我们将会简单记录 PowerShell 目录浏览的相关命令。此外还将介绍 PowerShell 的广义启动器变量。 一、PowerShell 的启动器变量 众所周知,Windows 将磁盘驱动器分配盘符,并使用盘符加以访问,比如 C:, D: 等。在 Windows PowerShell 中,驱动器将拥有更加广泛的内涵。我们通过命令 Get-PSDrive 来列出系统中有那些驱动器: PS C:\Users\ertuil> Get-PSDrive Name Used (GB) Free (GB) Provider Root CurrentLocation ---- --------- --------- -------- ---- --------------- Alias Alias C 16.34 23.33 FileSystem C:\ Users\ertuil Cert Certificate \ D FileSystem D:\ Env Environment Function Function HKCU Registry HKEY_CURRENT_USER HKLM Registry HKEY_LOCAL_MACHINE Variable Variable WSMan WSMan 从 Name 属性,可以获知每一个驱动器的名称。比如 C、D 等。从 Provider 属性可以看到除了传统的文件系统 FileSystem 之外,还可以看到更多的属性。
Read more


Windows Server Core 管理与 PowerShell 笔记(一)———— 基础配置 一、Windows Server Core 简介 Windows Server Core 是一个没有完整窗口界面的 Windows Server 版本。在安装 Windows Server 时,如果不选择安装“桌面体验”版本的 Window Server,那么则会安装 Windows Server Core。 启动 Windows Server Core 之后,就会默认打开一个 CMD 窗口。需要启动软件时,可以通过命令启动。另外,按下 Ctrl+alt+Del 可以打开管理界面。任务管理器中也可以启动新任务。除此之外,开始菜单、桌面、文件浏览器一概没有。 Windows Server Core 有如下好处: 没有完整的 GUI 界面,使得内存和硬盘占用更小,特别适合各种虚拟化环境。 没有 Internet Explorer、文件管理器、服务器管理器等常用应用,使得系统的攻击面更小。 可以更加快速的安装、部署和启动在各种容器虚拟化之中。 与此同时,也会有一些问题: 没有很多应用导致没有办法像正常的 Windows 图形界面那样使用和管理 Windows,只能够通过 PowerShell 来进行管理。 可能会导致部分功能缺失,比如缺少Internet Explorer,在使用 Invoke-WebRequest 命令(对应 wget)时,必须使用 -UseBasicParsing 参数,否则会调用并没有安装的浏览器组建来解析内容,因此会报错。 都这样了,为什么不用 Linux 呢? 我也不知道! 二、PowerShell 管理 Windows Server 基本配置 本文即以后可能的命令对于图形界面的 Windows 各种版本都能够使用(其实可以极大的提高桌面 Windows 的使用效率)。
Read more


Windows Server Core 管理与 PowerShell 笔记(零)———— 与 Windows Server 的初次相遇 对于一直使用 Linux 作为服务器操作系统的我,一直对 Windows Server 作为服务器的表现如何非常好奇。最近我读了关于 Windows Server 管理的书,也尝试迁移到 Windows Server 2019。这个系统给了我一个不同于 Linux 的全新体验。尽管使用时间并不长,也确实有一点点自己的感悟。正好借此写一点文字,尝试阐述一下我浅显的看法。 一切皆文件 or 一切皆对象 Linux 的哲学之一,就在于其系统的抽象(包括硬件、软件、进程甚至内存)都被抽象成为一个文件。一切配置都是在文本文件中进行。而 Windows 则截然不同,其大多抽象称为对象:系统的进程是一个个对象、窗口和句柄是一个个对象,注册表中的配置是一个个对象,用户是一个个对象。作为 Windows Server 的核心功能活动目录(AD)来说,也是用管理多种对象的方式实现域控这一个具体的问题。 其实从命令行的方式,就能够非常明显的认识到这一思想上的不同。 Linux 的命令行都是基于文本的,也正是这个原因, grep,awk,sed 这些文本命令会被大量的穿插于 shell 命令行之中。而 Windows 的 PowerShell 命令输入输出的,是一个个对象。举个简单的例子,终止所有进程名以 p 开头的进程。这个例子摘抄于网络,但是很能说明问题。Linux 下是这么写的: ps -e | grep "^p" | awk '{ print $1 }' | xargs kill 在这个过程之中,我们需要使用 grep 来过滤以p开头的进程,用 awk 选取处进程的名字,最后送入 xargs 进行删除。再来看看 Windows 下是如何实现的:
Read more


Mac OS 与 Linux 的目录结构比较 从系统内核说起 传统 Linux 的内核是宏内核,其绝大部分功能都是由一个巨大的内核完成的。而Mac OS 的内核既不是宏内核,也不是微内核。从构成来看应当算混合内核,其核型组建是由卡耐基·梅隆大学开发的 Mach kernel ,其上实现了许多 FreeBSD 的众多组件。最终大部分系统调用都是由 UNIX/BSD 接口提供的,也因此其系统文件目录结构与 Linux 较为相似。 然而在 Linux 常见的文件存放位置确实与 MacOS 以及 FreeBSD 有较大区别,这也常常会给我们带来困扰。因此,有必要对其目录结构进行梳理。我们将从 Linux 的文件结构作为对照,给出相应的区别。 FreeBSD 与 Linux 的不同。 就笔者的感受而言,FreeBSD 与 Linux 的文件存放位置基本一致,只在细微之处存在一星半点的区别。主要有一下几点。 大部分情况下 Linux内核一般放置在 /boot 处,或者直接放在根目录下;而 FreeBSD 存放在 /boot/kernel/kernel 或者 /boot/kernel.old/kernel 中。这种命名很容易让人想起 Windows.old 文件夹,有异曲同工之妙。 FreeBSD 的核心系统和软件会跟随官方代码源 SVN 进行滚动,因此 /bin, /lib, /etc 等文件夹之中的大部分文件都是不建议修改的(会在升级时被覆盖),以此来保证系统的完整性和更新时候的稳定性。默认软件安装、配置全部存放于 /usr/local 之中的 bin, etc, lib, share 等文件夹之下。这样的好处就是用户软件和核心组建分离,不像 Linux 那样在大版本更新时经常遇到各种问题。 Mac OS 的文件系统 在 Majave(10.
Read more


Giving State to the Stateless: Augmenting Trustworthy Computation with Ledgers Gabriel Kaptchuk, Matthew Green, Ian Miers Network and Distributed Systems Security (NDSS) Symposium 2019 一、Introduction 该篇文章做了一次尝试,将可信计算平台(如 Intel SGX, ARM TrustZone 等)与区块链(如 BTC, ETH) 结合,期望实现无状态的可信计算。背景如下: 中心化和去中心化网络已经广泛使用,去中心化网络已被证明可以有更长的寿命和更高的可靠性。 有状态的可信计算环境可能会被攻击(需要外部存储非易失数据、以及监控网络流量等) 可信计算环境的硬件资源有限,特别是非易失存储资源的有限。 解决办法: 将有状态的可信计算环境(TEE)变更为无状态的TEE。使用类似传统 http 的模式提供计算服务。同时引入分布式账单(Ledger)来记录状态。文章给出了一个Host、TEE 和 Ledger 之间的三方协议,来实现该方案。 对于通常的服务,可以用如下公式形式化描述:P是给定程序,对于输入Ii,当前状态Si和随机代价ri,产生确定输出Oi和新的状态Si+1。 $$ P(I_i,S_i,r_i) \rightarrow O_i,S_i+1 $$ 文章对上述模型做了一下修正,以提高安全性: Attempt 1: 加密程序状态,无法抵御重放攻击 Attempt 2: 使用 Ledger 存储状态信息,也无法抵御回放攻击 Attempt 3: 使用 Ledger 绑定程序的输入。通过向 Ledger 中提交输入,可以解决上述攻击。 Attempt 4: 随机化。为了防止恶意Host 复制程序执行,采用伪随机数发生器,产生随机代价??? Extension 1: 减少 Ledger 带宽 … Extension 2: 增加公共输入输出 Extension 3: 指定程序 二、模型 文章给出模型的三个参与者:
Read more

Linux_FileSystems

27.03.2019  in linux

Linux 下文件系统性能的简单评测 其实这篇文章的数据源早在19年2月份就已经完成了 … 主要是为了看看 Linux 系统中那么多文件系统在实际使用时的性能表现如何,特别是为了考察 2019 年初 btrfs 性能能否基本满足日常使用。值得注意的是,测试使用了 MacBook Pro 2016 的固态硬盘,对于机械硬盘结果可能有较大差别。 这次测试主要是在 Linux Kernel 4.20 和 3.10 两个版本中进行测试,可以看到在内核几年的发展过程中,文件系统的性能有了非常明显的提升。测试中还引入了 ZFS 这个广泛使用与 FreeBSD 的重量级文件系统,可惜不知道是不是笔者配置原因, openzfs 在 Linux 4.20 中没有办法使用,因此只有 3.10 的数据。 测试方法 为了忽略文件系统底层细节,也为了尽可能模拟日常使用中的任务。我选择使用 mdtest 工具,模拟文件的创建、读取、修改、删除;文件夹创建、读取、删除;以及文件树的创建、删除。每次测三次,取平均。 ./mdtest -d /mnt/test/ -n 10000 -i 测试机器 Macbook Pro 2016 i5-6360u 8GB LPDDR3 256G PCIE SSD 数据 Kernel 3.10 Kernel 4.20 结论 从结论来看: 文件系统性能有着较大提升,其中 xfs 、 btrfs 等提升较为明显。 目前来看, ext2 文件系统性能最好,但是考虑到其年代过于久远,没有日志等特点,不再推荐使用。 ext3,ext4 文件系统性能也较为优异。 xfs, btrfs 等由于引入 COW 特性,导致对于文件删除性能有较大差距。 普遍来看,目前对于性能要求较高则推荐使用 xfs 和 ext4 文件系统。 btfrs 性能提升非常之大,如果需要使用其高级功能,则可以考虑使用(从官网上看,除了磁盘限额有性能问题、raid 5⁄6 模式可能有bug外基本稳定。 zfs 在 linux 下可能由于驱动原因,性能较差,不适合用于重度使用
Read more


Measurement and Analysis of Hajime, a Peer-to-peer IoT Botnet Stephen Herwig, Katura Harvey, George Hughey, Richard Roberts, Dave Levin Network and Distrubuted Systems Security(NDSS) Symposium 2019 这篇文章主要介绍了作者近距离的观察了一个基于 P2P 协议的物联网僵尸网络。该网络目前没有发动过攻击的记录。 文章指出,该网络与其他僵尸网络的有一下显著特征: 并非传统中心化 command-and-control(C&C)网络,而是分布式的。 对于多种物联网芯片架构有着广泛的支持:mips、arm等 文章中说:该网络的卓越之处不在于其已经发生的攻击,而在于其让研究人员深刻的认识到了物联网设备的脆弱性。 论文中主要有如下发现: 物联网特征使得僵尸网络的规模变得很大(超过 95000 活跃机器) 各种 CPU 架构都容易遭受攻击。但是架构的分布与国家有明显相关性(美国感染设备大部分是 arm5 架构,而巴西则主要是 mips 设备。 设备的平均在线时间大约是 5 小时,其暗示物联网设备会经常性重启和重新感染。 物联网僵尸网络传播速度极快。 历程 论文观察到了僵尸网络的多次更新,这些更新常常伴随着新的漏洞的利用,导致大量新设备的感染。僵尸网络通过 uTP 协议对更新进行广播,每次更新后,可以观测程序更新迅速在网络中传播。 其他特性 论文观察了僵尸网络大小变化、感染设备寿命、地理位置分布、设备架构、攻击频率等性质。 有趣的是,文中指出中国广泛存在多个设备公用一个IP(暗示 nat 的使用),而巴西则同一个设备分配了多个 IP 地址。IP地址分配不均匀非常显著! 结论 Hajime 作为新的超大物联网僵尸网络,其规模已经 incredibly(豆豆口气)的大,地理分布广泛,且高可靠。研究该僵尸网络有助于观察互联网的各种特征。
Read more


Countering Malicious Processes with Process-DNS Association. Suphannee Sivakorn, Kangkook Jee, Yixin Sun, Lauri Korts-Pa¨r, Zhichun Li, Cristian Lumezanu, Zhenyu Wu, Lu-An Tang, Ding Li. Ndss 2019 这篇论文主要讲了如何在企业服务器上设置 DNS 监控器来监控所有进程级别的DNS查询,通过地理位置、IP、查询时间、whois 等信息来辨别恶意进程。文章中实现了 PDNS 的模型来监控进程 DNS 查询,而后由机器学习网络和传统方式结合来标示恶意进程,实现了较高的准确率和较低的假阳性和假阴性率。 可能有一个问题在于其中获取了所有 DNS 查询的domain 、 频率、IP 等信息,并发送给服务器,可能导致隐私的泄露。这里是一个可以改进的地方。 Background 传统基于 dns 的查询只能区分到机器级别存在有风险的dns查询 目前大量恶意进程使用类似 twitter, github 等正常网站的服务来隐藏其恶意性,给传统 dns 检测机制带来挑战。 Archtecture PDNS 通过多种路径获取 Hosts 上的 DNS 查询记录。 客户机上 dns 查询情况及其他信息(IP 、domain、location 以及进程名、加载的动态链接库、查询频率、主机名、软件发布者签名及证书等信息) 网络上对于 DNS 链路的捕捉 Dns 服务器上的查询情况(记录的创建时间、生存时间、TTL、nameserver、域名、IP和域名的位置信息、whois信息等) 这些数据发送给 PDNS 服务器用于训练模型和预测。
Read more


OBLIVIATE:A Data Oblivious File System for Intel SGX Adil Ahmad, Kyungtae Kim, Muhammad Ihsanulhaq Sarfaraz, Byoungyoung Lee. Ndss 2018 这篇主要讲了使用 SGX 技术实现了一个可用于web服务的混淆文件系统,用于在不可信服务器上提供隐私数据的 Web 服务。主要是用来对抗包括page failed等侧信道攻击。 该方案亮点在于结合了 SGX 和 ORAM 算法来混淆文件读取的偏移量等信息,使用 cmov 条件转移指令来混淆读取内存内容。但是性能上有一定损失。 为了应对三种 Side-Channel Attacks: Syscall Snooping Attacks: SGX 调用 ocall 过程中,向内核泄漏信息。 Page Fault Attacks: 当 EPC 页面第一次加载时,触发 Page Fault Attacks,可能泄漏信息。 Cache Based Attacks:各级缓存中泄漏信息。 方案: SGX 和 ORAM 算法结合,来混淆对文件系统读取时的偏离量。Path ORAM 算法简介: 采用完全二叉树结构。叶子节点数等于真实节点数。灰色标记的 abcd 节点为真实数据节点,efg为dummy 节点(随机填充)。另外有一张 Position map 表(加密存放于 SGX 中,指向真实节点位置。
Read more