We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Kapow! A Web Framework for the Shell

00:00

Formal Metadata

Title
Kapow! A Web Framework for the Shell
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
This talk is about "Kapow!" an open source webframework for the shell developed by BBVA Innovation Labs. We will talk about the current development of the project including an overview of Kapow!'s technology stack and the recent release of the first stable version. The motivation behind the project was to create an adapter between the shell and the web. Allowing users to expose command line programs as HTTP services with a high degree of freedom and flexibility, not imposing any predefined behavior. The project is based on an open specification. Kapow! supports an increasing list of HTTP features; including forms, websockets and streaming. The architecture is based on exposing a private REST API through which the shell can interact with the incoming user HTTP requests. Leveraging this architecture an ecosystem of specialized tools is planned, to help with common high level tasks in Kapow! services. For example: - Shell commands that can interact with incoming web browser requests and render specialized web pages. - Automatic mapping of shell command parameters to REST API through bash completion scripts. Roberto will do some demos about creating Kapow! services from scratch (expose nmap as a service, tcpdump and pandoc).
Software frameworkGastropod shellRight angleComputer animation
Computer networkLine (geometry)Computer fileSoftwareWeb 2.0Internet der DingeFormal languageCASE <Informatik>Group actionMilitary baseWeb serviceComputer animation
Line (geometry)Computer networkThomas BayesDependent and independent variablesInteractive televisionWeb serviceGastropod shellWeb 2.0Goodness of fitFunction (mathematics)Computer animation
Computer networkLine (geometry)Computer-generated imageryServer (computing)Function (mathematics)Streaming mediaTesselationRootoutputIntegrated development environmentFile formatGastropod shellTransformation (genetics)Generic programmingSoftware
Line (geometry)Computer networkGeneric programmingAreaFormal languageNatural languageInformationImplementationTransformation (genetics)Engineering drawing
Line (geometry)Computer networkGeneric programmingGeneric programmingEngineering drawing
Computer networkLine (geometry)Server (computing)Gastropod shellMereologyLimit (category theory)Cellular automaton
Computer networkInterface (computing)ImplementationComputer animation
WeightSoftwareDemo (music)
Operator (mathematics)Suite (music)Self-organizationIntranetComputer networkInsertion lossSoftwareDatabaseInternetworkingData managementComputer animation
Server (computing)Process (computing)Menu (computing)StatisticsDependent and independent variablesRead-only memoryMiniDiscPhysical systemData typeContent (media)Dependent and independent variablesPhysical systemServer (computing)Scripting languageRoutingMultiplication signComa BerenicesInteractive televisionPower (physics)InformationProcess (computing)Function (mathematics)Type theoryCellular automatonBefehlsprozessorSource code
Execution unitGroup actionCycle (graph theory)Video gameProcess (computing)Interface (computing)User interfaceState observerSuite (music)Real-time operating systemCellular automatonDependent and independent variablesRight angleServer (computing)Scripting languageComputer animation
Operator (mathematics)Software developerWechselseitige InformationWindowSoftware developerComputer animation
VaporContent (media)Observational studyWindowServer (computing)Dependent and independent variablesLine (geometry)Form (programming)Interactive televisionComputer virusFunction (mathematics)Multiplication signComputer fileAntivirus softwareBus (computing)Operating systemSource code
Arrow of timeVaporPort scannerMoment (mathematics)Computer clusterServer (computing)Antivirus softwareSource codeComputer animation
Port scannerInformation securityPower (physics)Computer animation
Operator (mathematics)Software developerInformation securityComputer networkSoftwareSensitivity analysisNumberLaptopWebsiteBitSpring (hydrology)Streaming mediaComputer animation
Server (computing)Computer networkDependent and independent variablesRange (statistics)Server (computing)Source codeComputer animation
Computer networkServer (computing)Integrated development environmentPasswordWordCore dumpComputer animation
Run time (program lifecycle phase)PasswordCycle (graph theory)Video gameComputer-generated imageryInformationQuery languageStandard deviationFrame problemMotion captureRevision controlIPClient (computing)Dependent and independent variablesInternetworkingSoftwareCellular automatonSource codeComputer animation
Computer networkLine (geometry)Speech synthesisPerfect groupGastropod shellSoftwareOpen source
Distribution (mathematics)Computing platformMultiplicationArchitectureSoftware developerLattice (order)Binary codeMultiplication signSingle-precision floating-point formatObservational studyOnline helpSoftware developerSoftware testingComputer architectureFlow separationShared memoryProjective planeComputer animation
Point cloudOpen source
Transcript: English(auto-generated)
Okay, everybody. It looks like Roberto Martinez is about ready. Can you all please take your seats and let him get started. He's going to be talking about Kapow. I'm going to hit the button right now. All right. It's all you.
Hello, everybody. I'm here to speak about Kapow. Let's begin. So, first of all, there are two separate worlds. On the left, we have the network world, which inhabitants are web services, browsers, IoT devices, you name it. And they speak with
several languages, but the main one is HTTP. The other world is the command-line world. The citizens are the commands, files, file descriptors, and they communicate through
pipes and redirections. So, how we communicate these two worlds together? From the command-line world to the network, it's very easy because we have a lot of very good tools like cURL, WGate, HTTP, you name it. Those tools can perform HTTP requests to web services, for
example, and output their responses to the shell and interact with them very easily. The other way around is more complicated because we have a lot of options, but none
is very good. We have, for example, the CGA approach in which we have a CGA server that can receive an HTTP request and make some transformation. First of all, the CGA server
pollutes our shell environment with HTTP data and predates the standard input and the output streams with HTTP data also. This is not my favorite approach because the commands that we are trying to interface with the network have to know how to deal
with the HTTP request. Another approach is the so-called generic adapter approach in which we receive some HTTP request and our generic adapter makes some specific
transformation which is particular to its implementation and call a command with the data. This is very similar to the CGA approach, but it's particular to the adapter that we are using. Another approach is to use a custom adapter.
Maybe if it's not possible to use a generic adapter because it's not suitable for a command, we can use our favorite language and make an HTTP server and when the server receives
an HTTP request, it can execute our command passing the data and everything is hunky-dory. But this has some limitations because the command that we are interfacing is not part of the shell and it's very difficult to interact with other commands without modifying
our custom adapter. The last one and the saddest one is just keep up and make a new implementation of our command with an HTTP interface. But you know, we are losing decades of experience in command line commands.
So isn't there a better way to interface the network world and the command line world? Just there is and I'm going to show you. So let's see some demos.
So first, consider this scenario. We have an internal host that maybe is our database or a printer or something that is in an internal network and we have users on the internet that need to know if the device is up or if the device is down. How we
do this? Any clue? So the first that came to mind is SSH into the external host that we have and just ping the device. No? But this has some problems
because we have to manage SSH accounts in the external host and maybe it's not very secure. Another way is using kapow. Can you see this? So the first thing that we
have to do is start the kapow server. This enables an HTTP server in the host and now we have this file, ping.pow, that is not a scary, it's just a cell script in which we are using another kapow subcommand, kapow root, to instruct the kapow server
to add HTTP endpoint that when called will execute this cell script. In this cell script we are just executing the ping command with just one ping to our server, internal server,
and we are redirecting the output of the ping command to another kapow subcommand, which is the kapow set command that interacts with the incoming request and set the response
body to the data that is passed along. So we execute the script, now kapow knows how to deal with the ping endpoint, and if we execute a call, it just works. What can we do now?
Well, we have a lot of tools in the system to give more information to our users, so maybe it's time to make a nice API to let them inspect things that they are not
capable of. For example, which processes are running in our server, or maybe what type of CPU we have, anything that they need to know and they can't know because
they are in another host. We execute the script again, and that's it. So what just happened?
A kapow server works like this. We have the kapow process which has two interfaces, a public interface which interacts with the user, and a private interface that interacts with the cell. When a request from the user arrives to the user interface,
a cell process is spawned, and in that cell process maybe a script is executing some kapow set commands that interact with the internal data interface. This is interacting
in real time with the HTTP request that comes from the user. So in this example, kapow set response body banana is setting a banana in the user response. Let's see another example. Kapow is also very useful for developers. I don't know if you have to work with Windows,
I don't recommend it, but kapow is also available for Windows. And then here using kapow for Windows from SQL, which is a bus implementation, but because kapow interacts with a cell,
you don't have to use it with a bus. You can use it with the Windows command line if you want to, but I don't recommend either. And here we are creating an endpoint in the kapow server
to use the Windows antivirus software that comes with the operating system to scan a file that the user is uploading through a form. We are storing the file,
we are using the antivirus to scan it. We are formatting the output and finally giving the output to the HTTP response. So we launch this, now kapow is running,
and now from my Linux environment, I can upload a clean executable. And the kapow server is using the antivirus software to scan it. There is no threads,
but if we use a virus, upload the virus, yay, it works. Finally, kapow is very useful for security teams, too. Because, for example, if you have a network with sensitive data,
you don't want to give access to that network to maybe to auditors or pentester in some situation. So kapow can be very useful to convert or transform the pentester tools to APIs that can
be deployed inside those sensitive networks and use it from the side. In this example, I am using kapow to create an API that uses the TCP-DAM software to scan the network on my
laptop, sorry to sniff the packets from the network of my laptop, and create a stream, HTTP stream that can be used somewhere else. I'm using sudo here because I'm lazy and not
properly configured. So now the server is ready and we can use for another host
a simple curl and a byte with a word shark. If we use something from the internet, here we are
making a sniffing a network through an HTTP API. So finally, what's the kapow approach? The kapow approach is sitting in between those two worlds and speaking perfect HTTP
with the network world and speaking perfect shell with the command line world. This way, we can interact more seamlessly. Kapow is distributed, first of all, it's an open-source project. It's distributed at a single study binary so you can start without any dependencies.
It's multi-platform. We distribute it for Linux, Windows, and Mac and it's available for several architectures. It's well documented and it's tested.
But we need your help because we need users. So please, if you like what you've seen, try kapow. Give us a star on GitHub, please. Share with a friend or with somebody that maybe likes it. And join us. We need said users, developers, and so on. And that's it. Thank you.