►
From YouTube: Three Years of Lessons Running Potentially Malicious Code Inside Containers - Ben Hall, Katacoda
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Three Years of Lessons Running Potentially Malicious Code Inside Containers - Ben Hall, Katacoda
For the past three years, Katacoda has been providing an online learning and training environment for cloud-native technologies. The live environments for Docker, Kubernetes and other Cloud-Native technologies are accessible via the browser. A side effect is that users can, and have, execute malicious code and attempted to hack the system from inside the container. In this talk, Ben will share the lessons learned of building Katacoda and some of the interesting stories and security attempts from the past three years. This talk will give insight into: - Out of the box security with Docker and Kubernetes - Docker and Linux security issues - Monitoring for malicious activity - What happens when it all goes wrong. In the end, attendees will learn different approaches they can take to secure their own systems and be prepared for potential attacks they might face.
To learn more click here: https://sched.co/FuKR
A
Good
afternoon
everyone,
so
my
name
is
Ben
hall
and
for
the
last
three
years,
I've
been
letting
anyone
on
the
internet
we're
in
potentially
malicious
code
on
my
service,
and
this
is
a
story
about
how
I
managed
to
do
that
and
how
I
managed
to
keep
ourselves
secure
and
utilized
containers.
Keep
everything
nicely
contained
and
a
reason
why
I,
let
anyone
ruin
any
code
they
want
on.
A
My
servers
is
because
I'm,
the
founder
of
cats,
coda
cat's
coda,
is
an
interactive
learning
platform
for
software
developers,
and
so
we
teach
people
how
to
use
darker
kubernetes
and
many
of
the
other
cloud
native
tooling
that
you're
gonna
hear
about
today
and
tomorrow,
through
the
ISTE
o
harbor
and
all
of
the
other
foundation
projects.
We
work
closely
with
different
companies
such
as
Red
Hat,
who
have
learned
OpenShift
comm,
where
they
describe
how
he
can
use
their
OpenShift
platform
to
solve
many
of
your
problems
and
we're
embedded
into
the
kubernetes
website
at
kubernetes
I/o.
A
A
Now,
as
you
would
imagine,
when
people
see
this
terminal
window,
they've
never
been
asked
for
a
login
they've
never
been
asked
for
an
email
address.
They
don't
have
to
enter
credit
card
details,
and
so
they
like
to
explore
and
so
they'll
kind
of
poke
around
and
I'll
see
that
their
routes,
because
we
want
people
to
be
able
to
learn
to
the
full
potential.
We
don't
want
to
restrict
what
they
can
do,
and
so
they
can
install
different
packages
and
obviously
they
can
then
try
and
delete
everything,
and
that
is
always
beautiful.
A
When
people
delete
anything
because
they've
just
this
wall
of
text,
where
Linux
kind
of
let
you
delete
certain
things
and
then
says
no,
you
can't
delete
processes.
That
way
don't
be
silly
and
like
from
a
people
into
me,
like
great
now,
you've
successfully
managed
to
destroy
your
session,
but
you
haven't
managed
to
damage
cat
coda
and
that's
because
we
are
building
on
top
of
the
container
technology
and
we'll
get
more
into
that
in
a
moment.
A
But
we
kind
of
progressed
further
and
people
try
and
explore
more
interesting
aspects
such
as
slow
down
Google
by
Corden
DDoS
attacks
and
getting
really
excited
when
the
giggle
response
time
it
slightly
slower.
Now.
Obviously,
this
didn't
quite
work
with
ping.
Google
can
cope
with
that.
However,
we
do
see
more
glamorous
networking
type
attacks
happening
on
our
system,
and
so
what
we're
going
to
talk
about
today?
If
how
we
look
and
manage
containers
and
the
container
security
aspect,
so
we're
going
to
have
a
quick
refresher
about
container
security.
A
With
me,
you
think
we've
got
to
look
at
them
different
types
of
attacks
and
different
ways
that
people
are
attempting
to
exploit
category
so
cryptocurrency
mining,
it's
a
popular
one
and
we'll
look
at
how
that's
being
coped
with
and
then
we'll
look
at
more
kind
of
exploits,
so
how
they
try
to
exploit
the
kernel,
how
they
trying
to
attack
our
hosts
and
then
how
are
they
trying
to
perform
other
networking
and
related
attacks
to
gain
access
to
cat
coda
infrastructure
or
other
people's?
So
when
they
have
this
terminal
and
I
try
and
delete
everything?
A
How
do
we
make
sure
that
that
isn't
affecting
cat
code
on
that
isn't
having
an
impact
on
other
users
within
our
system?
I'm
great?
Thankfully,
most
of
this
comes
for
free
because
of
the
features
which
we
have
inside
of
docker
and
container
technology,
and
so
as
a
quick
refresher,
we've
kind
of
got
these
core
technologies.
We
can
allow
users
to
win
at
non-root
if
we
wanted
to
by
setting
the
flag
in
over
the
dock
file
or
when
we
launch
the
container.
A
Now
this
isn't
quite
relevant
for
us,
because
we
want
people
to
be
able
to
install
packages.
We
want
people
to
have
control
in
a
live
environment,
but
obviously
in
a
realistic
production
environment,
you
would
never
need
to
learn
apt-get,
install
or
install
additional
packages,
because
that
would
be
doing
it
in
your
beautiful,
continuous
integration
pipeline,
and
so
instead,
you
can
set
a
you
Vietnam
route
and
become
more
secure
now,
a
feature
which
is
more
beneficial
is
uther
namespaces.
A
So
this
is
how
you
can
separate
what
is
considered
root
and
the
root
privileged,
either
on
the
host
machine
to
what
is
considered
the
root
user
inside
of
a
container,
and
so
by
having
this
isolation,
we
had
a
if
a
person
did
manage
to
break
out
a
container,
they
wouldn't
have
read
permissions
on
the
host.
Instead,
there
would
still
be
a
low
privileges
on
a
host.
The
container,
however,
would
be
able
to
install
and
package
everything
up.
A
We
have
copy-on-write
technology,
so
this
is
how
we
get
some
file
isolation,
so
when
everyone
deletes
files
within
their
containerized
system
or
that
container
environment
does
not
actually
delete
in
the
file
on
the
ward
disk,
if
not
deleting
that
base
images
instead,
if
just
adding
the
pointers
into
the
copy
and
write
to
indicate
from
the
file
system
viewpoint,
data
file
no
longer
exists,
but
actually
because
we're
using
images
and
we've
got
that
base
image.
The
underlying
file
even
never
touch,
and
so
people
can
delete
whatever
they
would
like.
A
We
then
need
to
start
worrying
about
how
do
we
restrict
to
people?
How
do
we
limit
how
much
access
and
how
much
capabilities
they
can
you
slide
in
the
environment?
We
all
can't
just
give
away
infinite
resources
for
free,
so
we
need
to
restrict
it
somehow,
and
so
the
first
way
we
do,
that
is
with
three
groups,
see
groups
limit
things
like
how
much
memory
can
in
a
process
access.
So
we
want
to
limit
everyone
to
a
gigabyte
of
memory.
Then
we
can
limit
that
process
using
three
groups.
A
We
can
limit
how
much
CPU
it
can
access
by
a
shares
and
for
making
sure
that
it
can't
overload
a
system
making
sure
that
had
equal
share
of
the
resources
available.
Now
this
is
somewhat
problematic.
It's
not
ideal
and
we
discuss
how
that
works
later,
but
there
are
deed
resources
in
place
and
we
can
control
other
things
like
disk
I/o.
How
quickly
can
you
write
disk?
A
How
quickly
can
you
write
to
the
network
and
other
kind
of
restrictions,
but
they're
not
hard
limits,
and
this
instituted
problems
for
us
and
we'll
do
it
ourselves
in
a
minute
we
have
namespaces.
So
what
can
I
use
a
fee?
So
when
a
user
goes
on
to
a
containerized
process
and
go
like
hey
what's
running
on
the
system,
they
will
only
see
the
processes
which
belong
to
that
containerized
process
and
that
makes
sure
that
they
can't
interact
or
interfere
with
anything
else
winning
on
a
system.
A
A
This
gives
us
some
levels
of
protection,
making
sure
that
they
can't
gain
additional
privileges
if
they
wanted
to,
and
then
we
have
the
three
feature
that
the
button
that
comp
app
armor
and
capabilities-
and
these
are
probably
the
most
important
security
features
for
us,
because
if
limits
all
of
the
dangerous
interactions
and
dangerous
team
calls
that
a
user
may
be
able
to
make.
For
example,
we
can
block
people
mounting
the
disk
of
the
host
from
with
inside
of
the
container.
Today
they
can't
get
access
to
the
actual
disk.
A
We
can
block
them
being
able
to
install
kernel
modules
because
we
don't
want
them
to
have
access
to
that
kind
of
level.
Tin
things
like
hostname
system
clocks,
all
of
these
kind
of
core
functionalities
get
disabled
with
a
combination
of
calm
up,
armor
and
capabilities,
and
it
all
comes
out
of
the
box
for
free
right.
A
We
have
already
allowed
everyone
to
aqus
by
giving
them
a
completely
open
access
to
the
system,
but
if
you're
inside
of
an
organization
it
may
be
different,
you
may
have
different
attack,
vectors
and
different
things,
and
so
I
recommend
everyone
to
take
into
account
what
death
threat
model
looks
like
as
I.
Think
kind
of
Kotov
is
very
explicit,
but
you'll
see
the
cat
coda
style
of
experience
in
many
different
places.
A
The
attacks
and
I
search
in
this
case
steal
confidential
company
info
and
ember
in
cryptocurrency
mining
on
top
of
it,
and
so
basically
this
is
what
the
talk
is
going
to
discuss
what
happens
when
you've
accidentally
been
exploited.
When
someone
have
gained
access
to
your
system,
how
he
can
you
impact
to
blast
radius,
and
how
can
you
impact
how
much
controlled
they
have
of
your
system?
And
so,
let's
look
at
cryptocurrency
mining
to
start
with
now,
cryptocurrency
mining
is
quite
simple
to
detect
in
its
nature.
A
When
someone
starts,
you
see
a
nice
spike
on
your
CPU.
Everything
goes
to
a
home
two
percent
and
they
will
sit
there
happily
until
the
posted
to
shut
down
and
now.
The
problem
is
that,
with
cat
coda,
we
also
ruin
machine
learning.
We
want
people
to
be
experimenting
with
tensorflow,
cube
flow,
etc
and
actually
the
traffic
patterns
and
the
behavior
is
very
similar,
like
it's
very
hard
to
detect
what
a
legitimate
cryptocurrency
well
and
not
legitimate
cryptocurrency,
compared
to
a
legitimate
machine
learning
process,
because
they
want
to
do
the
same
thing.
A
They
want
to
take
over
all
of
the
resources
and
win
everything
out
quickly
as
possible,
and
so
now
that
we
start
getting
into
like
how
can
we
start
detecting
legitimate
workloads
on
our
system
compared
to
non
legitimate,
exploited
attacks?
And
so
now,
let's
look
at
how
we
do
that
a
bit
more
closely
now
other
thing,
if
you
do
something
like
leave
your
port
open,
you'll
get
people
scanning
the
internet,
trying
to
find
these
loopholes,
trying
to
find
these
gaps
in
systems
that
they
can
use
to
exploit.
A
So
live
with
an
accidental
honeypot
which
I
put
on
the
Internet
I.
Actually
don't
Lee
left
the
Dhaka
port
open
and
someone
kindly
sent
me
an
email
saying,
like
you
probably
don't
want
to
do
that.
It's
pretty
scary,
because
I
wasn't
sure
how
I
finally
email
address
until
they
pointed
out
in
your
SSH
file
and
your
authorized
keys.
You
have
your
email,
so
it's
like
excellent,
that's
concerning,
and
this
is
what
everyone's
doing,
but
attacks
can
be
a
little
bit
more
subtle
than
that.
A
So
this
is
an
attack
where
people
are
using
cryptocurrency
as
part
of
images
inside
of
the
docker
hub,
and
this
is
one
of
the
issues
which
got
reported
to
docker.
It's
slightly
concerning
that
it's
still
open
because
there's
not
really
that
much
dhaka
can
do.
But
the
case
was
it
was
a
legitimate
image.
It
had
a
legitimate
use
case
of
performing
memory,
tests
of
the
system,
making
sure
that
all
of
the
memory
was
valid,
and
so
the
problem
with
that
is
memory
tests
take
quite
a
long
time
to
run
by
their
very
nature.
A
So
this
was
happy.
It
was
doing
its
job,
but
in
the
background
it
also
had
cryptocurrency
mining
winning,
and
so
it
would
not
only
be
utilizing
all
of
your
memory.
It'll
also
be
utilizing
all
of
your
CPU
without
you
being
aware
of
it
and
a
lot
of
these
other
attacks,
which
is
why
we
should
never
download
a
random
image
after
docker
hub
and
win
it
in
production,
because
we
do
not
know
what
it's
doing.
In
the
background.
We
don't
know
where
it's
sent
in
our
data
or
how
it's
utilizing
our
system.
A
Once
it
been
discovered
on
one
of
these
many
different
systems
which
are
all
connected-
and
this
is
how
their
Tesla
attacked
worked,
so
they
hid
IP
addresses
from
CloudFlare,
so
you
couldn't
actually
easily
block
the
incoming
traffic,
even
if
you
wanted
to
and
then
never
use
an
unlisted
and
kind
of
private
issue
minor
pools.
So
you
couldn't
even
this
white
layer
blacklist
all
of
the
IP
addresses
in
the
system
to
make
to
restrict
it,
which
is
problematic
and
if
more
than
just
cryptocurrency.
A
A
So
how
do
we
solve
all
of
these
problems?
We
have
networking
and
people
trying
to
misuse
cat
coda
in
in
designed
ways.
So,
as
I
mentioned
at
the
beginning,
we
have
C
groups,
we
have
ways
to
limit
isolation
and
limit
how
much
a
user
can
do
within
the
platform,
but
this
doesn't
quite
take
into
account.
A
If
we
could
have
to
share,
we
can
say
that
it's
a
weight
of
helmets,
CPU
a
process,
it's
allowed
to
access,
and
so,
if
nothing
else
is
winning
on
that
box,
it
had
all
of
the
shares
available
because
there's
nothing
else
into
up
to
net
and
nothing
else,
requesting
access.
If
something
comes
along
with
a
higher
privilege,
then
of
course
it
will
get
interrupted
and
it
will
take
the
high
privilege
process
will
have
access
to
the
CPU
it
requires,
but
that
doesn't
mean
that
any
leftover
CPU
is
still
being
utilized.
Hence
why?
A
When
it,
the
attack
starts
all
of
the
CPU
spikes
10%,
no
matter
how
we've
configured
the
CPU
shares
in
terms
of
networking,
we
can't
control
how
much
data
a
process
is
allowed
to
use.
We
can't
tell
Ducker:
hey
only
allowed,
if
person
to
upload
a
gigabyte
of
data
and
then
cut
them
off
from
the
network.
We
don't
have
those
api's
and
being
exposed
within
a
system
now,
fortunately,
with
kubernetes
and
the
container
networking
interface,
they
are
introducing
traffic
shaping.
So
at
the
lowest
level
we
will
have
api
that
include.
A
A
And
it
will
give
us
some
control
and
some
assurances
about
how
our
applications
are
allowed
to
behave
on
a
system,
but
even
with
all
of
the
themes
in
place,
people
will
find
additional
ways
to
be
hidden,
so
this
was
kindly
donated
and
by
someone
on
Kats
coda
by
the
virtue
of
them,
winning
it
I
deemed
it
donated,
and
you
can
see
at
the
top.
It's
checking
to
see
how
many
CPUs
we
have
access
to,
and
it's
like,
if
it's
below,
for
that
generally
remains.
A
A
All
the
time
like
when
you
go
to
AWS,
lambda
or
the
equivalent
here,
you
would
only
be
allowed
to
win
serverless
for
five
minutes
or
15
minutes,
depending
on
how
its
configured
and
then
it
automatically
gets
shut
down
and
for
this
in
a
similar
process
which
we're
taking
and
we've
already
been
encouraged.
This
with
VMs
and
containers
like
we
don't
want
these
long
running
VMs
for
just
maintenance
reasons.
A
They'll
get
out
of
day,
they'll
become
a
snowflake
ie
they'll
be
unique,
and
we
want
to
make
sure
that
they're
being
automated
and
refreshed,
and
so
we
already
have
this
habit
of
recycling
the
containers
and
VMs
every
now
and
again,
and
so
we
just
introduced
that
for
environment
sessions
to,
and
this
is
good
hygiene
practices.
If
a
container
has
been
changed
or
modified
by
recycling
it
and
killing
it
automatically.
A
Then
we
are
introducing
an
additional
level
of
protection,
something's
very
easy
to
do
now
with
kubernetes,
which
will
manage
that
process
and
well
out
for
worse
without
as
losing
traffic
or
interrupting
the
users.
The
next
one
is
a
little
bit
more
interesting
about.
How
do
we
block
and
restrict
certain
types
of
bad
traffic
and
certain
types
of
bad
user
behavior
and
one
of
the
approaches
is
IP
tables?
Everyone
knows
and
loves
IP
tables,
which
isn't
quite
true.
A
We
can
say,
like
port
25
on
the
outbound
of
the
traffic
isn't
allowed,
so
no
one
can
connect
to
a
mail
server
and
catch
Khoda
and
start
using
us
to
spam
people's
email.
Instead,
we've
blocked
port
25,
which
is
great,
but
the
problem
is
that
doesn't
quite
work
with
the
way
that
Dockers
configured
at
iptables.
Is
it
interjects
itself
at
interesting
points
like
really
early
on
in
the
process?
A
It
then
had
its
own
filtering
mechanisms
going
down
the
chain,
and
so
it
makes
it
very
hard
to
gain
access
and
compete
with
docker
about
who
had
got
their
filtering
capabilities
within
the
system.
It
is
possible,
you
need
to
inject
yourself
before
docker,
but
it's
something
to
keep
in
mind
that
you
can't
apply.
Ip
tables
and
expect
them
to
work
because
docker
will
just
ignore
them
by
default.
A
more
interesting
capability
is
using
the
packet
filter,
be
the
BSD
packet
filter.
A
It's
not
very
easy
to
write
the
packet
filter
programs,
I'm
much
more
acceptable
and
a
portable
way,
if
you
think
I
service
mesh,
so
something
like
a
network
policy
in
kubernetes
or
Sto,
which
everyone's
talking
about
through
those
aren't
familiar
with
having
something
like
sto
in
place,
everything
all
of
the
traffic
in
our
system.
We
can
filter,
we
can
add
restrictions
to
make
sure
that
only
certain
services
can
talk
to
each
other
so
that
we
don't
open
up
our
entire
platform
to
everyone
else.
A
If
I
don't
exploit
did
happen
and
we
can
also
restrict
all
of
the
outbound
all
of
the
egress
outbound
traffic
in
sto
is
blocked
by
default,
and
this
is
good
practice
by
design
right.
Why
do
we
have
containers
and
pods
talking
to
the
outside
world
when
they
should
be
completely
isolated,
thumb
back
stand?
They
shouldn't
go
off
to
think
like
AB
get
to
do
updates.
Instead,
we
don't
need
that
happen.
Instead,
we
can
just
keep
everything
closed
and
only
whitelist.
A
A
But
fundamentally
it's
a
game
of
cat
and
mouse
like
they're,
always
going
to
be
new
attacks
that
they're
always
going
to
be
new,
exploits
and
we're
kind
of
watching
monitoring
and
keeping
things
on
top
of
it,
and
this
is
where
we
start
seeing
other
types
of
tax
and
the
name
one
being
piggy
backs
like
people
using
cat
coder
in
order
to
launch
additional
attacks
against
our
sales
or
against
other
people.
So
I'll
start
with
talking
about
host
level
attacks.
A
Now
this
is
where
someone's
gained
access
to
your
system
and
they're
now
attacking
the
system
which
that
part
or
that
container
is
winning
on
and
the
biggest
problem
is
when
people
decide
to
win
everything
at
the
privileged
container.
So
when
you
do
docker
burn
you
set
that
privilege
flag
and
basically
it
removes
all
of
the
security
capabilities
that
docker
has
enabled
by
default.
It
makes
sure
that
everything
runs,
but
as
it
we
have
no
security,
and
it
is
very
easy
from
an
attack
that
vector
to
then
gain
access
to
the
hosts.
A
You
can
ask
the
kernel
information
about
the
system
ie.
What
disks
do
I
have
in
the
host
and
docker?
Will
kindly
tell
you
things
like
their
video
a1
that
that
exists
because
you're
privileged
you
can
use
mount
so
you
can
mount
a
disk
into
a
temporary
folder
within
the
container
and
then
you
can
just
navigate
it
around
because
you
are
winning
at
privileged
you're
winning
at
root.
A
We
have
to
think
which
I
mentioned
at
the
beginning,
the
fedcon
app
armor
the
capabilities
which
restrict
things
like
mounting
so
that
we
can't
mount
a
desk.
So
we
can
only
access
things
within
our
containers
and
the
author
gives
us
some
more
control.
So
if
you
win
as
trace
on
a
process,
you'll
see
all
of
the
system
cause.
That
process
is
being
made
and
I
said
that
compal
then
allow
you
or
disallow
you
to
with
system
cause
you're
meant
to
be
which
you're
allowed
to
call.
So
in
this
case
we're
allowing
open
we're
allowing
reads.
A
But
if
people
change
the
file
mods
to
our
mod
on
the
file,
then
that's
gonna
be
blocked
and
we
can
restrict
how
much
control
people
have-
and
this
is
good,
because
this
allows
us
to
restrict
system
codes
which
are
potentially
malicious
and
potentially
dangerous.
One
of
the
very
early
duck
escapes
way
back
in
2014
was
using
a
system
called
it's
basically
looping
over
every
single
inode
file
handle
in
the
system.
It
was
trying
to
get
the
file
name
and
then
once
it
had
found
a
file
which
was
looking
for
in
this
case
the
passwords
file.
A
But
we
can
start
to
discover
things
by
the
very
nature
of
containerized
systems.
The
container
is
still
winning
against
a
shared
kernel,
like
everything
on
our
system
is
still
talking
to
the
same
thing,
even
when
there
aren't
and
containers,
and
so
we
can
ask
about
things
like
uptime.
What
version
of
the
kernel
is
winning
and
like
what
CPU
or
what
disks
are
on
the
system,
and
this
allows
us
to
find
a
potentially
attack
interesting
attack,
vectors
within
the
platform
which
we've
got
access
to.
So
this
is
your
portal.
A
Until
we
can
ask
like
what
CPUs
do,
I
have
access
to
what
CPUs
is
this
container
winning
on
and
it
kindly
now
reports
all
of
the
books
that
have
been
fixed.
It
reports
that
it
didn't
have
meltdown
to
the
house
back
to
great
Microsoft,
it's
secure,
but
the
flipside.
If
we
ask
any
other
system-
and
it
doesn't
report
this
information,
we
know
that
they
are
dimmable
to
deeds,
attack
vectors
and
we
have
meltdown
and
specter
potentially
available
to
us.
A
We
can
see
information
about
where
it's
running,
so
you
can
ask
a
process
what
C
groups
have
been
applied,
and
so,
in
this
case
darker,
like
cut,
coda
and
docker
con
report,
are
you
winning
inside
of
the
container
and
if
you're,
winning
inside
cubing,
it
is
like,
which
assured
us,
they
will
say:
you're
winning,
K,
pods,
great
I
know
that
I'm
in
the
world
of
kubernetes,
and
so
now,
I
can
start
looking
at
potential.
Kubernetes
exploits
to
find
wade
into
the
system.
A
So
I
know
information
about
the
context
like
have
they
accidentally
left
a
service
account
token
on
the
environment.
Do
they
have
our
back
enabled
and
have
everything
be
restricted
because
I
know,
my
contacts
are
no
potential
attack
vectors,
but
I
also
know
about
how
that
process
has
been
deployed.
So
in
this
case
this
is
me
connecting
to
Azure
for
and
instantly
I
go
and
open
up
the
portal.
A
But
it
already
says
that
that
instance,
that
process
had
been
running
for
the
last
46
minutes,
and
so
that
means
like
either
they
have
a
pre
warm
tur
of
VMs,
winning
that
you
just
connected
to,
or
it's
potentially
a
shared
VM.
We
can
look
at
the
kernel
and
see
if
it
winnings
anything
old
and
potentially
vulnerable
in
this
case,
Microsoft
aren't,
which
is
great,
but
we
can
look
at
things
like
the
file.
A
What
file
system
options
are
available
when
discs
available
and
we
can
void
to
certain
locations
like
tests
like
the
temp
folder,
and
so
if
we
convoy
to
the
temp
folder,
that
means
that
we
can
potentially
fill
the
disk.
If
it
is
a
shared
VM,
then
that's
going
to
interrupt
everyone
else
and
that's
going
to
interfere
and
interact.
No
one
else
will
be
allowed
to
use
a
system
and
it
gets
even
more
dangerous
because
we
can
add
quotas
like
device.
A
This
is
one
of
the
things
which
Red
Hat
have
solved
and
fixed
with
Padma,
and
so,
if
you
look
and
try
and
perform
the
same
attack
vector
with
pod
man
or
container
of
winning
on
pod
man,
which
is
red,
hats,
new
container,
win
time,
then
you'll
see.
Everything
which
is
potentially
could
be
filled
is
now
stored
at
tempo
fests,
and
so,
instead
of
actually
hosts
having
access
to
all
of
the
disk,
it
only
had
access
to
a
hundred
Meg,
which
is
much
more
sensible
at
a
default
option.
A
And
finally,
we
have
things
like
fork
bombs,
and
this
is
a
great
bit
of
bash
scripting,
create
a
new
bass
function
called
:.
The
body
of
that
is
Co,
calling
the
function
:
pipe
in
the
output
to
a
function,
code,
:
and
M
releasing
control
after
the
function
has
been
defined.
It
calls
a
function
called
:
the
affected,
a
huge
resource,
consumption
of
your
system
and
the
system
load
goes
up
to
4,000.
You
have
7000
processes
winning,
and
that
is
the
last
you'll
see
of
that
box.
A
Until
you
do
a
physical,
hard,
reboot,
there's
no
processes
and
no
resources
left
on
the
system,
and
this
is
just
frustrating.
There
is
literally
no
purpose
to
it.
Apart
from
causing
disruption
and
previously,
when
doc,
with
relief,
there
wasn't
a
fix,
but
fortunately,
now
doc
worked
hard
with
the
Linux
kernel
team,
they
introduced
a
new
flag
called
pit
limit,
and
so
now
we
can
restrict
how
many
processes
people
come
fork
and
how
many
pulses
people
can
launch.
A
There's,
no
noise
api's,
we
think
even
it
is
which
you
can
say.
Please
don't
allow
a
DDoS
attack.
Can
it
just
didn't
have
that
capabilities
in
place,
so
instead,
this
is
where
we
have
to
fall
back
to
think
like
the
Berkeley
packet
filter
and
have
that
very
low-level
fine-grained
control,
which
is
an
inspection
on
every
single
packet
through
our
system
to
see
whether
it
potentially
allowed
or
not.
A
But
what
about
internal
attacks
like
we
have
potentially
an
attack
in
the
kubernetes
cluster
via
the
service
account
service
tokens
that
have
been
left
in
a
pod,
and
this
is
something
which
had
now
been
disabled
with
our
back
and
so
by
default
women's
more
secure.
But
it's
something
that
you
need
to
make
sure
that
you
have
configured
and
have
enabled
on
your
system
and
again,
this
can
all
be
thought
with
doing
things
like
network
policies
restricting
how
much
scope
a
pod
a
how
much
scope
at
container
has
and
kubernetes
have
great
api's
to
support
this.
A
So
in
this
case
restricting
who
has
access
to
our
API
and
also
restricting
who
had
access
to
the
outbound
Internet.
So
basically,
we
can
apply
this
network
policy
and
everything
within
a
default
namespace.
Now
it's
not
allowed
talk
to
the
outside
world,
though,
even
if
we
did
from
how
I
managed
to
attack
and
managed
to
find
an
exploit,
they
wouldn't
be
able
to
talk
to
the
outside.
They
wouldn't
be
able
to
launch
DDoS
or
cryptocurrency
mining,
because
the
restrict
network
it
restricted-
and
this
is
what
SEO
is
doing.
A
This
is
how
is
protecting
our
systems
and
why,
if
there
is
a
great
security
feature
to
have
and
start
building
upon,
but
all
of
this
is
irrelevant.
If
we
don't
have
visibility,
we
need
visibility
in
our
systems
to
ensure
that
people
are
paying
aware
that
people
are
attacking
us,
but
also
aware
of
what
attacks
are
potentially
learning
launching
and
so
a
great
way
to
solve.
This
is
Cystic
and
Falco
Falco
had
recently
donated
to
the
CCF.
A
Mining
solution
and
Falco
can
alert
you
on
this
post
it
into
a
flat
channel,
and
then
you
can
go
and
investigate
and
gain
visibility
into
your
security
process,
and
this
is
a
great
way
to
defect
to
protect
yourselves
to
infirmary
our
containers
secure.
Well,
fundamentally,
yes,
if
you
are
following
the
best
practices,
if
you're
following
all
of
the
right
guidelines,
containers
have
a
huge
amount
of
security
built
in
but
like
with
everything,
there
are
gaps.
There
are
gaps
in
the
system
which,
like,
if
you
don't
accompany
you,
maybe
the
mobile
too.
A
So
hopefully,
things
like
the
network
in
our
discuss
will
give
you
insights
in
how
to
protect
it.
But
at
the
end
of
the
day,
Nitin
is
secure,
like
VMS
are
an
a
secure
approach.
This
is
a
beautiful
attack
which
the
attackers
could
break
out
of
a
VM
just
by
attacking
the
floppy
disk
driver,
which
is
exactly
what
you
need
when
you're
winning
a
huge
cloud-based
platform.
A
So
it's
dangerous
but
like
this
is
what
we've
been
doing
for
the
last
three
years
in
cat
coda,
but
as
a
community
and
as
a
technology
community
we've
been
doing
it
for
the
last
20
years.
So
we
know
security
is
always
a
risk.
We
just
need
to
make
sure
that
we're
applying
the
things
we
need
to
to
make
sure
that
we're
as
secure
as
possible
at
this
point
in
time.
So
here
with
some
quick,
wins,
I'd
recommend
if
we,
if
you
can
don't
win
as
route.
Sadly
this
isn't
the
case
for
cats
coda.
A
We
want
that,
but
normal
everyday
production
systems
shouldn't
be
running
processes
as
wheat.
If
you
can
make
the
file
system
read-only
make
sure
that
no
one
can
actually
write
to
disk
because
then,
if
they
can't
like
this,
they
can't
download
additional
binaries,
which
means
they
can't
launch
them
in
the
first
place,
keeps
you
much
more
secure
if
you
can
again
block
egress
block
all
of
the
outbound
traffic,
because
why
do
you
need
it?
A
If
you've
got
good
CI
process
and
your
image
had
being
built
and
then
deployed,
it
should
never
change,
which
means
it
should
never
need
to
talk
to
the
outside
world.
Apart
from
a
few
30
api's,
and
that's
where
things
like
network
policy
is
and
a
service
metal
sto
can
help
control
that
it
can
help
give
you
those
flexibilities
and
EAP
ice
and
make
that
easy
to
manage
without
having
to
resort
to
IP
tables.
But,
fundamentally
you
need
visibility.
A
You
need
to
create
visibility,
to
see
what's
happening
within
your
system
and
see
any
potential
attacks
which
may
be
happening.
That
is
why,
if
you're
just
blind
to
what's
happening
in
the
system
and
with
that
I
hope
you
get
gain
something.
Thank
you
David
for
listening.
If
you
have
any
questions,
please
always
tweet
me
or
email
me
at
Catco
to
calm
and
go
explore
and
have
fun
on
the
platform
and
see
what
you
can
learn.
Thank
you.