网文收集
基于TCP/IP协议的服务很多,人们比较熟悉的有WWW服务、FTP服务、电子邮件服务,不太熟悉的有TFTP服务、NFS服务、Finger服务等等。这些服务都存在不同程度上的安全缺陷,当用户构建安全可信网络时,就需要考虑,应该提供哪些服务,应该禁止哪些服务。同时,在使用这些服务的时候,你可能没有想到,TCP/IP从一开始设计的时候就没有考虑到安全设计。
TCP/IP存在脆弱性
IP层的主要曲线是缺乏有效的安全认证和保密机制,其中最主要的因素就是IP地址问题。TCP/IP协议用IP地址来作为网络节点的惟一标识,许多 TCP/IP服务,包括Berkeley中的R命令、NFS、X Window等都是基于IP地址对用户进行认证和授权。当前TCP/IP网络的安全机制主要是基于IP地址的包过滤(Packet Filtering)和认证(Authentication)技术,它的有效性体现在可以根据IP包中的源IP地址判断数据的真实性和安全性。然而IP地址存在许多问题,协议的最大缺点就是缺乏对IP地址的保护,缺乏对IP包中源IP地址真实性的认证机制与保密措施。这也就是引起整个TCP/IP协议不安全的根本所在。
由于UDP是基于IP协议之上的,TCP分段和UDP协议数据包是封装在IP包中在网络上传输的,因此同样面临IP层所遇到的安全威胁。现在人们一直在想办法解决,却仍然无法避免的就是根据TCP连接建立时“三次握手”机制的攻击(如图1)。这些攻击总结起来包括:
源地址欺骗(Source Address Spoofing)或IP欺骗(IP Spoofing);
源路由选择欺骗(Source Routing Spoofing);
路由选择信息协议攻击(RIP Attacks);
鉴别攻击(Authentication Attacks);
TCP序列号欺骗(TCP Sequence number spoofing);
TCP/IP协议数据流采用明文传输;
TCP序列号轰炸攻击(TCP SYN Flooding Attack),简称SYN攻击;
易欺骗性(Ease of spoofing)。
![]() 图1
比如网管员都熟悉的因特网控制信息协议(ICMP),它是TCP/IP协议组的一个基本网络管理工具,在帮助网络管理人员排除网络故障中立下了汗马功劳,同时ICMP攻击却十分猖狂。最明显的是ICMP重定向报文,它被网关用来为主机提供好的路由,却不能被用来给主机的路由表进行主动的变化。如果入侵者已经攻破一个对目标主机来说可利用的次要网关,而不是基本网关,入侵者就可以通过有危险的次要网关给信任主机设置一个错误的路由。多数的服务主机在TCP重定向报文上不实行有效检查,这种攻击的影响和基于RIP的攻击相似。
另外,ICMP也可以被用来进行拒绝服务攻击(如图2)。个别的报文如目标不可达或者超时,就可以用来重置目前的连接,如果入侵者知道TCP 连接的本地及远端的端口号,将生成该连接的ICMP 报文。有时这样的信息可以通过NETSTAT服务来实现。一个更普遍的拒绝服务攻击是发送伪造的子网掩码回应报文。无论主机是否查询,它们都将接受该报文,一个错误的报文就可能阻塞目标主机的所有连接。
![]() 图2
应用服务不容乐观
1.文件传输协议
FTP经久不衰的原因在于它可以在互联网上进行与平台无关的数据传输,它基于一个客户机/服务器架构。FTP 将通过两个信道(端口)传输,一个传输数据(TCP 端口 20),另一个传输控制信息(TCP 端口 21)。在控制信道之上,双方(客户机和服务器)交换用于发起数据传输的命令。一个 FTP 连接包含4个步骤:用户鉴权→建立控制信道→建立数据信道→关闭连接。FTP 的连接控制使用 TCP (Transmission Control Protocol, 传输控制协议),它保障了数据的可靠传输。因此,FTP 在数据传输中不需要关心分组丢失和数据错误检测。
匿名FTP作为互联网上广泛应用的服务,安全等级的低下受到了黑客的频繁光顾。匿名FTP 是真的匿名,并没有记录谁请求了什么信息,谁下载了什么文件,上传了什么东西(有可能是木马)。FTP存在着致命的安全缺陷,FTP使用标准的用户名和口令作为身份验证,缺乏有效的访问权限的控制机制,而其口令和密码的传输也都是明文的方式。
2.Web服务
Web服务器位于宿主基础结构的前端,它与Internet直接相连,负责接收来自客户端的请求,创建动态Web页并响应请求数据。最初WWW服务只提供静态的HTML页面,为改变人们对网络互动请求的愿望,开始引入了CGI程序,CGI程序让主页活动起来。CGI程序可以接收用户的输入信息,一般用户是通过表格把输入信息传给CGI程序的,然后CGI程序可以根据用户的要求进行一些处理,一般情况下会生成一个HTML文件,并传回给用户。很多CGI 程序都存在安全漏洞,很容易被黑客利用做一些非法的事情。现在很多人在编写CGI程序时,可能对CGI软件包中的安全漏洞并不了解,而且大多数情况下不会重新编写程序的所有部分,只是对其加以适当的修改,这样很多CGI程序就不可避免的具有相同的安全漏洞。很多 SQL Server 开发人员并没有在代码编写开始的时候就从安全防护基础开始,这样就无法确保您开发的代码的安全性,其结果就造成了无法将应用程序的运行控制在所需的最低权限之内。
如果Web 服务需要输出敏感的、受限的数据,或者需要提供受限的服务,则它需要对调用方进行身份验证。如果客户访问都是在一个可信的域中,我们就完全可以放心使用,但在实际应用中是不可能实现的。所以,系统级的身份验证也就无法实现,至少在现阶段无法实现。例如:可以使用IIS为基本身份验证配置Web服务的虚拟目录。通过这种方式,使用者必须配置代理,并提供用户名和密码形式的凭据。然后在每次Web服务通过代理请求的时候由代理传递它们。这些凭据是以明文形式传递的,所以应该只在SSL中使用基本身份验证(如图3),但很少有管理员这样做。
![]() 图3
另外,Web服务本身不提供容错机制。如果Web服务采用了软件冗余技术,就可以保证一个版本出错,另一个版本就很少有机会出现相同的错误。代码的重复利用不能保证错误的完全避免,因此在某个模块发生某个物理故障时,其他模块也就完全瘫痪。
随着Java Applet、ActiveX、Cookie等技术的大量应用,当用户使用浏览器查看、编辑网络内容时,采用了这些技术的应用程序会自动下载并在客户机上运行,如果这些程序被恶意使用,就可能窃取、改变或删除客户机上的信息。对于恶意程序的侵害,用户很难实时判断程序性质,因此,在获得高度交互的Web服务时,如何抵御这些安全威胁绝非简单的客户端设置就可以解决的。
提高网络可信度
前面我们已经提到了IPv4存在的弊端,很多安全防范技术被忽略了,它不可避免地被新一代技术IPv6取代。IPsec安全协议就是事后发展的一种协议(如图4),而NAT(网络地址转换,Network Address Translation)解决了IP地址短缺的问题,却增加了安全风险,使真正的端到端的安全应用难以实现。端到端安全性的两个基本组件——鉴权和加密都是IPv6协议的集成组件;而在IPv4中,它们只是附加组件,因此,采用IPv6安全性会更加简便、一致。
![]() 图4
在现在的网络环境中,尤其是园区网当中,由于不存在NAT地址转换的问题,所以IPSec具备允许部署可信计算基础架构的基本特征。IPSec数据包验证能够确保整个IP报头、下一层协议(例如TCP、UPD或ICMP)报头以及数据包有效负载的数据完整性。
另外,针对数据包的单向Hash算法用以提供校验和。通信发起方计算校验和并在发送之前将其附加到数据包中;响应方则在收到数据包后为其计算校验和。如果响应方所计算出的校验和与数据包中附带的校验和完全匹配,则证明数据包在传输过程中未被修改。校验和的单向计算特性意味着其取值无法在传输过程中进行修改,这也就保证了端到端的数据传输过程的可信程度。
----------------------------------------------------------------------------------------------------------------------
1. 前言
TCP通信时,如果发送序列中间某个数据包丢失,TCP会通过重传最后确认的包开始的后续包,这样原先已经正确传输的包也可能重复发送,急剧降低了TCP性能。为改善这种情况,发展出SACK(Selective Acknowledgment, 选择性确认)技术,使TCP只重新发送丢失的包,不用发送后续所有的包,而且提供相应机制使接收方能告诉发送方哪些数据丢失,哪些数据重发了,哪些数据已经提前收到等。
2. SACK选项
SACK信息是通过TCP头的选项部分提供的,信息分两种,一种标识是否支持SACK,是在TCP握手时发送;另一种是具体的SACK信息。
2.1 SACK允许选项
该选项只允许在有SYN标志的TCP包中,也即TCP握手的前两个包中,分别表示各自是否支持SACK.
2.2 SACK选项
选项类型: 5
选项长度: 可变,但整个TCP选项长度不超过40字节,实际最多不超过4组边界值。
该选项参数告诉对方已经接收到并缓存的不连续的数据块,注意都是已经接收的,发送方可根据此信息检查究竟是哪个块丢失,从而发送相应的数据块。
* Left Edge of Block
不连续块的第一个数据的序列号。
* Right Edge of Block
不连续块的最后一个数据的序列号之后的序列号。表示(Left Edge - 1)和(Right Edge)处序列号的数据没能接收到。
3. SACK的产生
SACK通常都是由TCP接收方产生的,在TCP握手时如果接收到对方的SACK允许选项同时自己也支持SACK的话,在接收异常时就可以发送SACK包通知发送方。
3.1 对中间有丢包或延迟时的SACK
如果TCP接收方接收到非期待序列号的数据块时,如果该块的序列号小于期待的序列号,说明是网络复制或重发的包,可以丢弃;如果收到的数据块序列号大于期待的序列号,说明中间包被丢弃或延迟,此时可以发送SACK通知发送方出现了网络丢包。
为反映接收方的接收缓存和网络传输情况,SACK中的第一个块必须描述是那个数据块激发此SACK选项的,接收方应该尽可能地在SACK选项部分中填写尽可能多的块信息,即使空间有限不能全部写完,SACK选项中要报告最近接收的不连续数据块,让发送方能了解当前网络传输情况的最新信息。
3.2 对重发包的SACK(D-SACK)
RFC2883中对SACK进行了扩展,在SACK中描述的是收到的数据段,这些数据段可以是正常的,也可能是重复发送的,SACK字段具有描述重复发送的数据段的能力,在第一块SACK数据中描述重复接收的不连续数据块的序列号参数,其他SACK数据则描述其他正常接收到的不连续数据,因此第一块SACK描述的序列号会比后面的SACK描述的序列号大;而在接收到不完整的数据段的情况下,SACK范围甚至可能小于当前的ACK值。通过这种方法,发送方可以更仔细判断出当前网络的传输情况,可以发现数据段被网络复制、错误重传、ACK丢失引起的重传、重传超时等异常的网络状况。
4. 发送方对SACK的响应
TCP发送方都应该维护一个未确认的重发送数据队列,数据未被确认前是不能释放的,这个从重发送队列中的每个数据块都有一个标志位 “SACKed”标识是否该块被SACK过,对于已经被SACK过的块,在重新发送数据时将被跳过。发送方接收到接收方SACK信息后,根据SACK中数据标志重发送队列中相应的数据块的“SACKed”标志,但如果接收不到接收方数据,超时后,所有重发送队列中数据块的SACKed位都要清除,因为可能接收方已经出现了异常。
5. SACK应用举例
发送方发 接收方接 接收方发送的ACK
送的数据 收的数据 (包括SACK)
5.1 SACK累加接收的数据
5.2 数据包丢失,ACK丢失
5.3 数据段丢失和延迟
5.4 数据段丢失且延迟
6. 结论
通过SACK选项可以使TCP发送方只发送丢失的数据而不用发送后续全部数据,提高了数据的传输效率。
-------------------------------------------------------------------------------------------------------------------
现在C3750的文件系统做一个总结。
查看文件系统。默认是flash.
dir all (flash: )
show file system
更改目录:
cd xx
pwd (查看当前目录)
新建目录:
mkdir xx
删除目录:
delete/force(不再询问确认)/recursive(删除目录下的子目录和文件)
如果是flash: (整个flash),如果是目录,则是整个目录。
不可恢复。
copy,还是复制。
创建一个tar文件:
archive tar/creat x……(目的) x……(源)
查看一个tar包含的文件:
archive tar/table xxx.tar
解压缩一个tar文件:
archive tar/xtract xxx.tar flash: (解压缩整个tar,只能解到当前flash)
archive tar/xtract xxx.tar flash:/xxxxx (指定解压缩整个tar,或其中某个文件,目录)
查看一个可读文件的内容:
more xxx (可以是远程的,如TFTP)
配置文件:
cisco.com上提供的ios为tar格式。包含的文件见文档。
升级IOS文件:
archive download-sw/overwrite(覆盖原IOS)/reload(重启) ftp://x.tar
或者
archive download-sw/leave-old-sw(保留原IOS)/reload(重启) ftp://x.tar
download时会有算法来验证新IOS是否适合当前模块和内存,否则会报错。
如查选用/overwrite,不管down的IOS是否与现在相同,都会被删除。
download完成后,会自动将boot参数指向新IOS.
(文档虽然没讲,但是我想,有足够flash空间的情况下,还是不要覆盖原IOS,传完再删)
上传IOS文件:
archive upload-sw ftp://x.tar
上传算法会自动把多个系统文件生成为。tar ,并上传。
(详细系统组成文件见文档937页):info, the Cisco IOS image, and the web management files.
IOS恢复参见文档里的Troubleshooting部分
升级前后对比:
升级前:
Switch#dir flash:
Directory of flash:/ 5 drwx 192 Mar 01 1993 00:03:52 c3750-i9-mz.121-19.EA1d 15998976 bytes total (9545728 bytes free) Switch# Switch#sh ver Cisco Internetwork Operating System Software IOS (tm) C3750 Software (C3750-I9-M), Version 12.1(19)EA1d, RELEASE SOFTWARE (fc 1) Copyright (c) 1986-2004 by cisco Systems, Inc. Compiled Mon 05-Apr-04 22:40 by antonino Image text-base: 0x00003000, data-base: 0x007CBC3C ROM: Bootstrap program is C3750 boot loader BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.1(19r)EA1b, RELEASE SOFTWA RE (fc2) Switch uptime is 16 minutes System returned to ROM by power-on System image file is "flash:c3750-i9-mz.121-19.EA1d/c3750-i9-mz.121-19.EA1d.bin" cisco WS-C3750G-12S (PowerPC405) processor (revision H0) with 118776K/12288K byt es of memory. Processor board ID CAT0849N2YU Last reset from power-on 1 Virtual Ethernet/IEEE 802.3 interface(s) 12 Gigabit Ethernet/IEEE 802.3 interface(s) The password-recovery mechanism is enabled. 512K bytes of flash-simulated non-volatile configuration memory. Base ethernet MAC Address : 00:129:97:7C:80 Motherboard assembly number : 73-8307-08 Power supply part number : 341-0048-01 Motherboard serial number : CAT084911NJ Power supply serial number : DTH08441JZ5 Model revision number : H0 Motherboard revision number : A0 Model number : WS-C3750G-12S-S System serial number : CAT0849N2YU Top Assembly Part Number : 800-21966-01 Top Assembly Revision Number : L0 Version ID : N/A Hardware Board Revision Number : 0x07 Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ---------- * 1 12 WS-C3750G-12S 12.1(19)EA1d C3750-I9-M Configuration register is 0xF
Switch# Switch#sh flash:
Directory of flash:/ 2 -rwx 1075 Mar 1 1993 00:24:27 00:00 config.text 3 drwx 192 Mar 1 1993 00:23:48 00:00 c3750-i5-mz.122-25.SEA 5 -rwx 5 Mar 1 1993 00:24:27 00:00 private-config.text 15998976 bytes total (8053760 bytes free) Switch# Switch#sh ver
Cisco IOS Software, C3750 Software (C3750-I5-M), Version 12.2(25)SEA, RELEASE SO FTWARE (fc) Copyright (c) 1986-2005 by Cisco Systems, Inc. Compiled Tue 25-Jan-05 20:26 by antonino ROM: Bootstrap program is C3750 boot loader BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.1(19r)EA1b, RELEASE SOFTWA RE (fc2) Switch uptime is 2 minutes System returned to ROM by power-on System image file is "flash:c3750-i5-mz.122-25.SEA/c3750-i5-mz.122-25.SEA.bin" cisco WS-C3750G-12S (PowerPC405) processor (revision H0) with 118784K/12280K byt es of memory. Processor board ID CAT0849N2YU Last reset from power-on 1 Virtual Ethernet interface 12 Gigabit Ethernet interfaces The password-recovery mechanism is enabled. 512K bytes of flash-simulated non-volatile configuration memory. Base ethernet MAC Address : 00:129:97:7C:80 Motherboard assembly number : 73-8307-08 Power supply part number : 341-0048-01 Motherboard serial number : CAT084911NJ Power supply serial number : DTH08441JZ5 Model revision number : H0 Motherboard revision number : A0 Model number : WS-C3750G-12S-S System serial number : CAT0849N2YU Top Assembly Part Number : 800-21966-01 Top Assembly Revision Number : L0 Version ID : N/A Hardware Board Revision Number : 0x07 Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ---------- * 1 12 WS-C3750G-12S 12.2(25)SEA C3750-I5-M Configuration register is 0xF
Switch# --------------------------------------------------------------------------------------------------------------------
Catalyst 3524 switch IP 地址的配置
直接进入默认的VLAN 1中进行配置命令如下:
interface VLAN1
ip address 172.16.1.3 255.255.0.0
即可。
在Catalyst 中控制对Telnet的访问
bluestudy_a(config)#access-list 2 permit 172.16.0.0 0.0.255.255 (定义标准的访问列表)
bluestudy_a(config)#line vty 0 15(进入telnet端口,最多允许16个telnet的会话)
bluestudy_a(config-line)#access-class 2 in(应用上述定义的访问列表,即只有172.16.0.0/16的网段可以实现对交换机的telnet会话)
设置交换机的enable 密码
注:对于如上的密码,secret的优先级更高,优先起作用。
设置console口密码
设置对telnet的密码:
设置登陆用户名和密码:
bluestudy_a(config)#username bluestudy password bluestudy
bluestudy_a(config)# bluestudy_a#show running Current configuration: ! version 12.0 no service pad service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname bluestudy_a ! enable secret 5 $1$b1mb$p6XgV/PY9WqvJy9MrHZFG/ enable password bluestudy ! username bluestudy password 0 bluestudy ! ip subnet-zero ! interface FastEthernet0/1 ! interface FastEthernet0/2 ! interface FastEthernet0/3 ! interface FastEthernet0/4 ! interface FastEthernet0/5 ! interface FastEthernet0/6 ! interface FastEthernet0/24 ! interface GigabitEthernet0/1 ! interface GigabitEthernet0/2 ! interface VLAN1 ip address 172.16.1.3 255.255.0.0 no ip directed-broadcast no ip route-cache ! access-list 2 permit 172.16.0.0 0.0.255.255 ! line con 0 password bluestudy transport input none stopbits 1 line vty 0 4 access-class 2 in password bluestudy login line vty 5 15 access-class 2 in password bluestudy login ! end bluestudy_a# ----------------------------------------------------------------------------------------------------------------------
我们称发送回显请求的ping程序为客户,而称被ping的主机为服务器。大多数的TCP/IP实现都在内核中直接支持Ping服务器—这种服务器不是一个用户进程(在第6章中描述的两种ICMP查询服务,地址掩码和时间戳请求,也都是直接在内核中进行处理的)。
ICMP回显请求和回显应答报文如图1所示。
图1 ICMP回显请求和回显应答报文格式
对于其他类型的I C M P查询报文,服务器必须响应标识符和序列号字段。另外,客户发送的选项数据必须回显,假设客户对这些信息都会感兴趣。
U n i x系统在实现p i n g程序时是把I C M P报文中的标识符字段置成发送进程的I D号。这样即使在同一台主机上同时运行了多个p i n g程序实例,p i n g程序也可以识别出返回的信息。
序列号从0开始,每发送一次新的回显请求就加1.p i n g程序打印出返回的每个分组的序列号,允许我们查看是否有分组丢失、失序或重复。I P是一种最好的数据报传递服务,因此这三个条件都有可能发生。
旧版本的p i n g程序曾经以这种模式运行,即每秒发送一个回显请求,并打印出返回的每个回显应答。但是,新版本的实现需要加上-s选项才能以这种模式运行。默认情况下,新版本的p i n g程序只发送一个回显请求。如果收到回显应答,则输出“host is alive ”;否则,在2 0秒内没有收到应答就输出“no answer(没有回答)”。
--------------------------------------------------------------------------------------------------------------------- 本文出自 51CTO.COM技术博客 |







7layer
博客统计信息
热门文章
最新评论
友情链接