Re: Compromised postgresql instances
От | Andrew Dunstan |
---|---|
Тема | Re: Compromised postgresql instances |
Дата | |
Msg-id | 56825482-ddc4-0c38-e633-61061d0ae4fc@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: Compromised postgresql instances (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Список | pgsql-hackers |
On 06/08/2018 06:13 PM, Andrew Gierth wrote: >>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > > Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > >> Please cite actual instances of such reports. Vague queries like > >> this help nobody. > > We do also get them on the IRC channel every once in a while, not > very frequently but enough to notice (maybe 2-3 so far this year?). > > Tom> Unless there's some evidence that these attacks are getting in > Tom> through a heretofore unknown PG security vulnerability, rather > Tom> than user misconfiguration (such as weak/no password), I'm not > Tom> sure what the security list would have to offer. Right now it > Tom> seems like Steve's move to try to gather more evidence is quite > Tom> the right thing to do. > > Right. All the instances on IRC that I'm personally aware of have > followed this pattern: either the user has used "host all all 0.0.0.0/0 > trust", or they used "host all all 0.0.0.0/0 md5" where the password for > the postgres user has been one where it's plausible that a simple > automated dictionary attack could have guessed it (e.g. "654321" in one > report). > > Excuses for doing this have varied (but I'm pretty sure I've heard "we > put that in while trying to fix a problem and forgot to take it out" > more than once - so it's worth a reminder that one should never, ever, > suggest this on any help forum). > > The reports are similar enough and generic enough that it seems pretty > certain that the scanning and subsequent compromise is all automated; > some reports have included a (failed) attempt to use local root exploits > to escalate from the postgres user to root access. Compromised systems > have been reportedly used as DDoS traffic sources and for cryptocurrency > mining, but obviously other uses can't be ruled out. I don't know of any > reports of data being exfiltrated or modified, but that doesn't mean it > doesn't happen. > > I have (private) logs of the channel going back a while, but I haven't > made any attempt to track how often it happens - the above is basically > all from memory. > Well, I guess every service is going to be vulnerable to misconfiguration. The fact that they are automated (oresumably knowing how to speak the wire protocol or using a library that does) is a bit scary, but not surprising. My view is that generally DB servers should not be reachable from the internet in the first place, certainly not without a client cert, but ideally not at all. Then misconfigurations like those Andrew refers to above would not be so lethal. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: