I'm trying to look into this ... I don't know what host 192.5.186.65 is. It's not in i2u2.org and it's not in hostbase or dns. 192.5.186.80 should not be responding on those ports as far as I know, all the ipmi interfaces should be on hidden net. I'm making sure the ipmi is configured on node1.i2u2.org properly -- Adam Max Trefonides CELS Systems [email protected] On Jul 7, 2014, at 12:05 PM, Gene Rackow <[email protected]> wrote:
It appears that with all the new vulns being reported in IPMI, Shadowserver has taken up the task of scanning the world again. It appears they have found an IPMI service running on node1.i2u2.org. Running some netflow, this appears to be from a scan they did at 0705.20:14:11 They poked UDP 192.5.186.80 623 via UDP and get a response back. They probed lots of other systems, but only this 1 responded.
"timestamp","ip","port","hostname","tag","ipmi_version","asn","geo","region","city","none_auth","md2_auth","md5_auth","passkey_auth","oem_auth","defaultkg","permessage_auth","userlevel_auth","usernames","nulluser","anon_login","error","deviceid","devicerev","firmwarerev","version","manufacturerid","manufacturername","productid","productname" "2014-07-06 01:14:11","192.5.186.80",623,"node1.i2u2.org","ipmi","1.5",683,"US","ILLINOIS","LEMONT","no","no","no","no","yes","-","disabled","disabled","yes","no","no",,,,,,,,,
I'm not exactly sure what they are reporing in this.
Any hope of just killing UDP access from outside on these subnets? In looking at the netflow logs for the past week, it appears the only legit traffic is syslog going to 130.202.172.3 Argonne central server. syslog going to 128.135.125.120 con.ci.uchicago.edu. radius traffic going to auth.mcs.anl.gov:1812 dns traffic to 130.202.101.6 and 130.202.101.37
Why is 192.5.186.65:161 talking to 192.117.188.130 random ports? Israeli Traktor Company 0701.05:54:40.571 0701.05:54:40.571 5 192.117.188.130 19922 3 192.5.186.65 161 17 0 2 176 0701.05:54:40.578 0701.05:54:40.578 5 192.5.186.65 161 3 192.117.188.130 19922 17 0 1 134 0701.05:54:40.600 0701.05:54:40.600 6 192.5.186.65 161 3 192.117.188.130 19922 17 0 1 134 0701.06:39:40.532 0701.06:39:40.532 5 192.117.188.130 22913 3 192.5.186.65 161 17 0 2 176 0701.06:39:40.547 0701.06:39:40.547 5 192.5.186.65 161 3 192.117.188.130 22913 17 0 1 134 0701.06:39:40.571 0701.06:39:40.571 6 192.5.186.65 161 3 192.117.188.130 22913 17 0 1 134 0701.07:25:57.035 0701.07:25:57.035 5 192.117.188.130 26045 3 192.5.186.65 161 17 0 2 176 0701.07:25:57.058 0701.07:25:57.058 5 192.5.186.65 161 3 192.117.188.130 26045 17 0 1 134 0701.07:25:57.090 0701.07:25:57.090 6 192.5.186.65 161 3 192.117.188.130 26045 17 0 1 134 They probe, we respond.
There are many other probes that are not getting anywhere. The 2 below are the only others that got a response. 0705.09:21:15.302 0705.09:21:15.302 6 71.6.165.200 40000 3 192.5.186.80 5353 17 0 2 148 0705.09:21:15.300 0705.09:21:15.300 6 192.5.186.80 5353 3 71.6.165.200 40000 17 0 2 212
0705.20:14:11.197 0705.20:14:11.197 6 192.5.186.80 623 3 184.105.247.230 53030 17 0 2 116 0705.20:14:11.174 0705.20:14:11.174 5 184.105.247.230 53030 3 192.5.186.80 623 17 0 2 102
--Gene