It has an effect if your Postgres instance isn't blocked at the firewall, and people are actually trying to access it. Which they will, unless you block them. As I said, probably much safer to block at the firewall level--better protection from DOS as well.
On Thu, 2007-11-01 at 08:51 +0000, Stuart Lewis [sdl] wrote: > Hi Sue, > > pg_hba.conf only controls who can communicate with Postgres, not who can > communicate with DSpace. > > Normally it is only 'applications' (e.g. DSpace) that talk to Postgres, > not users. > > A user talks to DSpace, who in turn talks to Postgres. Postgres has no > idea or interest in the IP address of the user who is using DSpace, only > that of the DSpace application. > > Therefore adding malicious IP address into that config file will sadly > have no effect. You have to block users higher in the stack, either at > the application level (apache or tomcat directives), or at the network > level (firewall changes). > > Thanks, > > > Stuart > _________________________________________________________________ > > Gwasanaethau Gwybodaeth Information Services > Prifysgol Aberystwyth Aberystwyth University > > E-bost / E-mail: [EMAIL PROTECTED] > Ffon / Tel: (01970) 622860 > _________________________________________________________________ > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS] > Sent: 31 October 2007 17:51 > To: Mika Stenberg; [email protected] > Subject: Re: [Dspace-tech] Blocking a malicious user > > You can block ip addresses at the postgreSQL level in the pg_hba.conf > file. Here is a person I blocked by ip address who was sending all > kinds of GET requests to our DSpace server: > > host all all malicious.ip 255.255.255.255 > reject > > Sue Walker-Thornton > NASA Langley Research Center > ConITS Contract > 757-224-4074 > [EMAIL PROTECTED] > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Mika > Stenberg > Sent: Wednesday, October 31, 2007 6:00 AM > To: [email protected] > Subject: Re: [Dspace-tech] Blocking a malicious user > > We've had problems like that as well. Blocking specific IP's works only > for > a while since many bots and spammers seem to change their IP frequently. > We > didnt come up with a decent solution for this, but blocking an entire > country of origin for a period of time has been on my mind. Managing the > allowed requests / timeslot for a specific IP might also do the trick. > > -Mika > > > > If they're nasty enough, though, they'll drown your Apache or Tomcat > > server in replying with 403s. I've had times that I needed to be > > absolutely merciless and block at the firewall level, using iptables; > > then they don't even get as far as userspace. > > > > On Tue, 2007-10-30 at 14:01 -0500, Tim Donohue wrote: > > > George, > > > > > > We had a similar problem to this one in the past (a year or so ago). > I > > > > > just flat out blocked the IP altogether (not even specific to > > > /bitstream/) via this Apache configuration: > > > > > > <Location /> > > > Order Allow,Deny > > > > > > Deny from {malicious ip} > > > > > > Allow from all > > > </Location> > > > > > > This looks similar to your config though (except it blocks all > access > > > from that IP). > > > > > > - Tim > > > > > > George Kozak wrote: > > > > Hi... > > > > > > > > I am having a problem with an IP that keeps sending thousands of > "GET > > > > > > /bitstream/..." requests for the same item. > > > > > > > > I have placed the following in my Apache.conf file: > > > > > > > > <Directory /bitstream/> > > > > Options Indexes FollowSymLinks MultiViews > > > > AllowOverride All > > > > Order allow,deny > > > > allow from all > > > > deny from {malicious ip} > > > > </Directory> > > > > > > > > I also placed the following in my server.xml in Tomcat: > > > > <Valve className="org.apache.catalina.valves.RemoteAddrValve" > > > > deny="xxx\.xxx\.xxx\.xx" /> > > > > > > > > However, this person still seems to be getting through. My java > > > > process is running from 50%-80% CPU usage. Does anyone have a > good > > > > idea on how to shutout a malicious IP in DSpace? > > > > > > > > *************************** > > > > George Kozak > > > > Coordinator > > > > Web Development and Management > > > > Digital Media Group > > > > 501 Olin Library > > > > Cornell University > > > > 607-255-8924 > > > > *************************** > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > - > > > > This SF.net email is sponsored by: Splunk Inc. > > > > Still grepping through log files to find problems? Stop. > > > > Now Search log events and configuration files using AJAX and a > > browser. > > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > > _______________________________________________ > > > > DSpace-tech mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > > > > > > > > > > > ------------------------------------------------------------------------ > - > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a > browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > DSpace-tech mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > > > > > > > ------------------------------------------------------------------------ > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > ------------------------------------------------------------------------ > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
