I use CentOS 7.x also CSF/LFD installed. Till now they did not get into the server.
I'll look into mod_security. Thanks, On Fri, Oct 7, 2016 at 1:01 AM, Anthony Biacco <abia...@handll.com> wrote: > > > On Thu, Oct 6, 2016 at 3:42 PM, Spork Schivago <sporkschiv...@gmail.com> > wrote: > >> Are you sure they haven't successfully found away in? There are some >> free programs that I use to help prevent this stuff. ConfigServer >> Firewall / LFD is a good one. Rkhunter and chkrootkit scan for rootkits. >> The big one that helps the most, I feel, is Mod Security. That's the >> one that monitors the traffic looking for known scanning software, >> exploits, etc and blocks it. I run in a *nix environment and don't have a >> lot of experience with Windows servers though. Not sure what you're >> running. I'm always really paranoid and would definitely be worried about >> by system being compromised if I saw traffic like you're seeing though. >> But again, I'm not really that intelligent when it comes to stuff like this. >> >> Ken >> >> > I was going to suggest mod_security as well. I'm not running it, but it's > on my TODO list. I have to determine the performance implications, if any. > > -Tony > > > >> On Thu, Oct 6, 2016 at 5:21 PM, Spork Schivago <sporkschiv...@gmail.com> >> wrote: >> >>> Thanks Tony! Much appreciated. >>> >>> Erik, >>> >>> Did I ever try to run what on my server? The string query that >>> Berkeley sends looking for the malware to respond? If so, no, I have >>> never tried to send that carefully crafted packet to my Apache server. >>> From the previous user who had what appears to be the same issue as Mitchell >>> though, I would imagine it'd probably just deliver my default web page >>> (index.html). That's my guess though. >>> >>> If anyone cares, I can copy the other e-mails they sent to me that >>> explain how it all works and why the full string isn't in the Apache logs >>> (I think that has something to do with the way Apache responds to the >>> string). >>> >>> They're not actually trying to exploit the server, they're just trying >>> to find servers that have been infected. If the malware sees a special >>> string, it responds with a special string. At that point in time, the >>> college contacts the local law enforcement for that area to inform them and >>> hope that they contact the owner of the server to inform them that they're >>> infected. Not the best way I guess to inform people, but better than >>> nothing I guess. >>> >>> Here, in my city, I doubt the local law enforcement would ever contact >>> me with anything computer related. I contacted them before because of a >>> crime that happened in my house but because the internet and a computer was >>> involved, they said they couldn't help and my best bet would be trying to >>> contact the FBI or some other government organization. I doubt anyone at >>> my police station really knows much about PCs. There doesn't seem to be a >>> cyber crimes division or anything like that. >>> >>> On Thu, Oct 6, 2016 at 4:08 PM, Anthony Biacco <abia...@handll.com> >>> wrote: >>> >>>> >>>> >>>> On Thu, Oct 6, 2016 at 8:47 AM, Spork Schivago <sporkschiv...@gmail.com >>>> > wrote: >>>> >>>>> >>>>> There's away to do a reverse IP lookup on the IP address and see if >>>>> there's a DNS entry for it. That's how I was able to successfully figure >>>>> out who the senders were (Berkeley) originally. I used dig I believe. >>>>> I >>>>> don't have access to my Linux box right now, otherwise I'd check to see if >>>>> the IP addresses are actually from Berkeley. There's always a chance >>>>> that >>>>> they're using more than one server / IP now to conduct the scanning. I >>>>> believe they were originally trying to scan the whole internet. >>>>> >>>>> >>>> based on the IP of 169.229.3.91 given by Mitchell: >>>> >>>> 91.3.229.169.in-addr.arpa. 9787 IN PTR >>>> researchscan1.EECS.Berkeley.EDU. >>>> >>>> University of California - Office of the President UCSD-NET-169-228 >>>> (NET-169-229-0-0-1) 169.229.0.0 - 169.233.255.255 >>>> University of California at Berkeley ISTDATA (NET-169-229-0-0-2) >>>> 169.229.0.0 - 169.229.255.255 >>>> >>>> -Tony >>>> >>>> >>>> >>>> They had said it's a very specific type of malware that only affects >>>>> IIS to their knowledge. If you're not running a Windows server running >>>>> IIS, you should be good to go. >>>>> >>>>> On Thu, Oct 6, 2016 at 8:27 AM, Rainer Canavan < >>>>> rainer.cana...@sevenval.com> wrote: >>>>> >>>>>> On Wed, Oct 5, 2016 at 6:26 PM, Joe Muller <jmul...@arccorp.com> >>>>>> wrote: >>>>>> > From the looks of it I would say it is targeting servers running >>>>>> SSL. Are >>>>>> > you serving up HTTP or HTTPS ? >>>>>> >>>>>> I don't think that that is valid SSL, unless your httpd discards the >>>>>> first few bytes. >>>>>> There was a SANS handler diary entry just yesterday about this: >>>>>> >>>>>> https://isc.sans.edu/forums/diary/SSL+Requests+to+nonSSL+HTT >>>>>> P+Servers/21551/ >>>>>> >>>>>> if I try `openssl s_client -connect localhost:14020`, I get the below >>>>>> entry in my access.log, >>>>>> which matches the description in the diary: >>>>>> >>>>>> 127.0.0.1 localhost:14020 - - [06/Oct/2016:14:24:53 +0200] - >>>>>> "\x16\x03\x01\x01,\x01" 400 226 "-" "-" >>>>>> >>>>>> this, however, is something completely different. I'd also guess it's >>>>>> some kind >>>>>> of vulnerability scan: >>>>>> >>>>>> > IP >>>>>> > 0.0.0.0 - - [02/Oct/2016:11:29:08 +0300] >>>>>> > "n\x1d\xb6\x18\x9ad\xec[\x1d\b\xe6k\xbb\xe5L" 200 48605 >>>>>> > 0.0.0.0 - - [02/Oct/2016:16:04:20 +0300] >>>>>> > "\x95\xa3\xb1\xce\xc8\xeb:\x86\x87\xb4\x03g\xfa~\x9f{\x07\xd >>>>>> a\xef6O\xa1~\x91[\xf2\x05E\xac\xad\x8d\x9d\xbe\xf5\xfc\xc5\" >>>>>> \xed\xa3u" >>>>>> > 200 48605 >>>>>> >>>>>> Rainer >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >>>>>> For additional commands, e-mail: users-h...@httpd.apache.org >>>>>> >>>>>> >>>>> >>>> >>> >> >
