Forum OpenACS Development: OT: Security Alert

1: OT: Security Alert

Posted by Jon Griffin on 12/04/01 04:53 PM

I seem to be getting a renewed interest in ports 111 and 79 on all the boxes I admin. Because I have about 10 boxes I tend to see patterns.

I would like to stress to everyone to take care and block finger (port 79), and really most everything.

I would also suggest running nmap on your boxes to see what is open.

2: Response to OT: Security Alert (response to 1)

Posted by Jon Griffin on 12/13/01 07:39 PM

OpenSSH is rumored to have a new exploit in versions prior to 3.0.2. The specific one is 2.9.2 or p2 for non-openbsd people.

There are known (although low risk) exploits in versions 3.0.1 and earlier. Also, SSHD 2.4.0 is believed vulnerable also.

I have been noticing a bunch of scans to 22 that have strange packets (SYN and etc) and it appears to be related to a program that a cracker group named TESO created.

I am going to download the crack code now to look at it and do some testing. Others are also looking at it.

For those who challenged me to break into their boxen or stop bashing distros, first I am not a cracker and don't really have time to play those games and second your valued, prized team that also makes openSSH (and installs it on your distro) is not infallible. Don't make challenges until you know the facts.

Bottom line, do what you want, but if you depend on someone else or a (worse yet) a distro to be secure, be ready to be compromised.

3: Response to OT: Security Alert (response to 1)

Posted by Tom Jackson on 12/13/01 10:45 PM

Jon,

Thanks for your advice on using portsentry and logcheck! I installed that the the last time I got worried about ssh. Now I have moved ssh to a higher port, but probably it is time to replace it with a version that is invulnerable (at least for now).

One question on portsentry for those who might only want to rely on moving the port number around. I have configured portsentry to install a new ipchain to blackhole an attacker. This was supposed to be better than creating a route to a dead host, or a reject route. However, this method still allows the attacker to probe open ports, or so it seems, as I tried to connect twice to a closed port which activated the tripwire, but I was still able to connect to a webserver. If this is true, it seems that this option has much effect on an attacker looking for vulnerabilities.

4: Response to OT: Security Alert (response to 1)

Posted by Jon Griffin on 12/14/01 12:24 AM

I am not sure I understand your question.

Are you saying that once portsentry blocks a site it can still connect to other services? I haven't seen this behavior.

5: Response to OT: Security Alert (response to 1)

Posted by Jon Griffin on 12/14/01 12:25 AM

BTW,
This just came in to me: CERT Advisory CA-2001-35 Recent Activity Against Secure Shell Daemons

So I am not the only one seeing this.

6: Response to OT: Security Alert (response to 1)

Posted by Tom Jackson on 12/14/01 01:25 AM

A month or so ago, a company that I am working with noted the existence of an actual working attack. Several weeks ago we moved the ssh port.

In response to my previous post, I configured portsentry to start with the -atcp option. This option starts up and dynamically determines which address:ports are listening, and does not monitor them.

Then I attempt to telnet from another machine to for instance, port 38. The message log looks like this:

Dec 13 15:00:36 multi portsentry[23886]: attackalert: TCP SYN/Normal scan from host:
tjackson-3.dsl.speakeasy.net/216.254.26.189 to TCP port: 38
Dec 13 15:00:36 multi portsentry[23886]: attackalert: Ignoring TCP response per
configuration file setting.

The portsentry.conf file is set to run a command when the tripwire is activated, and I have tried both of these separately, recompiling and restarting each time:

# ipchain support for Linux
KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l"

or

# Newer versions of Linux support the reject flag now. This
# is cleaner than the above option.
KILL_ROUTE="/sbin/route add -host $TARGET$ reject"

Once the trap has been set, I can still connect to port 80, which leads me to believe that the command is not being run. I would think I should be able to see a route show up in the second case. The host name is multi.zmbh.com, in case you want to give it a try.

Also, I just tried running the route command above and it works. I wonder what I am doing wrong?