April 2014 - Core-other - mailman3.cels.anl.gov

userbase2 cross domain account name uniqueness
by John Valdes 04 Jun '14

04 Jun '14

Hi Ti, I'm trying to create an account in the LCRC domain in userbase2 for Xiaoliang Zhong, an ANL Postdoc in MSD. His ANL username is "zhongx" which isn't used in LCRC (or MCS), so I'd like to use that as his LCRC account name (that's the name he chose in his account request). However, that account name is in use in the CI domain by ID Xiang Zhong (aka Sally Zhong) who appears to be a different person, and so userbase2 (via sovereign) isn't allowing me to use zhongx as Xiaoliang Zhong's account name in the LCRC domain. Is it possible to remove the requirement that account names be unique across domains in userbase2? Or at least between CI and ANL domains (the latter being MCS, LCRC and Kbase), as having unique account names within ANL would be desirable I think (when approving accounts for LCRC, I try to use the person's ANL username or MCS account name if they have one of the latter). Or will allowing non-unique account names between CI and ANL cause problems? Alternately, in this specific case, it looks like Xiang Zhong in CI is an old account (from 2012) and was denied every resource she requested (except Zimbra Mail), so if that account isn't active in CI, maybe we could rename it and/or purge it from userbase2 and free up zhongx as an account name? Otherwise, I'll assign a different account name to Xiaoliang Zhong for his LCRC account. John

2 3

where's Linda 4/29
by Linda Winkler 29 Apr '14

29 Apr '14

a.m. downtown to patch fiber for UC back to Lab after lunch lw

1 0

Housewarming Party
by Leggett, Torrance I. 28 Apr '14

28 Apr '14

I forgot to formally announce this, but you've heard me talk about it at the sync. Amy and I are having a housewarming/birthday party on May 17th starting at 3:30 (that's when Aidan's Minecraft bday party will start) going until people decide to leave. There will be food and drinks. Everyone's invited just let me know if you're planning on coming. Our address is 240 Bennett Ct S, Oswego, IL 60543.

1 0

where's Linda 4/28
by Linda Winkler 27 Apr '14

27 Apr '14

taking Mon as a vacation day lw

1 0

More problems being found from off-site.
by rackow＠anl.gov 26 Apr '14

26 Apr '14

There is a serious problem in that the cyber office bases most of our scanning activity on the ARP tables. It appears there are major sections of the 140.221 networks that this data is not being collected. The result being that the machines to not appear "alive" and not getting scanned. This has resulted in several OpenSSL Heartbleed vuln machines being found. Now we just got notice that 140.221.87.207 and 140.221.87.208 are acting as NTP servers to the world and vulnerable to issues that would allow them to become part of a DDoS attack on others. There should be no reason to have these machines acting as NTP servers to the world. Before more things hit us with unknowns, I think it's time for an overall review of the firewall/acl/conduit layout of the 140.221 networks and systems. --Gene

4 5

Re: SNMP access into 140.221.87.
by Ryan M. Aydelott 25 Apr '14

25 Apr '14

So these were configured with basic SNMP access which as far as I know is not needed for these hosts, that has since been disabled on both m6/m7 and the running service shutdown. root@m7-p:~# update-rc.d -f snmpd remove Removing any system startup links for /etc/init.d/snmpd ... /etc/rc1.d/K20snmpd /etc/rc2.d/K80snmpd /etc/rc3.d/K80snmpd /etc/rc4.d/K80snmpd /etc/rc5.d/K80snmpd -ryan On Apr 25, 2014, at 2:06 PM, Ryan M. Aydelott <ryan.aydelott(a)gmail.com> wrote: > > > On Apr 17, 2014, at 1:59 PM, Stacey, Craig J. <stace(a)anl.gov> wrote: > >> Are these Magellan IPs? >> >> -- >> Craig >> >>> -----Original Message----- >>> From: core-helpdesk-bounces(a)mcs.anl.gov [mailto:core-helpdesk- >>> bounces(a)mcs.anl.gov] On Behalf Of Gene Rackow >>> Sent: Thursday, April 17, 2014 1:59 PM >>> To: core-admins(a)mcs.anl.gov >>> Cc: Rackow, Eugene A.; Schmitz, Corby B. >>> Subject: SNMP access into 140.221.87. >>> >>> We got an alert from Shadowserver indicating they were able to connect to >>> the UDP port 161 on machines 140.221.87.207 and 208. >>> >>> "timestamp","ip","protocol","port","hostname","sysdesc","sysname","asn", >>> "geo","region","city","version" >>> "2014-04-16 06:01:28","140.221.87.207","udp",161,,"Linux m6-p 3.2.0-30- >>> generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 >>> x86_64",,683,"US","ILLINOIS","LEMONT",2 >>> "2014-04-16 08:14:17","140.221.87.208","udp",161,,"Linux m6-p 3.2.0-30- >>> generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 >>> x86_64",,683,"US","ILLINOIS","LEMONT",2 >>> >>> Not sure what the firewall rules are for this subnet, but this really shouldn't >>> have been allowed through. >>> >> >> >> >

1 0

RE: UDP inbound?
by Stacey, Craig J. 23 Apr '14

23 Apr '14

Are we still allowing UDP inbound? Any reason to? The device below is a webcam. There may be others like this. -- Craig ________________________________________ From: Gene Rackow [rackow(a)anl.gov] Sent: Tuesday, April 22, 2014 4:41 PM To: Stacey, Craig J. Subject: UDP inbound? It appears that shadowserver is poking around some more. They just sent us indication they poked at 140.221.11.51 36630 UDP and found a response of this, yesterday. "Linux/2.6.31, UPnP/1.0, Portable SDK for UPnP devices/1.4.1","upnp:rootdevice","uuid:Upnp-BasicDevice-1_0-00408CC2B661::upnp:rootdevice" They also indicate this from a hit on this, but the traffic looks UDP not TCP, so .. http://140.221.11.51:49152/rootdesc1.xml I haven't attempted to do a full UDP based scan across MCS space from outside to see what may be there. We need to get a better handle on what is there and what can/should be able to be locked down. --Gene

3 2

Where's Tina - today and Friday afternoon
by Stanton-Piersanti, Tina Joy 22 Apr '14

22 Apr '14

Vinnie’s game was cancelled last night and his coach just text us and said it is rescheduled for tonight. Joe is on the late shift this week, I will leave early to take him. Also, my Uncle died over the weekend. Leaving early Friday afternoon to go with my mom to his services. T.

1 1

dev.i2u2.org
by rackow＠anl.gov 21 Apr '14

21 Apr '14

The host 192.5.186.72. dev.i2u2.org is coming up has having "DropBear" SSH server installed on port 22. It also indicates it has some default SSH keys from Supermicro as well. We need to adjust something in the backend on scavenger as this just appeared in the CIS scans, not MCS. 192.5.186.72 dev.i2u2.org 71533 SuperMicro Device Uses Default SSH Host Key Medium 2014-04-20 00:30:02 192.5.186.72 dev.i2u2.org 70545 Dropbear SSH Server < 2013.59 Multiple Vulnerabilities Medium 2014-04-18 07:30:02 192.5.186.72 dev.i2u2.org 58183 Dropbear SSH Server Channel Concurrency Use-after-free Remote Code Execution High 2014-04-18 07:30:02 Not sure what this is, or may have been at the scan times. -_Gene

4 9

Mass Acknowledgement Executed
by Nagios 18 Apr '14

18 Apr '14

Acknowledged Alerts: by stace reason: Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;atlantis.icis.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;climate-search.cels.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;climate.mcs.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;ftp.mcs.anl.gov-http;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;inside.alcf.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;inside.mcs.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;kiosk.mcs.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;nimbusproject.org;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;pmodels.mcs.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;recruit.mcs.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;see.ci.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;webapps.cels.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;www-i.mcs.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;www.cels.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;www.cogkit.org;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;www.cosmea.mcs.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;www.mcs.anl.gov;1;0;0;stace;Acking Alerts - Change Me [1397869874] ACKNOWLEDGE_SVC_PROBLEM;wilbur-copy.mcs.anl.gov;www.scidacreview.org;1;0;0;stace;Acking Alerts - Change Me

1 0