One for the Security Guru's

Once there was a company durring the dot.com boom. This company had
some outside consultants come in and tell them how to do a number of things. Many of the things were laughed off but some stuck. 2 things in particular are giving me nightmares now that I'm at this company. They have survived the bust and I think will actually stand a very good chance to be very important in the near future so I want to see them stay sane, stable and secure.

The consultants aparantly told the company admins that kernel modules
were a massive security hole and extremely easy targets for root kits. As a result every machine has a 100% monolithic kernel, some of them ranging to 1.9Meg in filesize. This of course provides some other sticky points such as how to do a kernel boot image.

I'd like it from the guru's on exactly how bad a hole this really is
and if there is a method in the kernel that will prevent such exploits. For example, if I disable CONFIG_MODVERSIONS is the kernel less likely to accept a module we didn't build? Are there plans to implement some form of finger printing on modules down the road?

Thanks for your imput guys,
Robert

:wq!
---------------------------------------------------------------------------
Robert L. Harris

DISCLAIMER:
These are MY OPINIONS ALONE. I speak for no-one else.
FYI:
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

I seem to recall that there are rootkits with kernel modules out in the wild. If I recall correctly, there is a kernel capabilities patch that will disallow loading modules after some point.

Its been something I've been meaning to look into more, but with a million other projects on the platter ...

-- John E. Jasen ([email protected])
-- User Error #2361: Please insert coffee and try again.

Typical consultant rubbish. Yes, LKMs can hide rooted systems, but the system has already been broken into by then. You must be root to load a module or copy a module to /lib/modules, depmod ignores modules that are not owned by root. IOW, if somebody can load a module then they already own your system!

Fingerprinting modules is a hardy perennial. It cannot be done in user space (how do you fingerprint the loader, libc, insmod etc.?), it can only be done in kernel. No kernel code exists to do that, although LSM may be getting there. The stumbling block is - who creates the fingerprint? Answer - root. You are trying to identify the difference between a valid root user and a malicious root user, both of whom have exactly the same privileges. It does not work!

LSM with its fine grained security model might help in this area, but don't hold your breath. LSM has not been accepted into the kernel yet.

There are techniques for getting the same effect as LKMs even when the kernel is not compiled with modules. Phrack had a series of articles on this subject. Turning off modules increases the effort of hiding the break in by 5-10%, it does not make the system any more secure. Remember, if somebody can load a module then they have already broken in.

Modules make no difference to security. If I can add a module I can swap the kernel and reboot the box, or I can patch the kernel. In fact I can load modules into module-less kernels its just a bit harder.

It doesnt help you without a lot more than just fingerprints. You can revoke module loading at boot time if you want - it only makes things a little harder.

If you want to make it theoretically impossible then you need to load the modules required early then revoke the module loading and rawio capabilities. At that point I should not be able to get raw hardware access or load a module. You need to revoke both of the so I can't for example hand load modules by poking in /dev/mem.

Alan

IMHO the security risks associated with modules is not the potential for getting higher permissions but rather that having the loadable module capability makes it *easier* to hide your code and actions once you're in because what you would want to do is change the running kernel to hide your actions and loadable modules makes it easier to dynamically change a running kernel in general (DUH! :-). In short - LKM support doesn't open any doors; It does makes it slightly easier to stay invisible once you're in.

There are, again IMHO, much simpler things that I'm willing to bet company X isn't doing (because no one is doing them) that would help much more to security then disabling LKM support. For example - when you download a new update of a kernel (or any program for that matter) source/patch (or binary package) from the net do you check the GPG signature validity? I would be VERY surprised if you answer 'yes'... :-))

Gilad.

It's the typical so-called Security Consultant's lies. After all, if they knew what they were doing you wouldn't need them. They create phony scenarios and then "solve" them. For instance, they will load a module using a "root kit". Look, your system needs to have been broken into in order to load a module. It's already been broken into, the module is just a Security Consultant lie.

To load a module, you need to be root. If you are root and you shouldn't be, the system has been broken into. It's just that simple. It's not possible for insmod or depmod to load a module, sitting in a rogue user's directory, that suddenly gives that rogue user some privileges that he or she didn't already have.

We had some Security Consultant idiot from some well-known auditing agency declare that all Linux machines were vulnerable to outside attacks and "continuing use of such software could result in a investor lawsuit..."

