[LINK] Re: Security Micro-HowTo vs. Adam's generalised Red Hat
Sun, 13 Feb 2000 22:18:35 +1000
Love the subject! :)
>> ARGH! Red Hat strikes again. I keep telling people it's a wide open
>> hole with so much vunerability ... but they don't seem to undersdtand.
>> . . .
>> My response - "When are you going up upgrade to a more secure version
>> of Linux."
>The trick is, with any computer which is exposed to the Net, to keep
>up-to-date with security enhancements to the server and daemon programs.
Robin, as I said, feel free to send me a letter of authority to breach your
security. No matter how up to date you are, I can get inside a Red Hat
server any time I wish.
>Some updates are to deal with weaknesses which expose the system to
>external attacks and others are to deal with threats from users who have
>accounts on the machine. Some of the problems may be denial of service
>attacks, but usually the attacker's aim is to gain control of the
>machine with root privileges, which enables them to do whatever they
Foirget denial of service attacks. They are a totally differnent problem.
I'm refering to the ability to get root privs on a Red Hat server any time
I wish, no matter how much security, logging and firewalling you put in place.
I only know a few people who know what I know and I tell no one for the
explicit reason that it's far to easy to crack. Testing on Slackware and
Debian didn't show the same simple exploit.
I do know there are others around who know and use the exploit frequently
and I can't patch it.
>passwords, were completely exposed to NetBIOS packets from anywhere in
>the world. Within a week, they were hacked, by a Melbourne attacker who
>also hit hundreds of other machines.
Remember the incident well :)
>I should have been smarter:
>1 - Keep up with security updates.
But what about the consideration that he coder deliberatley writes a
backdoor into the code?
Or perhaps the code itself creates a backdoor that is not easily noticed or
>That's all I really needed to do. However, there is a small chance that
>an attacker could exploit a vulnerability before the Red Hat site had
>listed an update, or before I installed it.
What's your IP address? My Fax number is 02 9729 0899.
>all updated packages and alerting you to every update ASAP. There is a
>Red Hat security advisory mailing list too, which I am on.
But it only reveals those exploits that are found by people who report
them. There are exploits on many O/S's that are unreported simply because
there is no easy way to fix them at the present O/S code level.
It's hoped that major version updates will fix such things, but not always
the case. I've got a LOT of experience in this area.
>Also, there are programs which can be run to watch all activity and
>report suspicious activity - to detect attacks and in particular the
>"root-kit" sort of complete loss of security.
You won't detect this entrace attempt.
>Firewalls may play a role, but the vulnerabilities are usually in those
>programs which need to be exposed to the Net anyway.
Firewalls will do nothing for this exploit.
>Of course you should disable all servers, daemons and UDP and TCP ports
>which you don't actually need.
ALWAYS! Best advice! Ensure that lpd isn't running. It's a huge hole!
>Finally, you should be more pay more attention to suspicious events.
But only if they can be seen. The exploit I'm aware of (as are several
others) can't even be seen using tcpdump!
>a small file was deleted. You can't be sure that an attack would leave
>such evidence, but it pays to be paranoid when the normally rock-solid
But a quick disk editor view of the file system will show you what is and
is not there. I recently had someone become very concerned that I was able
to view their disk histroy and then they admitted they in fact had been
DoS'ing another site.
I was not impressed.
>All of the above applies to maintaining any computer which is connected
>to the Net. It has nothing to do with Red Hat, Linux, Unix, Windows or
>the nature of the operating system.
Certainly the rules you suggest are true, but they don't stop exploits.
>Normally, with a dialup ISP account, a Windows box is not threatened by
>NetBIOS packets, because the ISP filters those out with their routers.
They do? Gosh the number of ISPs in Australia (about 87%) that do NOT
filter ports 135-139 is shocking.
>This may not be the case in some HFC cable Internet services.
I don't believe it is.
>I use Red Hat out of convenience, to be in the same boat as as many
>Linux users as I can. So far, I haven't found a need to use another
>distribution of Linux, but some people do.
Every operating system has it's purpose. Even Windows :)
>Most of the security issues are common to all Linux and most Unix
>systems, since the server / daemon code is derived from a common source.
But the kernal code often is not :)
I've heard of an exploit in FreeBSD, but never been able to simulate or
exploit a FreeBSD server. Mind you - for the same reasons I don't explain
the Red Hat exploit, no one who seems to know the BSD one will explain it
to me :)
>I guess that by sticking with a big, very active, well resourced Linux
>company, that their updates would be timely and appropriate.
Sometimes it's better to stick with one that seems to release slightly back
dated code! I honestly do prefer slackware and haven't yet had a sucessful
hack attempt. SPAMING was the worst thing to happen to me.
I use to have open port 139's on a couple of servers for anyone to use, but
that ihas since been closed. Actually we now filter just about everything
at the border router, the the Firewall, then through address translatin to
the servers themselves, then another firewall.
I can recall happily shoving a windows box on the Internet with a live IP
address and no passwords once. Gosh I even remember having unix servers
with no root passwords!
So far gone are those days.
>Nonetheless, others with more experience could argue that one
>distribution of Linux or Unix is better supported, or perhaps inherently
>more secure, than another.
Yes and no. On the same token, one flavour of Unix is going to do a job of
one type better than another.
>NetBSD, for instance, is well suited to
>running servers, in terms of performance and perhaps security.
Depends on the server resources!
>I am sure that Adam's generalised attack on Red Hat is not valid as a
>criticism of Red Hat's software or support. It may however be valid to
No, I didn't critise the software support :) Just the kernel and it's
potential exploit. Problem is who to tell to have it fixed knowing it will
be fixed. My research shows it's not something that will be fixed easy and
to be honest might see Red Hat frozen for quite some time. It's not easy
to exploit unless you know what you are doing and exactly the sequent to
carry out. I've also found on occasions that it can appear time sensitive,
although it might just be caused by lost packets through busy routers.
>as an observation, because:
>1 - There are more Red Hat systems than others (I guess).
And more Red Hat systems exploited and being used by hackers. I'm yet to
find or hear of a Slackware server being exploited since 2.0.39.
>2 - They may be installed by people with less experience and
> understanding of security issues. (Arguably the distribution
Sadly the simple epxloits fall into this category.
> and its documentation could alter this - a Net-connected
> system could by default put on a song-and-dance the moment any
> part of it was subject to a security advisory.)
I tend to agree it's time default meant EVERYTHING blocked.
>3 - Those inexperienced users may think: "Well, I am using the same
> software as everyone else, and their houses are not burning down,
> so I am safe."
>> If anyone has a Red Hat box they think is REALLY REALLY secure, let me
>> know and send me a "Letter of Authority to check security on [INSERT
>> IP ADDRESS" and I'll let you know what your problems are.
>184.108.40.206 This is my home/office name/HTTP/mail/FTP server and
>router to my LAN. Its connected via a 56K modem and I don't want this
>flooded. Nor do I want to spend too much on the incoming traffic at
>$0.19 per megabyte.
I don't need to flood it! Actually I only need to send about 80 - 100
packets :) Keep your eyes open!
>None of the above relates to the attacks which were originally described
>in the previous thread - flooding a machine's Net connection with
>packets to confuse it, or reduce the number of legitimate packets which
Actually it does a little. You see the coordinated effort that seems to be
brewing right now has a group of hackers using bindscan and gip to produce
some rather interesting reports of vunerable servers.
The other code on the servers seems to be a daemon that listens on a port
waiting for a "signal" and destination to attack. Then it's all on. Seems
it can do everything from SMTP attacks to basic ICMP. There are even UDP
floods! It seems to trigger a meshed network of daemons on other servers.
>get through. These attacks are effective against any Net connection,
>whether it goes to a computer or a router. Apart perhaps from
>subtleties with annoying the deamons or server programs, it would not
>matter what OS was in use.
Anyone with a CISCO should have "no ip broadcasts" turned on at minimum
>This denial of service attack is most likely to be launched from a
>compromised machine, and may involve other perfectly healthy systems as
>All the more reason to make sure your permanently connected machine
>(which is most at risk from these things) is secure against attack!
Shame we can't protect ourselves against traffic targeting our uplinks!
Well I suppose we can switch the link off :)