Locations of visitors to this page

Thursday, December 24, 2009

questions about database link

questions about database link
dblink问题

Q1:
我现在有两个生产库,A库的部分表通过DBLINK提供给B库使用,B库的应用访问B库,并通过B库查询A库的这些DBLINK链接的表,现在有一个问题:
检查发现 B库的连接数比较多,进一步检查发现有50多个连接是来自A库,即使不用这些DBLINK的表,但连接还是建立的,通过DBLINK建立了8个表的连接,但实际上有50个连接,
是否应用不访问,那么DBLINK的表就没有连接?


A1:
1. 是长连接, 一般, 不用的不会释放
2. 跟会话有关, 不同会话之间不共享数据库连接
3. 可调整open_links参数, 控制打开的连接数

Q2:
奶奶的,会不会出问题? 生产A 上通过DBLINK建立了 B库一个表,并建立同义词, A上一直往这个同义词上插入数据,导致如下的SQL建立的连接达到50多个,全部都是一样的,现在都停止插入了,但进程依然存在,刚才查了open_links参赛,都是4,但为什么会有这么多连接呢?怎么去控制?插入进程应该早就停止了并释放连接,但两个数据库之间的连接到底什么时候释放呢?
INSERT  INTO "SM_SEND_SM_LIST" ("SERIALNO","SERVICEID","SMCONTEN
T","SENDTARGET","PRIORITY","RCOMPLETETIMEBEGIN","RCOMPLETETIMEEN
D","RCOMPLETEHOURBEGIN","RCOMPLETEHOUREND","REQUESTTIME","ROADBY
","SENDTARGETDESC","FEEVALUE","LINKID","PAD1","PAD2","PAD3","PAD
4","PAD5") VALUES (:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:1
4,:15,:16,:17,:18,:19)

刚才了解了一下,是应用程序往这个同义词插入数据,应用程序通过WEBLOGIC的连接池处理,是不是连接池的连接不释放,导致dblink连接不释放?
这玩意会不会增长到几百甚至更多?

A2:
1. 你的weblogic的连接池创建了50个会话连接到数据库上, 应用程序访问数据库, 会被随机分配一个连接, 可能是50个中的任何一个, 所以50个会话可能都被用到了, 所以数据库连接就会有50个
2. 程序退出, 连接池不释放连接, 会话依然存在, 所以数据库连接数不变
3. 只要会话数一定, 数据库连接数就一定, 所以不会涨到几百
4. open_links能够限制每个会话最大打开的数据库连接数, 没有系统全局的限制


Q3:
1,我的应用有7个呢,每个WEBLOGIC都设置有50个连接
2,检查发现大部分插入都是一个SQL,采用绑定变量方式;
3,难道就没有别的方式可以降低连接数量
4,Open_links这个参数好像对这个没有效果,每个进程肯定只建立一个连接,处理完成后进程消失,但连接不消失,而且从这个案例来说,不可能出现一个进程产生多个连接的现象

我考虑将这个表从B库迁移到A库,A库德插入可能是不同的进程,但B库扫描这个表的进程应该一直是一个,那么这样就应该只有一个连接了!

A3:
1. 你有7个weblogic, 每个的连接池有50个连接? 还是7个应用使用同一个weblogic, 一共有50个连接?
第一种情况: 如果7个weblogic, 连接池中每个连接都用到了你那个数据库连接, 那么应该最多看到350个连接
第二种情况, 如果连接池中每个连接都用到了数据库连接, 那么应该最多看到50个连接
上述任何一种情况, 如果不是每个连接都用到了数据库连接, 则看到的连接数应当更小

2. 跟这个没关, 即使用到了n个表, 连接也只有1个

3.
1)在本地数据库端只有open_links的限制
2)前面说过了回话退出时会释放连接
3)第一条指出了可能的最大连接数
4)alter session close database link可手工关闭连接, 但这么做没意义, 下次还会自动创建

4.用到了几个数据库连接, 建立的链接就是几个, 可建立的最大值由open_links确定
因为虽然程序(进程)退出了, 但连接池创建的会话不会退出, 所以连接不消失
因为连接池创建了50个连接(会话)到数据库,每个会话都用到了数据库连接, 所以你看到的连接数是50个





外部链接:
30 Managing a Distributed Database
OPEN_LINKS



-fin-

nmap ping scan

