While you're checking around, grep sshd /var/log/messages and have a good hard look at it (nothing to do with mail, but a lot to do with system security).

Something you can do to get the script kiddies out of your system is (1) do not allow root login in sshd.conf
Uncomment PermitRootLogin and change yes to no.

If you're seeing tons of break-in attempts, consider installing DenyHosts or fail2ban. DenyHosts takes less fiddling around to get going and it automagically adds the IP address of offenders to /etc/hosts.deny; it also shares the experiences of other users around the world by adding offender addresses to your /etc/hosts.deny periodically; I like that.

Fail2ban is a little more fiddling but it will not only do what DenyHosts does, it will also eliminate offenders found in your HTTPD access_log and error_log -- it can use /etc/hosts.deny for many things or it will use IPTABLES. Either of those will bar any access to your systems. What goes in /etc/hosts.deny is "permanent;" IPTABLES can be transient, up to you.

DenyHosts is found at http://denyhosts.sourceforge.net and fail2ban at http://www.fail2ban.org/wiki/index.php/Main_Page.

In keeping with many recommendations, use passwords that are a least 8 characters, contain at least one numeric character, at least one puncuation character and zero dictionary "words." Don't use numeric sequences; e.g., 1234. Use upper case characters mixed with lower case.

Go get John the Ripper (http://www.openwall.com/john/) and run your passwords against it -- mine run for 24 hours without getting cracked (then I quit just because no attacker would ever have that much time to crack a password).

Web mail? Well, I use gmail for LinuxQuestions simply because AT&T seems to think LQ is a spammer (dammit, can't convince them otherwise). I don't even get spam on the thing (yet!) and I did try using the AT&T SMTP server with it (too much screwing around with both mail addresses) so I just pretty much leave it alone and it seems to work all right. On the AT&T side of the world, I use Thunderbird after I've already looked at the web mail page to see what's what -- they do block a whole lot of spam from ever getting to Thunderbird and I kind of like that.

I've had the same e-mail address for over 10 years, never had a problem with the criminal element (although I thing it's kind of fun when I've sent myself ads for Viagra...).

1 members found this post helpful.

I am pretty sure I haven't been phished twice in two weeks, and I cant imagine why anyone would make two attempts at brute forcing my gmail, I don't keep anything terribly useful in there.

I ran the command 'grep sshd /var/log/messages' about 5 minutes after boot and received the following:
I don't really know what to make of this but it appears a client has connected on port 22?

That's normal at start up; it usually takes a while (if you're connected to the network either directly or through a router) for you to get found (even up to a day or so in my experience) -- basically, they ping looking for responses then launch into trying to get in with ssh, that's when the failed password messages start showing up.

Have to wonder, though: darkstar is the default system name for a Slackware box. Did you set up your network with netconfig? Might want to think about doing that a picking another name and domain... or, maybe not -- if it ain't broke, don't fix it, eh?

My point was that if his local machine was compromised, it was not via software running natively, but rather a browser based attack.

This is my field. I am familiar with the attack vectors and mechanisms used, and his browser will have been the catylist for any attack.

I would safely guarnetee that there is no malicious software running locally and that chrootkit etc will not find anything. Of course it's a good idea to run it anyway, but its better to focus on the actual vulnerability rather than checking something unrelated.

Actually, these days a Linux user is often just as vulnerable as a Windows user (saying M$ really is quite childish). You won't like hearing that, and many will deny it, but its the truth.

Why?

Because as I said previously, the browser is the target these days. The local OS is often irrelivant, especially when an exploit targets the browser regardless of the OS it is running on.

Well, technically phished would come under "sniffed somehow"

D1ver: which browser version are you using, and are all your security patches up to date?

Do you have any of the Adobe products installed, flash or reader?

I never ran netconfig after installing as everything seems to be working. I'm reasonably new to Linux and Slackware in particular so I'll have to read up on netconfig.

I'm using Seamonkey and Firefox, both with adblock and noscript. They're up to date with 13.0 -stable. The in browser flash plugin is installed.

I've changed all my passwords and am going to try to migrate away from Gmail. I hope this doesn't happen again

Hi,

My suggestions if read without bias or feeling is to look at the system holistically not just from a browser standpoint. Things do happen with a GNU/Linux system less than a M$ but still can occur if good practices are not followed. If for a browser session or for a system in general anything can be broken into if proper safeguards have not been followed.

If you feel the use of the token M$ is childish then so be it. I just use M$ as my lazy icon for Microsoft and if you don't like it: 'Then so be it'.

You seem to look at the browser as the only weak point. I look at giving the person the available potential entry or violations. Sometimes when you look through a tunnel you only see the confined view not the panoramic view.

I'm not challenging you but you seem to take offense to my suggestions that there are the possibilities of violations other than the browser. Sure the most often can be shown to be the session when speaking of a desktop application but the OP & others should be aware of the other potential problems. Heck, a recent security risk pertaining to the font issues opened up a potential security risk with FF that could have introduced a system issue therefore security risk to the base via FF by a knowledgeable user. Now if someone doesn't upgrade the FF browser then a potential security risk will create issues within the OS itself. I think it was mozilla-firefox-3.6.3 that corrected the potential security risk that most people generally would not have addressed. This had nothing to do with a current browsing session but with content for a session.

I never indicated 'chkroot' would do such but that would be the means to insure a safe environment. A user that is concerned with a secure system must use all available tools to gain that environment. Be it for security tools within a application or good user habits, one must continue to attain the secure system with every possible means. Therefore don't bias someone with just one concept but to suggest the means to attain the secure system.

So my suggestion is to keep oneself secure holistically by general senses and following good proven methodology.

I don't know how often you check your system(s) attacks nor who's been knocking on the door. But it does happen all the time. If you want to stick your head in the sand and say it's not a problem 'then so be it'.

Hi,

Actually your FF is not up to date for Slackware 13.0. would be to upgrade to 'xap/mozilla-firefox-3.6.3' from -current.

I suggest that you look at the Slackware 'Security Advisories' and be sure to sign up.

Just a few more useful links;

Slackware® Essentials
Slackware® Basics
Linux Documentation Project
Rute Tutorial & Exposition
Linux Command Guide
Bash Reference Manual
Advanced Bash-Scripting Guide
Linux Newbie Admin Guide
LinuxSelfHelp
Getting Started with Linux

The above links and others can be found at 'Slackware-Links' . More than just Slackware® links!

Hmm thanks again onebuck. Subscribed to the mailing lists and will use Seamonkey exclusively until 13.1 is released

Hi,

You could get the FF 'mozilla-firefox-3.6.3-i686-1.txz' package from '-current' without to much work.

Hi.

I get what you are saying, I just think it is irrelevant.

Yes, it is always good to follow good security practices and have a secure system.

In this particular instance however, the generic advice you give isn't relevant.

Suggesting to run chrootkit or modify hosts.deny or whatever is like suggesting an oil change for a flat tire.

The browser or browser plugins are the weak point in the situation described by d1ver.

I'm not looking at this from a narrow point of view, I'm looking at it from an experienced point of view.

The difference between suggesting you do full maintenance because you are unsure what the actual problem is, and knowing what the actual problem is.


Oh, I don't take offence at all, but I do disagree with you.

Looking for rootkits simply doesn't make sense for the scenario d1ver described. It won't hurt and helps to be sure, but it is very unlikely to be the cause.


I agree, but I was trying to solve d1vers specific problem rather than give generic good practices for staying secure.


Say what?

It is rare that browser vulnerabilities allow local file placing and execution.

Thus, it is rare that a browser vulnerability will creat an issue with the OS itself.

This is part of why I consider it is unlikely the problem is malicious software running locally.

Well, I would again use my example of suggesting an oil change for a flat tire.

General maintenance and good practices are good, but it is better to fix the specific problem when someone brings that to attention.

Sure.

As I said, it's my job, and it's my field...so yes, I know quite a bit about this.

Anyway, I don't disagree with your general point that good security pracices should be followed. I just disagree with your approach to d1vers problem.

If you reply it may be a while before I do, I'm off to costa rica early tommorow morning

Hi,

I hope you have a good trip!

As for the FF vulnerability that I mentioned, you really should look at that security risk.

As I stated previously the methods presented are good prevention and a good means to secure one's system.

Nice. In forensics no facts can be presented without evidence. In security fixing security problems starts with determining the cause. Since you are so sure I'm left wondering what tools and commands you use to determine if this was 1) bruteforced, (let's skip sniffing), 3) obtained via software or a browser-centric attack? Please target the OPs machine as investigative target if you will and please be as detailed as possible.

