locked
這樣表示SQL server被入侵的嗎? RRS feed

  • 問題

  • 各位大大,小弟的ibmserver剛install好的win2003+sql 2000 sp3a,patch和防毒也都setup ok,

    但開了3389 port和1433 port (以便遠端作業)

     

    結果幾天後,run netstat -a卻出現以下怪怪的東東,請問是被入侵了嗎?若是該如何解決與預防?

    (很肯定LAN中並沒有CACW-SERVER這台電腦)

     

    --------------------------------------------------

     

     TCP    ibmserver:ms-sql-s         CACW-SERVER:5016       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:5038       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:5448       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:5461       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:5591       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:5888       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:6089       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:6346       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:6614       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:7247       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:7774       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:8263       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:8848       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:9488       TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:12713      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:13344      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:13953      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:14568      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:14714      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:15162      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:15490      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:15751      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:16096      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:16306      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:16679      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:16897      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:17294      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:17484      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:17852      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:18058      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:18339      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:18866      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:19404      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:22243      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:23871      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:24596      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:25161      ESTABLISHED
     TCP    ibmserver:ms-sql-s         CACW-SERVER:25802      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:28093      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:28837      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:28935      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:29428      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:29505      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:30035      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:30559      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:31140      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:31673      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:32261      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:32394      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:32818      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:32935      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:33333      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:33504      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:33865      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:34082      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:34396      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:34886      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:35090      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:37000      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:37600      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:38079      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:39781      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:40313      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:40813      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:40912      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:41432      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:41927      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:42450      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:42963      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:43212      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:43514      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:43538      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:43886      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:44037      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:44258      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:44587      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:44668      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:47549      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:48377      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:48775      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:49196      TIME_WAIT
     TCP    ibmserver:ms-sql-s         CACW-SERVER:49625      TIME_WAIT

    2007年6月18日 上午 07:52

解答

  • 看去不像,您可以改用微軟的 TCPView for Windows v2.4 圖形化工具,以便以圖示的方式來察看更詳細的資訊,比方說,遠端的 IP。

    請注意:
    第一次使用時,請記得調整字型與大小,免得您得載上放大鏡才能看清楚執行結果。

    2007年6月18日 下午 12:22
    版主
  • 1. 升級 SQL Server 2000 到 SP4

    2. 非必要,別開 port 1433

    3. 你可以觀察 SQL Server 目前的活動狀態,看看有沒有人在 try SQL 指令,如果有的話可能就要注意。

     然後把它強制 close 掉。

     通常只要安裝了最新的修補,就不會有太大問題,不過我建議把 port 關掉比較好。

    2007年6月20日 上午 02:23
    版主
  • 請改用樓上的軟體進行測試,若不便安裝的話可以改用netstat -na進行查閱...

     

    列出來的清單內容是本機正常服務連線為

     

      Proto   Local Address          Foreign Address        State

      TCP    192.168.1.3:80         192.168.1.5:2087       ESTABLISHED   (192.168.1.5使用2087Port對伺服器的http:80連線)

      TCP    192.168.1.3:80         192.168.1.2:1044       ESTABLISHED   (192.168.1.2使用1044Port對伺服器的http:80連線)

      TCP    192.168.1.3:80         192.168.1.3:2088       ESTABLISHED   (伺服器使用2088Port對自己的http:80連線)

     

    通常1024-65536Port為本機對外連線使用的Port,除了特定被綁定的Port,

    例SQL:TCP/1433 UDP/1434,Tomcat:8080。系統會自動跳過這些Port。

     

    LocalAddress區代表自己本機接受連線或是對外連線的IP及Port

    Foreign Address區代表遠端對本機的連線,亦或是本機對外的連線。

     

    上例以外部使用者嘗試對本機http:80連線

     

    LocalAddress會看到本機服務使用80Port對外部使用者回應

    Foreign Address會看到外面使用者的IP及使用1024~65535Port對您的機器進行連線。此為正常狀況。

     

    如果您用netstat -na的結果,從Foreign Address過來的皆為同一IP(不同Port)對您特定服務進行大量連線。

    那可能就是攻擊行為,但您必需先進行測試。

     

    請進行下列兩者測試來判斷是否正常連線

    1.您的前端AP對SQL連線者一次會產生多少連線。也可能是AP設計不良導致。

    2.Ping CACW-SERVER這個電腦來嘗試抓取對方的IP,來確定是否區網內的電腦。通常windows服務內wins若正常運作同區的是有辦法取得IP資訊。

     

    以下的狀況就較為可能是有攻擊行為或前端AP設計不良

    =========================================================

      Proto   Local Address          Foreign Address        State

      TCP    192.168.1.3:80         192.168.1.2:1024       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1025       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1026       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1027       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1028       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1029       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1030       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1031       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1032       ESTABLISHED

     

    如何判斷是否是攻擊行為呢?或是對方中毒?

    下netstat -na後看到

    Local使用大量連號或不連號的Port對Foreign特定Port連線,可能為您的伺服器中毒。

    Local Address          1024-65535  -----> Foreign Address        特定port

     

    反之

    Foreign使用大量連號或不連號的Port對Local特定Port連線,則可能為使用者端中毒正在攻擊您的伺服器。

    Local Address          特定port  <--------  Foreign Address        1024-65535

     

    如果是您的伺服器中毒,也可以藉Local Address資訊查到,是否有您未進行的連線但netstat -na卻可以看到連線。

    我本身是使用active ports去檢查(簡稱:aports),不過有些防毒會把它當成是病毒。因為可以強制關閉特定程式發出的連線。

     

    該軟體通常可以抓到本機發出去外面的異常連線是由哪一個程式發出。來判斷是否您安裝過的程式亦或是木馬。

    不過不建議對系統不熟悉的人,用手動方式去刪改一些放在系統資料夾及或使用Regedit內去調改設定。

     

    2007年6月20日 上午 04:14

