Protect 100BaseTX from malicious actions

An even cheaper media converter is the TP-Link MC220L. I have bought these new for less than GBP20.0 on ebay. 850nm multimode SFP modules can often be bought for about GBP1.00 on eBay. Short multimode patch cables with LC connectors are very cheap as well. GBP(a few).

The MC220L is very solidly made with a steel case. It accepts any make of SFP module as it does not have any connections to the i2c interface in the SFP connector and therefore has no way of knowing which module type is being used.

The slight disadvantage is that it ONLY works at 1Gbit/s and does not do speed conversion. If you can cope with that limitation I would definitely recommend it.

As already mentioned small switches with SFP connectors are a good solution too. I know that the Netgear GS110TP works with any make of SFP module. Most other small switches will probably do so as well.

John

Yes, I've already designed a module that effectively does this (because it has to protect the *protocols* and traffic as well -- not easily done with "just hardware"). And, to provide other services that aren't available in a stock switch (which further justifies the cost of doing so)

"Don't encrypt your WiFi traffic. Just pick *better* neighbors!"

"Don't put all that security in your casino, just service better clientele!"

The "business" example was by way of illustration, only. I suspect most folks don't have big switches in their homes. And, I suspect most homes don't have precious resources that are exposed via those switches.

I.e., if a port dies (or, is destroyed!) on a switch, you just move the device to another port, replace the switch, and/or replace/repair the device that may also have been damaged in the process. Your lights still work, the monies in your checking account are still available, no one "goes hungry" while it's "down", etc.