Of course the attack against Linux was "true". If you put a Linux machine (or Sun or whatever), on the outside of a firewall it may be attacked, therefore vulnerable to attack. And, if investors learned that you were so stupid as to put it outside a firewall, you might get sued by the investors. It's all perfectly true. It's a trick by liars that lie by telling irrefutable truths.

In a similar scenerio, a Windows machine might not even be attacked. There is nothing to be gained, even as the operating system is compromised. It would likely crash before any proprietary information could be obtained. One of the advantages of Windows is that it's so awful that only GWBASIC users are interested in it, then only to change the location of a GOTO ;^.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America

You can get the same effect as a module with a kernel without any modules support compiled. There are even root kits out there which do exactly this.

If you want a little more security, don't run a vendor kernel (sic!). Not because they're unsafe but because many rootkits have binary modules for some well known kernels (2.4.9-34 or 2.4.18-3 come to mind); clean up your systems (e.g. don't ever ever ever have a compiler and a development kit on an internet connected system. If you don't have a compiler, 80% of all root kits will not work or will simply not be able to build the process hiding stuff because it comes as C code). If you run 2.4.18-3-rerolled with MODVERSIONS off, lots of the kiddie root kits break.

You can't get security by design. Ask the OpenBSD people who tried this and failed.

You get security by installing your systems, administrating them (which means looking at logfiles, unusual activities), keeping your boxes up to date with vendor patches and by training your staff to be security aware. Read lists like Bugtraq. Invest time (and money!) in the security of the systems.

If some consultant sets up a box and slaps a "this is safe" label on it, start being suspicious. I've seen more than my share of RedHat 5.x and 6.x boxes which were installed like this and then they called me 12 months later because the "so secure" boxes have been rooted...

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Actually at the place that just went bankrupt on me I had a Security consultant complain that 2 of my servers were outside the firewall. He recommended that I get a firewall just for those 2 servers but backed off when I pointed out that I would need to open all of the same ports that are open on the server anyways so the vulnerability isn't any less with the firewall.

Firewalls are another Security Consultant's lie and using them for anything other than preventing outside connections to internal machines and keeping certain DOS attacks outside the network is a waste of money. To top it off they make admins feel safer so they are less likely to make sure the machine is actually admined properly.

Never trust Security Consultants.

Gerhard

--
Gerhard Mack

[email protected]

<>< As a computer I find your faith in technology amusing.

yes someone who has root can get the effect of modules by patching /dev/kmem directly so eliminating module support does not eliminate all risk.

it does however eliminate the use of the rootkits that use kernel modules.

you need to decide if the advantages of useing modules are worth it for your situation.

what do you compile into a kernel to make it 1.9M compressed? I suspect that you could trim that down to fit a floppy for a rescue disk. In addition you may want to consider making your rescue disk be a CDROM so that you can not only fit a larger boot image, but you can also fit more untilities to help you work on the system.

also there are a couple ways to make a CD bootable.

One way is to use the floppy image (I think it's called El Torito or something like that)

In addition I have created bootable CD's with lilo and ext2 partitions. If it's an IDE CDROM you can setup a CD to treat it like a read-only IDE drive (or you used to be able to anyway, I haven't checked it since 2.2 days)

David Lang

Followup to:  <[email protected]>
By author:    David Lang <[email protected]>
In newsgroup: linux.dev.kernel

One thing about all of this that matters is the following:

It's not about how secure your system is.

It's about how smart/well equipped/patient the attacker needs to be *once they have already broken into your system*.

I recently had one of my machines broken into, but the service in question was not running as root, and the attacker wasn't able to find any privilege-escalation bugs on my system. I found a whole collection of attempted security violations in a directory in /tmp, and a daemon (called "bind" -- not "named") had been installed to get access to my system again. Needless to say, I cleaned that stuff up, and also got a close look at the rootkit.

Since my machine hadn't succumbed to the rootkit, it seems the attacker had simply moved on. Most of these kinds of attacks are actually automated these days, unless you're a high-value site for them.

The kernel module, and/or replacing common user tools like ps, are usually about trying to hide the existence of whatever intrusion-installed software there is. It really helps more on "springboard" site than sites that are the genuine attack targets.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

[ Snip! ]

Be surprised: I run "gpg --verify foo.tgz.sign foo.tgz" every time I download from kernel.org. And, "rpm --checksig *.rpm" on stuff from redhat.com too.

Given the recent trojaned source packages, I recommend that everyone do the same.

	=	=	=	=

The preceding public service message has been sponsored by Anal Retentive Sysadmins .Org (Motto: Constipation: It's not just a gob, it's a career!)

James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com

i very much doubt this would stop anyone who really wanted todo something like loading a module.

Stating something like that would also mean booting the kernel from a disk inside the machine is also insecure.

As to load a module you must be root and if you are root you can read / write disks. Thus you could recompile your own kernel install it try to force a crash or a reboot which is not hard as root and the person may not even notice that the kernel has grown by a few bytes after the crash.

The only thing it may do is slow somebody down.
A lot of people out there if they can get access to a system and cannot keep it will also tend todo a rm -rfv / or equivelent nasty.

James

and when an attacker looks into your .bash_history see this and modifies gpg and rpm ?

First, I use ksh, so the kiddie is looking into the wrong history. ;^)

Second, I'm trying to keep him/her/git out by not loading a trojaned package. Once the scumbag is inside your box, it's much harder to throw them out. In fact, a reinstall is usually in order.

Third, if they don't do it already, I'd like kpackage, gnorpm, and similar tools to always check signatures before loading a package. (And, for the GPG public keys used to have come with trust signatures from the installation CD.) That would really help with all the newbies to *nix coming on board now.

PS: If you don't trust your gpg or rpm, boot off install CD # 1, switch to a
text console, and use the ones on the CD. QED. :^)

