Showing posts with label FortiGate. Show all posts

Sunday, July 8, 2012

How to secure an inbound policy with a secondary user authentication

It is possible that you’d want to allow access to an inbound “service” that needs authentication before you actually hit the service it’s destine for. Lets say you have a web-server on the inside of your firewall. It has semi-private data on it, that you can’t easily secure with the web-application. Maybe you have a situation where you just want the service to be protected with a pre-authentication so brute-force against the web-application won’t work correctly.

Here’s how:

Create your VIP – If you don’t have one.

config firewall vip	Enter into VIP
edit External_HTTPS_T11443_w1	Name 1st VIP (I uses _w1 because you could create multiple for multiple WAN connections)
set extintf wan	Set External Interface
set mappedip 10.11.3.254	Set Internal IP
set portforward en	Enable PAT
set extport 11443	This is your External Port to Access GUI (I suggest not using 443)
set mappedport 443	This is the Internal Mgmt Port (443 is default)
End	End

Create a local user account – You could use LDAP if you wanted, but not covered in this tutorial.

config user local	Enter Local User Creation
edit allow	Enable the Account
set passwd SecurePassword	Set a Secure Password
end	End to save

Create a group to use for policy

config user group	Enter Group Creation
edit ServiceAuth	Name the group
set member “allow”	set the members, “allow” is the local account create previously

Config firewall policy - If you don’t have one.

config firewall policy	Enter Firewall Policy Creation
edit 0	“edit 0” creates a new entry after the biggest number.
set srcintf wan	set the Source Interface (wan) in this instance, probably a port or wan1/2 for you
set dstintf InternalSwitch	set Destination Interface (InternalSwitch). Likely a port or internal for you.
set srcaddr “all”	Set your Source Address. This is the group you created in previous steps
set dstaddr “External_HTTPS_T11443_w1”	Set your Destination Address. This is your VIP Group you created earlier
set action accept	Accept the traffic
set identity-based enable	Enable the ability to do Identity Based
edit 0	Create next ID
set schedule always	Set schedule
set logtraffic enable	Set logging of traffic
set groups “ServiceAuth”	Set the group (Created earlier)
end	End the Identity policy
end	End the Firewall Policy Save

How to use this new policy

Regardless of service needed, port forwarded/authenticated or any other application using this policy, you must first authenticate to the firewall before using it.
- It is extremely important that you authenticate using HTTPS and not HTTP. Otherwise, your credentials pass in the clear.
- Ex. if protecting RDP, you have to first go to https://ExternalIP:3389 and login with the local/group that is allowed into the policy
- Once you authenticate, you can then RDP directly into the ExternalIP
Once you authenticate, the authentication timer is started. It is possible you’d want to extend this

config user setting Enter the User Setting

set auth-timeout 240 Set the timeout in minutes for 4 hours, 480 minutes is the max.

end end and save

Friday, July 6, 2012

Securing down your FortiGate UTM appliance

Securing it for a Static IP

If you have a Static IP or group of Static IP’s that you use to connect remotely to your Fortinet device, there is an easy way to map external services, secure it down to a group of subnets and allow only a few IP’s to remotely manage the firewall from the Internet. There are other ways, this is my favorite with the most amount of control and logging available for the remote connections. Let’s get started.

Scenario (My Setup)

WAN IP = Dynamic (wan)
LAN IP = 10.11.3.254 (InternalSwitch)
Internal Management Port (HTTPS) = 443
Internal Management Port (SSH) = 22
Trusted External Subnets =

12.166.20.0/23
utm.doesntexist.com (DynDNS)

Let’s get started with a Dynamic or Static IP

Log into firewall
Create a new VIP for HTTPS Access

config firewall vip	Enter into VIP
edit External_HTTPS_T11443_w1	Name 1st VIP (I uses _w1 because you could create multiple for multiple WAN connections)
set extintf wan	Set External Interface
set mappedip 10.11.3.254	Set Internal IP
set portforward en	Enable PAT
set extport 11443	This is your External Port to Access GUI (I suggest not using 443)
set mappedport 443	This is the Internal Mgmt Port (443 is default)
next	Next to start SSH entry, end to not setup ssh

Create a new VIP for SSH Access

edit External_SSH_T11022_w1 Name this VIP, using _w1 to separate multiple WAN connections

set extintf wan Set External Interface

set mappedip 10.11.3.254 Set Internal IP

set portforward en Enable PAT

