Безопасность в сети.

Я тут подписан на лист firewall-wizards - весьма приличный лист, модерируемый Marcus J. Ranum - личность в этой области весьма известная. Я приведу несколько его ответов. Надо отметить, что я с ним почти во все согласен. Но приведенные письма интересны не только с точки зрения безопасности, а и с точки зрения на ПО вообще. На мой взгляд, здесь и переклички с реестром, и с надежностью ОС, и безопосностью в сети.

---

Ryan M. Ferris wrote:
>I think what is missing here from this discussion is a more serious
>debate
>on the inherent security differences between monolithic kernels and
>micro-kernels. Or perhaps real-time versus non-real time OS.

There hasn't been a lot of discussion around those issues
because there's not a lot of "there" there. "microkernels" are
mostly marketing hype, not a real technology. Nowadays, the
hardware abstraction layers for physical devices probably
represent more code than the entire V7 UNIX kernel. So what
should we call QNX? a "pico kernel"? See? It's just marketing.

The real question is complexity and management of complexity.
In theory non-monolithic kernels are less complex, but in fact
what you've done is just shuffled the complexity around into
another place. So what if the filesystem is a separate process
from the scheduler, VM system, and IP stack? You still depend on
it just as much, and you've now got the additional worry of
making sure that the channel between kernel modules is tamper
proof AND fast. Basically, you can't win. What happens is
that when security is applied to a non-monolithic kernel all
the developers heave a sigh of relief and conclude that security
is no longer THEIR PROBLEM and write the usual crap code.

>I agree "Appliance" is a meaningless term - I've worked on three
>different
>appliances each with a different version of a different customized
>monolithic kernel OS (W2K SAK, RH Linux 7.0, OpenBSD). Someone could
>ship
>you embedded NT in a toaster oven and call it secure.

Worse things than that have been done. Folks have shipped
"appliances" as "secure" that were running stock FreeBSD.
I even saw one hardware device that was running a lightened-up
version of Linux - including wu-ftpd with a million holes
you could march an army through... It's just marketing.

>What is not meaningless to security and function is kernel size,
>functionality, hardware access levels.

