> -----Ursprüngliche Nachricht-----
Von: stakanov@freenet.de Gesendet: Di. 22.12.2015 17:29 An: opensuse , Betreff: [opensuse] Have I been hacked or visited? seccheck and rkhunter outputs
I get the following two separte messages by seccheck and rkhunter.
Rkhunter:
Warning: The file properties have changed: File: /usr/bin/rkhunter Current inode: 1458231 Stored inode: 1455628 Warning: The file '/usr/bin/ssh' exists on the system, but it is not present in the 'rkhunter.dat' file. Warning: The file '/usr/sbin/sshd' exists on the system, but it is not present in the 'rkhunter.dat' file. Warning: The file properties have changed: File: /etc/rkhunter.conf Current inode: 525324 Stored inode: 525329 Warning: The file '/etc/rkhunter.d/00-opensuse.conf' exists on the system, but it is not present in the 'rkhunter.dat' file. Warning: Hidden file found: /usr/bin/.fipscheck.hmac: ASCII text
Seccheck complains about:
Please note that these security checks are neither complete nor reliable. Any attacker with proper experience and root access to your system can deceive *any* security check!
Changes in your weekly security configuration of linux-ge2e:
Please check and perhaps disable the following unused accounts: Warning: user root has got a password and a valid shell but never logged in
Question: The latter could be because of sudo? Instead for ssh and sshd I do not have any explanation. It is deactivated on this system. Has there been an update that can cause this?
lastlog does not show anything special. Only local user did log in...at least following the log.
-----Ursprüngliche Nachricht Ende-----
Now, I found a lot of new fies of ssh authentication made the 14th december of this year. I never use ssh, I do not log in remotely to my notebook and up to now I had my peace of mind to disallow ssh root login and to change the port while having everything set to disabled. Now I have a question. Somebody who does not want to use "remote" at all. What can he do to un-install every remote package. The problem is that if you un-install openssh a lot of applications of kde seemed to complain. So I tried and un-installed it. But nothing happened. Why do I have all these dependencies for features that I do not use. Wouldn't it be better to put those in a pattern to install if needed instead of putting them into kde-base? What problem do I actually have if I do not have opensssh installed at all? To me it seems none. Even tor does not seem to rely on it. So why on normal desktop systems is there ssh, if by default it is de-activated. Wouldn't an active selection with usable defaults as option not be the better choice. Thanks for educating me.
P.S. Merry Christmas to everybody and for who has the itch of "politically correctness" and feels bothered by it (somebody could be pastafari, or whatever else, I know, so: seasonal greetings to them.
--- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! http://email.freenet.de/basic/Informationen
* stakanov@freenet.de stakanov@freenet.de [12-24-15 07:18]: [...]
Somebody who does not want to use "remote" at all. What can he do to un-install every remote package. The problem is that if you un-install openssh a lot of applications of kde seemed to complain.
[...]
So don't "uninstall", just don't open the firewall ports.
No open ports, no external access. Now only physical access is a problem.
On Thu, Dec 24, 2015 at 8:56 AM, Patrick Shanahan paka@opensuse.org wrote:
- stakanov@freenet.de stakanov@freenet.de [12-24-15 07:18]:
[...]
Somebody who does not want to use "remote" at all. What can he do to un-install every remote package. The problem is that if you un-install openssh a lot of applications of kde seemed to complain.
[...]
So don't "uninstall", just don't open the firewall ports.
No open ports, no external access. Now only physical access is a problem.
For completeness:
A modern malware attack often uses a reverse tunnel.
ie. malware gets on the machine via a phishing attack or an infected website.
Once on your machine it establishes outbound connections to a command and control site that tells it what to do.
No inbound connections are needed so a traditional firewall blocking incoming posts has no effect.
I would guess the majority of infections today happily ignore inbound firewalls.
Greg
* Greg Freemyer greg.freemyer@gmail.com [12-24-15 13:48]:
On Thu, Dec 24, 2015 at 8:56 AM, Patrick Shanahan paka@opensuse.org wrote:
- stakanov@freenet.de stakanov@freenet.de [12-24-15 07:18]:
[...]
Somebody who does not want to use "remote" at all. What can he do to un-install every remote package. The problem is that if you un-install openssh a lot of applications of kde seemed to complain.
[...]
So don't "uninstall", just don't open the firewall ports.
No open ports, no external access. Now only physical access is a problem.
For completeness:
A modern malware attack often uses a reverse tunnel.
ie. malware gets on the machine via a phishing attack or an infected website.
Once on your machine it establishes outbound connections to a command and control site that tells it what to do.
No inbound connections are needed so a traditional firewall blocking incoming posts has no effect.
I would guess the majority of infections today happily ignore inbound firewalls.
iow, the *only* _safe_ computer is one in an inaccessable location without any means of power.
On December 24, 2015 10:45:36 AM PST, Greg Freemyer greg.freemyer@gmail.com wrote:
On Thu, Dec 24, 2015 at 8:56 AM, Patrick Shanahan paka@opensuse.org wrote:
- stakanov@freenet.de stakanov@freenet.de [12-24-15 07:18]:
[...]
Somebody who does not want to use "remote" at all. What can he do to un-install every remote package. The problem is that if you
un-install
openssh a lot of applications of kde seemed to complain.
[...]
So don't "uninstall", just don't open the firewall ports.
No open ports, no external access. Now only physical access is a
problem.
For completeness:
A modern malware attack often uses a reverse tunnel.
ie. malware gets on the machine via a phishing attack or an infected website.
Once on your machine it establishes outbound connections to a command and control site that tells it what to do.
No inbound connections are needed so a traditional firewall blocking incoming posts has no effect.
I would guess the majority of infections today happily ignore inbound firewalls.
Greg
If they are very sophisticated they csn hide outbound ports from some tools, probably not all.
Using netstat you can look at all the outbound connections, and explain every one of those to yourself.
Fairly easy to do on your own workstation, but quite a task on your gateway.
On 12/24/2015 11:08 AM, John Andersen wrote:
If they are very sophisticated they csn hide outbound ports from some tools, probably not all.
Using netstat you can look at all the outbound connections, and explain every one of those to yourself.
Fairly easy to do on your own workstation, but quite a task on your gateway.
Be sure to check all your diagnostic tools too, like netstat, they could have been altered to hide evil traffic. Check them against distribution media using sha256sum.
Regards, Lew
On Thu, Dec 24, 2015 at 2:08 PM, John Andersen jsamyth@gmail.com wrote:
On December 24, 2015 10:45:36 AM PST, Greg Freemyer greg.freemyer@gmail.com wrote:
On Thu, Dec 24, 2015 at 8:56 AM, Patrick Shanahan paka@opensuse.org wrote:
- stakanov@freenet.de stakanov@freenet.de [12-24-15 07:18]:
[...]
Somebody who does not want to use "remote" at all. What can he do to un-install every remote package. The problem is that if you
un-install
openssh a lot of applications of kde seemed to complain.
[...]
So don't "uninstall", just don't open the firewall ports.
No open ports, no external access. Now only physical access is a
problem.
For completeness:
A modern malware attack often uses a reverse tunnel.
ie. malware gets on the machine via a phishing attack or an infected website.
Once on your machine it establishes outbound connections to a command and control site that tells it what to do.
No inbound connections are needed so a traditional firewall blocking incoming posts has no effect.
I would guess the majority of infections today happily ignore inbound firewalls.
Greg
If they are very sophisticated they csn hide outbound ports from some tools, probably not all.
Using netstat you can look at all the outbound connections, and explain every one of those to yourself.
Fairly easy to do on your own workstation, but quite a task on your gateway.
They often use a polling strategy of one poll a day or less and also use standard ports at the far end.
It is difficult to detect manually and certainly not by just the occasional audit of current open sockets.
This is one reason companies are moving to using white lists of allowed outbound connections. The hope is the command and control sites won't be on the white list.
Websense is a major player in that market. And a lot of my customers use it or similar.
Greg
On 12/24/2015 11:44 AM, Greg Freemyer wrote:
This is one reason companies are moving to using white lists of allowed outbound connections. The hope is the command and control sites won't be on the white list.
Websense is a major player in that market. And a lot of my customers use it or similar.
Yes, but that only works on dedicated purpose machines with large budgets, and an IT department that deliver employee smack-downs.
Anything upon which the user is apt to run a web browser can't be filtered in such a way without resorting to a very tightly controlled proxy server (which simply moves the problem somewhere further away and harder to manage).
I egress filter email ports, and a few similar things at the firewall, but when your users are talking to big-mailers (google, yahoo, microsoft) it becomes almost impossible to keep a list of valid destinations up to date. Connection addresses end up being pools any you never know what IP the next connection is going to.
Egress filtering is hard, which is exactly why malware almost always attempts to use outbound connections, and very often uses standard destination ports (like 80) and often uses standard protocols.
On Thu, Dec 24, 2015 at 3:11 PM, John Andersen jsamyth@gmail.com wrote:
I egress filter email ports, and a few similar things at the firewall, but when your users are talking to big-mailers (google, yahoo, microsoft) it becomes almost impossible to keep a list of valid destinations up to date. Connection addresses end up being pools any you never know what IP the next connection is going to.
Lots of places simply don't let "workstations" make outbound connections to random SMTP servers.
Verizon for one doesn't allow port 25 traffic in either direction for home users.
I don't know if most companies allow random outbound POP/IMAP connections.
I can imagine that a lot of companies block those too. Users are forced to use the corporate email server.
Greg -- Greg Freemyer www.IntelligentAvatar.net
On 12/24/2015 12:28 PM, Greg Freemyer wrote:
On Thu, Dec 24, 2015 at 3:11 PM, John Andersen jsamyth@gmail.com wrote:
I egress filter email ports, and a few similar things at the firewall, but when your users are talking to big-mailers (google, yahoo, microsoft) it becomes almost impossible to keep a list of valid destinations up to date. Connection addresses end up being pools any you never know what IP the next connection is going to.
Lots of places simply don't let "workstations" make outbound connections to random SMTP servers.
Verizon for one doesn't allow port 25 traffic in either direction for home users.
I don't know if most companies allow random outbound POP/IMAP connections.
I can imagine that a lot of companies block those too. Users are forced to use the corporate email server.
Greg
Greg Freemyer www.IntelligentAvatar.net
Agreed, those port 25 egress attempts are easy to block. But with Google using and others requiring (or strongly encouraging) secure connections (smtp = 465, pop3S = 995 ImapS = 993) you have other things to block, which are much harder).
For those users that use Gmail/Yahoo/Hotmail, I'd rather have them using a MUA than using a browser, as I think its a bit more secure. But maybe that's just me.
On Thu, Dec 24, 2015 at 3:42 PM, John Andersen jsamyth@gmail.com wrote:
For those users that use Gmail/Yahoo/Hotmail, I'd rather have them using a MUA than using a browser, as I think its a bit more secure. But maybe that's just me.
I've seen those blocked for HTTP/HTTPS too.
As security is ratcheted up, more and more sites are blocked.
I've seen companies where the desktops/laptops are in a DMZ that lets them get to a fairly unrestricted web, but not much of the company assets. To get to the company assets they have to log into a terminal server (via remote desktop). From there they can get to the company assets, but have tight restrictions about where on the web they can go.
Lots of inventive solutions out there.
Greg
-- Greg Freemyer www.IntelligentAvatar.net
On 12/24/2015 02:11 PM, John Andersen wrote:
Yes, but that only works on dedicated purpose machines with large budgets, and an IT department that deliver employee smack-downs.
Anything upon which the user is apt to run a web browser can't be filtered in such a way without resorting to a very tightly controlled proxy server (which simply moves the problem somewhere further away and harder to manage).
I egress filter email ports, and a few similar things at the firewall, but when your users are talking to big-mailers (google, yahoo, microsoft) it becomes almost impossible to keep a list of valid destinations up to date. Connection addresses end up being pools any you never know what IP the next connection is going to.
Egress filtering is hard, which is exactly why malware almost always attempts to use outbound connections, and very often uses standard destination ports (like 80) and often uses standard protocols.
With the level of sophistication of the current malware, it really boils down to the old tried and true rules to keep you safe.
With e-mail:
- only open attachments when that:
(1) are from a known sender, and (more importantly); (2) you are *expecting* to receive.
- if there are *any* questions about (1) or (2) above:
(3) confer with the sender (before opening); or (4) *do not* open the attachment.
With web-sites:
- only visit reputable sites (that may mean not using some at all), - disable flash (in favor of html5, etc.), - disable javascript (FF noscript, etc.), - block cookies from 3rd party sites (legitimate sites still work), - know what you are clicking on (to the extent possible - slow down), and - if it looks suspicious, it probably is (close window using WM [X] button)
There are many more good rules of thumb, but this minimum set will prevent you from being your own worst enemy.
It's a shame the world if full of so damn many dishonest and dishonorable people.
On 12/24/2015 12:37 PM, David C. Rankin wrote:
disable javascript (FF noscript, etc.),
The problem here is that an exceeding large percentage of websites refuse to run at all without javscript these days.
On 12/24/2015 02:44 PM, John Andersen wrote:
disable javascript (FF noscript, etc.),
The problem here is that an exceeding large percentage of websites refuse to run at all without javscript these days.
Yes,
But then you are alerted and presenting with a nice list of sites that *you choose* to enable or not.
I can't tell you the number of times a site complains about needing javascript, or images are not autoshown, and you are faced with a list of 15 sites wanting you to enable JS. When in reality there are only 1 or 2 actually required for full functionality with the remainder attempting to run who knows what (ads mainly).
The point is with something like 'noscript' *you* control what runs as opposed to what some 3rd party thinks you should run. Don't get me wrong, I'm not claiming that it is some type of "silver-bullet", but it is just one more defensive measure you can take in the climate we find ourselves in.
I have never been more disappointed in humanity's uncanny knack for destroying or just flat "bleeping up" a beneficial resource to the point it is basically untrustworthy for both business and consumer use.
Linux enjoyed a pass for a long time, but now these type of threats are an equal-opportunity annoyance regardless of OS.
-
David C. Rankin -
Greg Freemyer -
John Andersen -
Lew Wolfgang -
Patrick Shanahan -
stakanov＠freenet.de