set extport 11022 This is your External Port to Access GUI (I suggest not using 22)

set mappedport 22 This is the Internal Mgmt Port (22 is default)

end end to save

Create a VIP Group

config firewall vipgrp	Enter VIP Group Entry
edit ExternalManagement_w1	Create a group for the External Management using _w1 to define the one for WAN1
set interface wan	Set the Group’s interface (wan) in this scenario
set member “External_HTTPS_11443_w1” “External_SSH_T11022_w1”	Add the two members to the group

Create address object for trusted IP

config firewall address	Enter Address Creation
edit “TrustedSubnet_1”	Call this what you want, but you are creating a name for this trusted IP
set subnet 12.166.20.0/23	Add the trusted subnet
next or end	Next or end to create more

Create address object for trusted FQDN

config firewall address	Enter Address Creation
edit “Trusted_FQDN_1”	Call this what you want, this is a trusted FQDN example
set type fqdn	Setup a type FQDN
set fqdn “utm.doesntexist.com”	Add your trusted FQDN

Create address group object

config firewall addrgrp	Enter Address Group Creation
edit “Trusted_Remote_w1”	Create a group name for Trusted addresses on w1
set member “TrustedSubnet_1” “Trusted_FQDN_1”	Add members to the Group
end	End to save

Create new ExternalAdmin account

config system admin	Enter Address Group Creation
edit ExternalAdmin	Create your ExternalAdmin Account
set accprofile super_admin	super_admin is a full rights admin, but I suggest creating a restricted user for External Access
set password SecurePassword	Change SecurePassword with a secure password
End	Save and create new Account

Lockdown admin to local subnet only

config system admin	Enter Address Group Creation
edit ExternalAdmin	Create your ExternalAdmin Account
set accprofile super_admin	super_admin is a full rights admin, but I suggest creating a restricted user for External Access
set password SecurePassword	Change SecurePassword with a secure password
End	Save and create new Account

Create firewall policy

config firewall policy	Enter Firewall Policy Creation
edit 0	“edit 0” creates a new entry after the biggest number.
set srcintf wan	set the Source Interface (wan) in this instance, probably a port or wan1/2 for you
set dstintf InternalSwitch	set Destionation Interface (InternalSwitch). Likely a port or internal for you.
set srcaddr “Trusted_Remote_w1”	Set your Source Address. This is the group you created in previous steps
set dstaddr “ExternalManagement_w1”	Set your Destination Address. This is your VIP Group you created earlier
set action accept	Accept the traffic
set service “HTTPS” “SSH”	Set the two services you need. These are the “internal” services and not the external. If you management port is not standard you may need to create a service object for this.
set logtraffic enable	Enable logging for your sanity.
end

This will in effect do the following:

Allow the default “admin” to only login from inside the network
Create a new user for ExternalAdmin of the firewall
Create 2 VIP’s to allow inbound mapping for alternative ports to the inside management ports
Allow you to ping the firewall from anywhere
Trust just a few IP/FQDN’s for remote management
Log traffic accessing the VIP
Apply inbound UTM if you wanted, not in this tutorial though

To use this you will want to either:

To use web-management, use the IP of the External Interface to use

https://externalIP:11443

Use DynamicDNS to “find easier”

Putty via externalIP:11022

Hope this helps you create a secure access method to your firewall.

Enjoy!

Monday, February 20, 2012

Bit Torrents Killed My Internet, but not My Internet Connection.

Wazzup:

Ok, so I have this small fascination with having downloaded the Internet, so in my life, I have found that Bit Torrent used in a semi-legal way is a great tool. Since I’m paying more child support than what any child needs, I have to cut where it doesn’t really matter and TV is the start. So between watching lots of ROKU and downloading/watching TV shows/movies… I have found that I can pretty much watch anything anyone else does, but it might be a day or so later. Not to mention listen and play whatever I want, but that’s a different story.

The Setup:

Charter was gracious enough to give me one heck of a deal to replace my outdated worn out 5mb ATT DSL Line (though it was one stable and reliable services… Thank you ATT). I spied Charter for a long time and found a deal I couldn’t go wrong with, $50 install, $200 modem, $200 rebate on Modem and $50 rebate on install, with a $29/mo fee for a whopping 40Mb/Sec, of course that’s only for 6 months, then its $50/mo, which is what I was paying ATT for. Nice deal on my side and I get +35mb/sec for about $2/mo. WOW.

The Issue:

