赞
踩
最近突然对大语言模型感兴趣
同时在平时的一些线下断网的CTF比赛中,大语言模型也可以作为一个能对话交互的高级知识检索库
本篇文章旨在记录我在本地部署大语言模型的过程
Ollama是一个轻量级、可扩展的框架,旨在帮助用户在本地机器上构建、运行和分享大语言模型。
前往Ollama的官网Ollama下载最新版本的安装包
需要注意的是,该软件默认安装在C盘下,所以如果有精神洁癖的小伙伴也可以使用docker部署Ollama
在终端中输入ollama --version
返回版本信息,说明安装成功
前往系统环境变量设置,添加如下系统变量
重启Ollama
目前在Ollama上,Gemma模型已经拥有超过430K的拉取次数。基本上Gemma可以算是Ollama最热门的模型了
Gemma提供了不同参数规模的版本,2b(20亿参数)和7b(70亿参数)。参数的数量直接影响了模型对语言的理解能力,更多的参数通常意味着更好的理解、生成和预测能力,但同时也需要更强大的计算资源和更长的处理时间
每个参数版分为轻量版和全量版,2b模型即便是在没有独显的笔记本电脑上都能尝试运行,而规模更大的7b、7b全量版分别需要8GB和16GB显存。
因为本人的笔记本显卡是RTX 3070Laptop,为了防止显卡撑爆,选择部署2b全量版
首先确保Ollama框架有在运行,在终端中输入ollama pull gemma:2b-instruct-fp16
拉取模型
gemma后跟的是参数版本
拉取模型的过程中尽量开代理,因为Ollama的数据库在海外
提示success
说明拉取成功
Mistral 7B 是一款拥有70亿参数的精心设计的语言模型,旨在实现卓越性能和高效运行。它在各类基准测试中表现出色,超越了当前最佳的开源13B模型——Llama 2,并在推理能力、数学计算精准度以及代码生成任务上均超越了已公开的34B模型——Llama 1
执行ollama pull qwen:7b
拉取模型
考虑到本地部署时对硬件的要求,我们不得不选取参数量较小的模型
通常的游戏笔记本的显卡内存在4G到8G之间,对应的模型参数量范围在20亿到70亿间
而今年年初阿里巴巴开源的Qwen1.5恰好有一个70亿参数量的版本,显存占用在7G左右,非常适合在中高端游戏本上部署
执行ollama pull mistral:latest
拉取模型
code llama在llama2模型的基础上,利用代码数据进行训练和微调,提高了llama2在代码生成上的能力
code llama提供了三种模型,每种模型包含7B,13B,34B三个尺寸,支持多种编程语言,如Python, C++, Java, PHP, Typescript (Javascript), C#, Bash等。
这里我们选用基础模型,执行ollama pull codellama:7b
拉取模型
Open WebUI是目前GitHub上开源的类Chatgpt前端界面中,star数量最多的框架之一
而更重要的是Open WebUI的前身即Ollama WebUI,所以它对于Ollama的支持非常好
执行下面的指令来拉取并部署Open WebUI的docker容器
docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
在浏览器上访问https://localhost:3000
点击加号添加刚刚拉取的所有模型,方便后续同时测试多个模型
在本文章中,会对部署在本地的模型进行相同的提问测试,包括知识广度和代码能力
首先是知识广度上的测试,我们询问2道安全岗的面试题
- 请向我介绍一下蜜罐技术
Mistral从原理和应用上全方位介绍了蜜罐技术,它的回答不仅准确,用词也非常专业。
Qwen的回答非常模板化,使用总分总的形式展开回答,但相比Mistral的回答少一些实用细节
Gemma的回答虽然详细但完全不适用,因为它误解了蜜罐技术的定义,说明它在知识广度上和其他模型存在差距
Codellama的回答提供了一个与网络安全不同的视角,专注于使用蜜罐收集用户行为数据的概念。虽然这种用法在市场研究和用户行为分析中可能有其价值,但它与蜜罐技术在网络安全领域的典型应用相去甚远。
- 信息收集如何处理子域名爆破的泛解析问题?
MIstral回答如下
During information gathering or subdomain enumeration, an attacker may use techniques like DNS brute-forcing or subdomain enumeration tools to discover potential subdomains of a target domain. One common issue they might encounter is the presence of Zone Transfer (MX) records or CNAME records pointing to IP addresses with open resolver servers or to other domains, which can facilitate the discovery of additional subdomains through a process called transitive name resolution, also known as “glue” or “tied” records.
To mitigate this issue, organizations can take several steps when handling subdomain enumeration:
- Disable Open Resolver Servers: Ensure that your DNS servers are not configured to respond to unsolicited recursive queries from external sources. This will prevent attackers from using them as a means to discover additional subdomains through transitive name resolution.
- Configure Response Rate Limiting (RRL): Implement RRL on your DNS servers to limit the number of requests that can be sent by a single source in a given time frame. This will help prevent attackers from quickly enumerating multiple subdomains using brute-forcing tools.
- Filter Out Undesired Records: Use firewalls and access control lists (ACLs) to block or filter out unnecessary DNS records, such as MX records that contain open resolver servers or CNAME records pointing to external domains.
- Monitor for Anomalous Activity: Set up intrusion detection systems (IDS) and security information and event management (SIEM) solutions to monitor and alert on anomalous DNS queries, such as rapid subdomain enumeration attempts.
- Implement Honeypots and Decoys: Use Honeypot technologies and decoy domains to misdirect attackers from the real infrastructure. This can help protect sensitive information and resources while also providing valuable intelligence about the attacker’s tactics, techniques, and procedures (TTPs).
- Regularly Update DNS Records: Ensure that your subdomain records are updated regularly to minimize the exposure of old or outdated services or applications. This will help reduce the likelihood of discovery through enumeration attempts.
- Implement DNS Security Extensions: Use DNS security extensions such as DNSSEC and DANE to secure your DNS infrastructure and prevent attackers from manipulating or poisoning your records.
Gemma回答如下
信息收集如何处理子域名爆破的泛解析问题取决于具体情况,以下是一些常见解决方案:
1. 分析泛解析结果
- 首先,需要确认子域名是否真正属于您。您可以通过域名注册页面或 DNS 管控器的 DNS 查询来查询子域名是否指向您指定的服务器。
- 您可以分析泛解析结果的来源,例如,如果子域名来自根域名注册服务器,那么它可能被恶意攻击者通过 DNS poisoning攻击。
- 您可以分析泛解析结果的记录,例如,如果记录中存在一个指向恶意网站的记录,则可能是一个恶意攻击者的攻击目标。
2. 识别恶意记录
- 恶意记录通常包含以下特征:
- 与您网络相关的名称,例如子域名或 IP 地址。
- 与您的网站或服务相关的名称。
- 与其他恶意记录相同的语法或内容。
- 与您服务器连接的端口或协议。
- 与您网站上部署的软件或工具相关的名称。
- 您可以使用工具,例如 iRule 或 Nessus,来分析网络记录并识别恶意记录。
3. 阻止恶意记录
- 您可以使用 DNS 过滤器或其他安全工具来阻止恶意记录的创建或更新。
- 您可以使用 DNS 记录过滤技术来阻止特定子域名或 IP 地址访问特定网站或服务。
- 您可以使用反恶意软件扫描工具来扫描您的网络,以识别并删除恶意软件。
4. 监控子域名的变化
- 定期检查子域名的 DNS 记录,以确保它们仍然指向您的服务器。
- 如果您发现子域名已改变指向恶意网站,请立即采取行动。
5. 考虑实施安全措施
- 使用 SSL 证书来加密您的网站连接。
- 使用防火墙和入侵检测系统 (IDS) 来保护您的网络。
- 使用安全软件,例如恶意软件扫描工具和 DNS 过滤工具,来保护您的设备和数据。
- 确保您的设备和软件的更新及时完成。
请注意,处理子域名爆破的泛解析问题需要专业技能和经验,建议您寻求安全专家或安全团队的帮助。
在这个问题上,Codellama的回答显然优于其他三种模型,因为他理解了信息收集的含义,所以提出了攻击建议而不是防御建议
在代码能力上,我们让模型进行代码审计,来测试它们对代码的理解能力
问题如下
<?php // 获取用户提交的用户名 $username = $_GET['username']; // 连接到数据库 $conn = new mysqli('localhost', 'user', 'password', 'database'); // 检查连接 if ($conn->connect_error) { die("连接失败: " . $conn->connect_error); } // 构造SQL查询,这里存在SQL注入的风险 $sql = "SELECT * FROM users WHERE username = '$username'"; $result = $conn->query($sql); if ($result->num_rows > 0) { // 输出每一行数据 while($row = $result->fetch_assoc()) { echo "id: " . $row["id"]. " - Name: " . $row["name"]. " - Email: " . $row["email"]. "<br>"; } } else { echo "0 结果"; } $conn->close(); ?>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
请识别上述PHP代码中存在的安全漏洞,并解释为什么这些部分是脆弱的。如果有的话,请提出对上述代码进行优化的建议,以提高其效率和安全性。
这段代码存在SQL注入漏洞
Mistral回答如下
The given PHP code has several security vulnerabilities:
- SQL Injection: The code uses user-supplied input ($username) directly in the SQL query without any form of validation or sanitization. This makes it vulnerable to SQL injection attacks where an attacker can inject malicious SQL statements and potentially gain unauthorized access to sensitive data, modify or delete data, or even take control of the database server. To mitigate this risk, it’s recommended to use prepared statements with parameterized queries instead of directly inserting user input into the query string. This will help ensure that any user input is treated as literal values rather than SQL code.
- Lack of Input Validation: The code does not check if the user-supplied ‘username’ parameter is valid or within expected format. This can lead to unexpected behavior and potential security issues. It’s important to validate user input, for example by checking its length, character set, or using regular expressions.
- Lack of Error Handling: The code does not have proper error handling mechanisms in place. If the query fails due to an SQL syntax error, the code will simply display a generic error message “连接失败:”. It’s important to handle errors gracefully and provide informative error messages to the user.
- Insecure Database Credentials: The database credentials are hardcoded in the script which is not recommended as it can expose sensitive information if the source code gets compromised. Instead, use environment variables or configuration files that are not accessible to the public.
- Use of mysqli_ instead of PDO: While both are PHP extensions for interacting with databases, MySQLi is considered less secure than PDO since it does not support prepared statements by default and lacks some advanced features like statement binding. It’s generally recommended to use PDO over MySQLi for better security and ease-of-use.
To improve the code, consider the following suggestions:
- Use Prepared Statements with Parameterized Queries: Replace the current SQL query construction method with prepared statements and parameterized queries which will help prevent SQL injection attacks by ensuring that user input is treated as literal values.
- Input Validation: Validate user input before processing it to ensure that it meets expected format and length requirements. Use regular expressions or other validation functions to check the input.
- Proper Error Handling: Implement error handling to provide informative error messages to the user in case of any SQL query failures. This will help prevent potential attacks by providing minimal information to attackers.
- Keep Database Credentials Secure: Do not hardcode database credentials in the script. Instead, use environment variables or configuration files that are not accessible to the public.
- Use PDO instead of MySQLi: Consider using PHP Data Objects (PDO) extension for better security and ease-of-use since it supports prepared statements by default and has advanced features like statement binding which can help prevent SQL injection attacks.
Mistral准确地识别了SQL注入漏洞,并提供了标准的解决方案,即使用预处理语句和参数化查询。同时Mistral正确指出了缺乏输入验证和错误处理的问题。
Qwen的回答依然非常简短,虽然它正确识别出了SQL注入的漏洞并给出了优化建议,但它提到了未正确关闭数据库,很明显是对代码的误解
Gemma识别出了SQL注入漏洞,并提出了一系列防御措施。然而,一些建议表述可能不够精确,特别是关于用户输入处理的部分。
Codellama的回答中,对代码的优化建议最为全面
模型 | 知识广度 | 代码理解能力 |
---|---|---|
Mistral | 高 | 高 |
Qwen | 中 | 中 |
Gemma | 中 | 中 |
Codellama | 高 | 高 |
经过简单的测试,Mistral和Codellama的表现相对来说更加出色,能够部分满足我们对本地大模型的需求
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。