This problem isn't cool. It's not cool at all. Even if this problem was stated to be cool by the Fonz himself this problem wouldn't be cool. What is the problem? Windows 8 wifi drivers and certain wireless access points. Let's get into it.
I love Windows 8. I do. Heck, I'm a shill for Microsoft Windows 8. Do I love the start screen? Yes I do. Do I love the graphical design? Yes I do. Do I love the how "things just work" in Windows 8? Yes I do. It's true. It's true. Is Windows 8 perfect? No it's not. It is getting there though. That's another blog post for another time though. What I've encountered thus far in my Windows 8 love and experience is a problem with Windows 8 wifi drivers working with access points. At my house, my Lenovo Windows 8 ultrabook works excellent with my wireless network. I have a Netgear wireless router and my Win 8 ultrabook "just works" with it. No problem at all. Now, at work, we have BYOD so I take my ultrabook to work with me; it will not "just work" with the access point. I have a coworker who also loves Windows 8. Guess what? Her HP tablet pc will not "just work" with the access point either. Those are the only two Windows 8 devices currently at work so that is the extent of my first-hand experience with the problem, but if you "bing" or "google" something along the lines of my problem there are many other people having the same issue.
Specifics
The Windows 8 laptops will only get a limited connection to the wireless network. Running the troubleshooter will "fix" the problem for about 3 minutes then the device is back to limited. The troubleshooter says "Not a valid IP configuration: fixed" and "no default gateway: fixed." Then you have full connection for 0 to 3 minutes before it goes back to limited. Bizarre (to me anyway). Right off I thought it would be a driver issue. I updated the drivers to the latest and greatest for the Intel Centrino Wireless-N 2230. Didn't work. I uninstalled the Windows 8 driver then installed the Windows 7 driver for the device. That didn't work either (so I went back to the Windows 8 driver). I made sure the power management was correct, i.e., the laptop couldn't turn off the adapter to save on power. That didn't work either.
* at this point I think I should mention that, yes, all other laptops and wireless devices connected and functioned perfectly on the wireless network*
What could be causing the intermittent issue? Especially since it's only Windows 8? I'm not sure why I went here, but I went into the settings for the WAP. Perhaps the firmware for this Netgear model didn't want to play nicely with Windows 8? It's possible given the age (a few years old). I updated the firmware on the device. That didn't fix the issue. My frustration was quite high to say the least. So, I scoured the tech forums. Oddly enough, I did find something I hadn't tried that someone had tried which was changing the channel/frequency setting in the WAP from auto to, in his case, channel 6. That worked for him. I gave it a shot. Guess what? It worked for nearly an hour then the ultrabook just disconnected. It didn't even go to limited. It just disconnected. I changed to other channels only to find the same disappointment.
Stupid things I tried that obviously didn't fix the issue:
Turning off the firewall
Disabling other network adapters besides the Intel Centrino
Resetting WinSock
*****UPDATE*****
I had a motorola WAP on the hardware shelf. I added it and configured it to the network and, to no surprise, the Win 8
laptops connected quick, working just like they're supposed to. What
I've concluded from this problem is the Win 8 wifi drivers just aren't
playing nice with all WAPs. I wonder why?
Thoughts? Anyone?
Showing posts with label networking. Show all posts
Showing posts with label networking. Show all posts
Monday, April 8, 2013
Tuesday, March 19, 2013
Are 3G and 4G USB modems a security threat?
According to researchers Nikita Tarakanov and Oleg Kupree they are.
From Network World:
"For one, it's easy to make an image of the USB modem's file system, modify it and write it on the modem again. There's a tool available from Huawei to do modem backup and restore, but there are also free tools that support modems from other manufacturers, Tarakanov said.
Malware running on the computer could detect the model and version of the active 3G modem and could write an image with malicious customizations to it using such tools. That modem would then compromise any computer it's used on.
The modem contains the installer for an application that gets installed on the computer, as well as the necessary drivers for different OSes. The application allows the user to stop, start and manage the Internet connection established through the modem.
The configuration files for the installed application, as well as those of the application installer stored on the modem, are in plain text and can be easily modified. One setting in the configuration files defines what DNS servers the modem should use for the Internet connection.
An attacker could change those entries to servers controlled by the attacker, Tarakanov said. This would give the attacker the ability to direct users to rogue websites when they're trying to visit legitimate ones using the modem connection.
While the application installer itself cannot be directly modified to load malware because it's a signed executable, there are some entries in its configuration file that can be used for this purpose.
For example, many configuration files had paths to antivirus installers and an option of whether to install those programs or not, Tarakanov said. The researcher said that he never found an antivirus installer shipped with the USB modems he tested, but the feature was there.
An attacker could create a custom image with a modified configuration file that enables this feature and installs a malicious file stored on the modem instead of an antivirus program. If the image is written on a USB modem, every time the user would install the modem application, the malware would also be installed, Tarakanov said.
The researchers also found a possible mass attack vector. Once installed on a computer, the modem application -- at least the one from Huawei -- checks periodically for updates from a single server, Tarakanov said. Software branded for a specific operator searchers for updates in a server directory specific to that operator.
An attacker who manages to compromise this update server, can launch mass attacks against users from many operators, Tarakanov said. Huawei 3G modems from several different Russian operators used the same server, but there might be other update servers for other countries, he said.
Tarakanov said that he didn't look for vulnerabilities in the actual modem drivers installed in the OS, but he expects them to have vulnerabilities. The vast majority of third-party drivers in general have vulnerabilities, he said.
Tarakanov specializes in exploit writing and finding vulnerabilities in the Windows kernel mode drivers. However, Oleg Kupreev was the leader for this particular research project concerning 3G/4G modems.
Research in this area is just at the beginning and there's more to investigate, Tarakanov said. Someone has to do it because many new laptops come with 3G/4G modems directly built in and people should know if they're a security threat"
Let's hope new models will be safe because I use a 3G usb modem on occasion.
Source: Network World
From Network World:
"For one, it's easy to make an image of the USB modem's file system, modify it and write it on the modem again. There's a tool available from Huawei to do modem backup and restore, but there are also free tools that support modems from other manufacturers, Tarakanov said.
Malware running on the computer could detect the model and version of the active 3G modem and could write an image with malicious customizations to it using such tools. That modem would then compromise any computer it's used on.
The modem contains the installer for an application that gets installed on the computer, as well as the necessary drivers for different OSes. The application allows the user to stop, start and manage the Internet connection established through the modem.
The configuration files for the installed application, as well as those of the application installer stored on the modem, are in plain text and can be easily modified. One setting in the configuration files defines what DNS servers the modem should use for the Internet connection.
An attacker could change those entries to servers controlled by the attacker, Tarakanov said. This would give the attacker the ability to direct users to rogue websites when they're trying to visit legitimate ones using the modem connection.
While the application installer itself cannot be directly modified to load malware because it's a signed executable, there are some entries in its configuration file that can be used for this purpose.
For example, many configuration files had paths to antivirus installers and an option of whether to install those programs or not, Tarakanov said. The researcher said that he never found an antivirus installer shipped with the USB modems he tested, but the feature was there.
An attacker could create a custom image with a modified configuration file that enables this feature and installs a malicious file stored on the modem instead of an antivirus program. If the image is written on a USB modem, every time the user would install the modem application, the malware would also be installed, Tarakanov said.
The researchers also found a possible mass attack vector. Once installed on a computer, the modem application -- at least the one from Huawei -- checks periodically for updates from a single server, Tarakanov said. Software branded for a specific operator searchers for updates in a server directory specific to that operator.
An attacker who manages to compromise this update server, can launch mass attacks against users from many operators, Tarakanov said. Huawei 3G modems from several different Russian operators used the same server, but there might be other update servers for other countries, he said.
Tarakanov said that he didn't look for vulnerabilities in the actual modem drivers installed in the OS, but he expects them to have vulnerabilities. The vast majority of third-party drivers in general have vulnerabilities, he said.
Tarakanov specializes in exploit writing and finding vulnerabilities in the Windows kernel mode drivers. However, Oleg Kupreev was the leader for this particular research project concerning 3G/4G modems.
Research in this area is just at the beginning and there's more to investigate, Tarakanov said. Someone has to do it because many new laptops come with 3G/4G modems directly built in and people should know if they're a security threat"
Let's hope new models will be safe because I use a 3G usb modem on occasion.
Source: Network World
Monday, March 11, 2013
xPrintServer Office Edition Review
xPrintServer Office edition is an excellent product! A product that is definitely worth the money. It's easy to setup and easy to configure if needed. This is nearly plug-and-play. I say nearly because I did have to go into the admin panel of the device and run the "discover" feature two times. I'll get to the that. For right now, know this is an excellent product.
The product comes in very nice packaging that has a clean style design. When I unboxed it I was amazed at the size of the device. It's about the size of an iPhone! I had read that on the product specs sheet but being the skeptical guy I am and didn't think it would actually be that size. Also in the box is an ethernet cable, power supply with adapters, wall mount kit (bracket and 2 screws), and rubber feet for those who don't want to wall mount their xPrintServer. As you can see in the picture you can connect a usb printer to it. I must admit, this reviewer hasn't tried that option. I've read positive things about that option, but I haven't tried that myself. Yet. If I do I will update this review.
I connected the device to our network via an ethernet calbe to our main switch. After it was connected and powered on, the LED network lights flickered and the device light at first flickered very fast then flickered slowly; this is the discover phase. I grabbed an iPad that was connected to our network via wifi. I browsed to a page then went to the printer options for safari. Only one printer was available. There should have been 3 printers available. I went ahead and printed the page just for testing and it worked just as it should have worked. After that, I went into the admin panel of the xPrintServer device. After running the discover tool
two times all 3 printers were discovered. I checked with my iPad to find that all 3 printers were ready for printing.
Aside from the device not auto-disovering all the printers at once, this device has been great. Setup is a breeze. Even the "extra" stuff I had to do was super easy and fast. All of this happened in less than 10 minutes. How great is that? You can't ask for more than that right?
In addition to enabling your iOS and Mac OS devices to print without any software or app installation, xPrintServer Office admin panel also has cool stuff for admins like: job status and viewer, log viewer, network configuration for the device, manually add a printer, and driver installation.
I highly recommend xPrintServer Office edition to those offices in need of printing from iOS devices and don't want to have to purchase iPad and iPhone printing enabled printers.
Tuesday, February 19, 2013
Windows Server 2008 R2 RDWeb Resources
This is the first post of February 2013 and it's already the 19th. I can't believe it. I haven't posted in a while, but it's not because of laziness: I've been working on RDWeb for my work. Along the way I found some very helpful and not so helpful resources. I'll only list the helpful links. Do note that these links may not solve your problem and that I'm not endorsing *every* solution mentioned in the links. The answers labeled "best answer" or "chosen answer" helped me in the forums. I didn't try every solution that is mentioned in the links below.
My main focus for deploying Remote Desktop Services was to make our local applications available to users located outside our network so that's the focus of the links below.
Getting Started
Deploying Remote Desktop Web Access Step-by-Step Guide
Resources on Troubleshooting Outside Access Problems
External Users Can't Connect to Apps in RDWeb
TS Gateway "the computer can't connect to the remote computer"
External Access to RDWeb Problem
How to resolve external FQDN to a local IP when behind a firewall
RD Gateway/Web Access Outside the Firewall
Your computer can’t connect to the remote computer because the Remote Desktop Gateway server address is unreachable or incorrect. Type a valid Remote Desktop Gateway server address.
Can't Access Through Gateway
Remote Desktop Gateway is Temporarily Unavailable
Licensing
Remote Desktop Services Licensing
Customizing the RDWeb website
Customizing RDWeb
Troubleshooting Remote Desktop from RDWeb
Remote Desktop via RDWeb
My main focus for deploying Remote Desktop Services was to make our local applications available to users located outside our network so that's the focus of the links below.
Getting Started
Deploying Remote Desktop Web Access Step-by-Step Guide
Resources on Troubleshooting Outside Access Problems
External Users Can't Connect to Apps in RDWeb
TS Gateway "the computer can't connect to the remote computer"
External Access to RDWeb Problem
How to resolve external FQDN to a local IP when behind a firewall
RD Gateway/Web Access Outside the Firewall
Your computer can’t connect to the remote computer because the Remote Desktop Gateway server address is unreachable or incorrect. Type a valid Remote Desktop Gateway server address.
Can't Access Through Gateway
Remote Desktop Gateway is Temporarily Unavailable
Licensing
Remote Desktop Services Licensing
Customizing the RDWeb website
Customizing RDWeb
Troubleshooting Remote Desktop from RDWeb
Remote Desktop via RDWeb
Wednesday, January 23, 2013
Configure Server 2008 VPN Behind Sonicwall TZ 210
You want to use your Server 2008 as a VPN for accessing remote applications and data at your workplace instead of your VPN firewall or a router that has that option? Understandable. Exciting that you found this post huh? No? Only useful? Well, okay.
First, install the server role.
The server role isn't called 'vpn' or anything like that. Go to Start > Server Manager > Add Roles > Select Network Policy and Access Services > Next > Next.
Select Remote Access Service > Next > Install > The Service takes a long time so make a sandwich or a salad if you're a vegetarian. When it finishes, click close.
Now go to Start > Administrative tools > Routing and Remote Access > The Server will have a red "south" Arrow on it > Right Click the Server and Select "configure and enable routing and remote access"
Next > Select "Custom Configuration" > Next.
VPN Access > Next
When prompted select "Start Service" > service will start > you can now close the Routing and Remote Access Console.
Make sure the user has 'dial-in access' in Active Directory Users and Computers. For example find Joe Smith in Active Directory. Go to his properties. In the dial-in tab, click "allow access."
Now we must go to the Sonicwall device.
Since the Server 2008 box is behind our firewall we must open the correct port and protocol to Server 2008. TCP Port 1723 and GRE (Generic Routing Encapsulation) to be exact.
You will need two rules in your Sonicwall. The first one is NAT.
Source original - any
Source translated - original
Dest original - your public IP
Dest Translated - your vpn server internal IP
Service original - pptp
service tranlated - original
The second rule is a firewall rule.
Wan to Lan
Source - any
Destination - my external IP
Service - pptp
Action - allow
These two rules cover the TCP port 1723 and the GRE protocol requirements.
Now you need to connect your remote client to the VPN server (your server 2008 box).
The following is for Windows Vista and Windows 7 machines.
Click on Start > Control Panel > Network and sharing Center > Connect to a Network > Set up a Connection or Network > Connect To a Workplace > Next.
Use My Internet Connection (VPN) > Enter the public IP address of the VPN server > Enter a Name for the Connection > Next > Enter your Domain Logon details > Connect.
I hope this helps. I couldn't find a single post covering all of this. There might be one out there. I couldn't find one so that's why I wrote this post. Enjoy!
First, install the server role.
The server role isn't called 'vpn' or anything like that. Go to Start > Server Manager > Add Roles > Select Network Policy and Access Services > Next > Next.
Select Remote Access Service > Next > Install > The Service takes a long time so make a sandwich or a salad if you're a vegetarian. When it finishes, click close.
Now go to Start > Administrative tools > Routing and Remote Access > The Server will have a red "south" Arrow on it > Right Click the Server and Select "configure and enable routing and remote access"
Next > Select "Custom Configuration" > Next.
VPN Access > Next
When prompted select "Start Service" > service will start > you can now close the Routing and Remote Access Console.
Make sure the user has 'dial-in access' in Active Directory Users and Computers. For example find Joe Smith in Active Directory. Go to his properties. In the dial-in tab, click "allow access."
Now we must go to the Sonicwall device.
Since the Server 2008 box is behind our firewall we must open the correct port and protocol to Server 2008. TCP Port 1723 and GRE (Generic Routing Encapsulation) to be exact.
You will need two rules in your Sonicwall. The first one is NAT.
Source original - any
Source translated - original
Dest original - your public IP
Dest Translated - your vpn server internal IP
Service original - pptp
service tranlated - original
The second rule is a firewall rule.
Wan to Lan
Source - any
Destination - my external IP
Service - pptp
Action - allow
These two rules cover the TCP port 1723 and the GRE protocol requirements.
Now you need to connect your remote client to the VPN server (your server 2008 box).
The following is for Windows Vista and Windows 7 machines.
Click on Start > Control Panel > Network and sharing Center > Connect to a Network > Set up a Connection or Network > Connect To a Workplace > Next.
Use My Internet Connection (VPN) > Enter the public IP address of the VPN server > Enter a Name for the Connection > Next > Enter your Domain Logon details > Connect.
I hope this helps. I couldn't find a single post covering all of this. There might be one out there. I couldn't find one so that's why I wrote this post. Enjoy!
Application Authentication Through VPN Tunnel Problem
This is a good "from the trenches" story, especially if you like networking. I've been working on this problem for exactly a week (no, not a crazy long time, but still, it's a while) and today I finally fixed the issue.
At work our main application for hr, payroll, general ledger, and employee self-service is called Springbrook. It's a nice, though slightly bloated, application that works for us. It's important to know how Springbrook is used for this story to make sense. Please bear with me while I give you the rundown.
The Springbrook application is installed on server1 along with the programs OpenEdge and Progress to handle all of the data processing for Springbrook. We have a separate drive just for Springbrook, OpenEdge and Progress. When the app is executed, the login page is opened in Internet Explorer. Springbrook uses the LDAP protocol (in our case Active Directory) to authenticate the user trying to login against the login id’s already inside of Springbrook, so when the session is established it requires that the user logs in and is authenticated to the domain which in turn makes the connection to the LDAP connector which verifies user info and allows them access.
How do the users run Springbrook? I have setup a mapped drive to the server on their workstations. I setup a desktop shortcut to the executable so the employees don't have to go that mapped drive each time and double-click the executable. So, it looks and feels like Springbrook is installed locally on their workstations.
This setup works great for local users right? What about remote users? We have those. One currently, but we're about to have one more permanent remote user. I decided to go with the VPN option in our Sonicwall TZ 210. It worked great. It was fast, surprisingly, and the user didn't have to go through remote desktop to use Springbrook which was nice. I mapped a drive to the server so she was able to use it just like the local users do. Fantastic.
Well, eight days ago Springbrook ran a service pack for the application. No problem because they do that on occasion to correct problems in the modules. The next day my remote user couldn't use Springbrook. I asked her if the VPN connected fine and she said "yeah, I can connect to the network, but I can't login to Springbrook." I told her to wait and I would be there in about fifteen minutes. I went through the checklist and found that nothing should be preventing her from logging in to Springbrook. I was so confused. The only change was the service pack install. I contacted Springbrook about this and the tech told me that somehow the authentication isn't happening in the VPN tunnel.
Okay. I knew that, haha
He then said that they use Citrix for their remote employees. I'm sure Citrix has a very nice WebApp tool, but if I can do this through a VPN tunnel and save us money that would be great. I don't like to go with paid solutions if we can implement a solution with equipment and software we already have. So, since I couldn't figure the problem out I decided to hit the forums. A person at serverfault recommended the VPN option in Windows Server 2008. I thought, "Why not?" I set that up in my lab. The VPN connection was fast, smooth, and near painless. *I'm going to write a blog post about it because it's so simple and there wasn't a single post containing all of the steps, instead I had to piece it together from multiple posts - ugh* Anyway, I connected to the VPN server, accessed the Springbrook share, ran Springbrook and guess what? I couldn't login to Springbrook. THE EXACT SAME PROBLEM. I understood possibly having an authentication issue using Sonicwall's VPN but there is no way that my server couldn't authenticate me because I connected to that server with my Active Directory credentials.
I was livid. Suddenly, I thought, "Why don't I try adding the .local to the domain name in the domain field?" The Springbrook login window requires a username, password, and a domain. All users and I mean all of our users don't have to put the .local for the domain however when you're up against a wall you try anything. I added .local to the domain name and then Springbrook launched. That fixed the issue. I couldn't believe it. I then wondered if that was the problem going through Sonicwall? I called the remote user, asked her when I could work on this for her, she said now and so I went to her office. I enabled the Sonicwall VPN connection, ran the Springbrook application, added the .local to the domain name and like a charm I was running Springbrook. The user was happy and yeah I was happy, but I want to know why I have to add .local to the domain name when logging in remotely now. Remote users didn't have to do that before last week. Why now?
I'm not satisfied. Could it be the recent Springbrook service pack update? I contacted Springbrook support and hopefully I'll hear back from them soon.
Anyway, lesson is try the easy things first. Like usual.
At work our main application for hr, payroll, general ledger, and employee self-service is called Springbrook. It's a nice, though slightly bloated, application that works for us. It's important to know how Springbrook is used for this story to make sense. Please bear with me while I give you the rundown.
The Springbrook application is installed on server1 along with the programs OpenEdge and Progress to handle all of the data processing for Springbrook. We have a separate drive just for Springbrook, OpenEdge and Progress. When the app is executed, the login page is opened in Internet Explorer. Springbrook uses the LDAP protocol (in our case Active Directory) to authenticate the user trying to login against the login id’s already inside of Springbrook, so when the session is established it requires that the user logs in and is authenticated to the domain which in turn makes the connection to the LDAP connector which verifies user info and allows them access.
How do the users run Springbrook? I have setup a mapped drive to the server on their workstations. I setup a desktop shortcut to the executable so the employees don't have to go that mapped drive each time and double-click the executable. So, it looks and feels like Springbrook is installed locally on their workstations.
This setup works great for local users right? What about remote users? We have those. One currently, but we're about to have one more permanent remote user. I decided to go with the VPN option in our Sonicwall TZ 210. It worked great. It was fast, surprisingly, and the user didn't have to go through remote desktop to use Springbrook which was nice. I mapped a drive to the server so she was able to use it just like the local users do. Fantastic.
Well, eight days ago Springbrook ran a service pack for the application. No problem because they do that on occasion to correct problems in the modules. The next day my remote user couldn't use Springbrook. I asked her if the VPN connected fine and she said "yeah, I can connect to the network, but I can't login to Springbrook." I told her to wait and I would be there in about fifteen minutes. I went through the checklist and found that nothing should be preventing her from logging in to Springbrook. I was so confused. The only change was the service pack install. I contacted Springbrook about this and the tech told me that somehow the authentication isn't happening in the VPN tunnel.
Okay. I knew that, haha
He then said that they use Citrix for their remote employees. I'm sure Citrix has a very nice WebApp tool, but if I can do this through a VPN tunnel and save us money that would be great. I don't like to go with paid solutions if we can implement a solution with equipment and software we already have. So, since I couldn't figure the problem out I decided to hit the forums. A person at serverfault recommended the VPN option in Windows Server 2008. I thought, "Why not?" I set that up in my lab. The VPN connection was fast, smooth, and near painless. *I'm going to write a blog post about it because it's so simple and there wasn't a single post containing all of the steps, instead I had to piece it together from multiple posts - ugh* Anyway, I connected to the VPN server, accessed the Springbrook share, ran Springbrook and guess what? I couldn't login to Springbrook. THE EXACT SAME PROBLEM. I understood possibly having an authentication issue using Sonicwall's VPN but there is no way that my server couldn't authenticate me because I connected to that server with my Active Directory credentials.
I was livid. Suddenly, I thought, "Why don't I try adding the .local to the domain name in the domain field?" The Springbrook login window requires a username, password, and a domain. All users and I mean all of our users don't have to put the .local for the domain however when you're up against a wall you try anything. I added .local to the domain name and then Springbrook launched. That fixed the issue. I couldn't believe it. I then wondered if that was the problem going through Sonicwall? I called the remote user, asked her when I could work on this for her, she said now and so I went to her office. I enabled the Sonicwall VPN connection, ran the Springbrook application, added the .local to the domain name and like a charm I was running Springbrook. The user was happy and yeah I was happy, but I want to know why I have to add .local to the domain name when logging in remotely now. Remote users didn't have to do that before last week. Why now?
I'm not satisfied. Could it be the recent Springbrook service pack update? I contacted Springbrook support and hopefully I'll hear back from them soon.
Anyway, lesson is try the easy things first. Like usual.
Monday, December 10, 2012
.NET 4 Full Install Saved The Day
Last week ended well. A remote user has been using a work app in an odd way and now she can finally use it 99% just like the users at our main site. Cool. Before, I had her connecting to our main site via Sonicwall Global VPN client, then using RDP to a virtual machine. No, it's not a horrible way to use the app, but it's not the best. Why did I have her setup this way? I'll explain.
Our application we use for HR, payroll, general ledger, project management, etc. runs from serer1. It's installed on that server. Our main site users have a mapped drive to server1 and a shortcut to the app on their desktops. They click on the shortcut, and since the app is web based, IE 8/9 pops up with the app graphic and a link for the database to connect to. Once the database link is clicked, the login window pops up for the user to put in her credentials then away she goes working. That's how the run process, well, runs. For the remote user, I had in mind the following: connect via vpn then use the app just like users at the main do. Well, my setup didn't go as planned. Earlier this year when I setup the remote user for app use, I ran the sonicwall vpn global client to connect to our main site. I mapped the drive to server1, placed the shortcut to the app on her desktop, clicked on it, ran the config, the IE app graphic window popped up, I clicked on the database link, but then nothing happened after that. Nothing. I clicked again and nothing. I at least expected an error message, but I wasn't given anything. The user was pressed for time. I asked her if I could investigate, that it could probably take a lot of time and she more or less said "no." I told her I could make a quick fix and she was fine with that. So, I setup the RDP method. She was fine with that and she had been fine with that for many months.
Last week she reminded me about it and wondered if I could eliminate the remote step. I told her it would probably take some time and she was fine with that. I setup a lab in my office, almost identical to her setup (the only difference was my connection was wireless). In my lab an error message displayed on the screen. I clicked on the database link, then BAM an error message popped up reporting an app crash. I flew to the event viewer and found an application crash reported. I then decided to compare and contrast my lab setup and our production setup. I found a difference (besides the vpn connection, :P): our production computers had .NET Framework 4 Extended and Client Profile whereas my lab computer only had .NET Framework 4 Client Profile. So, I installed .NET 4 Full on my lab computer and after that the app worked flawlessly.
I then called the remote user, setup a time, went out there installed .NET 4 full and then the app worked exactly as it should have worked. The user was ecstatic. I had never seen her so happy. She told me she didn't mind going through the RDP, but the text was small, the connection would timeout after inactivity; just those little things that don't ruin your work, but are just so annoying you can't work happily you know? Well, so far, so great for her current setup. All she has to do now is run the sonicwall global vpn client then she is able to work within the app.
Any suggestions for an alternate setup?
Our application we use for HR, payroll, general ledger, project management, etc. runs from serer1. It's installed on that server. Our main site users have a mapped drive to server1 and a shortcut to the app on their desktops. They click on the shortcut, and since the app is web based, IE 8/9 pops up with the app graphic and a link for the database to connect to. Once the database link is clicked, the login window pops up for the user to put in her credentials then away she goes working. That's how the run process, well, runs. For the remote user, I had in mind the following: connect via vpn then use the app just like users at the main do. Well, my setup didn't go as planned. Earlier this year when I setup the remote user for app use, I ran the sonicwall vpn global client to connect to our main site. I mapped the drive to server1, placed the shortcut to the app on her desktop, clicked on it, ran the config, the IE app graphic window popped up, I clicked on the database link, but then nothing happened after that. Nothing. I clicked again and nothing. I at least expected an error message, but I wasn't given anything. The user was pressed for time. I asked her if I could investigate, that it could probably take a lot of time and she more or less said "no." I told her I could make a quick fix and she was fine with that. So, I setup the RDP method. She was fine with that and she had been fine with that for many months.
Last week she reminded me about it and wondered if I could eliminate the remote step. I told her it would probably take some time and she was fine with that. I setup a lab in my office, almost identical to her setup (the only difference was my connection was wireless). In my lab an error message displayed on the screen. I clicked on the database link, then BAM an error message popped up reporting an app crash. I flew to the event viewer and found an application crash reported. I then decided to compare and contrast my lab setup and our production setup. I found a difference (besides the vpn connection, :P): our production computers had .NET Framework 4 Extended and Client Profile whereas my lab computer only had .NET Framework 4 Client Profile. So, I installed .NET 4 Full on my lab computer and after that the app worked flawlessly.
I then called the remote user, setup a time, went out there installed .NET 4 full and then the app worked exactly as it should have worked. The user was ecstatic. I had never seen her so happy. She told me she didn't mind going through the RDP, but the text was small, the connection would timeout after inactivity; just those little things that don't ruin your work, but are just so annoying you can't work happily you know? Well, so far, so great for her current setup. All she has to do now is run the sonicwall global vpn client then she is able to work within the app.
Any suggestions for an alternate setup?
Tuesday, October 23, 2012
My internet broke! What do I do?
You've heard it many times. You get the call from an employee, family member, or friend (sometimes all three-shudder) telling you something like, "I can't get on the internet. Help!" This will vary depending on your crisis stricken caller's techie-ness, of course, but they're basically telling you, "Hey, my internet is broke. Fix it. Now. I need to check my [insert preferred social media site here], then my email, then youtube to watch funny animals and people falling down, then some gossip columns, then amazon."
What do you do?
I remember in college and during my CompTIA studies that the number one, most important thing you do before anything else is interrogate the person you're helping. What were you doing when this happened? What was the last program you used? Did you hear any noises? Did any error messages pop up on the screen? And so on. That's important, sure, but that kind of approach really depends on the person doesn't it? In my experience the bulk of persons tell me what they can't do and then leave me. I used to try and ask questions, but those questions got me nowhere fast or slow. My approach is to ask the person what they can't do and what they want to be able to do. Quick. Simple. Then the person can leave while I try to make that happen.
To fix the "internet is broke" problem we'll make a list. This list I use at for home users and business users.
Determine environment
Is this PC a member of a domain? Is it a type of server? Is it workgroup PC? Is it a stand-alone PC? This is the number one thing to find out. If it's a stand-alone PC then you won't have to go through as many tasks as a PC that is a member of an active directory domain, right?
Renew the IP address
First and foremost, the easiest fix may be renewing the IP address if it's a device that utilizes DHCP. To determine if it is go the command prompt ( start, run cmd.exe for XP users, start search cmd, click on cmd for vista and above users) and enter the following command: ipconfig /all Look for the word 'DHCP Enabled' You should see to the right of that a 'Yes' or 'No.'
If DHCP is enabled, then run the following commands while still in the command prompt: ipconfig /release then ipconfig /renew This could fix the problem
Flush the DNS cache
DNS is darn important for web browsing. Let me say that again: DNS is darn important for web browsing. When a person looks up sites on the internet your device keeps a record of the DNS "stuff" for that site in some files on your device for quicker lookup time when you visit the site again. Sometimes, the DNS information (cache for us techies) stored on your device can get "messed up" (corrupted, no longer valid information) and this can cause you to not be able to visit certain sites. Well, this can be fixed. While a simple reboot can do the trick, entering following command at the command prompt is quicker: ipconfig /flushdns If successful the cmd prompt will return the following: Windows IP Configuration Successfully flushed the DNS Resolver Cache
Now, this method will work for a stand-alone PC, but what if the PC is a networked PC? For example, if it's a PC connected to a router. Well, the router also has a DNS cache. If that is corrupted, then it needs to be fixed. Reboot (turn off, then turn on) the router to fix the problem.
What if the PC is connected to a domain that has a DNS Server? The DNS server also has a DNS cache. How do you clear the DNS cache on a Windows DNS server?
- Open DNS in your Windows Server
- In the tree click on the DNS server(s)
- On the action menu (or right clicked menu), click clear cache.
These steps work for IE 7, 8, and 9.
In IE, go to Tools > Options
The Options windows opens. Click on Advanced. You should see a Reset button in the lower right portion of the window under a heading that reads, "Reset Internet Explorer Settings." Click on the Reset button.
In the Reset Internet Explorer Settings Dialog box, click on the Reset button.
After a little bit, IE will be return to the default state.
Dive Into the Windows firewall configuration
For Windows 7 users, click start and in the search bar type 'windows firewall' then click enter. For Windows XP users go to control panel then find Windows Firewall.
Try disabling rules/exceptions one at a time, checking internet searching after disabling each one. You might find that a certain rule/exception is blocking internet all together or certain sites.
Reset TCP/IP
If you can't connect to the internet, the TCP/IP protocol may be corrupted. If it is, then you'll need to reset this protocol using the netsh utility via command prompt logged in as an admin.
1. Open command prompt as an admin (start, run cmd.exe for XP users, start search cmd, right click cmd, run as admin for vista and above users).
2. At the command prompt, enter the following command and then press ENTER: netsh int ip reset c:\resetlog.txt By the way, you don't have to specify a directory path for the log file. If you don't want to, drop the "c:\" from the "resetlog.txt" portion of the command.
3. Reboot the computer.
Repair Winsock
If resetting TCP/IP didn't work, for example, if you're still getting "page cannot be displayed" when trying to access a site, or if Filezilla isn't working correctly then it may be a Winsock problem. Run the following command in command prompt as an admin to repair winsock netsh winsock reset catalog After repairing winsock (you're taking it back to default configurations) you may, MAY, have to reinstall services that use winsock.
Reset the default hosts file *copied and pasted from Microsoft*
To reset the Hosts file back to the default, follow these steps:
- Click Start, click Run, type %systemroot% \system32\drivers\etc, and then click OK.
- Rename the Hosts file to Hosts.old.
- Create a new default hosts file. To do this, follow these steps:
- Right-click an open space in the %WinDir%\System32\Drivers\Etc folder, point to New, click Text Document, type hosts, and then press Enter.
- Click Yes to confirm that the file name extension will not be .txt.
- Open the new Hosts file in a text editor. For example, open the file in Notepad.
- Copy the following text to the file:
For Windows XP or for Windows Server 2003For Windows Vista or for Windows Server 2008# Copyright (c) 1993-1999 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host 127.0.0.1 localhost
For Windows 7# Copyright (c) 1993-2006 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host 127.0.0.1 localhost ::1 localhost
# Copyright (c) 1993-2006 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host # localhost name resolution is handle within DNS itself. # 127.0.0.1 localhost # ::1 localhost
- Save and then close the file.
If this PC is connected to a network then the problem may very well be another PC or device causing the internet problem. Doing the above suggestions all day long won't fix the issue if another device on the network is the culprit.
Wednesday, October 10, 2012
Change the Interface DHCP Lease Is Bound To in Sonicwall
* Note: this blog post is about Sonicwall firmware version
"SonicOS Enhanced 5.8.1.5-46o"
So you've went through the VPN wizard. It's running. You have people using it. It's great. Oh wait! What's that? In your security log you see "attacks" labeled as "IP Spoof." Looking at the log, it shows the user logging in on interface X0, but their IP on your network is a X2 address. Sonicwall thinks it is an IP spoof. You see the external IP. You recognize the external IP is from one of your remote sites. It's no threat, but you would like for Sonicwall to not log it anymore. How do you fix it? I'm glad you asked.
Example setup.
X0\ LAN\ Static\ 192.168.10.XXXX\ you use this for DHCP for your wifi users
X1\WAN
X2\ LAN\ Static\ 192.168.1.XXXX\ this is your production network that doesn't utilize DHCP every user on this network has a static IP
In your VPN setup, Sonicwall binds the DHCP lease to the interface that uses DHCP (genius idea right?). So you've built this VPN connection. On the client's machine, you install the Sonicwall VPN client software to connect to the network. You want her to be on the production network though, so you change the virtual adapter the Sonicwall client uses on her machine to a 192.168.1. address. Now, she is able to access production network resources like she wanted. Great.
Back home, you see in the security logs, the IP Spoof stuff. How is that fixed? In the Sonicwall admin panel, go to VPN\DHCP over VPN. Click the dropdown box, select Remote Gateway then click configure.
You should see the following, "DHCP Lease Bound To:" and a dropdown box next to that with the various interfaces. Following our example above, choose the X2 interface so the client will be on the production network when logged in using the VPN.
Then click OK. You might see a goofy red message, but it won't keep you from making the change to the DHCP lease binding.
So you've went through the VPN wizard. It's running. You have people using it. It's great. Oh wait! What's that? In your security log you see "attacks" labeled as "IP Spoof." Looking at the log, it shows the user logging in on interface X0, but their IP on your network is a X2 address. Sonicwall thinks it is an IP spoof. You see the external IP. You recognize the external IP is from one of your remote sites. It's no threat, but you would like for Sonicwall to not log it anymore. How do you fix it? I'm glad you asked.
Example setup.
X0\ LAN\ Static\ 192.168.10.XXXX\ you use this for DHCP for your wifi users
X1\WAN
X2\ LAN\ Static\ 192.168.1.XXXX\ this is your production network that doesn't utilize DHCP every user on this network has a static IP
In your VPN setup, Sonicwall binds the DHCP lease to the interface that uses DHCP (genius idea right?). So you've built this VPN connection. On the client's machine, you install the Sonicwall VPN client software to connect to the network. You want her to be on the production network though, so you change the virtual adapter the Sonicwall client uses on her machine to a 192.168.1. address. Now, she is able to access production network resources like she wanted. Great.
Back home, you see in the security logs, the IP Spoof stuff. How is that fixed? In the Sonicwall admin panel, go to VPN\DHCP over VPN. Click the dropdown box, select Remote Gateway then click configure.
You should see the following, "DHCP Lease Bound To:" and a dropdown box next to that with the various interfaces. Following our example above, choose the X2 interface so the client will be on the production network when logged in using the VPN.
Tuesday, October 9, 2012
Hardware Firewall Is a Must
From TechRepublic's recent "10 Things" blog:
6: Deploy a hardware-based firewall Let’s face it: The built-in Windows firewall is simply not sufficient. If you want real security, you need a dedicated firewall on your network. This firewall will be a single point of entry that will stop many more attempted breaches than the standard software-based firewall will. Besides, the hardware-based fire will be far more flexible and customizable. Look at a Cisco, Sonicwall, or Fortinet hardware firewall as your primary protection.
This is an excellent, excellent, (did I say excellent?) recommendation. If you or your business is connected straight to your modem without any border protection from the external world then you're in jeopardy and by jeopardy I don't mean the game show, I mean trouble. Why? Because your PC or group of PCs have an external IP. Your device doesn't have a bouncer to keep the bad guys and crap out of your house. You don't have that extra layer of protection that a connected device needs to operate more securely. Now, don't think a hardware firewall will make you invincible. I don't want to paint the wrong picture. I do mean to say that a hardware based firewall along with other security measures can make you more secure.
What are the benefits of a hardware based firewall?
1. NAT
*cue hissing* Some techs don't think NAT is a security feature, but I do. There is some mystery regarding NAT. Was it meant for security? Was it not meant for security? I think it's up in the air. Even so, I think it's fair to say that NAT gives *some* security in that it gives your device a local IP instead of your public, external IP. Intruders, the green ones conservatively speaking, won't know your device's IP which does help. No, it's not a super excellent security feature, but it's just another layer of protection that is nice to have while we're still mostly in a IPv4 world.
2. Rules
With a hardware based firewall, you can make firewall rules which are rules that you create to allow the traffic you want coming in and leaving your network. You can make as many or as little rules as you like. Don't want RDP sessions coming in to your network? Block it. Don't like WMI packets coming in? Block those too. It's customizable. Some techs start by blocking everything then slowly unblocking ports as the days progress. For example, a tech had most ports blocked. He downloaded WoW was able to run some of it, then realized he needed to open certain ports for the game, so he did. That's what I mean by some techs block everything, then slowly open ports when the situation occurs. You don't need everything open right out of the gate. Only open ports that you need open.
3. Logs
Yeah, Windows and other OSs have log views, they're limited to your system though. With a hardware firewall you'll have logs informing you who and what was trying to access your network. You'll see your rules working. You'll see intrusions prevented, this app allowed, another app blocked and so on. It's helpful. It's encouraging. You can see your firewall at work or not at work. You'll see what's getting in, out, and blocked. Those are three reasons I can think of right away for getting a hardware firewall. You don't have to spend hundreds of dollars on a hardware firewall either. Routers come equipped with firewalls. For my home I use a Netgear wireless router that is excellent for my home setup. The firewall provides good protection, customization, and it's easy to use. Buy one.
Netgear WNR3500L this link gives you the specs and has links to the stores it's sold at.
* I didn't make the image used in this blog post. I found it in a google search from this website.
6: Deploy a hardware-based firewall Let’s face it: The built-in Windows firewall is simply not sufficient. If you want real security, you need a dedicated firewall on your network. This firewall will be a single point of entry that will stop many more attempted breaches than the standard software-based firewall will. Besides, the hardware-based fire will be far more flexible and customizable. Look at a Cisco, Sonicwall, or Fortinet hardware firewall as your primary protection.
This is an excellent, excellent, (did I say excellent?) recommendation. If you or your business is connected straight to your modem without any border protection from the external world then you're in jeopardy and by jeopardy I don't mean the game show, I mean trouble. Why? Because your PC or group of PCs have an external IP. Your device doesn't have a bouncer to keep the bad guys and crap out of your house. You don't have that extra layer of protection that a connected device needs to operate more securely. Now, don't think a hardware firewall will make you invincible. I don't want to paint the wrong picture. I do mean to say that a hardware based firewall along with other security measures can make you more secure.
1. NAT
*cue hissing* Some techs don't think NAT is a security feature, but I do. There is some mystery regarding NAT. Was it meant for security? Was it not meant for security? I think it's up in the air. Even so, I think it's fair to say that NAT gives *some* security in that it gives your device a local IP instead of your public, external IP. Intruders, the green ones conservatively speaking, won't know your device's IP which does help. No, it's not a super excellent security feature, but it's just another layer of protection that is nice to have while we're still mostly in a IPv4 world.
2. Rules
With a hardware based firewall, you can make firewall rules which are rules that you create to allow the traffic you want coming in and leaving your network. You can make as many or as little rules as you like. Don't want RDP sessions coming in to your network? Block it. Don't like WMI packets coming in? Block those too. It's customizable. Some techs start by blocking everything then slowly unblocking ports as the days progress. For example, a tech had most ports blocked. He downloaded WoW was able to run some of it, then realized he needed to open certain ports for the game, so he did. That's what I mean by some techs block everything, then slowly open ports when the situation occurs. You don't need everything open right out of the gate. Only open ports that you need open.
3. Logs
Yeah, Windows and other OSs have log views, they're limited to your system though. With a hardware firewall you'll have logs informing you who and what was trying to access your network. You'll see your rules working. You'll see intrusions prevented, this app allowed, another app blocked and so on. It's helpful. It's encouraging. You can see your firewall at work or not at work. You'll see what's getting in, out, and blocked. Those are three reasons I can think of right away for getting a hardware firewall. You don't have to spend hundreds of dollars on a hardware firewall either. Routers come equipped with firewalls. For my home I use a Netgear wireless router that is excellent for my home setup. The firewall provides good protection, customization, and it's easy to use. Buy one.
Netgear WNR3500L this link gives you the specs and has links to the stores it's sold at.
* I didn't make the image used in this blog post. I found it in a google search from this website.
Thursday, August 30, 2012
Create an Alternate HTTPS port in Sonicwall
For my new project with Remote Desktop Services, specifically Remote Apps offered externally to our network, I had to create an alternate HTTPS port in my Sonicwall TZ210 because we couldn't afford a new external IP (politics). Anyway, here's what you do.
Login to your Sonicwall appliance. In the left column, under network, click on Services. You're now in the Services section. Under Services, click on "add." The Add window opens allowing you to create your service. You should have fields for name, protocol, port range, and sub-type. After you've named your Service, select TCP for IP type and now put in the port range you want. For this setup, you probably only want one port number, so the range fields need the same number, e.g. beginning 1500 and ending with 1500. Click Add and you're done.
Just above Services is Service Groups. Click on Add Group. The Add Group window will open and you can customize your Service Group (I labeled mine <server name> RD Web). After you've named it, find the Service you created and add the Service to your Service Group. Click OK and you're done. You've created the alternate port for 443!
This is how you should feel after this accomplishment. Celebrate by yelling and beating your chest.
Login to your Sonicwall appliance. In the left column, under network, click on Services. You're now in the Services section. Under Services, click on "add." The Add window opens allowing you to create your service. You should have fields for name, protocol, port range, and sub-type. After you've named your Service, select TCP for IP type and now put in the port range you want. For this setup, you probably only want one port number, so the range fields need the same number, e.g. beginning 1500 and ending with 1500. Click Add and you're done.
Just above Services is Service Groups. Click on Add Group. The Add Group window will open and you can customize your Service Group (I labeled mine <server name> RD Web). After you've named it, find the Service you created and add the Service to your Service Group. Click OK and you're done. You've created the alternate port for 443!
This is how you should feel after this accomplishment. Celebrate by yelling and beating your chest.
Tuesday, August 21, 2012
Issues with camera system
At work we have a 12 camera Geovision surveillance system that runs a TCP/IP service allowing LAN users to access the system and a Web service allowing authorized WAN users/devices to access the system from outside our network. This has been in place for at least 2 years now. Well, the other day I decided to access the system from home to see if our PTZ camera was working (I had heard a complaint). I couldn't connect. More specifically, using the external IP and the port number only resulted with Google telling me it couldn't find anything related to such madness. Curious, I contacted my boss and asked him the last time he accessed the system from his iPad (geovision app). He told me it had been a long time and to not worry about fixing the problem until the next day at work. Cool.
When I arrived at work I checked the following, but I didn't follow my policy of starting with external then going internal; if I had, then I would have fixed the issue sooner. What I did was start the complete opposite. Doh!
What I did
Began with the camera server. I checked the local firewall settings. Windows Firewall was on and allowing exceptions. I had all of the correct exceptions checked too. I then moved to turning off the local firewall on the camera server and accessing externally, but that didn't work. The Web Cam service was running also on the camera server. So, no problem with that device.
I then move to what I should have checked to begin with: Sonicwall. I checked the access rules, but I didn't see anything out of the ordinary. Everything we use was right there in the list. I then go to the NAT policies. Ah-ha! I see an odd NAT service called "our server name"-services with http and https. What? My comment on the NAT rule sucked too: sick/vacation. That didn't make sense to me because I had the correct mail server stuff running and I couldn't imagine why this NAT rule could be used for mail server stuff. My geovision services use http (8080) for the web access and this random NAT service also using 8080 was conflicting with the geovision service, which is why we couldn't access the camera system externally. I turned off the random NAT rule, tried the web cam externally and like a charm I was able to access the camera system. It wasn't cheer time just yet though because I had to make sure our mail service with our employee self-service system was still running with that random NAT service turned off. I tried it out and yes, it still worked.
What did I learn from this experience? I learned a few things (things I already know, but haven't put into habitual practice yet - FAIL).
1. Work from external to internal. Working this way keeps things simple because it's easy to get the external stuff out of the way first since there aren't as many things external as there are internal.
2. Document clearly. Even non-firewall things need to be documented clearly. When you're doing something at your work leave notes on why you're doing this or doing that. I have no idea why I made that NAT rule and the comment didn't help me at all. I was testing something, but failed to turn it back off. If I had documented clearly then I would have known the purpose of that NAT rule.
3. When you turn a service off or on or replace/whatever make sure your production services are running just as they should be. You know you've done something right when the only thing the employees notice is the new thing they were expecting or nothing at all after your network project.
When I arrived at work I checked the following, but I didn't follow my policy of starting with external then going internal; if I had, then I would have fixed the issue sooner. What I did was start the complete opposite. Doh!
What I did
Began with the camera server. I checked the local firewall settings. Windows Firewall was on and allowing exceptions. I had all of the correct exceptions checked too. I then moved to turning off the local firewall on the camera server and accessing externally, but that didn't work. The Web Cam service was running also on the camera server. So, no problem with that device.
I then move to what I should have checked to begin with: Sonicwall. I checked the access rules, but I didn't see anything out of the ordinary. Everything we use was right there in the list. I then go to the NAT policies. Ah-ha! I see an odd NAT service called "our server name"-services with http and https. What? My comment on the NAT rule sucked too: sick/vacation. That didn't make sense to me because I had the correct mail server stuff running and I couldn't imagine why this NAT rule could be used for mail server stuff. My geovision services use http (8080) for the web access and this random NAT service also using 8080 was conflicting with the geovision service, which is why we couldn't access the camera system externally. I turned off the random NAT rule, tried the web cam externally and like a charm I was able to access the camera system. It wasn't cheer time just yet though because I had to make sure our mail service with our employee self-service system was still running with that random NAT service turned off. I tried it out and yes, it still worked.
What did I learn from this experience? I learned a few things (things I already know, but haven't put into habitual practice yet - FAIL).
1. Work from external to internal. Working this way keeps things simple because it's easy to get the external stuff out of the way first since there aren't as many things external as there are internal.
2. Document clearly. Even non-firewall things need to be documented clearly. When you're doing something at your work leave notes on why you're doing this or doing that. I have no idea why I made that NAT rule and the comment didn't help me at all. I was testing something, but failed to turn it back off. If I had documented clearly then I would have known the purpose of that NAT rule.
3. When you turn a service off or on or replace/whatever make sure your production services are running just as they should be. You know you've done something right when the only thing the employees notice is the new thing they were expecting or nothing at all after your network project.
Tuesday, August 14, 2012
Daily Security Checklist
I don't fancy myself as one of the greats in the IT world. I know I'm a lowly rookie IT professional just starting out, but I do think my daily security checklist is worth sharing. If you don't have a security checklist you go through each day you might want to create one (heck, steal mine I don't care) just so you will be able to catch things in time and for peace of mind. If I'm able, I go through this checklist first thing before I do anything else unless there's urgent work waiting for me as soon as I step through the double doors (we have a set of double doors at our building - nothing fancy, but it's kind of cool to walk through them all bad and stuff). This checklist is tailored for our network, so I'll be using the names of hardware and software we have. If you don't have the same hardware and software, replace the name for your configuration, e.g. replace Sonicwall with Cisco, Juniper, etc.
Checking the border - Firewall and DNS
Our border firewall is a Sonicwall TZ 210. This bad boy is perfect for our environment: small in physical size, priced just right, excellent security, small learning curve, and boasts a lot of tools for the admin. I check the Sonicwall logs first thing because that is the point between us and the "external." I check the following logs: attacks, anti-spam service, and networking. I then move over to the current connections under the firewall tab. After that, I check out the current data from the security dashboard. I'm not familiar with other hardware/border firewalls, Sonicwall is my area, but I would think Cisco and Juniper have similar types of logs and such. I think it's important to check the logs first thing and the current connections in and out of your network. After a while, you'll notice the "everyday" stuff. Even though it's tempting to not check these things after a week or so of clean data don't do it. Resist!
DNS security
This step might not be a necessary step depending on your configuration. I check our OpenDNS records after the border firewall check because next in line is our DNS security, so that's the logic I follow (maybe it sucks, but it works for me - haha). Anyway, I login to our OpenDNS dashboard and check the logs. It's important to see what network users are accessing and trying to access. I notice a lot of adware and malware blocked by OpenDNS. The cool thing about OpenDNS is their alert system. If OpenDNS has detected malware, you see the alert in big red letters on your dashboard. The only problem is that OpenDNS can't give you the internal IP address, but it's because it's border protection. So, not only is OpenDNS good for web service, but it's security system is nice as well.
Checking the Inside: Network Monitor, Server, and Antivirus
I then move on to internal checks. Network monitoring tools come in handy here, e.g. LANsweeper and Spiceworks, checking vulnerabilities on PCs and non-PCs. LANsweeper has an excellent dashboard view giving you information like the following: pcs not up-to-date, infections, low disk space, recent changes and other cool stuff for non-PC devices. Most network monitoring software does this. I check the necessary reports then move on.
Next, I check the Windows Server 2008 R2 logs in the server manager. If you don't use Server Manager I recommend it for the simplicity. Everything you need for quick checks is there: roles, functions, and event viewer. I check the high priority events then move on to antivirus. We use Kaspersky Small Office Security. I check the scans of all the PCs in the network to make sure there weren't any infections detected and I also check to make sure all of the PCs were updated.
That is my security checklist. I follow the outside to inside approach because it makes sense to me. Usually the biggest threats will come from the outside (threats users don't notice) and the smaller threats are on the inside. If you have any suggestions feel free to comment on this post. I'm usually on the lookout to improve my checklist.
Checking the border - Firewall and DNS
Our border firewall is a Sonicwall TZ 210. This bad boy is perfect for our environment: small in physical size, priced just right, excellent security, small learning curve, and boasts a lot of tools for the admin. I check the Sonicwall logs first thing because that is the point between us and the "external." I check the following logs: attacks, anti-spam service, and networking. I then move over to the current connections under the firewall tab. After that, I check out the current data from the security dashboard. I'm not familiar with other hardware/border firewalls, Sonicwall is my area, but I would think Cisco and Juniper have similar types of logs and such. I think it's important to check the logs first thing and the current connections in and out of your network. After a while, you'll notice the "everyday" stuff. Even though it's tempting to not check these things after a week or so of clean data don't do it. Resist!
DNS security
This step might not be a necessary step depending on your configuration. I check our OpenDNS records after the border firewall check because next in line is our DNS security, so that's the logic I follow (maybe it sucks, but it works for me - haha). Anyway, I login to our OpenDNS dashboard and check the logs. It's important to see what network users are accessing and trying to access. I notice a lot of adware and malware blocked by OpenDNS. The cool thing about OpenDNS is their alert system. If OpenDNS has detected malware, you see the alert in big red letters on your dashboard. The only problem is that OpenDNS can't give you the internal IP address, but it's because it's border protection. So, not only is OpenDNS good for web service, but it's security system is nice as well.
Checking the Inside: Network Monitor, Server, and Antivirus
I then move on to internal checks. Network monitoring tools come in handy here, e.g. LANsweeper and Spiceworks, checking vulnerabilities on PCs and non-PCs. LANsweeper has an excellent dashboard view giving you information like the following: pcs not up-to-date, infections, low disk space, recent changes and other cool stuff for non-PC devices. Most network monitoring software does this. I check the necessary reports then move on.
Next, I check the Windows Server 2008 R2 logs in the server manager. If you don't use Server Manager I recommend it for the simplicity. Everything you need for quick checks is there: roles, functions, and event viewer. I check the high priority events then move on to antivirus. We use Kaspersky Small Office Security. I check the scans of all the PCs in the network to make sure there weren't any infections detected and I also check to make sure all of the PCs were updated.
That is my security checklist. I follow the outside to inside approach because it makes sense to me. Usually the biggest threats will come from the outside (threats users don't notice) and the smaller threats are on the inside. If you have any suggestions feel free to comment on this post. I'm usually on the lookout to improve my checklist.
Thursday, July 12, 2012
PCs Intermittently Lose Connection to Server
Have you had this problem with your network? Over the past 2 1/2 years at work I've had this problem. We have funding/accounting/management software installed on Server1 and users who "use" this software do so via a mapped drive on their PC to Server1. Once in a blue moon a few PCs (not the same ones each time) will lose connection to Server1 (this happened 3 times - odd) completely, i.e. PC can't ping, RD to, or access shares on Server1 and likewise with Server1 to the PCs. The communication between them is dead, over, gone...you get it. How do I solve the problem? Now, the PCs can communicate with other nodes on the network, which they're getting juice to do that from Server2 I suppose. How do I solve the problem? By restarting Server1. I don't want to do that each time though. I want to know why this is happening and if there is another way to fix it.
Keep in mind that when I troubleshot this issue the user was impatient and wanted "it" fixed right away, so I didn't have the time to explore the problem deeply. The following is what I tried in order to keep from restarting Server1.
1. Restarting the problem PC. It didn't work.
2. Rejoining the PC to the domain. I took the PC off the domain, joined it to WORKGROUP then joined it to the domain. This didn't work either.
3. Did a GPUpdate via CMD line. Don't ask...I was scratching the bottom of the idea barrel. Obviously it didn't work.
That's what I tried. By this point the user was huffing and puffing. So, I went ahead and restarted the server and then all was right with the world; at least in the users world. So, I would like to fix this problem without resorting to server restart. Further, I would like to know what causes this to happen. I jumped over to Server Fault to glean wisdom from the sages there and boy did I glean!
Since the problem arises at random times and surfaces very little (3 times over 2 1/2 years) it's going to be difficult to actually troubleshoot this problem, but the guys over at Server Fault told me I could develop an attack plan for when it rears its ugly head again. So the plan, so far, is as follows: to see what is going on during the issue run Wireshark on one of the affect machines and also on Server1; to try and fix the issue disable then re-enable the network card on Server1 or run the following cmd on Server 1: arp -d* (enter). These were just a few suggestions given to me. I thought there would be a network service I could restart under Admin tools\Services, but the guys there said this isn't a service issue.
Anyway, I plan on updating this periodically as I explore the issue. I just posted the question at Server Fault today, so I might get more answers sometime after this posting.
***UPDATE*** 7/18/2012
The problem occurred again yesterday morning and at lunch, but this time it was just one PC that wasn't in the affected group last week. During the problem I did the following:
Went to the server, collected wireshark packets between the affected PC and the server. Then, I restarted the server because I know that works. That fixed the issue. I was only able to read through the collected data for a few minutes because other issues came up (I'm the only IT pro - one man crew) that occupied my time for the rest of the shift. Thought about it through the night. Came in this morning, collected network traffic just to see if there were any network process hogs and couldn't find anything bloating the "pipe." Then it hit me: check the kaspersky logs on the server. I checked the network attack blocker logs and found that last week Kaspersky detected dos.generic.synflood "attacks" from the 3 affected machines last week and the affected machine yesterday. When Kaspersky detects things like that, it will cut off communication with the attacking node for 60 minutes. The logs gave the exact time of the issue and the time matched up with the time affected users called me about the issue. I tracked the logs back 30 days and noticed those logs were clean of attacks.
I set the network attack blocker to only block the attacking node for 1 minute. I'm also going to investigate what the synflood attacks could be. At least for now I know why those machines were disconnected from the server. Of course now, I need to figure out the source of those dos.generic.synflood attacks.
Keep in mind that when I troubleshot this issue the user was impatient and wanted "it" fixed right away, so I didn't have the time to explore the problem deeply. The following is what I tried in order to keep from restarting Server1.
1. Restarting the problem PC. It didn't work.
2. Rejoining the PC to the domain. I took the PC off the domain, joined it to WORKGROUP then joined it to the domain. This didn't work either.
3. Did a GPUpdate via CMD line. Don't ask...I was scratching the bottom of the idea barrel. Obviously it didn't work.
That's what I tried. By this point the user was huffing and puffing. So, I went ahead and restarted the server and then all was right with the world; at least in the users world. So, I would like to fix this problem without resorting to server restart. Further, I would like to know what causes this to happen. I jumped over to Server Fault to glean wisdom from the sages there and boy did I glean!
Since the problem arises at random times and surfaces very little (3 times over 2 1/2 years) it's going to be difficult to actually troubleshoot this problem, but the guys over at Server Fault told me I could develop an attack plan for when it rears its ugly head again. So the plan, so far, is as follows: to see what is going on during the issue run Wireshark on one of the affect machines and also on Server1; to try and fix the issue disable then re-enable the network card on Server1 or run the following cmd on Server 1: arp -d* (enter). These were just a few suggestions given to me. I thought there would be a network service I could restart under Admin tools\Services, but the guys there said this isn't a service issue.
Anyway, I plan on updating this periodically as I explore the issue. I just posted the question at Server Fault today, so I might get more answers sometime after this posting.
***UPDATE*** 7/18/2012
The problem occurred again yesterday morning and at lunch, but this time it was just one PC that wasn't in the affected group last week. During the problem I did the following:
- Restarted the switch in her department - didn't work.
- Enabled then disabled her network adapter and the server adapter - didn't work
- Updated the driver on her PC this did work for the morning.
Went to the server, collected wireshark packets between the affected PC and the server. Then, I restarted the server because I know that works. That fixed the issue. I was only able to read through the collected data for a few minutes because other issues came up (I'm the only IT pro - one man crew) that occupied my time for the rest of the shift. Thought about it through the night. Came in this morning, collected network traffic just to see if there were any network process hogs and couldn't find anything bloating the "pipe." Then it hit me: check the kaspersky logs on the server. I checked the network attack blocker logs and found that last week Kaspersky detected dos.generic.synflood "attacks" from the 3 affected machines last week and the affected machine yesterday. When Kaspersky detects things like that, it will cut off communication with the attacking node for 60 minutes. The logs gave the exact time of the issue and the time matched up with the time affected users called me about the issue. I tracked the logs back 30 days and noticed those logs were clean of attacks.
I set the network attack blocker to only block the attacking node for 1 minute. I'm also going to investigate what the synflood attacks could be. At least for now I know why those machines were disconnected from the server. Of course now, I need to figure out the source of those dos.generic.synflood attacks.
Wednesday, June 13, 2012
Wrath of the Data Center!
There is a new podcast up over at Packet Pushers called Wrath of the Data Center. It's worth checking out. The official description of the podcast is: "...the new podcast dedicated to the pursuit of the CCIE Data Center
certification. The host of the show Tony Bourke brings guests to the
show to talk about CCIE Data Center study topics." Even if you're not actively pursuing the CCIE Data Center cert, the podcast is still worth checking out because of the wealth of information coming from professionals who are in the field, which is always profitable for IT pros.
The podcast page can be found here.
The podcast page can be found here.
Subscribe to:
Posts (Atom)