I believe that for a given amount of functionality you'll
need approximately a constant amount of code, regardless of
where you squish it around. And we've all seen studies that
show that error-rates per k-line of code are fairly constant
and shockingly high. Hardware access controls can help but
are often sacrificed in the interest of performance. Sure,
you could make a modular (note I did not say "micro-") kernel
that used message passing between components and you could
use the MMU to protect the messages, etc, but it'd be slower
than the guys who didn't do it that way, and it'd get slated
for addition in the next release (a nice way of saying "it'll
never happen")

>You are an NSA Analyst, monitoring traffic from multiple backbones
>that has
>be "muxed" or results from the parallel mirroring, spanning of many WDM
>optical switches - i.e. terabit amounts of information flow. The
>distributed
>systems needed to process such traffic on PC based sytems would be
>immense
>in number. You would probably opt for hardware based solutions as they
>would
>be more easily centralized.

Huh? Why do you say hardware can be more easily centralized?
Centralization/management/etc functions are almost always written
in software that runs on the hardware. Sure, you might be using a
c00l new ASIC but it's gonna be running software on it, written
probably in C, most likely on a tight deadline, and almost
certainly with the same error rate/k-line of code as most other
software.

>You are a major corporation (50K computer users) that wants a single or
>minimum access points for all proxied or firewalled traffic. How could
>you
>use a PC based firewall for this purpose without using many firewalls?

Do you understand that all firewalls are written in software?
I bet they're all written in C. Maybe they're burned into an
ASIC someplace but that just makes it impossible to fix the
bugs in the burned-in code. I've seen ASIC-based security
solutions that do some parts (e.g.: traffic collection) with the
ASICs but the higher level firewall functions are loaded from
flash memory. I.e.: they're software. They just don't run off a
hard disk and come with an install-shield script.

I think you believe too much marketing.

mjr.

---

Marcus J. Ranum http://www.ranum.com
Computer and Communications Security mjrranum.com

_______________________________________________
firewall-wizards mailing list
firewall-wizardshonor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

---

Paul D. Robertson wrote:
>> death importance, so I personally don't think the 'appliance' label
>> applies to any firewall or security product in existance.
>
>That battle has been lost...

What people don't seem to understand is that "appliance" is
a PACKAGING concept. It's got nothing to do with anything
else. It doesn't say anything about the quality, security,
or maintainability of the software/hardware mix inside the
device. Those are separate questions that are very important
to ask.

"Hardened" is the other one that makes me want to puke. Most
vendors call something "hardened" if they've disabled all
the guest accounts in /etc/passwd on a copy of FreeBSD. Now,
where I come from, "hardened" means that it has a security
design that makes a strong case for how the system is not
trivial to penetrate, and that it has the absolute minimum
of stuff necessary to do the job. That doesn't mean deleting
the compilers and X-windows apps - that means starting with
a kernel, a static-linked copy of fsck and init and building
upwards from there.

mjr.

---

Marcus J. Ranum http://www.ranum.com
Computer and Communications Security mjrranum.com

_______________________________________________
firewall-wizards mailing list
firewall-wizardshonor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

---

Mike Frantzen wrote:
>Packet filtering, even stateful packet filtering is pretty easy
>to do in hardware. Unless you're a big fish, you'd probabley do it in
>an FPGA as opposed to an ASIC.

Heya, Mike!

What does the 'P' in "FPGA" stand for?

mjr.

---

Marcus J. Ranum http://www.ranum.com
Computer and Communications Security mjrranum.com

_______________________________________________
firewall-wizards mailing list
firewall-wizardshonor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

---

Jared Valentine wrote:
>John Pescatore (VP @ Gartner) wrote a good report/article on just this
>subject. "Software security is soft security: Hardware is required."

What constantly boggles my mind is that anyone takes
Gartner's pronouncements on security seriously... They're
so ignorant they have no idea how ignorant they are.
You've got to understand that most of the input into
Gartner is from briefings arranged by the marketing
departments of companies that are paying them to listen
to their briefings. Basically, Garter sits at the apex of
the hype food-chain; they consume pure hype and produce
little sh&t-pellets of hype that is as dense as neutronium.
Remember, these are the guys who get all excited and
talk about revolutionary new technologies like "intrusion
prevention" without realizing that it's just a buzz-word
for stuff that has been around for ages. They're idiots.

>"Throwing more security software at a security problem that is caused
>by the
>essentially insecure nature of software is like going to a blind
>barber-it
>can only end badly and, more likely than not, bloodily."

Cute turn of phrase but what's he really saying?

He's saying he doesn't know what software is. And he probably
doesn't know what hardware is either. He appears to think that
buggy code only exists on hard disks, and doesn't realize that
buggy code can also get compiled down into FPGAs or strongARM
processors or coprocessors or whatever.

>While it is correct that all security comes down to "software" at some
>point, I would argue that hardware is much more secure. The difference
>between the two is that the hardware manufacturer can build off of a
>trusted
>base/OS. They can look at the OS line by line and strip out
>everything not
>essential for the operating of that firewall.

Go stand in the corner with Pescatore.

The difference between the two is that usually, memory-space in
hardware devices is expensive and manufacturers don't want to
run bloat-ware like UNIX kernels in it. So they use smaller
kernels like VXworks or QNX or whatever. But there's a kernel
(that's "software", see?) running down in there, you betcha.
Do they look at the OS line by line? Hell no. Do they strip out
security flaws? Hell no. If they're using QNX or VXworks, they
are using an OS that was designed to run in tight real-estate
and consequently was made modular so that you don't automatically
get a lot of stuff you don't NEED. This is unlike UNIX or Windows
or (worse) Linux - where the kitchen sink is not only included,
but it's bolted to the wall - and when you take the sink out
because you didn't need it, the wall falls over. In other
words, those realtime operating environments are "secure"
BY ACCIDENT in the cases where they are, in fact, secure.
They also appear to be more secure because they're obscure and
weird and hackers generally don't waste the time attacking
them because there's not much to do with them once you've gotten
into them. But any security that happens in these cases is because
the operating environment (that's "software" that "boots" on
the "embedded processor" often from read-only memory or flash
so it can be upgraded)

But it's ALL software.

Basically, what's going on here is that having a "hardware"
"appliance" lets people sweep upgrade problems under the rug
and pretend that they don't need to worry about it. Think of
it this way - when you buy a firewall that's got its firewalling
logic blown into ROM, are you REALLY happy with that? What if
some new attack comes out that the firewall doesn't protect
you against? OOPS! Well, you'll upgrade it, if you're smart.
But it'll be a software upgrade. Code, written in C, just like
all the other firewalls.

mjr.

---

Marcus J. Ranum http://www.ranum.com
Computer and Communications Security mjrranum.com

_______________________________________________
firewall-wizards mailing list
firewall-wizardshonor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

Вслед за вчерашним шумом со вскрытыми SMS-текстами ОпСоСов продолжение банкета на другом фронте. На этот раз отличился Приватбанк. Поисковики проиндексировали выписки из счетов…

// via Ilya V. Guy (Daemon) - Juick

О! В минувшей утечке обвинили хакеров! utro.ru
По ссылке много жёлтой горячки.
// via Sergey Tomilin, Facebook

// Транслировано с juick.com

В сеть утекли пароли Yahoo

В сеть утекли пароли Yahoo

Хакерская команда D33Ds Company выложила в сети более 453 тысяч паролей пользователей сервисов Yahoo. Известно, что взлом произвели через union-based sql... // t.co

 

 

// Транслировано с twitter.com.

О блокировке карт сообщили «Авангард», Транскапиталбанк, «Кольцо Урала», «Интеркоммерц банк» и ВТБ24; Альфа-банк решил ограничить их функционал


Российские банки начали блокировать и перевыпускать карты, с которых произошла утечка данных об их держателях при покупке билетов РЖД с 7 по 14 апреля. О том, что в апреле действительно была проблема с атакой на сайт РЖД, «Ведомостям» ранее сообщал источник в одном из госбанков.

В апреле анонимные хакеры выложили данные по пластиковым картам около 10 000 пользователей: всего, по их сведениям, под угрозой оказалось 200 000 человек. Хакеры опубликовали имя и фамилию владельца карты, часть ее номера и CVV-кода, а также срок действия.

Банк «Авангард» заблокировал около 3500 карт, получив предупреждение от Ассоциации Участников MasterCard о картах, скомпрометированных при покупке железнодорожных билетов, сообщил портал Finanz.ru. Также, по его данным, о блокировке карт сообщили Транскапиталбанк, «Кольцо Урала», «Интеркоммерц банк» и расчетный банк при оплате билетов ВТБ24. На сайте самих банков этой информации нет.

Директор по мониторингу электронного бизнеса Альфа-Банка Алексей Голенищев подтвердил, что проблема с атакой на сайт РЖД действительно была, и опубликованные в Интернете данные скомпрометированных карт соответствовали действительности. Однако Альфа-банку не пришлось полностью блокировать и перевыпускать карты: было достаточно ограничить функционал этих карт (а речь идет о нескольких тысячах карт), запретив по ним операции в Интернете без ввода одноразовых паролей, уточнил Голенищев.