The same is not true of businesses. E.g., if someone takes down a bit of infrastructure "after hours", there is some cost to you (a reflection of the cost to your *customers* who may have expected to be able to access that service at whatever convenient "local time"; the holiday attacks on MS/Sony's game services are an example of this).

Finally, most folks probably have much better control over who gets

*into* their home (how likely is a business to dispatch a TRUSTED employee to stand over each tradesman, visitor, etc. that enters the building to ensure they don't "touch" things that they shouldn't?)

A neighbor has a wireless alarm system -- all of the (field) sensors communicate with the "brain box" wirelessly. This suggests a simple attack vector of just jamming the local area with lots of targeted RF (you can sit and *listen* for months to fully characterize the frequencies and traffic patterns involved! Heck, you can even install the exact same model so you have even MORE access to its behavior in a wider variety of circumstances).

Ah, well perhaps the brain box is smart enough to treat loss of signal/connectivity as an alarm condition? I.e., instead of waiting for an intrusion *report* from a sensor, periodically

*poll* each of them and if a response is not forthcoming, then signal a fault?

And, of course, all of this would have to be battery backed to block *that* simple attack vector.

But, how does the brain box report the condition to "someone"? Telephone link (land line)? If so, cut the wire. No, let's protect even *that*! Build a cell phone into the device! (no one intent on burgling such a place would *ever* consider using something as illegal as a cell phone jammer, would they?)

[I have no idea the details of their actual system. Just know what it *looks* like from the few times I've been asked to babysit their home in their absence. If I was "of criminal intent" and "sufficiently motivated", I'd notice the sign on their front lawn ("Protected by ABC...") and research that (I'm sure there must be "underground" communities that share this sort of data, regularly) to *know* its vulnerabilities.]

Now imagine a *wired* implementation (to avoid the wireLESS pitfalls, above). How would you attack *that*? Imagine, instead, that it's not a "burglar alarm" but, rather, controls (your!) physical access to the property. E.g., unlocks the front door for you when you've identified yourself to it. Or, controls the internal environment in your home (temp/humid). Or, ensures the flora in your yard are maintained (esp while you are "away").

What incentive would people have to lock you out of your own house? Or, arrange for your HVAC to misperform? Or, kill all the plants in your yard??

[Yet folks will seemingly gladly lock you out of your PC -- even if they don't explicitly extort monies from you to allow you to regain access to the contents thereof! I.e., they "get something" out of *knowing* they have done this -- even if you are just a faceless entity somewhere on the globe.]

Hacking PC's wasn't anything more than an intellectual novelty... until EVERY home had one (larger attack surface -- even when they were connected via sneakernet... virii on floppies, etc.). Do you try to *add* security to a product AFTER it has been designed? (we see how well that has worked with email accounts, credit cards, software, etc.!) Or, do you think about all of the possible attack vectors *before* designing the product and design with that security in mind from the beginning?

The gaming industry is an excellent venue to see the extremes that folks will pursue to "steal in broad daylight" (well, not daylight as much as "under the mindful eyes of hundreds of security cameras and "undercover" employees). There is a real *motive* (that's REAL MONEY inside that machine! not just some abstract thing that may/maynot have value to others).

[I can recall all the hacks we engaged in with pinball machines in my youth -- none of them *illegal* or *destructive*. Yet, all designed to provide us with something -- "play" (i.e., something worth less than 25c) -- for nothing!]

Yeah, but imagine what you'd do if your intent was to cause more than just "simple" damage. E.g., not just taking out a single *port* but, rather, trying to take out the entire

*switch* (because most switches are highly integrated... if you can push a dangerous signal past the input protection and *onto* the pins of the chipset, you can potentially take out ALL of the ports serviced by that particular chip).

Yes. But you're just using the second media converter (and fiber) for galvanic isolation. A gap on a PCB can do the same thing. Especially if there are provisions made to provide a "sweeter path" for any hazardous signal (e.g., to Earth).

[This is, in effect, how you are hoping to prevent the path through "+5V" from propagating the signal *across* the fiber gap]

This would be impractical for most folks. Even *wired* is a challenge (I'm just opting for this approach as wireLESS is even MORE challenging!) in most cases. How many network drops do you have in *your* home (that aren't just cables strung along the floor or behind furniture)? :>

Yes. But they aren't protecting anything that has value to an adversary. What does he *gain* by DELIBERATELY taking out your phone service? Instead, they are there to protect from "accidental/act-of-god" events. E.g., TPC wouldn't take kindly to coming out to replacing arrestors on your property more than once in a lifetime! :>

Imagine controlling a bunch of CNC machines on a factory floor. Would you just *hope* employees didn't deliberately try to toast your entire fabric for fear of losing their job? What would you do when a disgruntled employee intentionally *did* do this? Could you even determine *who* it was? And, be able to bring "civil/criminal action" against him? (hey, he's already decided it was worth the cost of his own *job* before he undertook this!)

[When I was in High School, there was a period of time when it was seemingly en vogue to "pull the fire alarm" during school hours. What could the perpetrators have hoped to gain from these actions; perhaps AVOID taking an exam scheduled for that day?? "Um, hello... we'll just reschedule the exam for TOMORROW!" Yet, they were willing to risk *criminal* prosecution for this act. *Today*, it would be foolish NOT to install a security camera monitoring each such alarm switch. You can't PREVENT it from being pulled (as its whole purpose is to allow people to legitimately signal a dangerous condition) but you could later *see* who pulled it!]

What do hackers have to gain from remotely controlling the systems in your MOVING VEHICLE -- while you're inside? Or, leaking private emails if you proceed with your plans to distribute a movie?? Or, spray-painting (tagging) the sides of buildings? Or, spinning centrifuges up to excessive speeds? Or, dragging a key along the side of your vehicle?

Unless you can *physically* protect every critical resource, you expose a potential vulnerability. You wouldn't run a courtesy WiFi service directly off your corporate network (because it unnecessarily exposes your internal infrastructure). Would you run a network drop to a semi-publicly accessible location without similar precautions (on data)?

Yes, that was what inspired me to pursue my current solution: a dual MAC MCU that I treat as "disposable" (in the event of an "attack"). In my case, this approach gives me far more value than "just a fuse" as it can add application-specific services that a switch can't. So, I can rationalize that something *like* it is required in this "position" and treating it as sacrificial allows that capability to come "for free" (you wouldn't want to have to replace your main *switch* if someone toasted a port on it!)

I can already automatically cycle power to my "little boxes" so that's not a problem. And, I am not expecting frequent attacks. Rather, ensuring that something "less valuable" (disposable) gets lost in such an attack instead of something *more* valuable (or the system itself).

In my architecture, if one of these little boxes dies (regardless of cause), I *know* about it (i.e., the system knows that it has died -- and when!). Because ONLY that drop is affected, the system can react to the event. E.g., cycle power to see if this was a "fluke occurrence". If the device comes back up (thereby also allowing access to whatever "lies beyond"), log the event, mark the connection as "suspicious" (e.g., this should NOT have happened -- is the system under attack? is this port the point of that attack??), and hope a real human deals with the problem, soon.

[Part of the role of these little boxes is to ensure the *proper* traffic is flowing through that network drop at all times. "Why is the irrigation system trying to access the garage door opener?? Hmmm... maybe someone has access to the irrigation system located OUTSIDE and is using that network drop to attack the system. Let's shut down this suspicious link to safeguard against any potential active threat getting through! And, leave an alert for the homeowner that the irrigation system is now off-line and possibly compromised"]

OTOH, if an adversary could take out the entire switch, then nothing can talk to anything (the equivalent of jamming RF comms). The system has no recovery ability. Brittle.

But those are primarily at the protocol level. You don't tend to see folks deliberately trying to TOAST their local network drop. In part, because it is *their* network drop (i.e., THEY lose).

I essentially have a firewall on each port. I.e., I can prevent ANY specific traffic from entering/exiting via that port. Not just with address filters but, also, "network port"/protocol, etc. You can't talk to anyone/anything that isn't *currently* configured for your port.

Traffic is encrypted. If you can't speak the "language", you won't be talking to anyone! :>

This is intended as a closed network. The network is used as an interconnect medium. Much like the bus in your PC. What do you CURRENTLY have installed INSIDE your PC to monitor traffic on it's PCI (etc) bus?

Exactly. I filter connections based on IP and MAC addresses (as well as port/protocol, etc.). You can spoof a legitimate address. But, must *replace* the legitimate device USING THAT PARTICULAR DROP in order to have the remotest of chances to "talk". I.e., you can't just *move* a device to another port without the system approving (and enabling) that action. If AA:BB:CC:DD:EE:FF appears on a different port, it won't be allowed to pass any traffic AND will have that port marked as suspicious. If AA:BB:CC:DD:EE:FF appears anywhere else at the same time, you *know* it's suspicious (MAC address not unique).

If you have a legitimate need to move a particular device from one port to another, then the system needs to be involved in the process in order to inform the associated "little boxes" of the new physical routing. I.e., now you need access at a much higher level than just *physical* access to the devices.

If you have managed to remove the legitimate AA:BB:CC:DD:EE:FF and replace it with your spoofed AA:BB:CC:DD:EE:FF device without the system noticing (fat chance! the little box will see *any* disconnection so you'd have to literally splice wires and effect a near instantaneous switchover "mid-stream"), then you'd still need to know the current encryption keys -- else the little box will flag the connection as "suspicious" and take it offline.

See above.

This is the hardest to achieve as it requires human participation (beyond the issues I've addressed above).

The encrypted tunnels do a lot to *prevent* extraneous traffic. The filters and checks that I impose on the traffic go beyond "noticing" unexpected traffic but, also, blocking it as it occurs. Many IDS's are adaptive, of necessity, as they don't KNOW what traffic is "legitimate" at any particular time. So, for much traffic, they can only be effective retroactively.

In my implementation, the *fabric* is informed of what traffic should originate on each physical port and where that traffic is destined. I.e., the fabric appears as a crosspoint switch, of sorts. Anything that isn't following this preestablished pattern (which can vary over time) is either a glitch ("noise" from the environment -- should be rare!), bug/failure (i.e., something broken or breaking) or an attack.

Not consistent with the goal of thwarting *deliberate* attacks. "Security by obscurity" is no security at all.

Many of the connections are effectively "hard wired" -- though that wouldn't stop a determined adversary with physical access to the media.

Any "after-the-fact" approach is a no-win. Knowing *who* shot you is of little help if you're dead! :-/

The idea of having strictly controlled access rules configured into some box is OK, as long as the environment is stable, e.g. running exactly one specific protocol for a decade or two.

However, in a campus style network, there are frequent justified requirement to pass various kind of traffic through a box. To process and validate these requests and implementing the actual filtering rules, you are going to need an army of _trusted_ network administrators. During a longer period of times, it is likely that the rules are relaxed to reduce the workload and the expected security level is not maintained. You need to be realistic, what security level you can expect in practice over a longer period of time.

My rules aren't hardwired as my traffic isn't "static". E.g., the system may opt to deliberately migrate a particular process to a particular system device. So, the connections associated with that process have to similarly be moved (and enabled in the fabric).

Even though the hardware hasn't changed *in* the move.

Of course! I don't want to have to maintain *two* sets of fabric: one for "general purpose" use and the other dedicated to this "system".

Since changes to the system are rare, the cost (human involvement) of having to deliberately and specifically "introduce" new devices is a small one to pay (for the protections the implementation provides against attack).

OTOH, a guest visiting for a few days can freely connect his laptop to one of the network drops in the guest bedroom and surf the web, etc. But, regardless of his INTENTIONS, he'll *never* be able to play with the aspects of the protected system that are operating over the verysame fabric! If he opts to carry his laptop into the den and connect from there, the same applies. *He* is not inconvenienced if he's not trying to do something he "shouldn't".

OToOH, if he starts trying to probe the protected system, it can block those attempts AND shut his port off (i.e., effectively disconnect him from the network) in a heartbeat! So, even if *he* is not trying to attack but, rather, malware that is present on his laptop seeks to "go poking around", the system can protect itself. In such a case, the homeowner would have to take steps to reenable the network drop for "normal" activity: "What the hell were you doing? The system said you were trying to access something that you shouldn't have! Are you just RUDE? Or, is there malware on your laptop that you are perhaps not aware of??"

[Obviously, malware can't physically damage my hardware -- that requires the involvement of something corporeal!]

He means the TSA...

True. Part of the reason why I am suggesting doing it with a ready-made box - either the surge protectors I posted first, or the media converters - is that I have seen the results of "DIY" protection on a

10/100 Ethernet port. As designed, there were diodes from both lines of each twisted pair to ground, on the internal side of the transformer. These were supposed to conduct when the voltage got too far out of range and dump the extra voltage to ground. Problem was that these diodes also had relatively high capacitance, which caused bit errors on the Ethernet connection when run for a long time or at high loads. It took a little while to find... the port would come up and work, and you could ping or transfer small files just fine. You'd only see the problem when you hit it with lots of traffic. The solution was to not install those diodes.

Because of that experience, I am willing to err on the side of "buy a box from somebody" if the requirement is to protect an Ethernet line from strange voltages and currents.

Two locations with two ports each that are fished through the walls and terminated at a Keystone wallplate and everything.

One location with three ports that has Ethernet cables running along the floor and into the closet. I have the boxes and plates; I just need the tuits.

In days gone by, maybe my customers placed their orders by telephone. I had a summer job in a call center that did millions of dollars worth of business that way.

I think I'd try to have a hiring process to get good people, decent managers to keep the people happy, and enough sales to keep work coming through the door. People who are paid well, like their job, and think that the company will be around next year don't wire three-phase to the router.

I'd be pretty happy that he or she only managed to blow up my $2,000 managed PoE gigabit switch, and not my $100,000 milling machine. I'd tell everybody to sweep up and oil their machines while I went down to the server room and swapped in the $200 unmanaged switch that I keep on the shelf, and then go back to making money. Then I'd go order another fancy switch.

I don't recall that happening in high school, but it was popular to pull the dorm fire alarm during finals week in college. In Decmber in Missouri, you quickly learned to sleep in your clothes that week. I don't think anybody was trying to get out of an exam; they were just being jerks.

That's true. But when the cost of the protection approaches a significant fraction of the cost of the resource, you have to stop and think about it a little.

Wal-Mart, Target, etc could reduce shrinkage to absolutely zero by having armed guards at the doors and strip-searching the customers on entry and exit. At first the shrinkage as a percent of sales would go to zero, and then the sales would go to zero because nobody would shop there. Retailers have decided that it's OK to let some small percentage of stuff just walk out the door, in return for having a reasonably nice environment for their customers.

Matt Roberds

I had some ass running around pulling the fire alarm switches before the panel was installed. It turned out to be the general contractors 'Gopher'. I followed him into the construction trailer and screamed at him, till his boss joined in. Someone had connected several switches wrong, and it was over 120 F in the attic so I was in no mood to keep climbing back up there to have an open circuit. When the guy from the alarm company arrived to install the panel, he tracked me down to tell me that it was the first job site that was properly wired when he arrived.

--
Anyone wanting to run for any political office in the US should have to 
have a DD214, and a honorable discharge.

Hi Matt,

Check your mail...

SWMBO worked for the Director of Facilities at a local hospital. Apparently, the fire alarm system was sufficiently old and "unsupported" that it would periodically be "broken". At those times, folks were paid to sit in key corridors and, essentially, "watch for fires". Gotta wonder how this could make sense to *anyone*!

[lots of horror stories from hospitals. makes you nervous to EVER visit one!]

Sure, lots of sick people there, too.

I was recently hospitalized for major surgery. One of the nurses told me that I did *not* want to know what they did to me. The other half came home with bronchitis, which I got a week later. The surgery was a piece of cake compared to the complications caused by the bronchitis.

I knew of some wankers that used HF ham gear to screw with telco wiring. Better than mains AC because you can fry more stuff apparently.

I still say stop hiring douche bags. Put a check box on your employment form. "Have you ever or are you currently a douche bag?"

Now if you have IP cameras, that is another story. There was a SCADA attack done by getting LAN access by using the port for the camera.

Well crap, after I sent that message something else popped into my mind. The current trend in enterprise is to go thin client. Not a new trend of course, but new in terms of doing it for security. The idea is the thin client is encrypted. Anything else you plug in won't do anything due to the lack of a key. If some jerk uses the thin client, the amount of damage that can be done is limited to whatever capabilities you have on the thin client.

A good example is airports. There are countless computers scattered all over the place. Often the agent stations aren't manned. Half the patrons have notebook computers on them. The odds somebody plugs into your lan port is very high.

The literature regarding hardware protection is primarily concerned with lightning "events" (of small numbers!) and power dumps. All things that are more transient than a determined attack.

I am willing to lose the port that is "attacked" -- figuring the adversary can always CUT THE WIRE and effectively remove the device that is serviced by that drop. So, if he can fry the port associated with it, there is no functional difference (assuming I can repair the port without a major reinve$tment).

My concern is how the interface (PHY) design could exacerbate attacks that can spread beyond the single port. E.g., once you get to the pins of the chips that implement the switch, you could conceivably take out *every* port serviced by that chip(s). Imagine a "little box" that sits midspan between the switch and the device serviced by that switch port. So, I can replace that "little box", worst case, if it is destroyed in an attack.

"How many years have you been a douche-bag?"

I have *lots* of kit that is accessible from outside the house. 12 PTZ IP cameras, the irrigation controller, weather station, microwave link, utilities (water/gas/electric) monitoring, "general purpose" drops on front/back porches (i.e., drag an IP phone/TV out there on a nice summer evening), "network speakers" on the porches, etc.

So, there are ways an attack can be mounted without breaching the building itself.

But, any solution I come up with also has to be extensible to businesses and "institutions" (e.g., schools). Those being presumably much larger and more "exposed" than a house (which I can personally "watch over"). More opportunities for folks to exploit weaknesses.

Fire watch was common duty in wood barracks and other military buildings.

Older fire alarms pushed up to 10 amps in the loop, to make it a monitored circuit. Any poor connection would cause a relay to drop out and give a trouble alarm, before it would give a fire alarm. Then, the wiring and every component needed to be inspected. On place I worked did 'Standard Time' commercial fire alarm repairs as a sideline. The owner would take off for weeks after school let out for the summer, and between semesters at colleges to overhaul the clocks and fire alarms. He would come back in a bad mood, since most of the problems were caused by people tampering with the equipment or wiring.

--
Anyone wanting to run for any political office in the US should have to 
have a DD214, and a honorable discharge.

Yes, I've already addressed this. You have to protect each drop at the hardware and software/protocol levels.

The switch is an integral part of The System. Prior to any traffic (connection) being made, the switch is told the identities of the two parties (addresses), the ports they will be using and the protocol involved. The switch knows where each of these devices reside (because it was told as part of its initial configuration) so it can inform the applicable "little boxes" of the types of traffic they should pass from the devices they service.

So, even if you replace one of the devices with another masquerading at the same MAC/IP, *and* manage to find the unique key embedded in that device (each device has different keys; the system learns them when the device is "introduced" to it, initially), you are still constrained to only generate the type of traffic that the system currently *expects* for that device -- with the devices that are intended to receive that traffic.

E.g., an IP camera never has reason to connect to the "control port" of the alarm system. So, anything masquerading as that particular IP camera attempting to do so will be flagged as an "illegal (can't happen) access". And, the link shut down (by the "little box"). The system, of course, now knows something is wonky -- either that device has been compromised *or* there is some bug in its implementation that explains the misbehavior. In either case, it should be isolated as "not correctly functioning".

As a result, if you manage to hack a particular device, all you can do is *be* that device. There is no vector for privilege escalation.

[Of course, the ports on which the "control" system operates have to be physically secure -- locked away so you can't tamper with the core of the system]

A *wireless* implementation opens up all sorts of other issues that can easily lead to compromise. Hence the reason for dealing with a wired implementation, initially! (but, that means I have all these "conductors" that provide a path into the electronics "from outside")