James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com

dont most of thoose only use a shared libary which would mean 1 file overwrite and disable all. Though rpm i know is normally static.

heh by the time you dont trust it. Its normally time to reinstall.

When the attacker can look into the .bash_history of root he has already taken over the box. As Alan already stated before on this thread, when the attacker has root, the game is over anyway - what happens next only effects how long it will take you to find out you have 'guests'.

The purpose of the GPG spiel is to stop (read: make it harder) from the attacker becoming root in the first place, for example by replacing packages you download (either on the ftp site or in trnasit) with trojaned copies.

Gilad.

Gilad Ben-Yossef <[email protected]>
http://benyossef.com

 "Geeks rock bands cool name #8192: RAID against the machine"

They were blowing smoke. Once the attacker has root on your machine, you're toast, whether or not you have loadable modules enabled. The right defense is to prevent attackers from getting root on your machine; the consultant's recommendations are probably not the best way to spend your time and energy.

Um, what's sitting in the security and include/linux/security.h files in the 2.5 tree then? :)

In short, it's in, but not "every" part of it, yet.

thanks,

greg k-h

So you should've bought a more expensive firewall that offers protocol based forwarding instead of being a simple packet filter.

packet filter != firewall. That's the main lie behind most of the "Linux based" firewalls.

Get the real thing. Checkpoint. PIX. But that's a little more expensive than "xxx firewall based on Linux".

Actually, there _are_ security consultants, that know what they're talking about. Unfortunately they're drowned out most of the time by the drone of so called "self-certified Linux experts" which believe, everything can be handled by using the only tool they know.

BS. Invest money in real consultants that know their trade. They simply might not be the cheapest and they might tell you solutions that hurt (e.g. training your staff) but of course there are lots of people that know what they're talking about.

Ciao
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Don't put a compiler on the box.

The point is not, to make it impossible to root your box. The point is, to make it a) hard(er) and b) time intensive.

a) keeps out the kiddies with the r00t hAx0r kits
b) gives a security aware staff (or an IDS or a security watcher) a reaction window.

One of the most sucking decisions of mainstream distributions is that they offer to install a development kit on server installs. It seems that people working @ linux vendors either have no clue or simply don't understand the needs of their customers.

Sheesh, some even install a full desktop with "[gnome|kde]-games" on a server. What is this? Microsoft Windows <insert your poison here>" ?

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Thats not entirely accurate, or fair. A packet filter is a type of Firewall (or can be). A Firewall is a means to implement a security policy, usually specifically a network access policy. A Packet Filter, including a ""Linux based" firewall" is a perfectly acceptable means of achieving that goal, if it meets the policy requirements.

Ref. http://csrc.nist.gov/publications/nistpubs/800-10/ (over 7 years old, but still highly relevant).

Most commercial firewalls are very bad at protecting servers offering Internet services, they aren't designed to do it.

-tony