Trying to update large list of torrent files with some “friends” I started to notice that once I changed to charter I could either surf the Internet OR download torrents. At first I didn’t quite catch what was going on, as I figured it had something to do with the speed I had and how much I was downloading, but it started to be a PITA so I decided to tackle the task of finding out why if uTorrent was running, I had to pause them to browse the Internet. So just to get some keywords out there: Can’t browse the Internet while uTorrent is running on Charter Service with Motorola Modem but pings and other devices and/or computers work just fine.

Research:

So as any good person that knows how to Google, I started with some generic Google searches.

Some people were complaining about the same thing but most blamed the modem or the router.

So I decided to rule that out, I’d remove my Router and just plug into the modem. At the same time, I’d connect a laptop (2nd computer) and just verify that it couldn’t be the modem. So I fire up the laptop, my phone, a tablet, another phone and connect to the wifi. Then on my desktop I fired up uTorrent then WHAM… Desktop looses IE (started to think TCP) connection but the rest of the computers were just flying. Not the modem, if it was going to be the modem, my other devices would have died also.

Some people blaming uTorrent.

Not really wanting to leave uTorrent (as it was required for one of my “friends” sites) I found another compatible torrent program. qTorrent, surely it’s something with the torrent program…. Right? Well after learning a much less featured and slower program (man qTorrent takes forever to load), I was surely surprised to find that it was the program. Here we go with the real tech work.

Some posts pointed at the TCP sessions were being exhausted.

This is a fair statement. If I were to give one session/files (not torrent). The program would surely use over 65,000 connections. So off to the CLI.

nbtstat –an

Not really an impressive number came back, so I put that idea on the back burner, though it made sense.

Finding it was a TCP session issue… A breakthrough?

I don’t know if it was any sort of breakthrough, but it was however a great way to start testing and find when the issue happened. But how to test a TCP session? Pings always worked, even when the Internet was running, but that’s ICMP and Bit-Torrent kept running, but that’s UDP traffic. For those that don’t get this part, skip Smile So I figure if the UDP works, ICMP works, then TCP has to be the issue. Found this nice little utility here, big thanks to Eli Fulkerson! This tool allowed me to start a continuous "ping” to a TCP port, which I used 80 and 3389, just to make sure it wasn’t an issue with HTTP browsing but more like an issue with TCP connections.

Sure enough, it was a TCP session issue where once uTorrent, now qTorrent started, it blocked all TCP sessions, but why?

How to diagnose TCP Sessions and why they were failing.

Using Netstat –abn and Resource Monitor built into Windows 7, I found that there were no obvious issues. Back to the research board…

Tweaking TCP for broadband….

Surely this was it, it made so much sense. I get faster Internet, I have more bandwidth, it has to be TCP settings to low for my new bandwidth (NOW… AFTER ALL OF THIS, IT DOESN’T MAKE AS MUCH SENSE, but I was desperate) I used this utility here TCPOptimizer. Had some nice settings some seemed legit, so after a reboot, I fired up my test (which had become, TCPPing, qTorrent and 3 minutes of waiting at this point). And WHAM… it works.. yay, I’m at 3 minutes, still working, 5 minutes… Still working.. YAY, I’m about to write a nice UTM blog on this until… Death to my TCP. So maybe that didn’t fix it. I’ll leave the boring tweaking settings out of this blog, because it’s already long enough, and IT’S STILL NOT FIXED.

Maybe some Crazy Filtering/RST bomb from Charter?

I started to think maybe this was some reverse attack against P2P traffic. It didn’t’ make much sense, but… either did anything else. I found this site that confirmed they don’t much care…. on to the next idea.

I got it… Ethernet Driver

Of course, I’m such an idiot… It’s an issue with the Ethernet driver, I have to update it, that will fix my world. The driver had to be at least 6-12 months old, I’m running a new bit-torrent client… yadda… yadda. That’s it, my driver was almost a year old, of course… Download, Install, Update, Reboot, Wham… Bam… Damn, that wasn’t it.

Dedicating my upcoming life to fixing this issue… ONE WAY OR ANOTHER.

Ok, it didn’t take that long, but I had decided that this was a me against the machine. Nobody on the Internet had a clue, forums were spread with similar, less technically detailed questions, with the same answers I’ve tried 5 paragraphs up. So, if it took me a case with Microsoft (yes I’d have thrown a Microsoft Partner Case at it), I will do it.. DAMN IT!

The Fix (almost but not quite):

Starting from what I know

