Printable View
There is a relational amplification affect here. As you increase the number of hosts on your network, the bigger the smoke screen for SSH data streams. We live in a mixed environment along which serves traffic to not only regular employees but also business partners, state and federal agencies, etc., etc.. As Tiger states, the ability to effectively trigger on pure SSH sessions will be extremely difficult and labor intensive if possible at all.
PS
Websense rulez. :)
There are dark forces hiding in SSH now. It's always been the universal by pass besides port 80. It seems the only resolve is stoping the infection. In fact one could go as far as blocking installation packages in windows along with executables. Only allowing baseline windows system process' access. Websense will block msi.
/EDITIt's religious. :DQuote:
Websense rulez
Sorry for the double post, just saw Tiger.
Websense comes with 800,000 sha-1 executable hashes. In fact you can even drill down. For instance say you use Norton. It won't just tell you it's Norton or Symantec it will list the executables assigned to each module like Antivirus or ghost. You can rn reports of what it finds before locking anything down. I let my surfcontrol license run out for a number of reasons. Reporting, BAD categorization etc. Websense will give you a competative upgrade.... :D
Horse,
Can you say whether this malware acts as an application in it's own write, or if it uses other applications, to establish a connection to C&C. What I mean is, is the malware a server/client or does it hijack a running process, like IE, Iserver.exe, etc.
The ones I have seen are individual processes independent of others, spawned by calling an exe planted usually in the Windows folder.
I am fishing, but you know thatQuote:
The ones I have seen are individual processes independent of others, spawned by calling an exe planted usually in the Windows folder.
Would not, any old common or garden software firewall catch the out going connection?
Yes, unless it travels over an encrypted connection such as SSL or SSH. Here is where the trouble lies.
And the commercial solutions do not allow for, block all ssh/ssl traffic, unless trusted. Because its' encrypted it becomes trusted.
Security certificate, seems to be the only solution. In what is an open system.
I see four solutions for this problem.
1. Host based firewalling which only allows trusted applications to open new sockets
2. Some sort of authentication whereby applications request permission to use encrypted connections. However since program ID fields are not part of standard IP headers, this would be difficult.
3. Rewriting the stack to include program ID information in all IP headers, then stripping this at the gateway.
4. A different approach to authentication whereby before allowing an encrypted connection out, the gateway contacts the host and requests information on the generating application independently of the stream in question. Although this would require host software, it would not be more involved than installing Netware login clients.
Would any of this work?
This is sort of what I meant by using security certificates.Quote:
4. A different approach to authentication whereby before allowing an encrypted connection out, the gateway contacts the host and requests information on the generating application independently of the stream in question. Although this would require host software, it would not be more involved than installing Netware login clients.
It's about time we should be able to ring fence windows system folder and prevent write access to all but trusted applications.