Re: About an unclear IP address of PS6000

Storage

Information and ideas on Dell storage solutions, including DAS, NAS, SAN and backup.

About an unclear IP address of PS6000

Answered (Verified) This question is answered

I ask it about storage (EqualLogicPS6000) which we conserve it and manage.

I can confirm the IP address that we did not set when we refer to this storage in "snmpwalk".
As a result of having asked Dell Co.Ltd., I receive an answer when "it is the IP address that a storage manages, and this IP address is harmless".

However, these IP addresses are different every time when we inquire in snmpwalk.
Therefore, I cannot distinguish a malicious IP address from a harmless IP address. We think that this is a problem of security.
Please teach me the way to distinguish.

Thanking you in advance.

Verified Answer
  • There should be a total of 5 IP addresses on a PS6000.    The Group IP address, which is an IP ALIAS that can appear to be on each PHYSICAL network interface.   Then the 4 physical port IP addresses.   That's all the IP addresses that should appear to be associated with the array.  

    -don

  • There can be no other "malicious" IP addresses on the array.   What fields are you referring to?  Are the IP addresses in your environment?  Is the array on its own isolate IP subnet?  

    -don

  • Are you scanning with snmpwalk in your iSCSI network/vlan?

    Your iSCSI network should be isolated from your regular network, which should make it secure enough to not really need to scan it I would think.

    Member since 2003

  • What you are seeing is the result of basic TCP/IP.   This is the same for any network device.  The first set of IPs are the result of device announcing themselves as routers.  

    Control your network and you control that effect.  I.e. isolated iSCSI SAN and the use of firewalls.

    The connection state is iSCSI connections.  showing the server/array ports in use.

    Also you should upgrade to 5.2.2. at your next opportunity.

    -don

  • Hello,

    Please call me Don, and you're not being a pest.   However, those IPs are not in my environment so they won't show up.

    If you do a nslookup on one of those IPs you get:

    $ nslookup 85.78.75.78

    Server:         143.166.220.125

    Address:        143.166.220.125#53

    Non-authoritative answer:

    78.75.78.85.in-addr.arpa        name = GGMMDLXXVIII.gprs.sl-laajakaista.fi.

    Authoritative answers can be found from:

    75.78.85.in-addr.arpa   nameserver = ns6.sci.fi.

    75.78.85.in-addr.arpa   nameserver = ns3.sci.fi.

    75.78.85.in-addr.arpa   nameserver = ns5.sci.fi.

    So those are valid IPs.  

    I suggest you focus on your network itself.   Use something like 'iptraf' or 'wireshark' to monitor data to / from the SAN subnet.  

    The array is responding properly.  This same kind of thing exists on servers and other network devices.

    Regards,

    -don

