 So, first of all, let me get this out of the way. My name is Jeffrey. I'm not giving you my last name. I do work in the intelligence community. No, you can't spot me anymore. It's too late. Too obvious. And I have actually been required to provide you guys with this disclaimer. Everything that I put out here as to my solution for protecting these internet-enabled alarm system monitoring panels is not to be considered officially sanctioned policy by the United States government. It's only my particular solution in areas where facilities that I actually am responsible for. And so any issues you have with it, come yell at me. Don't yell at any of the feds. It's not their fault. OK, basically what we're here to discuss is alarm systems in general. And more specifically, issues involved with monitoring the status of the alarm systems and issues in protecting those alarm monitoring pieces, the hardware that is used to do that. Essentially, there are really, essentially, two, maybe three types of alarms. Most people associate when they talk about an alarm system, most people associate that with either a fire alarm, which basically detects smoke or fire in a facility, and then alerts the authorities or inhabits the area to the problem. And then more commonly, which is both residential and commercial, burglar alarms, which essentially do the same thing except without fire. Quite often, you'll find both types of alarms in one facility. And burglar alarms are basically the same thing. They detect unauthorized intrusion into your facility and then alert whoever the appropriate individual is to the situation. OK. Excuse me? What about moisture? Moisture? None of that. Well, I don't know. By the way, there's an individual up front who's a friend of mine who actually does a lot of physical security. I do more network security aside, but so occasionally, I will defer to him on that. Are you aware of any sensors that actually are designed for moisture? Would that be in the safety systems more than the burglar or fire? You want to come on up here or make it easier? Come on up, Lass. Come on up, come on up. No, you're not officially speaking. OK. My caveat would be, I don't deal with the moisture was because, frankly, all my stuff is in these lovely nice, as you've heard from our lovely vice president, Man's Eye Saves. So if they get flooded, I don't care as long as they don't float out the window and you get what's in them. Plus, he's never gotten a woman moist in his life. Must have laughed a little bit. So anyway, you can go ahead and then. There are sensors for everything. Moisture, heat, biochem sensors, air quality sensors. There's sensors for everything. Alarms and alarm, the control panels are the panels and he'll go into more of that. But the sensors are absolutely everything out there. OK. Basically, this is the anatomy of a burglar alarm, which is the most common alarm I have to deal with in my facilities, because I really, again, I don't care if the things blow up, burn up, or get completely moistened as long as you don't get what's on them. So all I care about is if you're coming in there and looking around. In the basic topology of a burglar alarm is you have a central panel that controls all the signals. And everything else is basically a seemingly spoken wheel topology with all the sensors lying on the outer sides. And there are multiple types of sensors. Most businesses will usually use one, maybe two of the types of sensors in areas that they care about. Military installations and some businesses that actually make a lot of money and are really paranoid. We use multiple sensors in an area to protect it. Generally, my facilities, every door has a balanced magnetic trigger on it. Every room has IR sensors that are set up to optimally monitor the room. And if, for some Godforsaken reason, the area has a window, we put glass breaks. And then the last piece of the puzzle is what the main item of my talk is about is monitoring the actual status of the alarm system. So in addition to the sensors and the main panel, you have the monitoring hardware connected. All right. This is basically, in my opinion, the de-evolution of alarm system monitoring hardware. Many, many years ago, excuse me. And if you can't hear me, let me know, and I'll speak up. When it first began, not that many people used alarms, because they're very expensive. So you either had a lot of money, like you were the government, or a really big business, and you really, really cared, because you were willing to pay out lots of money to monitor your alarm system. And the way it was done was generally dry copper hair pulled into your facility. Otherwise known as a T1. And they worked lovely. They're dedicated lines solely for your use, but they're extremely expensive. However, the reason I titled the slide de-evolution is, from a security standpoint, that's probably the most trivial thing to protect, because all you've got to do is harden your DMARC and anything beyond the phone switches is out of your control anyway. And you're not going to be the only one affected really. So that's pretty easy to protect. You just harden your lease line, harden your DMARC, and it's almost solely a fiscal security issue. Along the lines, after a few years, the alarm companies realized that most of the people that were using alarms at that time all had pots, plain old telephone service lines in their facility. So they began using the ubiquitous pots lines as they're monitoring data communication channel, because it was common. It wasn't something they had to specifically bring into the facility, because it was almost always there. And it's very cheap. What, was it about the 80s they moved to RF and cellular? Yeah, around the 80s, they discovered that while it was easier to take some of the expense of maintaining pots lines or requiring pots lines and move it over into cellular and radio backup systems, which then all they had to do is either maintain the towers and things like that, or outsource to somebody else like Sprint or whoever, and they had to maintain the infrastructure. The problem with that is, well, it's not that it's difficult to secure, it's just out of your hands. And you are subject to any outages on this other person's infrastructure. So a lot of the quality of service and stuff is now out of your hands. However, you have less to secure at your facility. And then, long about mid to late 90s and now, basically most alarm systems, especially new ones that are getting installed, the alarm companies aren't offering you, in general they're not offering you cellular backups. They're pushing the internet-enabled monitoring hardware. Reason being, because there's very little, there's very little infrastructure they have to maintain with that. And frankly, they say, well, everybody, everybody we deal with, whether it be you at your home or you at your business, we've all got broadband access at this point, so why not make use of it? And all they have to do is maintain a receiver station at their facility. And they put this client panel in on your system and call it a day. And it should be obvious to a lot of people here why I and quite a few people actually consider this a bad idea, because now quality of service, the quality of your internet connection becomes highly important. I mean, if you've got a lot of people that are playing online games on your network, now your alarm system as status packets have to compete with that traffic. And you begin to start getting a lot of false positives when you start getting your network flooded. Basically, there are quite a few of the internet-enabled alarm hardware, but two of the examples that I'm familiar with and that are most commonly deployed are ones made by a company called DMP, which basically makes a lot of that, DMP or a DEMCO. And they basically make a majority of the sensors that are deployed in alarm systems. They make a product that's called the ICOM or the ICOM-E. The only difference between ICOM and ICOM-E is ICOM-E, they added an AES encryption engine onto it. So frankly, if you have the option of getting ICOM or ICOM-E, they're not that much, they're not that different in cost, and one of them is going unencrypted. And the other major, the other more common one is a product called AlarmNet. The specific, well, there's a whole series of alarm data monitoring hardware under the AlarmNet name. This particular one is the AlarmNet I, which is for internet, or the common reference, the model number for it with Honeywell is 7845 I. And these are basically the two most common that if you're deploying a new alarm system, these are probably the two that you're going to be asked to choose from. Yes, yes, actually both of them do. In fact, the AlarmNet one, you don't have to choose whether you want unencrypted or encrypted. The AlarmNet product actually, by default, comes with encryption, and what's actually, I find kind of nice about it, is you get to choose which algorithm you want. And I'll get to it in a little while, but the DMP only uses AES, and the AlarmNet lets you choose, in depth, to one of the keynote speakers here, Blowfish or AES. In fact, I think the AlarmNet defaults to Blowfish, so you actually have to change the option to move it to AES. Some of us don't have a choice. OK, basically the DMP product, you have a choice between either UDP or TCP for your reporting traffic. It defaults to UDP, so if you want a little bit of a transaction integrity with TCP, you have to change the option to tell it you want TCP. The port is configurable on it. However, the default for the factory is port 201, and frankly, let's be honest, how often do you think the install tech bothers to change any of the factory defaults unless you actually insist? So this will come into play later when we discuss actually snarling around on your network to try and find these things, just because you're curious. Now, one of the things I find interesting about it is it also uses, if you choose AES, the AES key is 128-bit, which I find disappointing because the AlarmNet, when you deploy the AlarmNet one, the key is actually a 256-bit, which since the overhead isn't that big these days and embedded equipment is fairly, you know, resource, fairly well done. A 256-bit AES key is not really going to be too much trouble for it to use, so why didn't they bother using the largest key size? I don't know. One thing that's interesting is that the DMP guys, if you actually read their little marketing stuff, they tout all their lovely security features on there. And some of them, for people who are in this community who actually attend DEFCON at least once, maybe more than once, having a bit of a clue, you'll actually find some of the reasoning fairly laughable. And the sad point is this is not their sale stuff. Basically, this is the install text information. I got it because I shoulder-served my tech and when he left all this stuff, I kept it. So basically, one of the things that they touted as being a security feature is the fact that their communication protocol is proprietary and writes on top of TCPIP. And yeah, nobody's ever figured out a proprietary protocol, have they? And actually, even worse than that, I will read you the application note for the tech that is what they are told to spout back to you when you ask about the security features. The really sad part is this last little bit, and I'll read it off, it's a little long, but I'll read it off because I think some people at least get a kick out of it, especially here considering what's taking place at this DEFCON. Furthermore, it would be extremely difficult for a hacker to break into a panel or central station receiver through the network monitoring connection because several pieces of unfamiliar information are required to gain access. A potential hacker would have to know all of the following information, account number. Now, account number, OK, granted, I can understand how they think that's a problem. But generally, all of us who have alarm systems, everybody gets a little card. And guess what's on the top of that card, the account number, because hey, when you screw up and you actually have to talk to the data monitoring people and go, yeah, I know I set off the alarm, but I'm really supposed to be allowed to be here. First thing they ask you is, read off the alarm account number on your card, please. So all you've got to do is go to somebody's desk while you're wandering around pretending to be a delivery boy or whatever, and take the pushpin alarm account card off their corkboard with you, Xerox it, put it back, now you go to the account number. The next one is IP address. And I'm sure nobody here knows how to use Nmap and figure out what IPs are available on the network. And then in addition to that, they say the port number used by the system, and as I discussed previously, granted, the port is configurable. But it defaults to 2001, and what do you want to bet? They didn't change it. So all you got to do is go map the network. For anything on port 201, 2001, you probably found the alarm net. But beyond that, they actually have one semi valid, which is panel secret remote key, which is basically the shared secret that they use. I can tell you from my own experience, having shoulder surfed install at several of my facilities, in more than one state, as a matter of fact. The shared secret is only eight characters, and I didn't actually just breathe over a shoulder, but it looked to me as if it's the same one everywhere. And then the last one is their lovely feeling that their proprietary communication protocol running a top TCP IP is actually going to save you. So good luck. But the point I wanted to make actually in my talk is they're talking about access to the system. And frankly, I can tell you from my perspective, dealing in highly classified security environments, I don't really care to get access to your system. If I can disrupt it, I can make it useless. As long as I make your alarm system useless, you're not going to look at what I'm doing anywhere else. You're going to pay attention to all the phone calls coming in from Honeywell or ADT. You're going to pay attention to all the people complaining that they're getting alerts from the alarm system, and you're not going to pay attention to anything else. OK, and now a little bit about the alarm net one. It only uses TCP, so you don't have a nice little default there. You don't have to bother deciding whether or not UDP or TCP is good. And one point that I forgot to mention earlier and make earlier is that what we're talking about here is you've got guys who normally don't do network stuff. These guys, as far as they're concerned, the computer is that thing that plays solitaire for them all day. So asking them whether or not they want to use UDP or TCP is meaningless to them. They don't know whether one is better than the other. So they'll just go, whatever you think is good, go ahead. And so naturally, the tech's going to just leave it at the default. Now, the Honeywell on the downside, the port is not configurable. So there's your big tip on if you want to find one of the Honeywells. Anything running on port 54109, TCP, you probably found one. And in a second, I'll tell you, you can see at the bottom if you in-map it, if you've got a node on your network and it responds in some way on 54109, TCP. And you see in the in-map scan that the network adapter is identified as a DEMCO, Bingo. You know definitively that's an AlarmNet i device. Now the nice thing, as I mentioned earlier about the AlarmNet i, is you actually get to choose which encryption protocol you use. And if you're a general business or even residential, this is actually not specific to just businesses and military and all that. They're actually starting to deploy these and residential too, which is another point that I wanted to make in this talk, is that how many people out in suburbia are actually going to care about all this stuff? They're not. They're frankly, and all the DMP stuff and the AlarmNet stuff, they don't actually insist that you segregate this from the net at all. Their feeling is it's perfectly fine to stick this straight on the net. Because hey, nobody ever probes things on the net, do they? So you actually have a choice. It defaults to blowfish. Frankly, I love blowfish. I'd be more than happy to use blowfish. AES is actually a very good algorithm for my purposes and for anybody here that actually deals in facilities that have that nasty acronym SKIF. You have no choice. You have to use AES. The reason you do is because AES is UL2040 certified. And you cannot, in a SKIF or any other classified military environment, you cannot use any algorithm that's not. It's been UL2040 certified. So you have no choice but to default to AES. And then, of course, both of the monitoring panels will default back to a plain old telephone service dialer. And that's their backup method. If they can't communicate over the network because you flooded it or whatever's happened, the router's down or whatever, then they will flip over to the alternative, which is the dialer, which we'll call the central station. But basically, what the dialers do is they dial the central station, then they hang up. The central station calls back in and checks the status and all that. And again, this goes back to people who deal with SKIF. You don't have this option. I'll explain that in a little bit. OK, this is some of the characteristics. Some of this is I've already gone over. But basically, the DMP runs on port 2001. It is configurable, but generally you're going to find nobody ever changes it. Defaults to UDP, the reporting central station is a piece of hardware known as a CSC1R. And in DMP at Demco's favor, I will actually say that it's not easy to get a hold of their equipment. Unfortunately, it's not quite the same with the AlarmNet I equipment, which will play into disruption and attacks in areas later. And then with the AlarmNet, it defaults to, well, you have no choice, it uses TCP port 54109. And then it reports to an AlarmNet product called the 7810 IR. And what I found is, doing a little looking around, you can actually go on eBay and for $100, you can buy the reporting note. And as I mentioned, this actually will play a key part in attack and disruption scenarios later in the talk. One of the other amusing things about the DMP product in their extremely secure product, one of the defaults is you can configure the entire panel across the land with Telnet. Yeah. Now, the AlarmNet, as I said, reports to a 7810 IR. Now, the nice thing about the AlarmNet is you can't actually configure it over the network. It takes effort to, and a little bit of extra hardware to actually make it network accessible. The default way for configuration on the AlarmNet product is the AlarmNet device. It's an RS232 handheld configuration panel. And the device is called the 7720P. So, OK, now it's wonderful, because you think, OK, well, I can only configure it with this one device. But guess what? Go back to our friend eBay, you can buy one for $30. So basically, now the DMP product, as I mentioned, they're very, very careful about accessing it. You have to be a valid, verified vendor before they'll even sell it to you. So the chances that you're going to be able to go out and get it are much, much less. However, I'm sure if you go talk to Kevin Mendecki, it'll probably be happy to help you do a little social engineering and pretend you're a vendor. OK, now, basically, this is some really sanitized traffic, just to give you guys an idea of what the traffic looks like, so you can see what it looks like. And then you can see what it looks like. And we have actually noticed that there are indeed certain patterns that show up, both in the window sizes and in the sequence numbers. And there's not enough here to actually see the patterns. But at the end of the talk, I have actually set up a wiki for anybody who's interested in joining a few of us that are working on playing with these things and seeing what we can find out about them. And we actually have extensive traffic captures up there, so you're welcome to download and fire up TCP dump or Wireshark, read them in, and go look at them. And you will start to notice there are a lot of patterns in there. So our main goal is to basically reverse engineer the proprietary communication protocol, just to point out that there are a lot of patterns just to point out to them that that's not a security feature and please do something about it. And I'm also trying to, as I'll mention later, we're also trying to talk to them about other scenarios for trying to at least mitigate some of these issues. But yeah, this is basically what if you see traffic along these lines. And you'll notice they do definitely repeat. You get the normal TCP traffic with a little bit of a twist because you get the send coming back with a send act, and then you get the act. But then you get a push act and a push act back and a reset. And that's it. That's all you get. There's no act coming back for the client ever. And it just starts over. And it's really odd. And we've noticed that some of the Windows links today. And looking at the actual payloads on the things if you pull down the traffic captures that we have up on our Wiki, you'll notice that the payloads actually have certain areas that never change. So we're fairly certain that we have an idea of what they're using for an IV for their keys, too. Which also led us to believe that, frankly, all the shared secrets that they're putting in are probably the same everywhere. And then here's the example of traffic out of the DMP icon me. And again, you can actually notice that some of the traffic patterns, there are certain patterns that do show up in the traffic. And it's very similar to the other one, although you actually do see in the DMP product that somebody there must have read TCP IP Illustrator at some point because they understood that you should send a phone at the end. So they actually do halfway close the connection. All right, now this is really what I wanted to stress here is what are the considerations you have to take into account when your system, you're deploying into an alarm system and you're being told you're gonna monitor it via the net. And basically at this point, quality of service on your network becomes of the utmost important. And frankly, I do deal with firewalls, routers, and I personally am not really good with QoS. I mean, I can make it work, but it takes a long time. I know a few people are really good with QoS, but I'm not one of them. And one of the chances that most of the people that work in the physical security side are too, which leads to yet another issue that I'll address later. Now, as I mentioned earlier, if you're in a classified environment, specifically one that is covered by the security rules set forth in DCID6 slash nine, and most of the fans will be happy to explain to you what that is. It's basically, it's a director central of dollars directive that tells you what security criteria you must meet to protect an SCI facility. And one of the things in the NXB that I've denoted there is that you cannot have two-way communication to your alarm system. So guess what? That nice little lovely backup dialer? You're not allowed to have it. Why? Because the system, when the backup dialer calls into the station, the station will call back to you. At that point, the station can actually check all your sensors and everything. And if somebody on your end tells the station to initiate a configuration modification, they can upload your entire configuration out of your site, mod it, and have it re-downloaded to your system. I.e. they can change the access restrictions that are applied to certain accounts. They can add no accounts. They can delete accounts. They can change opening close times that you may have restricted for certain areas for reasons. And it's not that odd a scenario that someone could get that kind of elevated privilege to do those things with your system. And the reason I say that is you would be amazed what you can learn by simply shoulder surfing the install tech when he's at your place. Case in point, one of my facilities while I was walking around behind the ADT guy, I at this point actually know the ADT tech install login for the entire continental US. So I can log in as an ADT install tech because guess what? He was dumb enough to tell me that no, this is, we all use it everywhere. So, and no, I'm not gonna tell you what it is. You will if you give him a cookie. So, and then if you do figure it out and you get busted, I will not testify on your behalf. And then don't bother, don't bother Jennifer Granick or the EFS people because they're just gonna tell you good luck. Okay, more deployment considerations. As I said, network QS is now basically the most important thing right up there with firewalling. Those two now become equally if not sort of interchangeably important because if you flood your system, you flood your network. Now your alarm system's not gonna be able to communicate back to the central station, which means you're gonna start getting a lot of false alarms. If you're in a regular facility that's allowed to use the backup dialer, that's not quite as big an issue. You're gonna still get calls from Honeywell or ADT telling you're a job, telling you, hey, we've got a communication failure and do you really wanna spend all day long constantly picking up the phone and going, no, everything's fine. Yes, I'm getting to that. But it states that the alarm must be on a separate line but it also states very definitively, no two-way communication. And the dialer does indeed allow two-way communication. But the other issue that you brought up, I am getting to that. And as I said earlier, I have been required by my sponsor to say this is not at this point and I cannot imply that it will be, although wink, wink, I'm working with them. Official US policy on how to protect any system that may be monitored via the net as opposed to RF or lease line. So basically, yeah, routing issues are going to become the most important thing that you have to deal with. And frankly, you can only control all the way up to your next hop router. At that point, it's out of your hands, which is one of the reasons why I tried to explain to them before. They allowed all the alarm systems to say, no, we don't offer these other services to you. Sorry, take it or leave it, but it was a bad idea because how often do you have problems routing on the net pretty much every day? The other issue is now, angry Eastern block teenagers can come talk to your alarm system. And the last issue is, unless you do as the gentleman in the back mentioned and as most people that live in that particular environment are required to do and should, if they don't already do, is that it's not a good idea to put this straight on your land because now it's just another node, just like all the desktop boxes, which means, which will mean that not necessarily people are gonna maliciously mess with it, although some probably will, but if you get a box that's infected with a worm, it's gonna flood the network, cause you problems. So, and beyond that, it means all the guys in the golf courts and the flashlights with the nice shiny badges actually have to make nice with all of you guys. And how often do black T-shirt wearing shut-ins enjoy talking to the guy in the golf cart? It doesn't work out really well. Okay, some of the disruption scenarios, because as I stated, the point of our project is we don't really need access to the alarm system. We're not interested in taking it over and making it do what we want, although that might be a nice mystery box game for next DC. But basically all I care about is can I make your alarm system useless? Cause this is all I need. So the DMP guys and the alumni guys, unfortunately, both think that the fact that, oh, we have no, you scan it and you see no open ports, so therefore it's safe. But guess what, they talk IP. So they talk to the network. If they can talk to the network, the network can talk back. So what happens when you flood the network? Well, it depends on the reporting window that you have configured in your system. If your reporting window is once 24 hours, I'm pretty sure at some point I'm gonna figure out that my network's being flooded within that 24 hours and take care of it before it flags the system as having communication failure and people start getting calls. However, facilities like the one I live in, I have to have a reporting time that's like three minutes. So I start getting lots of false positives every day, and they are false positives. I mean, anytime I get a hiccup in my network, rounding, I get a false positive. So what happens when you set, what happens when you set your own syndrome resets back to the system? Same thing. The thing doesn't talk to the other end. Eventually you hit that reporting window, you start getting phone calls. Now the other thing is we haven't had much luck, but we're certain that it's possible. Since these things don't actually use DNS, they only talk to IP on the network. So DNS really isn't an issue because they don't even bother with DNS. But frankly, at that point, ARP cash poisoning becomes very important because if you can figure out what the, all you gotta do is figure out what the MAC address of the next upstream hop is on the system, poison the ARP cash, and then tell it you're the next hop, tell it you're also the reporting, got a system IP, and now it's talking to you. And frankly, if you got the alarm nut stuff in your facility, and you go out to eBay and you spend your 130 bucks, now you've got your own little monitoring system. ARP cash poisoning, tell it, quit talking to the guy over there over in Florida, frankly. That's where ADT keeps their boxes. Not that I'm encouraging people to go look for them. And now you tell them I'm really the box in Florida, even though all of a sudden you're only one hop away. So again, my disclaimer, this is my solution. This is not official government policy. This is only mine based on common sense from having done this kind of stuff for 17 years. My own experience is dealing in all sorts of facilities, both regular business facilities, my own home, and other facilities on behalf of the man, and then stuff I've cleaned from all the various tech install manuals that I've managed to sequester away when I'm dealing with some of the techs and they forget things at lunch. So basically what we did at my facility, and I'm trying to, at this point with the project that I'm gonna, after DEFCON here, open up to the public, is we basically decided that, well, it made sense as the gentleman back there pointed out, that not only would SCI facilities be benefit from having their system segregated on its own line, but everybody would. So we thought, well, if the vendors aren't gonna bother trying to solve this problem on the hardware side on theirs, then why not put a piece of hardware of our own design that we know has been thoroughly vetted and does the job properly and has security mitigation issues, security mitigation methods in place. So what we did, what I've been doing on the policy side is trying to put together a deployment policy. One of the things would be, insist that don't put it on your land, go pull in a DSL line, because DSL lines are like 20 bucks a month. So pull in a DSL line, because frankly, as I mentioned in the first talk, POTS lines and facilities are common. So find an unused POTS line, flip it over to DSL, and then go get yourself a North Link account or whatever for just generic, no-frills, no-frills, net access, DSL net access, because that's all you need. And then the QoS becomes less of a worry, because now you've only got one node talking on that network. QoS is still important, but it's not nearly as important because you're not gonna have to worry about other nodes on that network. At least you would hope not if you properly follow layer one security, fiscal security issues and lock it away. But at that point now, QoS becomes less of a worry, because you've only got one node, you've got your reporting node, you've got your firewall, you've got your DSL router. Beyond that, you can't control it, so why worry about it? One of the other things that I do basically, because it's a requirement for me, but it's also just part of my paranoid nature, is the DSL account is actually an individual's name, and no, it's not mine, so don't go look for it. And then we actually have all the billing go to a disassociated mailbox. But those are actually standard, those are operating procedure issues, not really directly relevant, but somewhat pertinent. So what we did was we started to build our own firewall. We decided the easiest way to build an embedded firewall was either a PCWrap box, or frankly, I like the Socrates boxes, so I defaulted to the Socrates boxes, because they're nice and cheap, really nice boxes. And frankly, after, I think like next week, Socrates is finally coming out with a really nice 686 box, only about 300 bucks in a 19 inch, one new rack mountable case for like 350 bucks, which not bad, I mean, granted it's a little more than a Linksys router, but you're not gonna want a Linksys router as your firewall for this for a few reasons. So basically, we're working on building a Linux system from source. We're looking at whether we wanna hack together our own distro, or whether we just wanna build a modification of busybox. The cost is potentially less than the long run, because in order to get a system that really is the quality you want protecting your alarm system, you're not gonna get a Linksys, you're gonna get one of the commercial ones, which are gonna potentially cost you a few thousand dollars, as opposed to a couple hundred bucks and maybe a day or two of your time. You also have more control over the configuration. I mean, when you buy a commercial firewall, and granted they're very good, but you don't have full control. You can't add or modify any of the services, really, at least not without avoiding the warranty on it, and then it becomes your own very expensive version of this. And in my case, doing this allowed me to standardize my hardware and software solution across the board. So if you have a situation like I do, where you deal with multiple facilities, and they're spread out all over the world, all over the country, all over the world, or whatever, you can still guarantee that troubleshooting issues is gonna be capital minimum, because the hardware's the same, software's the same, so it really reduces your troubleshooting issues to find out why the alarm system's not really happy. Some of the choices we made also, for whatever personal reasons we decided, for some of the reasons why we decided to make our own firewall is because we decided to use syslog ng as our logger, instead of sysklog. Reason for that is because syslog ng will actually report over TCP, which will also allow you to wrap it in an SSL tunnel, thus protecting your firewalling logs. If you decide that you want to do off-box logging, you can mitigate the network access on that by firewalling off the NF face that you connect to your administration monitoring network and simply tunnel the logs over there so that you don't have any issues with snitching or injecting at that point. And we also wanted to include log watch and log rotate, at least in my instance, because frankly, I'm lazy, and so I like having log watch, so it'll mail me my logs every morning and I can see what's been going on with people probing the system. And then I frankly did not want to build post fix or send mail or anything simply to move those logs off, so this allowed me to put SSMTP, because that's really all you need. I mean, it's just a simple little binary and just shatter your stuff off to a mail hub and call it a day. So some of the issues that I had to deal with was, if you're responsible for multiple alarm net monitors, how are you gonna monitor the logs? That will explain to you why I did the log watch thing because frankly I wanted to move all my logs off onto my desktop because it's one thing to monitor multiple sensors throughout a building. It's another thing to monitor multiple alarm sensors or alarm monitoring hardware throughout the country or throughout the world. You can't continually, every morning, fly to a different area and go check the logs. So this allowed us to run our logger over S tunnel to protect the logs and then run log watch to fire them off to us every morning so that we have a centralized nice little thing in our inbox instead of having to actually go out to each of the firewalls and actually log into them and monitor the logs manually. And also building our own firewall allows us to control the patching. When we built our own firewall that allowed us to only put in what we wanted. So we don't have a whole bunch of extra junk in there. For example, I mean if you go to the trouble of just creating a minimal install of Fedora, you're still gonna get all the wireless things and all that and even sillier than that, you're gonna get cups installed. It's solely because that's part of the LSB package on Red Hat and you can't actually remove it without really mangling the distro. So this way, building our own version of it allowed us to keep a lot of the stuff that had no business being on the firewall offered in the first place. It also made it a much smaller thing to deploy which makes it easier to simply just put up, we just put up an image, let the admins down, suck it down off one of the internal servers, run DD to pop it off onto a CF card, throw it in the soaker box, turn it on and call it a day. And then it also allowed us to have far more control over the firewalling rule set because we could literally get a shell if we needed and manually manipulate the rule sets on the fly as we saw fit as opposed to being restricted to whatever interface was provided to us and having no other options. And if we wanted to, as I mentioned earlier, if we want to add other functionality, whether or not it's a good idea, we would at that point be allowed to add things like inline start capability which would create some semblance of an active IPS. Well, what we're doing at this point is I've been dealing with a lot of IPS vendors and stuff, frankly, because I'm in the AHA group with H.E. Moore and a few other people. And so we've been, some of us have been talking about it, trying to develop traffic signatures from these so that you can identify them, not necessarily from nefarious purposes, but so that we can get a good handle on what is actually good traffic for these things, thus making it easier to pick up anomalous traffic and therefore if we decide to add inline snort functionality or whatever, now we have an easy way to deploy signatures that will actually do stateful packet inspection and say, even though this looks like is an acceptable firewall, a piece of traffic for the firewall, looking at the payload, I know it's malicious, handle it however I see fit. And the other thing that we have ongoing right now is we're actually, in addition to trying to pick out what the shared secret is, just for our own curiosity, we're trying to find people that are pretty handy with crypto, that are interested in testing to see how effectively the crypto was implemented in these items, granted they're UL2040 certified, which is great, but maybe they missed something maybe there are actual ways to bypass the encryption and grab a look at the proprietary communication protocol and then create your own man in the middle. And actually one of the points under there under the effectiveness is the timestamp and recently, we'll see it was a middle of last week, one of the guys is looking at the traffic captures that we have up on our wiki, he had mentioned that he thought it was a timestamp for the IB, but when I and a couple other people took a closer look at it, we realized actually there was a pattern and it looked to be the same, so obviously it's not a timestamp because it would change a little bit every single time and it doesn't, so that's actually a missed number. Now one of the things I have been trying to discuss with the vendors to, I got five, one of the things I have been trying to discuss with the vendors to take care of this is to get at least a minimum of authenticity to the entire communications process is trying to see if I can't convince them to implement an IP stack in their client and monitoring receiver stations, so you at least will have a modicum of secure feeling that you are indeed talking to the distant end that you think you are, thus not eliminating, but at least making the ARP cash portioning issue a little bit more difficult to pull off. And then basically at this point, that is actually the URL at the bottom is the wiki. As I said, we haven't actually gotten a fully functional version of the firewalling base out yet, but once we do, a link to the subversion repository for it, we'll actually go up on the wiki. So anybody who wants to go to that wiki, get yourself a count and start helping out, looking at traffic, making suggestions, helping out with working on the firewalling code or anything you're more than welcome to. The one thing I would suggest is I'm really cheap, so I didn't bother paying Dreamhost for a static IP. So there are no TLS connections. So frankly, if you get yourself an account here at DEF CON, you better change the password as soon as you get home because somebody else is gonna start using it. Basically, that's it. So if anybody's got any questions, I'll be happy to answer them. And thank you very much for your time. Yes? Vendor, what are some of the things that we have in here? Actually, they're actually pretty good about that too. Oddly enough. They really are. Like I said, the AlarmNet guys, they're the ones that I got more of their install manuals and stuff. And frankly, it's not, on that, it's not the vendor that's the problem. Getting the manuals, I got the manuals from the install tax because they don't pay attention. They go, I'm half done, but I gotta go out and get a smoke. So they go, you know? And they leave the manuals sitting right there. So I run over the copier, I copy it, I put it back. Now I gotta copy the manual. They don't look around, they don't know. They don't take the manual with them. But frankly, as I said, that's not the vendor. That's the Chubb employee or the Honeywell employee or the DMP or the Mom and Pop Alarm Shop if it's a residence. So that's something that's out of their reach. So I don't actually blame them for the fact that I have a lot of their install stuff. That's not their fault. They can only tell the vendor, please be careful with this and they can't fall them around and babysit them. Anybody else? Okay, thank you very much.