Joined: 18 Dec 2003
Posts: 13497
Location: Behind You
Posted: 11/27/11 11:13
kdh:
rickallen:
Kdh, thanks for the offer and I may have to take you up on it. I'm trying to avoid ip blocking since these attacks seem to be coming from all over the world including the US. Think I will set it out for a while to see what the team comes up with.
Whatever it is I hope it includes "deny all" on signups and "reject all" on messages. Better yet some checkboxes to select stuff to delete would be a good addition to some future release. Got to clear this stuff out.
BTW, anyone with this issue might want to set messages to admin approval. I see the spam bot us flooding my message system too.
the neat thing about my script is if you reboot the host, all the deny rules go away. So in the short term, it works out really well. when the storm clears up, you just reboot the host a few weeks later and your rule set is back to default.
Obviously the little dutch boy blocking IP's is not a solution and promoting it as one is not very helpful and is mostly cluttering up the thread.
If you would like, you could make it a csv or something people could import in to jamroom's blocked IP list.
I don't know why you would stick 4000 IP's in IPTABLES and think that you're doing something good? That is a ton of IPTABLES rules. On some systems you can cause it not to be able to restart, or to become so painfully slow... and obviously you shouldn't have to reboot a production server to turn off whatever you turn on.
If you dump it in jamroom's blocked IP's you negate that completely. No need for root or a script or whatever. Or also the option of dumping it in .htaccess is available
I WOULD suggest jamroom's blocked IP list.
Obviously the only real fix here, is fixing the software, anything else is little dutch boy security.
Kdh, thanks for the offer and I may have to take you up on it. I'm trying to avoid ip blocking since these attacks seem to be coming from all over the world including the US. Think I will set it out for a while to see what the team comes up with.
Whatever it is I hope it includes "deny all" on signups and "reject all" on messages. Better yet some checkboxes to select stuff to delete would be a good addition to some future release. Got to clear this stuff out.
BTW, anyone with this issue might want to set messages to admin approval. I see the spam bot us flooding my message system too.
the neat thing about my script is if you reboot the host, all the deny rules go away. So in the short term, it works out really well. when the storm clears up, you just reboot the host a few weeks later and your rule set is back to default.
Obviously the little dutch boy blocking IP's is not a solution and promoting it as one is not very helpful and is mostly cluttering up the thread.
If you would like, you could make it a csv or something people could import in to jamroom's blocked IP list.
I don't know why you would stick 4000 IP's in IPTABLES and think that you're doing something good? That is a ton of IPTABLES rules. On some systems you can cause it not to be able to restart, or to become so painfully slow... and obviously you shouldn't have to reboot a production server to turn off whatever you turn on.
If you dump it in jamroom's blocked IP's you negate that completely. No need for root or a script or whatever. Or also the option of dumping it in .htaccess is available
I WOULD suggest jamroom's blocked IP list.
Obviously the only real fix here, is fixing the software, anything else is little dutch boy security.
Wow..
Dutch boy.. Did you come up with that on your own?
So lets recap what happened here..
Some Spammers found a loop hole in JamRoom's account creation process.
The issue was reported to the JamRoom Dev team, and a few days later they came up with a "fix". While still not 100% bullet proof.
So we had 2 choices at the time.
1. Wait for Jamroom to fix the hole, while our Website was completely crushed with absolute garbage, our users move onto something else and we have to manually pick up the bits and peices days later.
OR.
2. Watch the logs, and just drop the ip address automatically before it becomes an issue with out having to wait for Jam Room, and carry on as normal.
Obvious answer is Obvious. Duh.
So while most of everyones website who posted in this forum was either filled with complete garbage, or stuck in maintence mode.. We remained online with no issues, and no spam.
Do I think 4000 IP Addresses in IPTables is the perfect fix?
NO. I said that a few pages back. Its called a Stop-Gap. People on this forum were screaming for help. I provided some help.
On top of that, dropping the IP also prevents those IPs from scanning our website for other potential loop holes.
What help did you provide? Suggest that jam room imports CSV files with IP address to ban? Really? So where were you planning on getting those IP addresses from? Activity log? How are you planning on remove known good ip addresses? Not only that.. you didn't help a damn thing, but make another JamRoom Feature Request.
I'm currently shoving almost 5000 chains into my tables at this time, and guess what.. No slow down, and top of the audio and video streaming i'm currently doing. I happen to have a server that can handle the load I throw at it. If your box falls over, then you just under spec'd your requirements. Plain and simple. Sysadmin/WebAdmin 101.
Not everyone has a true fire wall in front of their box. A reboot in the middle of the night during a slow time is no big deal and OK on my website once this attack stops.
Go back to thinking Dutch Boy Security.. Lets see how that works out for you. Its hack webadmins like you that refuse to think outside the box, drop down to a shell prompt, do a more on the access log and see whats really go on. If it aint in a pretty Web Gui Interface written in PHP.. You and your spam garbage filled websites are clearly screwed.
And for the record.. Importing a Ban IP list is already there.. I'll be sure to take the list of 5000 IP addresses I currently have and I'll just added them directly to the database from command line. Thanks for the suggestions chump.
Manually updated by user DB and set last update and last login fields to "right now". For me it was pretty simple, not many signups normally. I just looked for the first spam signup and updated all of the records less than the spam record to the new timestamp.
Went to the quota with over 8000 bogus signups and set prune days to 1 day. Ran the test and only got recent spam signups. Now click the run button and it removes 100 of them. Repeat until all of the garbage is gone.
BTW if you just setup prune on your quota and wait you are probably going to loose some real artists. It's all based on the last update and last login. Most of my people will only check in once a month or so and they would be deleted before the spam.
Like it never even happened.
_________________ JR 4.X + JR modules and addons ( I keep all of them current )
www.michiganmonster.com
Joined: 18 Dec 2003
Posts: 13497
Location: Behind You
Posted: 11/28/11 00:01
kdh:
djmerlyn:
kdh:
djmerlyn:
Sorry you're having a bad day!
im not the one with a server thats filled with spam and garbage..
how about you?
Doing great, couldn't be happier Happy holidays!
I see what you did there..
lol nobody came here attacking you. Just pointing out a fundamental flaw of trying to ban so many IP's, the suggested temporary solution could be improved. It would be great if it was an importable csv list to add to the jamroom block list (its quick to make one that you can import in phpmyadmin no ssh required). Not sure where what I said created a tangent. But it seems to be the way the day has gone. Sorry if that's how it came across.
Note that there is another thread here suggesting we have just that, you have the fastest start as of right now. I'll link the thread...
Guys chillout man, So you are getting nuked by a spam bot?
That happens to all of us someday, either on a forum either on a cms based system or in this case at jamroom.
Not much you can do about it and it does NOT help to flame brain and his team.
It would be nice if people stop B*tching and say thx for a change.
Anyway a quick fix till a serious update is made is to place a loading.php dummy redirect between your signup link and the actual signup form.
Somehow spammers cannot get past a simple redirect with a 3 seconds waiting time.
How to do it? very easy. Create a file called loading.php
add:
Code
$time = 3; //Time (in seconds) to wait.
$url = "http://yourdomain/signup (or what ever path you use to go to the signup for a artist or member account)"; //Location to send to.
header("Refresh: $time; url=$url");
and place it between your actuall singup button and the fill out form.
I have used this on forums, joombla, wordpress and also on jamroom and it keeps 95% of all spammers out.
Why i dunno, but you have to keep in mind spambots are just stupid programs who may be able to read captcha's BUT the moment the login routine changes (in this case by a delay redirect) the spam bot drops the connection.
Its simple tried and tested on very large forums and blogs so i got 99% reason to assume this will work on jamroom as well.
Or use the following trick:
Sooner or later your form may become a victim of people or programs that will try to send SPAM using your form. With proper form data validation they won't succeed in sending SPAM from your form to other people, but you can end up getting a bunch of random junk form submissions yourself.
» CAPTCHA
Usually when it comes to combating form SPAM you will find recommendations to use a visual CAPTCHA, that is a bitmapped image with random numbers and/or letters.
The fact is visual CAPTCHA has several accessibility issues and unless you have a high-volume website you should try using simple checks instead. Even W3C suggests using different approaches.
» The simple alternative
So, unless you own a large website you can try using a simple text confirmation code. As an example see our contact us page where the "Access code" is a simple text string like "MYCODE".
All this takes is an input field and a little bit of PHP code to check the entered code. Example code for the HTML form:
Then in the PHP script you can simply check if the entered code matches. Let's compare the code in lower-case to avoid problems with typing in CaSe SeNSiTiVe code:
Code
if (strtolower($_POST['code']) != 'mycode') {die('Wrong access code');}
Now the form will not be submitted unless the person enters the correct access code.
» But isn't this too easy and ineffective?
You can argue that this is too simple and spammers won't have any problems typing in the access code. But keep in mind two things:
Vast majority of SPAM is submitted using automated programs ("spambots"). Unless you have a high-traffic website with many users it is unlikely anyone will bother programming a spambot to read and post your specific access code just to send SPAM to one person.
If an actual person is submitting SPAM in your form it doesn't matter if you have a fancy Captcha as this person can read it no matter how fancy and secure it is. Luckily human submitted SPAM is very rare, these people are lazy and rather use programs to do their work on a large scale.
If your form is getting spammed I suggest you to try this method first instead of a visual Captcha, you will be surprised how effective something like this can be! KISS (Keep It Simple, Stupid!).
For those a bit more paranoid there are two more things you can do to make this even more effective:
Change your access code from time to time.
Place access code on some other page, not the one the form is on. For example instead of as suggested above
Please enter MYCODE above.
write something like:
You will find the Access code on our "about us" page.
Then place something like this on your "about us" (or some other) page of your website:
Access code for our contact form is MYCODE
This way you physically separate the access code from the form and it makes even less sense for anyone to create a spambot to target your website specifically.
This is indeed a very simple alternative to using visual Captchas, but do give it a try. You can always try other methods later if it doesn't work for you.
Cheers
PS you can actually get a list with banned ip's or known "bad" ip's and add them to ur .htacces file there are a few free scripts out there (Google it) who even will update the list from time to time so you can avoid 60% already.
In the end you cannot run away from spam its just the way it is, however you do not have to be einstein to take a few simple steps and avoid a whole drama.
im not the one with a server thats filled with spam and garbage..
how about you?
Doing great, couldn't be happier Happy holidays!
I see what you did there..
lol nobody came here attacking you. Just pointing out a fundamental flaw of trying to ban so many IP's, the suggested temporary solution could be improved. It would be great if it was an importable csv list to add to the jamroom block list (its quick to make one that you can import in phpmyadmin no ssh required). Not sure where what I said created a tangent. But it seems to be the way the day has gone. Sorry if that's how it came across.
Note that there is another thread here suggesting we have just that, you have the fastest start as of right now. I'll link the thread...
You came out the gate calling my quick solition dutch boy security. That is an attack.
What solution did you provide? Nothing, except request another JamRoom feature. I on the other hand provided something the community could use till JamRoom has another option.
If you don't agree with a known good working solution, don't be a chump and shoot it down because you don't agree with it. Provide a real working solution instead of waving your arms around like a keyboard commando and then demand more features. All it does is make you part of the problem.
Guys chillout man, So you are getting nuked by a spam bot?
No. We pretty much made it out the gate with almost no issues.
Quote:
That happens to all of us someday, either on a forum either on a cms based system or in this case at jamroom. Not much you can do about it and it does NOT help to flame brain and his team. It would be nice if people stop B*tching and say thx for a change.
If DJMerlyn is Brian, then his team needs to leash that guy in. Cause frankly thats not the kind of support I expect for something my team has sunk a fair amount of money and time into. That guy being a mouth peice for Jamroom is a bad idea. You don't insult one of your paying customers in a public forum. Its bad business.
If Brian isn't DJMerlyn, then big ups to the Jamroom Dev Team, and thanks for a product that does a good job for what we use it for and we will continue to spend money on it. We've alreay spent a few K in licenses, and we'll most likely spend more.
And big ups to DJVileroy for providing a real world known good working solution. This is great information, and something that should have been posted a few pages back.
I think there are tons of suggestions here. I think the solutions vary per what your comfort, access, JR management and skill level are....
We had to take our site offline for 6hrs total, that's it! I had to clean out like 50 rouge accounts, that's it!
We teamed up, as we always do, to provide a multi-pronged approach.. I provided Brian apache logs which eventually lead to the patched change set, I took the recapcha solutions here and while I was working those angles KDH was behind me providing another level of defense. This combination has worked for us, we have real users signing up and zero rouge accounts coming in with little system issues. So, there really isn't an argument its simply what worked/working for us. We are stable!
I do disagree, with the stance of importing the IPs to Jamroom. For one, it doesn't halt them from hammering apache looking for other holes, it just halts them from signing up. Since they are scanning profiles using the same IPs, apache takes the hit rather then iptables, having the same hijacked IPs lurking 10 profiles a second simultaneously isn't what we wanted even if they cant create an account, its bad traffic. Also, we don't know if its a botnet or a proxy so banning IPs completely in JR or in IPTables permanently isn't' the safest option. As mentioned, we are blocking them from Apache temporarily as a stop-gap and then once it halts I lean towards completely clearing the blacklist. KDH and I can disagree, makes for good systems discussion, then come to rational agreement between developers and sysadmins, that is how it supposed to work.
We are blessed to be armed with close to 30+yrs of bash, perl, php and linux systems. We took action fast, just like KDH or I would do for a production environment for the companies that we support. I work with a lot of custom beta software; waiting, hoping and praying for a response to a codebase is defiantly the solution long term but we needed to be reactive and proactive to keep our site online and users engaged. At the time we did what we could, since it works for us there isn't a debate, its simply our solution. If there is another that doesn't require mangling the JR codebase i'd like to know, i'll probably take that action as well. For now, the JR code base remains patched per JR suggestions but completely unaltered. I don't see a problem with that at all. As long as our site remains responsive and the server is monitored daily, its a nonissue and from a development perspective the safest/unaltered option that works for us.
Edit: also to note we have been using JR for MANY yrs. Our site has made it through JR v2, v3 and v4, we've unlocked nearly every feature, redesigned 3-4 custom templates, kept our license up to par, kept it secure and grown with JR the whole way. We LOVE using Jamroom we've actually wrote our own software around our JR community... Thanks Brian and JR community for all that your have done! No site is easy to manage, no codebase is perfect, it takes time, management and monitoring to be successful, secure and in our case have fun running a completely free online community in our spare time.
I also feel confident 4.6 will be a huge security update and is why its not released yet
Happy holidays!
and is why its not released yet