Hi. Sorry for the delay in my reply.

My reply will not be as in depth as it normally would be, because I recently damaged my laptop and am in costa rica, and the computers are kind of a pain to use. If you are interested though I can give you links after I get my laptop fixed.

Now, you are right, fixing problems starts with determining the cause, as with anything.

I have not checked d1vers system, and the reason I am sure the cause is limited to the browser is because I am familiar with how these attacks tend to operate. I will expand on that later.

If I wanted to be sure there was no malicious software running on the machine, I would do the following things:

1. Boot with a live cd and run chrootkit and similar software. There is little point in running it from the system you suspect to be compromised.
2. From the system you suspect to be compromised, carefully check what processes are running and what network connections are outgoing. You can use tools like lsof, ntop and netstat. I would also use tcpdump to examine outgoing traffic, and setup a firewall rule with verbose logging.
3. You would also have to check for application specific bugs or exploits. If this were a targetted attack rather than an automated attack, then someone may have gotten local access to the machine or something and changed a configuration setting or enabled remote access or such, that would not necessarily show as malicious.

The above would be a starting point, to start determining the problem. Of course, the above would not show most browser based attacks, as they do not rely on installing locally running software to the machine.


Now, why am I sure the browser is most likely the catylist for the attack? For the last few years, attacks have moved away from targetting specific OS vulnerabilities or relying on user stupidity.