Which is why some people configure kernels not to support installing modules and only use read-only media (e.g. CD-R) for booting. Sure, there's still the /dev/kmem hole, but this closes 2 classes of attacks - loading rootkit module and booting with a hacked kernel in straight-forward way.

BTW, this might be a reason to make kexec syscall to be a config option (if it isn't already.) The other reason is to avoid bloat for people that don't need it, but perhaps this is a stronger argument. I realize you can propably launch the kernel by hand (using /dev/kmem etc) if you really know what to do. But the same applies to adding code/patching kernel without CONFIG_MODULES support.

-- v --

[email protected]

Question: What do I lose when you remove /dev/kmem? Related question: Would it be useful to make /dev/kmem read-only?

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Makes no real difference. If the user got to root they can work the chmod command. What you want to do is revoke CAP_SYS_RAWIO which kills off all direct hardware access - mem/kmem/iopl/ioperm etc. It does stop non kernel fb X working but thats not a big deal on a server.

AFAIK Linux has "protocol base forwarding" (more commonly known as "state-full inspection") for *some* protocols.

Also, although Firewall-1 and PIX are very good products (and provide income to some of my best friends :-), the implications that they are somehow magically much better then the freely available ones is somewhat misleading IMHO.

They certainly offer more *features*, the question is whether these additional features indeed translate into better security. IMHO for most cases the answer is negative. Again, this is not because they are not good (or even better), but rather that they are better answer to the wrong question - the TCP and HTTP stream is perfectly fine and legal and the buffer overflow "hides" in the data payload but firewalls can't stop that (unless it's a relatively old attack) and that is, again IMHO, where the problems seems to be today.

The important question is *always*: "what is the threat?" For a lot of the practical common situations a Linux IPTables firewall will be as effective as the top notch Checkpoint/CISCO solution because FW-1 and PIX do offer a better parsing and response code (for example) but in the end of the day it's upgrading your OpenSSL libraries on time and such that really counts.

It's not about who is better - it's about who is *enough* to counter the threat enough to get you to a point where that specific issue isn't the 'weakest link' anymore. I think Linux does that very very well in many situations.