nmap ping scan
nmap ping扫描


1. 现象
有3台服务器, 都开了iptables, 允许ICMP,SSH访问
server1: 192.168.18.95
server2: 192.168.51.72
server3: 192.168.51.71

nmap扫描服务器server1的ssh端口, 结果是通的
$ nmap server1 -p22

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-12-24 07:47 UTC
Interesting ports on server1 (192.168.18.95):
PORT   STATE SERVICE
22/tcp open  ssh

Nmap finished: 1 IP address (1 host up) scanned in 0.134 seconds

另一台server2扫描不通
$ nmap server2 -p22

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-12-24 07:48 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap finished: 1 IP address (0 hosts up) scanned in 3.001 seconds
然而ping却能ping通
$ ping server2 -c 3
PING server2 (192.168.51.72) 56(84) bytes of data.
64 bytes from server2 (192.168.51.72): icmp_seq=1 ttl=63 time=0.314 ms
64 bytes from server2 (192.168.51.72): icmp_seq=2 ttl=63 time=0.214 ms
64 bytes from server2 (192.168.51.72): icmp_seq=3 ttl=63 time=0.247 ms

--- server2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.214/0.258/0.314/0.043 ms
SSH端口也可访问
$ ssh server2 uptime
username@server2's password:
 07:50:01 up 14 days,  8:02,  1 user,  load average: 0.00, 0.00, 0.00


将server2上的iptables关掉后, nmap扫描通过
# iptables -F
$ nmap server2 -p22

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-12-24 07:49 UTC
Interesting ports on server2 (192.168.51.72):
PORT   STATE SERVICE
22/tcp open  ssh

Nmap finished: 1 IP address (1 host up) scanned in 0.104 seconds

再打开server2上的iptables, 用root运行nmap扫描, 结果也是通的
# nmap server2 -p22

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-12-24 07:50 UTC
Interesting ports on server2 (192.168.51.72):
PORT   STATE SERVICE
22/tcp open  ssh

Nmap finished: 1 IP address (1 host up) scanned in 0.120 seconds

从server3用root向server2扫描也是通的
# nmap server2 -p22

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-12-24 08:10 UTC
Interesting ports on server2 (192.168.51.72):
PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: 00:16:C0:A8:33:47 (Semtech)

Nmap finished: 1 IP address (1 host up) scanned in 0.141 seconds

server1的iptables设置:
*nat
...
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
-A OUTPUT -o lo -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
...
*filter
...
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
...
-A RH-Firewall-1-INPUT -j DROP

server2的iptables设置:
*filter
...
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
...
-A RH-Firewall-1-INPUT -j DROP