所有回覆

  • 看去不像,您可以改用微軟的 TCPView for Windows v2.4 圖形化工具,以便以圖示的方式來察看更詳細的資訊,比方說,遠端的 IP。

    請注意:
    第一次使用時,請記得調整字型與大小,免得您得載上放大鏡才能看清楚執行結果。

    2007年6月18日 下午 12:22
    版主
  • 1. 升級 SQL Server 2000 到 SP4

    2. 非必要,別開 port 1433

    3. 你可以觀察 SQL Server 目前的活動狀態,看看有沒有人在 try SQL 指令,如果有的話可能就要注意。

     然後把它強制 close 掉。

     通常只要安裝了最新的修補,就不會有太大問題,不過我建議把 port 關掉比較好。

    2007年6月20日 上午 02:23
    版主
  • 請改用樓上的軟體進行測試,若不便安裝的話可以改用netstat -na進行查閱...

     

    列出來的清單內容是本機正常服務連線為

     

      Proto   Local Address          Foreign Address        State

      TCP    192.168.1.3:80         192.168.1.5:2087       ESTABLISHED   (192.168.1.5使用2087Port對伺服器的http:80連線)

      TCP    192.168.1.3:80         192.168.1.2:1044       ESTABLISHED   (192.168.1.2使用1044Port對伺服器的http:80連線)

      TCP    192.168.1.3:80         192.168.1.3:2088       ESTABLISHED   (伺服器使用2088Port對自己的http:80連線)

     

    通常1024-65536Port為本機對外連線使用的Port,除了特定被綁定的Port,

    例SQL:TCP/1433 UDP/1434,Tomcat:8080。系統會自動跳過這些Port。

     

    LocalAddress區代表自己本機接受連線或是對外連線的IP及Port

    Foreign Address區代表遠端對本機的連線,亦或是本機對外的連線。

     

    上例以外部使用者嘗試對本機http:80連線

     

    LocalAddress會看到本機服務使用80Port對外部使用者回應

    Foreign Address會看到外面使用者的IP及使用1024~65535Port對您的機器進行連線。此為正常狀況。

     

    如果您用netstat -na的結果,從Foreign Address過來的皆為同一IP(不同Port)對您特定服務進行大量連線。

    那可能就是攻擊行為,但您必需先進行測試。

     

    請進行下列兩者測試來判斷是否正常連線

    1.您的前端AP對SQL連線者一次會產生多少連線。也可能是AP設計不良導致。

    2.Ping CACW-SERVER這個電腦來嘗試抓取對方的IP,來確定是否區網內的電腦。通常windows服務內wins若正常運作同區的是有辦法取得IP資訊。

     

    以下的狀況就較為可能是有攻擊行為或前端AP設計不良

    =========================================================

      Proto   Local Address          Foreign Address        State

      TCP    192.168.1.3:80         192.168.1.2:1024       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1025       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1026       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1027       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1028       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1029       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1030       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1031       ESTABLISHED

      TCP    192.168.1.3:80         192.168.1.2:1032       ESTABLISHED

     

    如何判斷是否是攻擊行為呢?或是對方中毒?

    下netstat -na後看到

    Local使用大量連號或不連號的Port對Foreign特定Port連線,可能為您的伺服器中毒。

    Local Address          1024-65535  -----> Foreign Address        特定port

     

    反之

    Foreign使用大量連號或不連號的Port對Local特定Port連線,則可能為使用者端中毒正在攻擊您的伺服器。

    Local Address          特定port  <--------  Foreign Address        1024-65535

     

    如果是您的伺服器中毒,也可以藉Local Address資訊查到,是否有您未進行的連線但netstat -na卻可以看到連線。

    我本身是使用active ports去檢查(簡稱:aports),不過有些防毒會把它當成是病毒。因為可以強制關閉特定程式發出的連線。

     

    該軟體通常可以抓到本機發出去外面的異常連線是由哪一個程式發出。來判斷是否您安裝過的程式亦或是木馬。

    不過不建議對系統不熟悉的人,用手動方式去刪改一些放在系統資料夾及或使用Regedit內去調改設定。

     

    2007年6月20日 上午 04:14
  • 感謝各位大大熱心回應,

    經過改用netstat -an,的確可以看到是某個外部ip在連我的1433port,

    但奇怪的是這ip並不固定,一直在改變,

    請問若在1433 port要開放的狀況下,如何阻斷這個情況呢?

    這些連線是在try sa密碼是嗎?

     

    -----------------------------------------------------------------------

    TCP    192.168.0.20:1433     211.233.19.221:7295    TIME_WAIT
    TCP    192.168.0.20:1433     211.233.19.221:7471    TIME_WAIT
    TCP    192.168.0.20:1433     211.233.19.221:7554    TIME_WAIT
    TCP    192.168.0.20:1433     211.233.19.221:7644    TIME_WAIT
    TCP    192.168.0.20:1433     211.233.19.221:7825    TIME_WAIT
    TCP    192.168.0.20:1433     211.233.19.221:7985    TIME_WAIT
    TCP    192.168.0.20:1433     211.233.19.221:7995    TIME_WAIT

    2007年6月28日 上午 12:44
  • 您好

     

    有關192.168.0.x開頭的是虛擬IP,應該是透過Router或防火牆上面使用M_IP或V_IP來使外面可以連到您的SQL服務。

    首先您要確認的是,這個IP是否有授權連到您的SQL Server。

     

    就目前經驗看起來,這樣子的連線有兩種可能性。

    1.由於您並沒有適當的對您的SQL Server進行保護,因此Internet上的機器可以輕易連入您的SQL Server。

    2. 211.233.19.221是公司授權許可的管理IP,比如說貴公司的IP代表號為211.233.19.221(意即直接對internet使用的IP)

     

    於資訊安全角度來看,資料庫這種比較重要的服務,一般來說不會曝光在Internet上面,但部份管理員可能為了管理方便。

    或是硬體功能沒辦法針對service開port。在這幾種情況下,可能會直接進行未授權的全面開放或是針對公司IP進行授權。

    本意可能原本是想開一個服務供管理員使用。在未設定好的情況下,也增加駭客或網路型病毒攻擊的機會。

     

    若經查211.233.19.221是貴公司認可的管理IP的話,就代表使用那個IP的使用者都可以連入您的SQL Server,當然如果有多個管理員都可以管理SQL Server的話。產生這樣的連線則為正常狀況。反之,若為不認可的IP連入,您的網路保安規則,則需要重新檢討(簡單說就是在您的網路設備跟本機允許IP上面進行調整。)。並只授權給您所認可的服務。(如IIS連線、AP對資料庫的連線、管理者對資料庫的連線等)

     

    總之,您還是要查閱一下您的SQL Server到底有多少服務在使用,您才能下定論,資料流的脈絡也要清楚。哪幾台機器會使用到這台資料庫。否則隨意的更改,則有可能造成您既有服務運作異常。請跟您的工作夥伴討論後確認吧。

     

    2007年6月28日 上午 01:53
  • 請問此台 SQL Server 的 TCP 1433 必須提供外部 IP 進行連線嗎?
    如果不需要,建議以 貴公司的防火牆或路由器(Router)加以阻隔,如果網管人員不願去改設定,可以改由這台 SQL Server 所在的 Windows Server 2003 「系統管理工具」裡的「本機安全性設定」,於左邊窗格中,建立一條「IP 安全性原則(位置:本機電腦)」的規則,並於右側窗格選擇「用戶端(僅回應)」選項。

    參考資料:
  • 建立 IPsec 原則以限制連接埠
  • 如何在 Windows Server 2003 中設定 SNMP 服務的網路安全性
  • How To:使用 IPSec 提供二個伺服器之間的安全通訊