I know that it has to do with TCP Sessions, I know it has to do with running bit-torrent applications and I know there are no logs or known signs of the reason it was failing both on the routers and computer… That was just about it.

Lets go from what it’s not

I know it’s not the version, application, driver, etc…
I know it’s not the router being “junk” like I kept reading
I know it’s not my version of Windows being corrupt (ran SFC /scannow)
I know it’s not possible this is happening to me, I am IT.

The start of thinking and breaking into this is critical at this point. My sanity depends on it.

Time to consult my consultant… You might know him as Yarbi say what?, but I know him as a super smart dude I respect and we both bounce ideas off each other to come up with some real good solutions to real world scenarios (not all technical). We are still working on Vacation Return Policies.

New network card… This should rule a lot out

After talking with Yarbi over lunch, I decided that it almost had to be my Network card. It was really the only thing that made sense. Yarbi just happened to have a decent PCI 100/1000 NIC that was sitting on his shelf. I must borrow.

Installation… I noticed this was another Realtek card, but heh, what can it hurt. Reboot, change the patch cable. BAM, (Like it blew up).. NOGO, back to the drawing board.

The Fix.. Yes a FIX

I really hope this helps someone out, going to quickly outline the issue, what I know it is not and what the fix was. This could possibly apply to many routers, but the screenshots I’m going to include are from a Motorola Surfboard. Having seen lots of modems in my IT history, I know this setting is on A Lot of them. I hope this helps.

Issue with TCP connections, including HTTP when Bit Torrent Application running.
ICMP (Ping) and UDP (Bittorrent) are not affected
It only affects the computer bittorrent is running on, it does not affect the other devices on the exact same network and Internet connection.
Drivers updated and no virus present.

Drum Roll…

Accessing the Motorola Surfboard modem.

There it is. The two options in question were:

Port Scan Detection
IP Flood Detection

Disable both, make your screen look like this and it should resolve your issues. I really hope this helps someone out there!

It all makes sense. Damn, why didn’t I think about this 16 hours ago.

Post Analysis

Now that we know the issue was Port Scan Detection and/or IP Flood Detection. What do they do. Do we need them? Why turn them off? Why does Bit Torrent trigger these. Well here we go, from my Security Mind.

Port Scan Detection (disable)

This is defined as: “Port Scan Detection detects and blocks port scan activity originating on both the LAN and WAN”

What does this mean for P2P apps? Well, P2P creates a lot of outbound connections to multiple destinations, those destinations return the favor and then some by trying to spread the joy of P2P (the reason it works). This quick spread of P2P reconnects look like a Port Scan because of the large quantity of return ports that each destination returns. Also from the inside it is possible that the P2P application is triggering it due to the large quantity of ports is uses to communicate, but it is more likely on the WAN side.

IP Flood Detection

This is defined as: “IP Flood Detection detects and blocks packet floods originating on both the LAN and WAN”

But why does P2P trigger this effect, well, it’s really likely that the either LAN or the WAN could be blocking these large quantities of P2P connections that connect to many sources, seed in many directions and just plain out look like a flood of IP type traffic.

So why does UDP, P2P and ICMP work.

UDP is connectionless and would be very hard to close a connection with, it could be denied but the way I was testing UDP was with the P2P client, which would have had connections to the destination servers before the protection kicked in and dropped the new connections, but… it is also possible that the firewall can only truly block TCP sessions, I don’t really want to spend hours figuring this out, there is likely some manual or blog about this, I just haven’t found one.

Enjoy, now I can surf and P2P all at the same time… YAY!

Tuesday, August 2, 2011

How to configure a 2wire 2701HGV-B Modem with a FortiGate (ATT uVerse)

Recently I was tasked with bringing a ATT uVerse client online with a new SBS server. They needed site-to-site VPN's between the sites as well as public services forwarded to their SBS server for things like RWW, SMTP, OWA, RDP, etc...

We obtained a 5-block of Static IP addresses and off we went.

After talking to the first 3 "Level 2" technicians, I was confident that I was to statically assign an IP address to my FortiGate 50b WIFI's WAN1 IP, then I could set it up with Static IP's.

So I went ahead and did the obvious to setup a Static IP on my WAN1, configured Default Routes and Firewall policies. After logging on, I found that the www.ipchicken.com saw my static IP address and I thought I was set. Oh, how I was so wrong...

After returning, I tried to access the Public IP of the Firewall to configure some services, even though I had Ping and HTTPS forwarding configured, I was unable to do either. After doing a sniff of the WAN1 interface, I found that the traffic was not making it to the WAN1. Obvious... A firewall.