2. 调查
打开nmap调试信息和strace跟踪
1) server1:
$ nmap -v -d9 --packet-trace -n server1 -p22

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-12-24 07:52 UTC
The max # of sockets we are using is: 0
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  scan-delay: TCP 1000, UDP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
---------------------------------------------
READ selected for machine 192.168.18.95
Machine 192.168.18.95 MIGHT actually be listening on probe port 80
Hostupdate called for machine 192.168.18.95 state UNKNOWN/COMBO -> HOST_UP (trynum 0, dotimeadj: yes time: 727)
Timeout vals: srtt: -1 rttvar: -1 to: 1000000 delta 798 ==> srtt: 798 rttvar: 5000 to: 100000
Finished block: srtt: 798 rttvar: 5000 timeout: 100000 block_tries: 1 up_this_block: 1 down_this_block: 0 group_sz: 1
massping done:  num_hosts: 1  num_responses: 1
Initiating Connect() Scan against 192.168.18.95 [1 port] at 07:52
CONN (0.1040s) TCP localhost > 192.168.18.95:22 => Operation now in progress
**TIMING STATS**: IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ccthresh/delay, timeout/srtt/rttvar/
   Groupstats (1/1 incomplete): 1/*/*/*/*/* 10.00/50/* 1000000/-1/-1
   192.168.18.95: 1/0/0/1/0/0 10.00/50/0 100000/798/5000
Discovered open port 22/tcp on 192.168.18.95
Changing ping technique for 192.168.18.95 to TCP
Timeout vals: srtt: 798 rttvar: 5000 to: 100000 delta -381 ==> srtt: 750 rttvar: 3845 to: 100000
Timeout vals: srtt: -1 rttvar: -1 to: 1000000 delta 417 ==> srtt: 417 rttvar: 5000 to: 100000
The Connect() Scan took 0.00s to scan 1 total ports.
Host 192.168.18.95 appears to be up ... good.
Interesting ports on 192.168.18.95:
Fetchfile found /usr/share/nmap/nmap-services

PORT   STATE SERVICE
22/tcp open  ssh
Final times for host: srtt: 750 rttvar: 3845  to: 100000

Nmap finished: 1 IP address (1 host up) scanned in 0.116 seconds

2) server2:
$ nmap -v -d9 --packet-trace -n server2 -p22

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-12-24 07:53 UTC
The max # of sockets we are using is: 0
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  scan-delay: TCP 1000, UDP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
---------------------------------------------
Finished block: srtt: -1 rttvar: -1 timeout: 1000000 block_tries: 2 up_this_block: 0 down_this_block: 0 group_sz: 1
massping done:  num_hosts: 1  num_responses: 0
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap finished: 1 IP address (0 hosts up) scanned in 3.002 seconds
与1)对比发现, nmap扫描server1时连接了server1的80端口

$ strace nmap server2 -p22
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(3, SOL_SOCKET, SO_LINGER, {onoff=1, linger=0}, 8) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.51.72")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(4, [3], [3], [3], {1, 0})        = 0 (Timeout)
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(3, SOL_SOCKET, SO_LINGER, {onoff=1, linger=0}, 8) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.51.72")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(4, [3], [3], [3], {1, 0})        = 0 (Timeout)
close(3)                                = 0
...
write(1, "Note: Host seems down. If it is "..., 81Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
) = 81
...
连接server2的80端口, 2次超时(Timeout)后报错'Host seems down.', 然后退出

3) root用户扫描server2:
# nmap -v -d9 --packet-trace -n server2 -p22

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-12-24 07:53 UTC
The max # of sockets we are using is: 0
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  scan-delay: TCP 1000, UDP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
---------------------------------------------
Packet capture filter (device bond0): (icmp and dst host 192.168.11.18) or ((tcp or udp) and dst host 192.168.11.18 and ( dst port 34806 or dst port 34807 or dst port 34808 or dst port 34809 or dst port 34810))
SENT (0.0100s) ICMP 192.168.11.18 > 192.168.51.72 Echo request (type=8/code=0) ttl=52 id=10191 iplen=28
SENT (0.0100s) TCP 192.168.11.18:34810 > 192.168.51.72:80 A ttl=40 id=58342 iplen=40 seq=1674883102 win=1024 ack=2782179358
RCVD (0.0100s) ICMP 192.168.51.72 > 192.168.11.18 Echo reply (type=0/code=0) ttl=63 id=43696 iplen=28
We got a ping packet back from 192.168.51.72: id = 56906 seq = 21184 checksum = 52980
Hostupdate called for machine 192.168.51.72 state UNKNOWN/COMBO -> HOST_UP (trynum 0, dotimeadj: yes time: 446)
Timeout vals: srtt: -1 rttvar: -1 to: 1000000 delta 382 ==> srtt: 382 rttvar: 5000 to: 100000
Finished block: srtt: 382 rttvar: 5000 timeout: 100000 block_tries: 1 up_this_block: 1 down_this_block: 0 group_sz: 1
massping done:  num_hosts: 1  num_responses: 1
Initiating SYN Stealth Scan against 192.168.51.72 [1 port] at 07:53
Pcap filter: dst host 192.168.11.18 and (icmp or (tcp and (src host 192.168.51.72)))
Packet capture filter (device bond0): dst host 192.168.11.18 and (icmp or (tcp and (src host 192.168.51.72)))
SENT (0.1240s) TCP 192.168.11.18:34786 > 192.168.51.72:22 S ttl=51 id=27748 iplen=44 seq=3810228640 win=4096
**TIMING STATS**: IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ccthresh/delay, timeout/srtt/rttvar/
   Groupstats (1/1 incomplete): 1/*/*/*/*/* 10.00/50/* 1000000/-1/-1
   192.168.51.72: 1/0/0/1/0/0 10.00/50/0 100000/382/5000
RCVD (0.1240s) TCP 192.168.51.72:22 > 192.168.11.18:34786 SA ttl=63 id=0 iplen=44 seq=3799856132 win=5840 ack=3810228641
Discovered open port 22/tcp on 192.168.51.72
Changing ping technique for 192.168.51.72 to TCP
Timeout vals: srtt: 382 rttvar: 5000 to: 100000 delta 44 ==> srtt: 387 rttvar: 3761 to: 100000
Timeout vals: srtt: -1 rttvar: -1 to: 1000000 delta 426 ==> srtt: 426 rttvar: 5000 to: 100000
The SYN Stealth Scan took 0.01s to scan 1 total ports.
Host 192.168.51.72 appears to be up ... good.
Interesting ports on 192.168.51.72:
Fetchfile found /usr/share/nmap/nmap-services

PORT   STATE SERVICE
22/tcp open  ssh
Final times for host: srtt: 387 rttvar: 3761  to: 100000

Nmap finished: 1 IP address (1 host up) scanned in 0.141 seconds
               Raw packets sent: 3 (112B) | Rcvd: 2 (92B)
发送ICMP echo request, 并向80端口发送TCP ACK包

# strace nmap server2 -p22
...
socket(PF_INET, SOCK_RAW, IPPROTO_RAW)  = 4
setsockopt(4, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
setsockopt(4, SOL_IP, IP_HDRINCL, [1], 4) = 0
socket(PF_INET, SOCK_RAW, IPPROTO_RAW)  = 5
setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
setsockopt(5, SOL_IP, IP_HDRINCL, [1], 4) = 0
socket(PF_PACKET, SOCK_RAW, 768)        = 6
ioctl(6, SIOCGIFINDEX, {ifr_name="lo", ifr_index=1}) = 0
ioctl(6, SIOCGIFHWADDR, {ifr_name="bond0", ifr_hwaddr=00:14:22:12:39:2b}) = 0
ioctl(6, SIOCGIFINDEX, {ifr_name="bond0", ifr_index=5}) = 0
bind(6, {sa_family=AF_PACKET, proto=0x03, if5, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0
getsockopt(6, SOL_SOCKET, SO_ERROR, [17179869184], [4]) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 7
ioctl(7, SIOCGIFADDR, {ifr_name="bond0", ifr_addr={AF_INET, inet_addr("192.168.11.18")}}) = 0
ioctl(7, SIOCGIFNETMASK, {ifr_name="bond0", ifr_netmask={AF_INET, inet_addr("255.255.255.0")}}) = 0
close(7)                                = 0
brk(0x17164000)                         = 0x17164000
setsockopt(6, SOL_SOCKET, SO_ATTACH_FILTER, "\1\0\0\0\0\0\0\0\20)h\0\0\0\0\0", 16) = 0
fcntl(6, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
recvfrom(6, "\0\220\301\224x\377\177\0\0\220\301\224x\377\177\0\0p\301\224x\377\177\0\0\360\255\23\27\0\0\0"..., 1, MSG_TRUNC, NULL, NULL) = 114
recvfrom(6, "\0\220\301\224x\377\177\0\0\220\301\224x\377\177\0\0p\301\224x\377\177\0\0\360\255\23\27\0\0\0"..., 1, MSG_TRUNC, NULL, NULL) = 114
...
recvfrom(6, "\0\220\301\224x\377\177\0\0\220\301\224x\377\177\0\0p\301\224x\377\177\0\0\360\255\23\27\0\0\0"..., 1, MSG_TRUNC, NULL, NULL) = 146
recvfrom(6, 0x7fff7894c11f, 1, 32, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
fcntl(6, F_SETFL, O_RDWR)               = 0
setsockopt(6, SOL_SOCKET, SO_ATTACH_FILTER, "\231\0\224x\377\177\0\0\320\312\23\27\0\0\0\0", 16) = 0
sendto(5, "E\0\0\34\360Y\0\0-\1\335\334\300\250\v\22\300\2503H\10\0*\347\244\t)\17", 28, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.51.72")}, 16) = 28
sendto(4, "E\0\0(\2\275\0\0;\6\275h\300\250\v\22\300\2503H\367\205\0Pu\303\312^\312\303\312^"..., 40, 0, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.51.72")}, 16) = 40
select(7, [6], NULL, NULL, {0, 20000})  = 1 (in [6], left {0, 20000})
recvfrom(6, "\0\24\"\0229+\0\23\200\6\301A\10\0E\0\0\34\252\274\0\0?\1\21z\300\2503H\300\250"..., 104, MSG_TRUNC, {sa_family=AF_PACKET, proto=0x800, if5, pkttype=PACKET_HOST, addr(6)={1, 00138006c141}, [18]) = 60
ioctl(6, SIOCGSTAMP, 0x7fff78948b20)    = 0
close(4)                                = 0
close(5)                                = 0
close(6)                                = 0
...
创建原始套接字, 向server2端口0和80发送数据包

4) server2关闭iptables:
$ strace nmap server2 -p22
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(3, SOL_SOCKET, SO_LINGER, {onoff=1, linger=0}, 8) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.51.72")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(4, [3], [3], [3], {1, 0})        = 2 (in [3], out [3], left {1, 0})
recvfrom(3, 0x7ffffaa7bed0, 255, 0, 0, 0) = -1 ECONNREFUSED (Connection refused)
close(3)                                = 0
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(3, SOL_SOCKET, SO_LINGER, {onoff=1, linger=0}, 8) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("192.168.51.72")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(4, [3], [3], [3], {0, 99000})    = 1 (out [3], left {0, 99000})
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
sendto(3, "", 0, 0, NULL, 0)            = 0
getpeername(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("192.168.51.72")}, [17179869200]) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(34707), sin_addr=inet_addr("192.168.11.18")}, [68719476752]) = 0
close(3)                                = 0
...
连接server2的80端口, 1次连接被拒绝(Connection refused)后, 不退出, 继续扫描22端口

5) root从server3扫描server2
# nmap -v -d9 --packet-trace -n server2 -p22

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-12-24 08:10 UTC
The max # of sockets we are using is: 0
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  scan-delay: TCP 1000, UDP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
---------------------------------------------
Initiating ARP Ping Scan against 192.168.51.72 [1 port] at 08:10
Pcap filter: arp and ether dst host 00:16:C0:A8:33:46
Packet capture filter (device eth0): arp and ether dst host 00:16:C0:A8:33:46
SENT (0.0140s) ARP who-has 192.168.51.72 tell 192.168.51.71
**TIMING STATS**: IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ccthresh/delay, timeout/srtt/rttvar/
   Groupstats (1/1 incomplete): 1/*/*/*/*/* 10.00/50/* 100000/-1/-1
   192.168.51.72: 1/0/0/1/0/0 10.00/50/0 100000/-1/-1
RCVD (0.0150s) ARP reply 192.168.51.72 is-at 00:16:C0:A8:33:47
Timeout vals: srtt: -1 rttvar: -1 to: 100000 delta 364 ==> srtt: 364 rttvar: 5000 to: 100000
Timeout vals: srtt: -1 rttvar: -1 to: 100000 delta 364 ==> srtt: 364 rttvar: 5000 to: 100000
The ARP Ping Scan took 0.01s to scan 1 total hosts.
Initiating SYN Stealth Scan against 192.168.51.72 [1 port] at 08:10
Pcap filter: dst host 192.168.51.71 and (icmp or (tcp and (src host 192.168.51.72)))
Packet capture filter (device eth0): dst host 192.168.51.71 and (icmp or (tcp and (src host 192.168.51.72)))
SENT (0.0380s) TCP 192.168.51.71:35569 > 192.168.51.72:22 S ttl=57 id=4614 iplen=44 seq=1639929488 win=2048
**TIMING STATS**: IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ccthresh/delay, timeout/srtt/rttvar/
   Groupstats (1/1 incomplete): 1/*/*/*/*/* 10.00/50/* 1000000/-1/-1
   192.168.51.72: 1/0/0/1/0/0 10.00/50/0 100000/364/5000
RCVD (0.0390s) TCP 192.168.51.72:22 > 192.168.51.71:35569 SA ttl=64 id=0 iplen=44 seq=474347775 win=5840 ack=1639929489
Discovered open port 22/tcp on 192.168.51.72
Changing ping technique for 192.168.51.72 to TCP
Timeout vals: srtt: 364 rttvar: 5000 to: 100000 delta 9 ==> srtt: 365 rttvar: 3752 to: 100000
Timeout vals: srtt: -1 rttvar: -1 to: 1000000 delta 373 ==> srtt: 373 rttvar: 5000 to: 100000
The SYN Stealth Scan took 0.01s to scan 1 total ports.
Fetchfile found /usr/share/nmap/nmap-mac-prefixes

Host 192.168.51.72 appears to be up ... good.
Interesting ports on 192.168.51.72:
Fetchfile found /usr/share/nmap/nmap-services

PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: 00:16:C0:A8:33:47 (Semtech)
Final times for host: srtt: 365 rttvar: 3752  to: 100000

Nmap finished: 1 IP address (1 host up) scanned in 0.142 seconds
               Raw packets sent: 2 (86B) | Rcvd: 2 (86B)
发送ARP扫描


3. 分析
查看nmap手册
$ man nmap
...
HOST DISCOVERY
       One of the very first steps in any network reconnaissance mission is to reduce a (sometimes huge) set of IP ranges into a list of active or interesting hosts. Scanning every port of every single IP address is slow and usually unnecessary. Of course what makes a host interesting depends greatly on the scan purposes. Network administrators may only be interested in hosts running a certain service, while security auditors may care about every single device with an IP address. An administrator may be comfortable using just an ICMP ping to locate hosts on his internal network, while an external penetration tester may use a diverse set of dozens of probes in an attempt to evade firewall restrictions.

       Because host discovery needs are so diverse, Nmap offers a wide variety of options for customizing the techniques used. Host discovery is sometimes called ping scan, but it goes well beyond the simple ICMP echo request packets associated with the ubiquitous ping tool. Users can skip the ping step entirely with a list scan (-sL) or by disabling ping (-P0), or engage the network with arbitrary combinations of multi-port TCP SYN/ACK, UDP, and ICMP probes. The goal of these probes is to solicit responses which demonstrate that an IP address is actually active (is being used by a host or network device). On many networks, only a small percentage of IP addresses are active at any given time. This is particularly common with RFC1918-blessed private address space such as 10.0.0.0/8. That network has 16 million IPs, but I have seen it used by companies with less than a thousand machines. Host discovery can find those machines in a sparsely allocated sea of IP addresses.

       If no host discovery options are given, Nmap sends a TCP ACK packet destined for port 80 and an ICMP Echo Request query to each target machine. An exception to this is that an ARP scan is used for any targets which are on a local ethernet network. For unprivileged UNIX shell users, a SYN packet is sent instead of the ack using the connect() system call. These defaults are equivalent to the -PA -PE options. This host discovery is often sufficient when scanning local networks, but a more comprehensive set of discovery probes is recommended for security auditing.
...
       -sP (Ping Scan)
              This option tells Nmap to only perform a ping scan (host discovery), then print out the available hosts that responded to the scan. No further testing (such as port scanning or OS detection) is performed. This is one step more intrusive than the list scan, and can often be used for the same purposes. It allows light reconnaissance of a target network without attracting much attention. Knowing how many hosts are up is more valuable to attackers than the list provided by list scan of every single IP and host name.

              Systems administrators often find this option valuable as well. It can easily be used to count available machines on a network or monitor server availability. This is often called a ping sweep, and is more reliable than pinging the broadcast address because many hosts do not reply to broadcast queries.

              The -sP option sends an ICMP echo request and a TCP packet to port 80 by default. When executed by an unprivileged user, a SYN packet is sent (using a connect() call) to port 80 on the target. When a privileged user tries to scan targets on a local ethernet network, ARP requests (-PR) are used unless --send-ip was specified. The -sP option can be combined with any of the discovery probe types (the -P* options, excluding -P0) for greater flexibility. If any of those probe type and port number options are used, the default probes (ACK and echo request) are overridden. When strict firewalls are in place between the source host running Nmap and the target network, using those advanced techniques is recommended. Otherwise hosts could be missed when the firewall drops probes or their responses.
...
nmap在检测服务和端口之前, 默认首先检测主机是否是活动的, 这被称为主机发现(Host Disvocery)或ping扫描(ping scan)
如果主机发现不通过, 则不进行后面的端口扫描
主机发现的方式有多种, 默认方式是向主机80端口发送一个TCP ACK包, 并发送ICMP 回显请求(Echo Request)查询, 如在同一局域网则使用ARP扫描. 对于UNIX下非特权用户, 不发送ack包, 而是使用connect()系统调用发送一个SYN包.


4. 结论
1) 特权用户才可以建立原始套接字, 使用ARP, ICMP, ACK扫描

2) 普通用户运行nmap扫描server1:
nmap使用connect向80端口发送SYN, 因为server1上启动了tomcat服务, 80端口可访问, 所以主机发现成功通过

3) 普通用户运行nmap扫描打开iptables的server2:
nmap使用connect向80端口发送SYN, server2上iptables不允许访问80端口, 造成扫描超时错误, nmap认为主机不可达, 所以主机发现失败

4) 普通用户运行nmap扫描关闭iptables的server2:
nmap使用connect向80端口发送SYN, server2上没有监听80端口的服务, 造成连接被拒绝, nmap认为主机可到达, 所以主机发现通过

5) 特权用户运行nmap扫描打开iptables的server2:
nmap使用原始套接字发出ICMP回显请求, server2上iptables允许ICMP, 所以主机发现能通过

6) 普通用户ping命令扫描打开iptables的server2:
因为ping命令拥有setuid root权限, 运行时具有root权限, 可以创建原始套接字用ICMP扫描, 所以能ping通主机
$ ls -l $(which ping)
-rwsr-xr-x 1 root root 37280 Mar 14  2007 /bin/ping

6) 特权用户从server3扫描打开iptables的server2:
因为server2和server3处于同一子网, 所以使用ARP扫描, ARP属于第2层数据链路层, iptables无法过滤, 所以主机发现能通过



外部链接:
Chapter 15. Nmap Reference Guide
The Art of Port Scanning - by Fyodor





-fin-

Thursday, December 17, 2009

How to download oracle patches from CLI

How to download oracle patches from CLI
如何从命令行下载Oracle补丁


Oracle的FTP下载站点已于2009年11月6号关闭, 不再提供服务, 下载补丁只能通过My Oracle Support网站
$ ftp updates.oracle.com
Connected to updates.oraclegha.com.
421-*********************** Downtime Notice ************************
421-
421-This service was retired as of November 06, 2009.
421-
421-****************************************************************
421
ftp>

其实可以用命令行工具以HTTPS方式下载补丁
补丁的URL地址格式是:

https://updates.oracle.com/Orion/Services/download/?aru=<ARU编号>
ARU(Automated Release Updates)编号可在My Oracle Support网站上查到
1) 访问My Oracle Support网站
oraclepatch-01-home.png
2) 登录
oraclepatch-02-signin.png
3) 选择"Patches & Updates"
oraclepatch-03-tab2.png
4) 查找补丁
oraclepatch-04-advsearch.png
oraclepatch-05-search.png
5) 单击选择该行, 弹出菜单, 选择"View Read Me"
oraclepatch-06-viewreadme.png
6) 在说明文档的URL地址栏中找到ARU编号
oraclepatch-07-readme.png

比如,得到10.2.0.4 Patch Set的下载地址是:
https://updates.oracle.com/Orion/Services/download/?aru=10029612
然后用wget工具下载即可, 在命令行中还需提供登录用户名和密码, 如:
wget --http-user="myusername" --http-password="mypassword" "https://updates.oracle.com/Orion/Services/download/?aru=10029612"
对有密码保护的补丁, URL中再加上patch_password参数, 如:
https://updates.oracle.com/Orion/Services/download/?aru=12345678&patch_password=nosuchpasswd


wget常见问题:
1. File name too long
报错"File name too long", 无法写文件
Resolving oracle-updates.oracle.com... 68.142.116.74, 68.142.116.73
Connecting to oracle-updates.oracle.com|68.142.116.74|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 111,654 (109K) [application/zip]
p8524113_10204_Linux-x86-64.zip?download_url=http:%2F%2Fupdates.oracle.com%2FARULink%2FDownload%2Fprocess_form&userid=o-wenxie@motorola.com&email=wenxie@motorola.com&record_download_url=http:%2F%2Fupdates.oracle.com%2FARULink%2FPatchDownload%2Fpack_stats&timestamp=1260979159&patch_password=NO_PASS&context=A@10+H@aaru203.oracle.com+P@&aru=11423647&patch_file=p8524113_10204_Linux-x86-64.zip&ip_address=123.127.66.13&file_id=27511963&use_proxy=false&id=ZWtXM1l3WXFjVUlEZ2YwVDFUZ1ZOQTpHOWEvMlhXSTlRTDJRL2RKbXMvejJB: File name too long

Cannot write to `p8524113_10204_Linux-x86-64.zip?download_url=http:%2F%2Fupdates.oracle.com%2FARULink%2FDownload%2Fprocess_form&userid=o-wenxie@motorola.com&email=wenxie@motorola.com&record_download_url=http:%2F%2Fupdates.oracle.com%2FARULink%2FPatchDownload%2Fpack_stats&timestamp=1260979159&patch_password=NO_PASS&context=A@10+H@aaru203.oracle.com+P@&aru=11423647&patch_file=p8524113_10204_Linux-x86-64.zip&ip_address=123.127.66.13&file_id=27511963&use_proxy=false&id=ZWtXM1l3WXFjVUlEZ2YwVDFUZ1ZOQTpHOWEvMlhXSTlRTDJRL2RKbXMvejJB' (File name too long).

需要指定下载文件名, 该文件名可从wget输出中得到
文件名格式为:
p<补丁编号>_<数据库版本>_<操作系统>.zip
如:
p6810189_10204_Linux-x86-64.zip
也可在My Oracle Support查到
1) 访问My Oracle Support网站
2) 登录
3) 选择"Patches & Updates"
4) 查找补丁
5) 点该行开头的补丁编号
oraclepatch-11-detail.png
6) 显示出补丁详细信息, 单击"Show File Details"
oraclepatch-12-filedetail.png
7) 显示出文件名
oraclepatch-13-filename.png

在wget命令中加-O选项指定下载文件名:
wget --http-user="myusername" --http-password="mypassword" -O "p6810189_10204_Linux-x86-64.zip" "https://updates.oracle.com/Orion/Services/download/?aru=11423647"

2. 加-c选项不能断点续传
报错304 Not Modified
Location: https://updates.oracle.com/Orion/Services/download/?aru=10029612 [following]
--15:59:04--  https://updates.oracle.com/Orion/Services/download/?aru=10029612
Connecting to updates.oracle.com|141.146.44.51|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://oracle-updates.oracle.com/ARUConnect/p6810189_10204_Linux-x86-64.zip?download_url=http%3A%2F%2Fupdates.oracle.com%2FARULink%2FDownload%2Fprocess_form&userid=o-wenxie%40motorola.com&record_download_url=http%3A%2F%2Fupdates.oracle.com%2FARULink%2FPatchDownload%2Fpack_stats&email=wenxie%40motorola.com&timestamp=1260979145&patch_password=NO_PASS&context=A%4010%2BH%40aaru204.oracle.com%2BP%40&ip_address=123.127.66.8&patch_file=p6810189_10204_Linux-x86-64.zip&aru=10029612&file_id=22503408&use_proxy=false&id=QUViSEhzNWVGZFlpMGZvVjBlRnZwQTppeWJXRk9Mc2xiVitPU2F1UTNrd21R [following]
--15:59:05--  http://oracle-updates.oracle.com/ARUConnect/p6810189_10204_Linux-x86-64.zip?download_url=http%3A%2F%2Fupdates.oracle.com%2FARULink%2FDownload%2Fprocess_form&userid=o-wenxie%40motorola.com&record_download_url=http%3A%2F%2Fupdates.oracle.com%2FARULink%2FPatchDownload%2Fpack_stats&email=wenxie%40motorola.com&timestamp=1260979145&patch_password=NO_PASS&context=A%4010%2BH%40aaru204.oracle.com%2BP%40&ip_address=123.127.66.8&patch_file=p6810189_10204_Linux-x86-64.zip&aru=10029612&file_id=22503408&use_proxy=false&id=QUViSEhzNWVGZFlpMGZvVjBlRnZwQTppeWJXRk9Mc2xiVitPU2F1UTNrd21R
Resolving oracle-updates.oracle.com... 68.142.116.74, 68.142.116.73
Connecting to oracle-updates.oracle.com|68.142.116.74|:80... connected.
HTTP request sent, awaiting response... 304 Not Modified
15:59:05 ERROR 304: Not Modified.

同样需要指定下载文件名:
wget --http-user="myusername" --http-password="mypassword" -c -O "p6810189_10204_Linux-x86-64.zip" "https://updates.oracle.com/Orion/Services/download/?aru=11423647"

3. HTTPS证书出错
加上--no-check-certificate选项


外部链接:
Classic MetaLink and My Oracle Support Transition Information Page
Retrieving Oracle patches with wget
Automated 'wget' patch downloads: issue resolution



-fin-
Website Analytics

Followers