All Replies
  • There should be a total of 5 IP addresses on a PS6000.    The Group IP address, which is an IP ALIAS that can appear to be on each PHYSICAL network interface.   Then the 4 physical port IP addresses.   That's all the IP addresses that should appear to be associated with the array.  

    -don

  • Thank you very much for your prompt reply.

    Sorry,I understand that there is 5 IP address in PS6000.(Group IP ×1、physical port IP ×4)

    However, I can confirm about 20 IP addresses other than these 5IP addresses when I confirm PS6000 in "snmpwalk".

    In addition, IP address of this 20, it changes every time you check "snmpwalk".

    I feel that this is a problem.

    Because,If contains the IP address that is truly harmful,  we can not distinguish between harmless IP address.

  • There can be no other "malicious" IP addresses on the array.   What fields are you referring to?  Are the IP addresses in your environment?  Is the array on its own isolate IP subnet?  

    -don

  • Are you looking at MIBs like:  ipRouteDest

    RFC1213-MIB::ipRouteDest.172.23.30.91 = IpAddress: 172.23.30.91

    RFC1213-MIB::ipRouteDest.172.23.40.128 = IpAddress: 172.23.40.128

    RFC1213-MIB::ipRouteDest.172.23.73.122 = IpAddress: 172.23.73.122

    RFC1213-MIB::ipRouteDest.172.23.100.151 = IpAddress: 172.23.100.151

    RFC1213-MIB::ipRouteDest.172.23.250.199 = IpAddress: 172.23.250.199

    Or tcpConnState?

    RFC1213-MIB::tcpConnState.172.23.10.236.9876.172.23.10.242.58932 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.23.10.236.9876.172.23.10.243.57346 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.23.10.236.9876.172.23.10.243.57348 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.23.10.236.9876.172.23.10.243.57350 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.23.10.236.9876.172.23.10.243.57364 = INTEGER: established(5)

    The array is storing information from your environment.  I.e. TCP, and iSCSI connections, routers that have announced routes for hosts or networks, etc...

    -don

    Suggested by
  • Are you scanning with snmpwalk in your iSCSI network/vlan?

    Your iSCSI network should be isolated from your regular network, which should make it secure enough to not really need to scan it I would think.

    Member since 2003

  • Dear dwilliam62

    Thank you for always being so kind!

    Field that I see is the following.

    ・ipRouteDest

    RFC1213-MIB::ipRouteDest.0.0.0.0 = IpAddress: 0.0.0.0

    RFC1213-MIB::ipRouteDest.0.9.138.1 = IpAddress: 0.9.138.1

    RFC1213-MIB::ipRouteDest.5.0.1.0 = IpAddress: 5.0.1.0

    RFC1213-MIB::ipRouteDest.85.78.75.78 = IpAddress: 85.78.75.78

    RFC1213-MIB::ipRouteDest.101.116.104.48 = IpAddress: 101.116.104.48

    RFC1213-MIB::ipRouteDest.172.20.37.13 = IpAddress: 172.20.37.13

    RFC1213-MIB::ipRouteDest.180.107.1.0 = IpAddress: 180.107.1.0

    RFC1213-MIB::ipRouteDest.225.96.13.0 = IpAddress: 225.96.13.0

    RFC1213-MIB::ipRouteDest.255.255.255.255 = IpAddress: 255.255.255.255

    For Example,"85.78.75.78","101.116.104.48","225.96.13.0",We have not set IP addresses.

    In your Environment,these ip addresses can see?

    What FirmWareVersion are you using now? I'm using F/W 5.2.1.

    I have been doubting the possibility of a bug in the firmware...

    For these IP address, I checked Dell's Japan branch office,received the answer that

    「Storage has set up these IP address , Since there is no harm, we want you to ignore.」

    But when we leave this problem,we cannot distinguish malicious ip address and harmless ip address.

    Do you have the idea to distinguish malicious ip address and harmless ip address?

    The way,tcpConnState is the following.

    RFC1213-MIB::tcpConnState.172.20.37.12.3260.172.20.37.30.49356 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.20.37.12.3260.172.20.37.30.49651 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.20.37.12.3260.172.20.37.30.56068 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.20.37.12.3260.172.20.37.30.60730 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.20.37.12.3260.172.20.37.82.49154 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.20.37.12.3260.172.20.37.84.49154 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.20.37.13.3260.172.20.37.52.50262 = INTEGER: established(5)

    RFC1213-MIB::tcpConnState.172.20.37.13.65106.172.20.37.52.3260 = INTEGER: established(5)

    We appreciate your prompt attention to this matter.

  • thanks!  Dev Mgr

    Our iSCSI network is isolated from our regular network, which should make it secure enough to not really need to scan it .

  • What you are seeing is the result of basic TCP/IP.   This is the same for any network device.  The first set of IPs are the result of device announcing themselves as routers.  

    Control your network and you control that effect.  I.e. isolated iSCSI SAN and the use of firewalls.

    The connection state is iSCSI connections.  showing the server/array ports in use.

    Also you should upgrade to 5.2.2. at your next opportunity.

    -don

  • Dear dwilliam62

    I hope you don't think I'm being a pest!   I promise, this will be the last question.

    >What you are seeing is the result of basic TCP/IP.   This is the same for any network device.  The first set of IPs are the result of device announcing themselves as routers.  

    What you say is that The first set and the last set of IPs are the result of device announcing themselves as routers?

    I understand that The first set of IPs are default route , and the last set of IPs are broadcast address. These addresses are basic TCP/IP.

    But I think, For Example,"85.78.75.78","101.116.104.48","225.96.13.0" are not basic TCP/IP.

    My question is that

    ・In your Environment,these ip addresses can see?

    ・What FirmWareVersion are you using now?   I'm using F/W 5.2.1.

    I really appreciate all your help.

  • Hello,

    Please call me Don, and you're not being a pest.   However, those IPs are not in my environment so they won't show up.

    If you do a nslookup on one of those IPs you get:

    $ nslookup 85.78.75.78

    Server:         143.166.220.125

    Address:        143.166.220.125#53

    Non-authoritative answer:

    78.75.78.85.in-addr.arpa        name = GGMMDLXXVIII.gprs.sl-laajakaista.fi.

    Authoritative answers can be found from:

    75.78.85.in-addr.arpa   nameserver = ns6.sci.fi.

    75.78.85.in-addr.arpa   nameserver = ns3.sci.fi.

    75.78.85.in-addr.arpa   nameserver = ns5.sci.fi.

    So those are valid IPs.  

    I suggest you focus on your network itself.   Use something like 'iptraf' or 'wireshark' to monitor data to / from the SAN subnet.  

    The array is responding properly.  This same kind of thing exists on servers and other network devices.

    Regards,

    -don

  • Dear Don

    Please call me Takeshi. Thank you for putting up with my frequent Posts. I almost feel like we are becoming pen pals! By now, I guess you get used to my funny English writing.

    Now, I understood that your suggestion is " You should use  a network monitoring tool like wireshark or iptraf, and check that not exist illegal traffic on SAN subnet",and "Completely Isolate SAN subnet  from servers and other network devices"

    I think  the essential idea.

    Thank you so much for answering all my questions!

    Thank you for your kind cooperation, and I look forward to talk with you again!

  • Ohayou gozaimasu Takeshi-san,

     Dou itashi mashite! 

      Well, that about all the Japanese I remember!   Except for Sumimasen.   I used that allot when I was in Tokyo.  :-D 

     I'm glad I could help. 

     Take care my friend. 

     Yoroshiku desu,

     

    -don

Page 1 of 1 (13 items)