So I am making this quick guide so that you can save several hours. Here are VERY important details of how this has to work:

IF you assign a single STATIC IP address behind your network, you CAN NOT disable the firewall. This might be good if you have to have certain traffic come FROM an IP address, but don't want any inbound access to the device.
To disable the firewall, you will need to setup the device as a DHCP Client.
You will only be able to have 1 "Device" per Static IP when using DHCP.
With a FortiGate, it could be possible to have VDoms to get "multiple" devices, but dual WAN addresses are not supported for some reason. I have tried and tested as well as found other complaining of the same issue. I will dig up the reasons a very smart man has figured out shortly.
Once configured correctly, your Device will get a DHCP address from a PUBLIC block and not a private block, thus giving you a public IP on your firewall.
For network admins and network enthusiasts, this is a very confusing situation. But it is, what it is.

Here is how I accomplished this.

Basically here are the steps:

Pending you have previously been using the ATT modem as a router before trying to install the FortiGate UTM Firewall, you will need to connect to the IP of the uVerse router.
To find this, open a command prompt, and type 'ipconfig' The Gateway IP is your ATT uVerse Modem.
Open a web-browser and type in the IP of the gateway. In this instance it is 192.168.6.254.
Open Home Network and Advanced
Configure a new IP and DHCP Pool on your ATT DSL Modem (2701HGV-B). Lets use 10.20.30.254/24 (255.255.255.0) with a DHCP Pool from (10.20.30.100 through 10.20.30.200), we'll only need 1 IP/device.
When you click "Save" you will loose connection to this device. That is fine, just disconnect all devices except the WAN1 for the firewall
IMPORTANT!!! Disconnect all devices from the ATT modem and only have your FortiGate WAN 1 Attached Only to the DSL/ATT Modem.
Connect to your FortiGate firewall and login. If you do not know how to do this, please visit my other blog Using a Console Cable to configure a Fortinet Appliance. Change the "Internal Interface" what ever it may be in your situation to a Static or Manual IP. We will reuse our previous 192.168.6.254/24 address, so that we do not have to change any static device on the Internal network. It is suggested that if the IP subnet is 192.168.0.* or 192.168.1.*, to change to a different address. It is possible to use any address below 255 on the following schemes. (10.*.*.*, 192.168.*.*, or 172.16.*.*).
Configure the FortiGate WAN1 with a DHCP Address, you should get an address of 10.20.30.*, it will likely be 100, but not always.
Configure your Internal Interface with the old ATT Default Gateway (Or the Default Gateway of your choosing). In our instance it will be 192.168.6.254, please make sure to check Ping, SSH and HTPS, we might need these!
Configure a simple Internal-->WAN1 policy with NAT enabled.
Connect to the Fortigate Internal (Default Gateway) IP via https, using the IP we provided as the Internal IP. Login
Open another browser page to connect to the ATT uVerse modem/router via http://10.20.30.254
Clear the ATT Routers Machine Cache before starting by visiting the http://10.20.30.254/mdc
On the Left column, go to Resets and click the first Item "Reset Local Network". This should clear your device list under http://10.20.30.254 (Home Network)
Go to the FortiGate Device https://192.168.6.254, Status-->Network-->Interface. Edit WAN1, and click "Renew" next to DHCP.
Go back to the ATT router and you should see the FortiGate device listed.
Click Broadband Link-->Advanced
On the left column, select "Routed Interface", Fill in the gateway provided by ATT as well as the subnet mask provided by them. Check the "Auto Open Firewall" checkbox. Click Save.
Click Home Network-->Advanced and then "Edit Address Allocation" on the right column.
Inside of here, we will assign the Public IP to the FortiGate. For us Network Administrators, this is a VERY strange way of doing things. Please hang in there, we are almost done.
Inside the "Edit Address Allocation" section, you should see your single device.
Click the Address Assignment and scroll up, on top of the scroll list, is a "Assign Public IP" option. Select this.
Click WAN IP Mapping on the right side. This should have a dropdown with your Public IP blocks. Choose any that you wish to use.
Uncheck the "Firewall" box to remove firewalling (finally).
Go back to the FortiGate Interface and click Renew under WAN1. You may have to do this a few times, but after a few times, you should now have a Static Public IP address.

Thank you to all who read and you are welcome to those that learned and may have saved a day of research and calling horrible ATT support.