For some time now enterprises have exercised best practices for wireless security by separating wireless users into their own zone/network and interrogating them with firewall rules before they access the internal wired network(s). I have not seen this in wireless home products...until now!
First some background: I purchased FTTH by our local telephone company and noticed they came into my home with an Alcatel-Lucent GPON ONT which split data and POTS on the ONT. The data then went to a video-over-IP-to-Coax converter with built-in firewall/routing and switch ports.
I have an internal LAMP server (linux/apache web) running downstairs that connected to a LAN port. I turned on wireless on the provided router since I figure "why not"! Laptop connected but I couldn't access the LAMP server. Ooohhhhh!!! Troubleshooting! I love it!
Arp table on my laptop (windows) showed no MAC when I tried to ping the server. I know the server is still functioning as it was for over a year previously...so most likely not the server, but then again anything could happen right? Turn on TCPdump on the server, not seeing any ARP requests and of course no replies. Don't have hosts.deny being used so the packets should make their way up the stack to TCPdump utility (this bit me in the butt in the past when trying to troubleshoot syslogD). Verified IPtables entries, everything looked good (turned it off just in case). Set SElinux (this is redhat/centos box) to passive. Still nothing in tcpdump. Packets not even making it to the server.
Next step: Turn on wireshark on laptop. Okay, ARP requests going out, nothing coming back. Then...light bulb goes on...I'll add a static IP-MAC arp entry in windows (DOS prompt) using NetSH command (windows 7 won't allow you to use arp -s anymore, access denied error, even in elevated admin mode). Okay, check. At this point, I've bypassed the whole initial arp stage, my laptop should see that 1) The server IP is in the same subnet as mine, thus negating the need to arp/send to the gateway router and 2) construct the packet in its entirety using the destination MAC/IP of the server.
Started with a ping, nothing. ICMP doesn't make it to the server. Next HTTP request, nada! See the SYN go out, no ACK back. Server doesn't even see the SYN. That's when I'm convinced, the wireless router must be the culprit! Plug into the LAN physical ethernet port and IT WORKS!!! There are not settings on the router configuration page to disable this firewall functionality so I've since disabled the router wifi feature and placed a cisco AP off of one of the LAN ports, works great!
Sunday, January 18, 2015
Sunday, January 4, 2015
SDN and NFV - Virtualizing the Network | Automating Security
My SDN lab is finally coming together. Previously I wrote about using SDN technologies to support pro-active network defense mechanisms and I'm one step closer. It's interesting (and exciting) to be working with the tools that make up SDN as I have a background building automated provisioning tools since 1999. This involved careful review of the skills of our operations folk and what types of functionality should be included in the application. Today this act of having one leg in operations and one in development is referred to as DEVops.
Back to SDN.
I've tested several opensource controllers and settled on opendaylight (ODL) Hydrogen (first release) versus Helium (lastest, second release) or floodlight (Big Switch Neworks). I plan to check out Juniper's OpenContrail SDN controller shortly, but decided to keep moving forward with ODL and experimenting with python scripts to try and create some automated flow writes. I'll also be trying to migrate from my VMware hypervisor to Linux KVM or Openstack.
Once python scripts are built for flow writes, the next step will be to trigger on ingested data of any kind. For our network defense solution I'm going to set triggers against security logs. Splunk, a great opensource (paid version for larger ingest rates) is a great tool to allow us to pick up on certain events, set thresholds, and launch the python/openflow scripts. Here are some of the things I'll be attempting to trigger on:
Denial of Service Attacks
- Large volume attacks (network floods)
- Low and Slow attacks (usually host/thread based)
Response: Redirect the traffic to a packet capture device
Insider Threats
- Unsuccesful logins or access attempts
- Unauthorized escalation of priviledges
- Movements of or attempts to access large amounts of files/data
Response: Network disconnect or limiting network throughput. ID any staging servers being used.
Malware
- Infection points
- lateral movements
Response: Interrogate host by initiating a credentialed scan to check for deviations from baseline configurations. Check whitelisted hashes of applications for unauthorized changes. Place host into an isolated network segment/VLAN. Launch honeypot/fake services and/or place in sandbox and monitor behavior of malware in order to classify and determine indicators of compromise (IOCs).
VPN Access and Network Segment Monitoring
- Close monitoring of "tollgates" accessed by VPN users.
- Follow cross-network segment access
Response: TBD
Next Generation Firewall
- Attempts to "tunnel" one application through another.
- Reverse shells
Response: TBD
Back to SDN.
I've tested several opensource controllers and settled on opendaylight (ODL) Hydrogen (first release) versus Helium (lastest, second release) or floodlight (Big Switch Neworks). I plan to check out Juniper's OpenContrail SDN controller shortly, but decided to keep moving forward with ODL and experimenting with python scripts to try and create some automated flow writes. I'll also be trying to migrate from my VMware hypervisor to Linux KVM or Openstack.
Once python scripts are built for flow writes, the next step will be to trigger on ingested data of any kind. For our network defense solution I'm going to set triggers against security logs. Splunk, a great opensource (paid version for larger ingest rates) is a great tool to allow us to pick up on certain events, set thresholds, and launch the python/openflow scripts. Here are some of the things I'll be attempting to trigger on:
Denial of Service Attacks
- Large volume attacks (network floods)
- Low and Slow attacks (usually host/thread based)
Response: Redirect the traffic to a packet capture device
Insider Threats
- Unsuccesful logins or access attempts
- Unauthorized escalation of priviledges
- Movements of or attempts to access large amounts of files/data
Response: Network disconnect or limiting network throughput. ID any staging servers being used.
Malware
- Infection points
- lateral movements
Response: Interrogate host by initiating a credentialed scan to check for deviations from baseline configurations. Check whitelisted hashes of applications for unauthorized changes. Place host into an isolated network segment/VLAN. Launch honeypot/fake services and/or place in sandbox and monitor behavior of malware in order to classify and determine indicators of compromise (IOCs).
VPN Access and Network Segment Monitoring
- Close monitoring of "tollgates" accessed by VPN users.
- Follow cross-network segment access
Response: TBD
Next Generation Firewall
- Attempts to "tunnel" one application through another.
- Reverse shells
Response: TBD
Subscribe to:
Comments (Atom)

