Yeah, then hello everyone, so we would like to start.
Okay, yeah, so today's topic is testing IP tables firewall rules with Skeppy,
comply with the cybersecurity requirements from the UNECR 155.
Okay, turning the on button helps.
So yeah, first of all our agenda, so first of all we want to introduce ourselves
and also our employee shortly.
Then we want to ask the question, why test your firewall rules?
Afterwards we want to talk a bit about the basics of the net filter subsystem
and IP tables.
Then we will show you why we choose Skeppy as a tool to test the firewall rules
and we'll also show shortly the tool landscape that is out there.
After that we will now for over 10 years.
ElectroBit offers the EB Corpus Linux distribution based on the Yachto project,
but nowadays we have now also version based on Ubuntu
and we are cybersecurity management system compliant.
So now coming to the question, why should we test our firewall rules?
Well, the answer is basically in our case, well, we had cybersecurity requirements
for our embedded Linux distributions and for the automotive industry.
This means complying to an Air 155 which is demanding that you basically take care
about the cybersecurity for the software that goes into your car
and starting in just some few months all new vehicle registrations,
so vehicles that are new in the market will need to comply with that
and as we are working for building distributions for such cars,
well, we basically also needed to certify and test our firewall rules to sum it up.
So what is the overall situation?
Okay, we have a packet filter and this inspects our traffic in the networking stack.
Of course we have different use cases for using this packet filter
like the firewall, traffic statistics are locking
and in our case we have a net filter in the corner space
and for user space because the project was already going on for several years.
We actually have IP tables still and not NF tables, so that's our overall setup.
And just that much about that.
Okay, I think it's forward.
Output and post routing and then the egress
and yeah, that's just to give you an overview how the net filter looks in general.
So and IP6 tables, then a user space program,
I think you all know it but just to repeat it
and so that we are on the same page and to interact with the net filter.
It is organized in tables like the filter nut and mangle table you see here.
A table then consists of a change which basically again consisting of a list of rules
which can match a set of packets and a rule that specifies
okay, what to do with a packet that matches.
You can say for example, I'll drop it, I return to somewhere else,
I accept the packet or some user defined action
and if the packet doesn't match then the next rule in the chain will get executed.
So as I've already said, that is going to anywhere that is not sent itself
is then sent to the Docker isolation stage two
and otherwise we are returning and in the Docker isolation stage two
we are dropping every traffic that is going to the Docker zero interface
and also returning and therefore we are back at the original state there and yeah.
Yeah, so now I want to give a short overview over the tool landscape
but I will only highlight why we choose GAPI because we only got 25 minutes.
So yeah, I think here you can see the most common tools
that are able to create custom network packets
so CUT, Nemesis, NetCut and GAPI and I think there are many more out there.
They all have their pros and cons but I want to go now a bit into detail
why we choose GAPI.
Yeah, so why GAPI?
So it's a Python based interactive packet manipulating library
so Python is very common, I think everyone knows this
and it has a very low barrier to get into.
Yeah, with GAPI you can define send, receive, complete, custom packets
and you can manipulate across different layers very easily
so on the slide you can see link, network and transport layer
so it's very easy to create their custom packets
because the barrier is very low and you have a very easy entry
to create your first custom packets with it and send them and receive them
and have some highlights.
Yeah, and what was also a reason that we choose it,
we have already in the integration department running Intest framework
that is completely Python based.
So we needed to look that we choose some Python based solution.
So how do we test the system?
So we have the ingressing path and send then a packet to the application layer
as you can see there and then we have also the egressing path
where we send packets from the application layer then to the egressing path
so in our demo version we will provide a show later.
We use KEMU and send packets from the host to KEMU and from KEMU back
and one additional thing, so GAPI has its own network stack
so that runs beside for example the net filter
so you have to also keep in mind.
So we have here some basic examples to show you how easy it is
to craft your first custom network packet.
You see here the first example is just a TCP packet with destination port 80
and the flag as is set and as you can see this one liner,
when you copy this into your GAPI console is your first packet
and then you just have to send it to a specific interface or address whatever.
So this is as easy as it is.
So the second example is a bit more advanced.
There you can see that you can also use random IPs with various other options
here for the UDP protocol and it's very easy to understand what is happening
I think or from my point of view so it's good.
The other example we have is an ICMP package.
So we just have here on destination IP that also works
and then the ICMP protocol with type 3 and code 0.
SCAPI also provides ready solutions so that for example
for the NAVA discovery with IPVs.
Rule here TCP, okay that we got covered then we have a certain port
that we can also easily specify and then we have time to live of 8 here
though that's also just setting the parameter here for the IP packet
and finally we also are interested in certain flags.
So here we are using for example SYNFLAG here once
and then we have already our fitting packet and we can just send it.
Here we are sending it just easily out with SCAPI.
We can then on the other side SNF for it for example we take a look
okay what is arriving at PC at p port 1 2 3 4 and then we can just take okay
well those packet and the flags did match so it should be accepted
by the firewall and otherwise okay well the flags didn't match
and so it should be rejected.
Or to have a different example here we see a firewall rule
for the source that should match in the input chain on the source IP
so okay again just put it into the packet then we have
a certain destination port again with TCP so we are just crafting
our packet again in SCAPI as planned and then we are just again sending it
we can again just SNF on the other side with SCAPI and check okay
whatever is arriving on ETH0 now we can also have a filter in our
SNF function specified so we check okay is it TCP is the source
as expected and then we are waiting okay we are waiting for one packet here
and if this packet is there we are executing the packet to check function
and okay we are checking here for the port if the port is correct
and already SNF on the correct interface and check the IP address
and if we are on if we are received a TCP packet on the filter already
so it would match then the firewall rule and we can say okay it should be accepted
or if the port is not matching I don't know it would be 23 then it should be rejected
and here one last example it's basically again the same situation
we are crafting a ficking packet with TCP and port 100 here and then we are
again considering the interface here and also of course our IP address
I think you can see it very well from the arrows and then you can just send it out here
and again the other sub basically looks as known we are sniffing on the end
in the TAP0 interface this is well motivated by our QIMO setup
then checking the filter again some sanities executing a function again
still checking the port and if this matches then already it should be all accepted by the firewall
and otherwise it should be rechecked and I think we now have time for a demo
yes so please
yeah so as you can see now on the screen hopefully it's visible for everyone good I don't know
yeah
yeah so yeah you can see on the on the right window you can see the QIMO that is running
we already loaded the firewall rules we want to test and now I would start the sniffing
so that we can do the ingrass thing test and
yeah
in the in the IP table
fields are have gone up so everything worked fine on the on the ingrass path so now we can also
show the other way around
yeah
yeah I think so we can stop the demo I have I think I have some some mistake in one of the rules
so now I'm not allowed to send a packet this is the output packet we showed before that gets redirected
yeah sorry for that but if you go to the slide deck you can see you have can see here the demo
so it's a link to the GitHub repo where we have also stored everything with a read me
then you can see can test it on your own and if you want to extend something or yeah
so yeah then we are already at the end of our talk so as a summary so you now know why you should test your
firewall rules so it's yeah not only regarding to the UN our UN EC are 155 yeah you get some
overview over the net filter IP tables we showed you bit the lens very short overview of the landscape
and why our solution was skeppy yeah you hopefully get some basic insights how you can use skeppy for your
test cases hopefully and yeah also you saw that you can test IP tables with firewall rules if the if
everything is set up right so yeah with that we want to thank you for your attention and if you have any further
questions then please feel free to ask now or you can also see our contact informations on the slide yeah
thanks also from my side sorry about the screwed up demo I promise on give that it's fixed if not we are fixing it
today still so questions hi great presentation thank you so I searched occasionally over the last several years
for something that can simulate IP tables rules without needing a full network stack since for example the IP
tables save utility can dump entire IP tables configurations and the syntax seems simple enough is there something
non-obvious that prevents us from simulating rules entirely in memory without the need for a full network stack
sockets ton tap devices or virtualization I think I cannot fully answer your questions so I would say from
the perspective we have why we test the firewall rules so we our test case what was that we wanted to test our
the firewall rules we have in our system so the showcase we had here in the in our company we are running the
in tests directly on our target on the hardware because we want to know how the behavior is directly on the system with
the complete firewall config loaded so that we can ensure everything we have in our case we have requirements and we need to
test if the requirements are fulfilled in the in the firewall we have in the system and so
yeah that's true and yes kept the supports fast testing and we are aware of it and yeah so the basic answer is yes and how
you of course say okay I want to have a focus on passing there or there I mean it's not to be generalized because it of
course depends on the concrete firewall the concrete user cases you want to cover but yes kept the supports it so that's
also a great part of it I would say and I was that I think we can thank you and we are now directly on time so sorry but please
have a nice day have a great post