forum.excito.org

If there's any news please let meknow.

johannes wrote:Sorry, not at this stage. If the entire stock doesn't get sold soon it will move on to some auctioning firm who might be able to sell singles. I'll keep you posted on progress.

I suppose that was the case to keep down the administration and feel free to post the details.

I guess that this sale is no longer active due to the bankruptcy.

When you load the page http://www.excitostore.com/sv/store/excito-b3-med-wifi the price "SEK796 inkl. moms" but then, after about a second, the proce changes to "SEK995 inkl. moms"

Which is the correct info?

johannes wrote:With the recent events of intrusions in mind we should have been faster in letting updates through though.

Doyou need to have http available externally?
If so, do you need to have it available on the standard ports?
Is your B3 the gateway to the internet or do you have another router that can do port mapping that you connect the B3 WAN-port to?

Ubi wrote:In that case, the log files on the DNS server can tell us who that is =)

I have all the IP adresses of where the attacks originated from but it is likely that those are just random but machines already hacked and not the attacker's.

Another new security measure would of course be to limit "su" to a specific group in which no daemons are allowed.
That seems like a relevant default setting unless it would make it impossible for the web interface to update the installation. In such case I'd rather opt for a manual commandline ...

If this is really true, this does mount to the suggestion that the attacker knows he's on a B23. Has there been malicious content on that machine owned by root?
That's horrible!

My first B3 had a faulty motherborad failing to do gigabit speed networking and after getting it replaced I forgot to ...

Here's what I found

two hidden directories in /var/tmp with contents looking like phishing for bank details
removed!
/var/lock/ttoy being pretty empty except for hidden directories
removed!
/var/lib/apache2/fastcgi contains the following with the same timestamp as the /var/lock/ttoy above ...

Before doing the update I removed the crontab for www-data and did some manual cleaning of /tmp but what else is recommended to be cleaned?

Is it recommended and/or needed to change the shell of www-data and denying it to have a crontab as mentioned earlier in this thread or is that of no use?
I ...

My solution is to have this alias in /etc/aliases
root: /dev/null
Yes, but the whole point of these messages is to tell you something is wrong so that you can fix it. Hardly a solution therefore but more of a cover up.
It's a better solution that having almost 2 GB of useless chron-relaed mail ...

One picture says it all...

I've found suspicious activity on the following URLs returning else than HTTP 404

1) //%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C ...
2) //cgi-bin/php5?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63 ...
3) /cgi-bin/php/%63%67%69%6E/%70%68%70?%2D%64+%61%6C%75%6F%6E+%2D% ...
4) /cgi-bin/php?%2D ...

Performing the update via the web interface initially showed some progress but then stuck at "0%" for over 30 minutes so I refreshed the page and got the following:
Package name Package version
bubba 2.6.0.1
bubba-album 2.6
bubba-backend 2.6
bubba-frontend 2.6.0.1+security1
bubba3-kernel 1:2.6.39.4 ...