2007年6月28日 上午 04:27
版主
  • 是的,此台 SQL Server 的 TCP 1433 必須讓某個外部 IP可進行連線,

    但傷腦筋的是netstat 看到的外部IP一直在變,而且根本不是那個允許的外部 IP。

    2007年7月2日 上午 12:43
  •  aaatw 寫信:

    是的,此台 SQL Server 的 TCP 1433 必須讓某個外部 IP可進行連線,

    但傷腦筋的是netstat 看到的外部IP一直在變,而且根本不是那個允許的外部 IP。

    由此推斷被允許連線的外部 IP 位址是固定的,因此網管人員是可以在防火牆或 Router 加以阻隔的,以便允許特定的 IP 位址才能建立 TCP 1433 的連線
    2007年7月2日 上午 01:42
    版主
  • 我也碰到相同的狀況,但是我們的系統是在封閉的內部網路,並未對外作開放,並不像是病毒或是攻擊。

    一台 Web Server ( Win2003 , SP 與 線上更新都ok , IP=192.168.100.10)

    一台 SQL Serverv  ( Win2003 , SP 與 線上更新都ok ,安裝 SQL2000+SP4, IP=192.168.100.11)

    兩台電腦各自獨立,未加入網域,管理者密碼也不相同。

     

    狀況1. Web Server 中 網站透過 odbc 以 192.168.100.11,1433 連接資料庫

    Global.asa 中設定連線資訊:

    Application("conNET_ConnectionString") ="APC"

    Application("conNET_ConnectionTimeout") = 15

    Application("conNET_CommandTimeout") = 30

    Application("conNET_CursorLocation") = 3

    Application("conNET_RuntimeUserName") = "apcuser"

    Application("conNET_RuntimePassword") = "d7hh2ks6615c"

     

    ASP網頁中連結語法為:(ins_APC001Status.asp)

    dim conNET

    Set conNET = Server.CreateObject("ADODB.Connection")

    conNET.Open Application("conNET_ConnectionString") ,Application("conNET_RuntimeUserName") ,Application("conNET_RuntimePassword")

    - - - - - -

    strSQL="Select * from W_APC001_Status Where AID=" & AidNo

    Set rs=Server.CreateObject("ADODB.Recordset")

    rs.Open strSQL,conNET

    if rs.eof then

    - - - - - -

    else

    - - - - - -

    end if

     

    set rs=nothing

    set conNET=nothing

     

    再一個網頁(Main.asp)中崁入數個 Iframe 去呼叫上述 ins_APC001Status.asp 網頁,取得並顯示狀態內容。(一般大約會同時開啟15-30個IFrame)

    所以在顯示 Main.asp 這個網頁時,一開始是正常的,但是要是同時有較多同事一起開啟 Main.asp 這個網頁時,就會發生以下的錯誤訊息......

     

    Microsoft OLE DB Provider for SQL Server 錯誤 '80004005'

    [DBNETLIB][ConnectionOpen (Connect()).]SQL Server 不存在或拒絕存取。

    /Util/ins_APC001Status.asp , 列25

     

    一開始以為是 odbc 的問題,所以重裝兩台系統後,將資料連線的方式改為:(Global.asa )

    Application("conNET_ConnectionString") = "Provider=SQLOLEDB;Data Source=192.168.100.11,1433;Initial Catalog=APC;User ID=apcuser;Password=d7hh2ks6615c"

     

    其他 asp 中的語法都同上例,未作修改。

     

    結果一開始也是正常可以開啟網頁看到監測內容,但是過一段時間後,網頁更新速度開始變慢,最後又出現同樣的錯誤訊息。

     

    我必須強調,IIS 與 SQL 都是在內部網路工作,對外是完全不通的,也只有幾台工作站分散在不同辦公室中開啟 web 中的監控網頁。

    為了排除病毒與攻擊的問題,所有電腦也都重新安裝過並作過線上更新(線上更新完後防火牆與外部網路完全撤除,全都不能上網)

     

    原本在 win2000 環境下並未發生這樣的現象,最近升級到 win2003 之後,這個問題就出現了。

    原本以為是 odbc 的問題,但是改為 OLEDB 方式連線後,一樣出現這樣的狀況。

     

    後來開啟 dos 視窗檢查 web 主機上資料連線數量發現,只要  Main.asp 這個網頁刷新一次,再dos視窗用 netstat -n 檢查,就發現會出現許多

      TCP    192.168.100.10:2310    192.168.100.11:1433   TIME_WAIT

      TCP    192.168.100.10:2311    192.168.100.11:1433   TIME_WAIT

      TCP    192.168.100.10:2312    192.168.100.11:1433   TIME_WAIT 

      ..........(192.168.100.10 Port 號會一直增加,但 192.168.100.10 明顯是 web 自己的 IP,並非其他電腦的ip)

     

    並且一直累增,直到數千個時,Main.asp 網頁刷新就開始變慢,最後出現上述錯誤訊息。

    同時我用效能監視器監看 SQL 主機的資料連線數量,卻只有6-18個左右(視 User 數量不定)。

     

    我後來試過將 WEB 升級為主控站,ODBC 原本是Call IP的方式改為 Call Name的方式,

    就完全恢復正常??? 真的是太奇怪了,究竟是什麼原因呢?

    由於這套系統在內部測試功能正常之後,就要開放給外部使用,

    如果  web 本身是主控站,實在太不安全了。

     

    (有試過另外建立主控站,但是ODBC設定時可以用 name 的方式呼叫,但是網頁開啟時就會出現

    Microsoft OLE DB Provider for ODBC Drivers 錯誤 '80004005'

    [Microsoft][ODBC SQL Server Driver][Named Pipes]SQL Server 不存在或拒絕存取。

    /Util/ins_APC001Status.asp , 列25
     

    改用 OLEDB 或是 odbc by IP 方式呼叫就會有上述一開始正常最後還是會錯誤的現象 )

     

    請教各位前輩指點,這究竟是什麼原因?

    是我的資料連線語法與開啟 RecordSet 方式不對,或是系統在安裝時有其他授權或權限的設定需要調整?

    或是 Window 2003 的 odbc 與 oledb 的問題?

     

     

    2007年7月11日 下午 07:12
  • 請問 這跟 Window 2003 中 MSDTC ,預設的安裝選項並不支援跨機器的分散式交易 有關嗎?

     

    2007年7月11日 下午 07:38
  •  mark20031206 寫信:
    我也碰到相同的狀況,但是我們的系統是在封閉的內部網路,並未對外作開放,並不像是病毒或是攻擊。(恕刪...)
    只看到有內部網段的連線,沒看到有外部網段的連線。由下面這個錯誤訊息來看:

    Microsoft OLE DB Provider for SQL Server 錯誤 '80004005'

    [DBNETLIB][ConnectionOpen (Connect()).]SQL Server 不存在或拒絕存取。

    /Util/ins_APC001Status.asp , 列25


    問題發生的原因可能是:
  • SQL Server 在那時候當掉了
  • Hostname、IP 或 DNS 設定有問題
  • 沒有連線 SQL Server 的權限
    可能的解法如下:
  • 請嘗試替連線字串多加上如下的字串:
    Network=DBMSSOCN;
    或是
    Network Library=DBMSSOCN;
  • 將 SQL Server 驗證方式改用混合驗證

    其他相關參考資料:
  • Active Server Pages 和 Microsoft Data Access Components 中 80004005 錯誤的疑難排解指南
  • DSN network library shown as "Other" in ODBC Administrator
  • 造成「SQL Server 不存在或拒絕存取」錯誤訊息的可能原因
  • 當您嘗試使用 TCP/IP 通訊端連線到叢集中的 SQL Server 具名執行個體時,收到「SQL Server 不存在或拒絕存取」錯誤訊息
  • 2007年7月12日 下午 02:46
    版主
  • Dear Alex

     

    我的問題倒不是在 [ 無法連結資料庫 ] 這部分,而是在網頁開啟或刷新後,似乎有許多 DataConnect 被鎖住

    因為不管是用 OLEDB 或是 用 ODBC ,一開始都可以正常連結資料庫開啟網頁。

    但是一段時間之後,用 netstat -n 查看,會有數百上千個

     

      TCP    192.168.100.10:2310    192.168.100.11:1433   TIME_WAIT

      TCP    192.168.100.10:2311    192.168.100.11:1433   TIME_WAIT

      TCP    192.168.100.10:2312    192.168.100.11:1433   TIME_WAIT 

      .................................. 

     

      TCP    192.168.100.10:4931    192.168.100.11:1433   TIME_WAIT

      TCP    192.168.100.10:4932    192.168.100.11:1433   TIME_WAIT 

      .................................. 

     

    累積再 web 這台主機中,我想最後會造成這樣錯誤訊息

    Microsoft OLE DB Provider for SQL Server 錯誤 '80004005'

    [DBNETLIB][ConnectionOpen (Connect()).]SQL Server 不存在或拒絕存取。

    /Util/ins_APC001Status.asp , 列25

    有可能如同你說的SQL當掉,但是我在 SQL 主機上並未查到任何異狀,也確認 SQL Server 當時是正常的。

    如果有異常,應該是 Web Connect to SQL 這個中間或兩端的問題。

    而在三測試,似乎問題是出在 web 端。

     

    我想請教的是:

    為何在 WEB 端會有大量的 Connect 一直累積沒有被重複使用或是釋放 ? 該如何解決 ?

     

     

     

    2007年7月12日 下午 03:33
  •  mark20031206 寫信:
    我的問題倒不是在 [ 無法連結資料庫 ] 這部分,而是在網頁開啟或刷新後,似乎有許多 DataConnect 被鎖住(恕刪...)
    我發現您的問題有重複  po 文,為了契合主題,我先暫時把這個討論主題關閉,我們移駕到您另外開啟的那邊去討論:請問WIN2003 x64 版本中,IIS 連結 SQL2000 的問題
    2007年7月12日 下午 03:49
    版主