I finally got around to getting the PiTFT up and running. The instructions at https://learn.adafruit.com/adafruit-pitft-28-inch-resistive-touchscreen-display-raspberry-pi are very easy to follow, just make sure you follow them closely. After downloading the OS patches and applying them to a fresh copy of Raspbian, I was unable to get past a problem with a missing driver. It turns out that I didn't heed one small part of the instructions for removing something that came into the Raspbian mix after Sept 2013. Once I had removed the directory, as instructed, everything fell into place. Next on the list is to set up some libraries that can be used to form a menu function for executing individual script files. A picture of the PiTFT from the AdaFruit site is shown below. Note you can order this 2.8 inch touchscreen panel from the AdaFruit site at http://www.adafruit.com/products/1601 .
My desire is to have a screen X by Y matrix that can move between different menu levels and each one capable of executing a script file or executable.
This is a blog mostly about techie things, what I am doing to my apartment network on the cheap, IOT, 3D Printing, Raspberry Pis, Arduinos, ESP32, ESP8266, Home Automation, Personal Weather Stations, Things That Go Bump in the Night, and some side issues that need discussing. Remember, sometimes the journey to an end is as much fun as the goal achieved!
Sunday, June 29, 2014
Thursday, June 26, 2014
Portable Pi Project - Part #3
Well, I attempted to put the cables together to make the portable RPi. However, there were several issues that I had to deal with:
(1) when I applied power, it became obvious that there was not enough current going through the wires. I did check out all of the lines and the voltage was correct.
(2) I found one of the sides of my DPDT switch was momentary. I needed a switch that was ON-OFF-ON but I picked up one that was ON-OFF-(ON), the (ON) indicating that it was momentary - well, live and learn.
(3) I had the Adafruit 1601 2.8" touch screen on the RPi which added a 100ma load to the power supply, further dragging down the power
(4) the ethernet connection would not light off because of the low power.
So now I am back to trying out the application of power with regular power supplies to make sure that there is not something wrong with the particular RPi that I was using.
After using another, albeit more powerful power supply, I was able to get the RPi to come up and stay up, including the AdaFruit touch screen display. It would appear that I may have misjudged the amount of power needed with the switched setup that I was using earlier.
(1) when I applied power, it became obvious that there was not enough current going through the wires. I did check out all of the lines and the voltage was correct.
(2) I found one of the sides of my DPDT switch was momentary. I needed a switch that was ON-OFF-ON but I picked up one that was ON-OFF-(ON), the (ON) indicating that it was momentary - well, live and learn.
(3) I had the Adafruit 1601 2.8" touch screen on the RPi which added a 100ma load to the power supply, further dragging down the power
(4) the ethernet connection would not light off because of the low power.
So now I am back to trying out the application of power with regular power supplies to make sure that there is not something wrong with the particular RPi that I was using.
After using another, albeit more powerful power supply, I was able to get the RPi to come up and stay up, including the AdaFruit touch screen display. It would appear that I may have misjudged the amount of power needed with the switched setup that I was using earlier.
General Purpose RPi WiFi Thingy
I encountered another one of those interesting snags at work where you wished you had a device that did something out of the ordinary. With that in mind, I want to build a general purpose WiFi-Ethernet interface using a Raspberry Pi. I am willing to sacrifice an RPi to get what I want. This also should serve to get me back into the experiment game. I want the RPi to serve as a couple of different types of Router and Access Point configurations. No fancy VLAN stuff, just the basics. But since I occasionally need Wireshark and TOR I have some alternates. So what I want to do is the following:
1. Router #1
-- Ethernet -> Firewall (w/wo TOR Proxy) -> Ethernet (w/dns&dhcp)
2. Router #2
-- Ethernet -> Firewall (w/wo TOR Proxy) -> WiFi (w/dns&dhcp)
3. Access Point #1
-- Ethernet -> Bridge (w/wo Wireshark) -> WiFi (wo/dns&dhcp)
4. Router #3
-- WiFi -> WiFi -> Firewall (w/wo TOR Proxy) -> Ethernet (w/dns&dhcp)
5. Router #4 (wireless hotspot)
-- WiFi -> WiFi -> Firewall (w/wo TOR Proxy) -> WiFi (w/dns&dhcp)
6. Access Point #2 (Repeater)
-- WiFi -> WiFi -> Bridge (w/wo Wireshark) -> WiFi (wo/dns&dhcp)
7. Client Bridge #1
-- WiFi -> WiFi -> Bridge (w/wo Wireshark) -> Ethernet (wo/dns&dhcp)
8. Client Bridge #2 (Wireshark Passthrough)
-- Ethernet -> Bridge (w/Wireshark) -> Ethernet (wo/dns&dhcp)
I think that I will work this up both on a Raspberry Pi and on a VM to run on my work laptop. The front connections for WiFi (#4, 5, 6, and 7) should allow for capture pages (e.g., Panera). The back connections for WiFi (#2 and 5) should allow for WPA/WPA2 and a known SSID.
Thursday, May 15, 2014
Changing up the netwok for security
Well, after taking a CEH course at night, I have decided that I need to figure out a mechanism to protect my network from intruders. This is more of an exercise for me to apply some of the things that I have learned in the class. I have a number of different VLANs in the house, some pretty benign and some not so much (like access to TOR, etc.). Any one of these could lead to compromises in the network so I would like to re-evaluate what I am doing and make changes as necessary. I will be taking the CEH cert test in the next couple of weeks and that will free up time for me to become more involved in this process.
One specific thing that I would like to try is separation of connections from known or unknown entities to a special VLAN for that purpose. I want to separate out all of the internal networks from being compromised. In addition, I would like to put up an intrusion detection system for the existing networks and go about looking for unusual traffic patterns. Of course, one of the quirks about my setup is that I have everything going through an ActionTec router which can be almost a sieve without proper configuration. Updates to the firmware do not appear to be forthcoming and Verizon is insistent on my spending another $100 to get their "improved" ActionTec router just so I can get gigabit Ethernet to my other router connections.
One of the first things that I think I will try is to make all of the connections from the ActionTec router to be on separate VLANs. There really is no need for me to have everything on the same subnet and the router does have the ability to have completely separate VLANs from it.
One specific thing that I would like to try is separation of connections from known or unknown entities to a special VLAN for that purpose. I want to separate out all of the internal networks from being compromised. In addition, I would like to put up an intrusion detection system for the existing networks and go about looking for unusual traffic patterns. Of course, one of the quirks about my setup is that I have everything going through an ActionTec router which can be almost a sieve without proper configuration. Updates to the firmware do not appear to be forthcoming and Verizon is insistent on my spending another $100 to get their "improved" ActionTec router just so I can get gigabit Ethernet to my other router connections.
One of the first things that I think I will try is to make all of the connections from the ActionTec router to be on separate VLANs. There really is no need for me to have everything on the same subnet and the router does have the ability to have completely separate VLANs from it.
Monday, May 12, 2014
Portable Pi Project - Part #2
Well work activities, dealing with CEH training and the cert test in two weeks, and other things has prevented me from really stepping up to the plate on the RPi Portable idea. But to get back to the overall plan on this, I have looked at the power through the system. The portable looks like the following (not updated from last time):
I have looked at the power lead outs and it looks like a DPDT toggle switch and one 14 position terminal block (I have a 12 position which will have to do) will be able to suit my needs to power everything from either the wall wart or via the battery which is encased with the RPi Portable. The DPDT will be able to choose the 1.0 amp or 2.1 amp lines from either the wall wart or the battery, and if it has a center off, will be able to act as an on-off switch as well. What I will need to do is cut up some perfectly good USB cables to make this work. The cables will end up having a USB plug on one end, and pigtail leads at the other. I just have to make sure that the data leads are not used in the setup. So the power circuit should look like the following diagram:
Notice that I have pulled the power out to the board sides for the wall wart. I have also included a power out to the side for charging the battery. In addition, I have added a board (breadboard) connection so that I can do experiments with this setup as well. All of the internal connections, except for the DPDT switch can be done with cut USB cables. It also only requires a 12 position terminal strip. The high side (2.1 amp connection) goes to the hub and breadboard. The low side (1.0 amp connection) goes to the RPi and LCD screen. All grounds are tied together. Black lines are ground and red lines are 5 volt power lines.
I have looked at the power lead outs and it looks like a DPDT toggle switch and one 14 position terminal block (I have a 12 position which will have to do) will be able to suit my needs to power everything from either the wall wart or via the battery which is encased with the RPi Portable. The DPDT will be able to choose the 1.0 amp or 2.1 amp lines from either the wall wart or the battery, and if it has a center off, will be able to act as an on-off switch as well. What I will need to do is cut up some perfectly good USB cables to make this work. The cables will end up having a USB plug on one end, and pigtail leads at the other. I just have to make sure that the data leads are not used in the setup. So the power circuit should look like the following diagram:
Notice that I have pulled the power out to the board sides for the wall wart. I have also included a power out to the side for charging the battery. In addition, I have added a board (breadboard) connection so that I can do experiments with this setup as well. All of the internal connections, except for the DPDT switch can be done with cut USB cables. It also only requires a 12 position terminal strip. The high side (2.1 amp connection) goes to the hub and breadboard. The low side (1.0 amp connection) goes to the RPi and LCD screen. All grounds are tied together. Black lines are ground and red lines are 5 volt power lines.
Saturday, April 26, 2014
Project #8 - Update the Network for Security
After taking some classes in CEH, I have decided that I need to really look at my network and make sure that security is taken care of.
Wednesday, April 23, 2014
Deciding on some alterations to the virtual basis for the network
I just finished taking some online classes for the Certified Ethical Hacker certification. Now I need to study my butt off in preparation for actually taking the test.
After I succeeded in setting up a pen testing lab to use for the class, it became obvious that I needed to change some things about the layout of my network. I currently do not have any way of isolating the Mac Mini from the VLAN implementations that are being used in VMWare Fusion. In other words, I am now realizing that I need to isolate the VLANs to the Fusion network and to not allow access via the Mac Mini. This really doesn't make a lot of sense except that I am trying to protect the Mac Mini from what I do on the other VLANs. My problem is how to go about doing this. I should be able via firewall settings to perform the isolation. The problem is that Apple doesn't like to give up control of things like the firewall (my supposition since they keep changing the firewall mechanism they use without documenting the same). I currently have a couple of tools which have not been used until now: IceFloor and fwbuilder. Both of these tools are highly rated and address some of the shortcomings on using the Apple Mac Mini for my intended purpose.
I am currently running Mavericks on the Mac Mini (10.9.2). Everything, including the Mavericks Server is up to date.
After I succeeded in setting up a pen testing lab to use for the class, it became obvious that I needed to change some things about the layout of my network. I currently do not have any way of isolating the Mac Mini from the VLAN implementations that are being used in VMWare Fusion. In other words, I am now realizing that I need to isolate the VLANs to the Fusion network and to not allow access via the Mac Mini. This really doesn't make a lot of sense except that I am trying to protect the Mac Mini from what I do on the other VLANs. My problem is how to go about doing this. I should be able via firewall settings to perform the isolation. The problem is that Apple doesn't like to give up control of things like the firewall (my supposition since they keep changing the firewall mechanism they use without documenting the same). I currently have a couple of tools which have not been used until now: IceFloor and fwbuilder. Both of these tools are highly rated and address some of the shortcomings on using the Apple Mac Mini for my intended purpose.
I am currently running Mavericks on the Mac Mini (10.9.2). Everything, including the Mavericks Server is up to date.
Subscribe to:
Posts (Atom)