首页/网络/常用端口速查/260 openport 开放端口服务
200-299 系统端口54 条

260 openport 开放端口服务

Openport:1990 年代注册的服务名,仅存注册表记录,无 RFC 与公开实现。

常用端口速查网络更新于 2026-10-13

openport 是什么

openport 是注册在 260 上的 IANA 服务名,1990 年代由 John Marland 提交,注册表里只有名字和提交人,没有协议文档、没有 RFC,也查不到实现记录。它经常被误认为是某种「端口开放检测」工具,其实这个名称只表示当年某个服务希望使用该编号,与端口扫描器、放行策略都没有关系。260 在 0-1023 的知名端口段内,绑定需要 root 或 CAP_NET_BIND_SERVICE,所以现网若有监听,通常来自被手工指定端口的老系统。

基本信息

服务名openport
端口与协议260,TCP 与 UDP 均有登记
注册情况IANA 登记项,无 RFC 文档
登记背景1990 年代,注册人 John Marland
现网现状无公开实现,现网极少出现
权限要求0-1023 段端口,绑定需 root 或 CAP_NET_BIND_SERVICE

典型使用场景

  • 暴露面盘点:扫描发现 260 监听时,按未登记业务走核实流程,而不是套用名称含义下结论
  • 误报排除:收到「openport 端口开放」这类含糊描述时,要求给出进程与对端,避免名称误导处置方向
  • 防火墙评审:放行申请必须写明程序与访问来源,无名编号的申请尤其需要业务方书面确认
  • 遗留系统归档:确认是老系统固定端口后,登记到端口分配表并标注注册名与现网实际用途
  • 应急排查:陌生主机上出现 260 时,先看进程启动时间与父进程,再决定隔离还是继续观察

定位与排查

定位与排查
ss -lntup 'sport = :260'    # 查看 260 的监听进程与运行用户
sudo lsof -i :260    # 反查二进制路径,确认程序来源
awk '$2 ~ /:0104$/ {print}' /proc/net/tcp    # 十六进制端口,260 = 0x0104
nmap -sV -p 260 10.0.0.10    # 探测对端 260 的实际服务与版本
sudo tcpdump -nni any port 260    # 抓包区分监听与出站连接
netstat -ano | findstr :260    # Windows 侧查法,拿到 PID 后再看进程

ss 输出逐列读法

列含义关注点
State套接字状态,LISTEN 监听、UNCONN 为 UDP 无连接态无业务方认领的 LISTEN 要重点核查
Recv-Q接收队列里未被读取的字节数长期不为 0 说明程序没在读数据
Send-Q发送队列里未被确认的字节数监听态一般显示内核 backlog 上限
Local Address:Port:260 监听全部网卡,127.0.0.1:260 仅本机只要本机访问就不需要对外放行
Process程序名与 PID,需要权限才可见程序名可疑时用 ps -fp 与 ls -l /proc/PID/exe 复核
编号名称带有「open」这类词,很容易被当成安全结论使用,例如误以为「该端口开放是设计如此」。注册表里的名称只是提交者当时填写的服务名,不代表任何策略含义;判断是否该开放,要回到业务方、进程和访问来源这三件事上。

易错点

  • 把注册名当成设计依据:名称不代表策略,是否放行必须由业务方与访问来源决定
  • 用端口号推断服务名:冷门编号被后来程序抢占的情形常见,结论要回到进程与二进制
  • 未定位进程就先封端口:可能切断仍在用的老业务,现场消失后取证更难
  • 只在边界封禁而不同步主机侧与云安全组:内部横向路径仍然可达,风险并未消除
  • ss 不加 sudo 看不到进程列:容易得出「没有程序占用」的错误结论

数据来源与参考

  • IANA Service Name and Transport Protocol Port Number Registry

相关工具

​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