This is partly because OS's have gotten more secure, by implementing things like executable space protection and basic MAC, and also by enforcing better security practices such as strongly discouraging using the administrator/root account for everyday use.

Indeed, the malware "industry" has moved towards a profit model as opposed to the infamy model it was closer to in the 90's and early 2000's. These days, it is more of a goal to silently install software, typically a botnet client, which will not hamper performance or disrupt the user, but will allow the users idle cpu time and network resources to be harnessed.

Given the horrible horrible insecurity of adobe reader and flash (which are responsible for the majority of web exploits these days) the browser is an attractive target.

What I just described is more to do with how malware is installed via browsers these days, which I still don't believe to be d1vers problem.

Looking at the symptoms, only his password for a single account was compromised. There was no other strange behaviour, and no reason to suspect a rootkit had been installed (also because a rootkit is quite a bit more precise, and generally not considered malware of the type that would steal a password). Given that the majority of exploits are adobe product based, or directly browser related (XSS, phishing etc), as well as Linux not being a target for an automated attack(a targetted attack sure, but not an automated attack), then I am reasonably sure that his browser was the catylist.

Given that it is entirely possible to craft an email or an banner ad that can result in his gmail session being stolen, and that there is a miniscule amount of automated malware that targets linux, it clearly makes more sense that the browser was the catylist. It is the significantly simpler andliklier explanation.

If his browser, adobe products and such were all up to date, and there were no funky addons installed, and since there is no talk of any exploits affecting firefox 3.6.3 in the wild since its release, the only other explanation in my mind becomes something the user did. perhaps logging in to his acocunt on an untrustworthy computer at school or an internet cafe, perhaps using a chat client to use gtalk that gave away his info, etc, pissed off girlfriend etc...any number of possibilities really.

What i would actually suggest if d1ver is still reading this is to contact google directly. Out of all the webmail providers they have the best customer support and will actually get back to you regarding this, and may be able to tell you if your account was accessed from somewhere strange.

Sorry for grammar/spelling....costa rican keyboard....

Hi,

I was re-reading the thread for clarity and found this statement. Slackware 13.0 SeaMonkey has the same security risks. Update from '-current' for SeaMonkey or FF. Or just get Slackware 13.1 stable.