To this I all heartily agree. Get good people (and be prepared to *pay* for good people) and then *listen* to them. Sadly, I believe that the latter seems to be less common then the former... :-(

Gilad

Hm,

I've been in a hurry when I wrote my first mail. What I meant was:

- I remove drivers/char/mem.c from my kernel. What do I lose? (/dev/null, /dev/zero and /dev/full afaics but cut this down to "i remove everything related to mem_fops, kmem_fops and port_fops").

- I remove write_mem(), write_kmem() and write_port() from drivers/char/mem.c What do I lose?

Removing CAP_SYS_RAWIO is nice, but I actually want to remove the code from the kernel, not just disabling it (Yes, of course I could try but my test box is in pieces ATM...).

The pointer to the Xserver is a good one. Thanks.

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Just removing /dev/mem isnt enough. You still need CAP_SYS_RAWIO revoked. There are many raw i/o accessors it covers

It gets even worse if almost all of your services are encrypted(like you would find on an e-commerse site). https will blind an IDS. The last place I worked only had 3 ports open and 2 of them were encrypted.

Gerhard

--
Gerhard Mack

[email protected]

<>< As a computer I find your faith in technology amusing.

Nah. Do it right:

Internet ----- Firewall ---- SSL Accelerator Box --+---- Webserver
HTTPS HTTPS | HTTP
|
IDS

Check out the boxes from SonicWall, they're quite nice. Expensive, though. If your E-Commerce site can't afford them, well, then they shouldn't be able to affore a security consulant in the first place. :-)

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Unfortunantly there are things that you can't do with a network based SSL accelerator box (specificly have your webserver give people an understandable warning if they are useing weak encryption) so this isn't the Right (tm) way of doing things, it's one of the ways to do them.

David Lang

It already is a config option.

Eric

Eh... not really:

A. If there's a buffer overflow in the SSL Accelerator box the firewall wont do you much good (it helps, but only a little).

B. The firewall in this setup provides very little besides packet filtering anyway.

SO... basically we're back to square one. A better firewall might offer more features but in the end the end point must be secure or all of these features wont do a damn good, thus in many cases it would make sense to use the free (as in both beer and speech) solution provided by Linux, not because it's the best, but because it's enough: there are weaker links to worry about.

Gilad.

Gilad Ben-Yossef <[email protected]>
http://benyossef.com

 "Geeks rock bands cool name #8192: RAID against the machine"

Gee, isn't this a kind of "man in the middle" security breach ?!?! Most of the people on the net, including me, expect that nobody and I mean nobody is sitting between my browser and the web server, seeing unencrypted packets when we use SSL.

And now your telling me that the SSL Accelerator Box and the IDS is seeing in clear text the traffic I thought only the web server was seeing ?!?! And presumably, the IDS is logging somewhere all the credit card info that I might be sending...

Mind you, I guess nothing prevented somebody to do something behind the Webserver to do some wicked thing but now, your telling me that they are devices, on the open market, specially design to do this!

So now, you have to worry about "internal" security on 3 boxes instead of one.

Customer Information Security is now tredeoff for more Servers Security.

How sad :(

Danny

OK, I don't advertise that I'm the "know-it-all" when it comes to security, and in the State of Nevada (USA) I'm not allowed to advertise as a "security consultant" without a special license from the Private Investigator's License Board.

I have a firewall running on 2.4.18 (Red Hat 7.3/Valhalla with updates) which is (on an experimental basis) doing port-number-based forwarding to a Web server. The idea is that the Web server is *not* directly on the 'Net, but is instead behind a firewall that steers incoming traffic to it on two specific ports: 80 and 443. (Yes, I installed the slapper on the Web server.) This was done using IPTABLES.

I've also been experimenting with the traffic limiting capabilities, as one co-locate provider offers discounts for guaranteed lower bandwidth utilization, so by limiting the bandwidth using IPTABLES I should be able to cut my co-lo costs to 1/3 of what they would be with "unlimited" bandwidth.

I've worked with the PIX, and I don't see what I'm missing in features between the PIX and Linux/IPTABLES. I'm sure there is something. Please amplify on your comments.

If you don't control the network between the Accelerator and your webserver, you're toast anyway.

So what? How many "secure ecommerce sites" just put the information that you sent over the secure channel into a database accessible by a tcp port? or simply print it out? Send it via unencrypted mail to their sales department (presumable to [email protected]. Yes, I've already seen that.). HTTPS is just a gurantee, that your data isn't sniffed between your web browser and the device you're talking to. Once the data hits the web server, there is nothing that HTTPS can do or you can rely on.

Of course. Once you hit more than a few https transfers, you can either burn your cpu cycles for doing crypto or simply use a device.

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

This is a hardware device. Hardware as in "silicon". I very much doubt that you can run "general purpose programs" on a device specifically designed to do crypto. And this is _not_ just an "embedded Linux on ix86 with a crypto chip".

You're right. But if I'd let it off, I'd would have gotten mail with "there is no firewall in your setup, it's not secure". Either way I lose. :-)

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Am Don, 2002-10-24 um 11.47 schrieb Henning P. Schmiedehausen:

Don't laugh; I had such a box reinstalled from ground just the day before yesterday because I found a RedHat full Install on it. Not to mention that there're "admins" out there who use GNOME as root on a fairly busy mailserver <shudder>...

Servus,
       Daniel

http://www.lartc.org ; When talking about traffic shaping with Linux you're really talking about tc from the iproute2 package. I'd recommend you check out that URL if you havn't already and that you strongly consider using HTB for your traffic shaping needs, it's alot easier to use and makes alot more sense than CBQ.

Eh, it depends on how you look at it, but... The cisco includes support for checking out high-level protocols, such as HTTP. Basically you can set things up inside the PIX based on what URL is being requested and such. That's why the PIX is more than just a packet filter. Personally I still characterize my Linux box running iptables as a firewall. If you want to do the same kind of thing the PIX is doing on port 80 you'd need to run squid or something similar to it and set it up as a reverse proxy with associated access rules and whatnot. Things like deny anything with cmd.exe in it, etc.

Stephen

Pity they never read lkml, nor any literature at all.

I'm not laughing, I inherited a firewall box that had a full install of Red Hat 7.1, complete with GUI. I got the network information, loaded up 7.3 with minimal installation, and cleaned up that "minimal install" by using "rpm -qa" (it's your friend) to identify and rid the system of every single package not necessary to the operation of a firewall.

GCC. PERL. Sendmail (!). The eight different version of FTP. (I may be exaggerating, but the stream of packages that offer FTP client and server services seems to be endless.) Things that a root kit would find extremely useful to install back doors and other nasties. Debuggers. Those were just the extra packages -- I also scanned for unnecessary SUID binaries when I was finished and blasted them to the ol' game grid.

I then used IPTABLES to implement the security policy of the client, and part of that policy was that the only packets that were allowed to talk directly to the firewall was SSH, and only from my range of IP addresses, and ping from anywhere...and I rate-limited the ping to 10 per second so that a ping flood would not hose the return channel.

Incoming SYN requests to the firewall (except for SSH directed to the firewall) are alway dropped silently, and the vast majority of UDP packets also find their way to the bit bucket. Oddball TCP attacks (the log showed a LAMP-TEST packet attack last week) are also given the heave-ho. I have NAT in the outgoing direction, and only those ports necessary to the operation of the client are open. That means no ICQ, at all, for example. No streaming audio. And, as you can guess, no outbound connections are accessible to the likes of BackOrfice.

I'm sure there is a hole somewhere in that firewall box, but I have plugged all the ones I found documented on CERT.

Oh, and a low-volume Web server was moved off the firewall and onto a separate box, with the firewall forwarding packet traffic via IPTABLES rules.

It certainly seems that taking down a server
to do a reinstall is fairly catastrophic compared
to the mere possibility of running X11 -

MfG,

Jup

Followup to:  <1035539042.23977.24.camel@forge>
By author:    Henning Schmiedehausen <[email protected]>
In newsgroup: linux.dev.kernel

Hardware devices have bugs, too. Furthermore, most devices marketed as "hardware" still have programmable stuff underneath. Trust me.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

PIX? Is that the one that breaks TCP/IP when an ACK is lost on the side that the data is coming from?

Roger

** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

So, your PIX is looking at the HTTP requests, and it is validating them. Fine. Now what is the largest HTTP request that you're going to allow? 1k? 10k? 100k?

The PIX is NOT filtering the size of the HTTP request. It will happily allow a multimegabyte request to come through. Is that exploiting a bug in your http server? You don't know. And the PIX doesn't help.

When I encountered a PIX, multimegabyte HTTP requests were valid, and the PIX screwed them up. A slight thinko on the side of the PIX programmers.

The PIX HTTP filtering may give you some extra controls (I hear you can do URL based filtering.... Wow!). Don't you have that control on your webserver?

Roger.

** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

Don't you have a compiler at home? I do.

Roger.

** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

Of course they have. I'm not that dumb. :-) I won't expect any piece of silicon speak http, snmp and have configureable ip adresses without any programming. I do had my share of Cisco router fun.... :-)

But my point is, that these beasts normally don't run a general purpose operating system and that they're much less prone to buffer overflow or similar attacks, simply because they don't use popular software with known bugs (e.g. OpenSSL) or these functions (like doing crypto) are in hardware.

If you have a processor that sets up an ASIC to do "insert https here, use this key, remove http there", you might be able to attack the IP stack running on the processor which gets the packets from the wire and puts them back onto the wire. But you won't be able to trick any bug or overflow in the crypto routines into opening a root shell on the ASIC. :-)

Especially if there is no such thing as a /bin/sh binary on the bugger. And even if you _do_; you still only have a shell on the accelerator. Not on the application server.

If you ask me "how can you trust such a device if you can't look at the source; well, I don't have to. I can tell the customer "this device has been approved by <insert your certification authority here> and you pay gobs of cash for simply having this certified device".

Replace "device" with "certificate" and you have the same thing as getting your web server key certification from Verisign or Thawte. You pay money and get a "trusted device".

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Depends on your PIX OS. As with any other OS, there are bugs and you should monitor the vendor mailing lists for updates and fixes.

It did broke SACK once. There was an update and the problem was solved. Thats what a vendor is for.

Regards
Henning

What did you think? That I fall bait to this troll? :-)

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

The script kiddies simply haven't bothered to attack these boxes yet. When they are done with the bugs in the common oses, they will move on to other targets...

And you say that a "root shell" on the box doesn't give you root on the application server? It might be too hard for a "worm" but it will be easy for a human.

Roger.

** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

As someone who has worked on a couple of these which are presently on the market I can assure you that many of these things have plenty of 'popular software' in them... albeit hacked up and mangled to bits at times... but it's there, and often vulnerable to many of the same problems you would have under Linux/Apache/whatever.

--cw

Aren't the signatures on kernel.org automatically generated?

Florian Weimer 	                  [email protected]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898