Showing posts with label firewall. Show all posts
Showing posts with label firewall. Show all posts

Monday, February 20, 2012

GNS3 - PIX Firewall Emulation

PIX Firewall Emulation

GNS3 is also capable of emulating PIX firewalls. Once again, you’ll need to provide your own PIX image. If you want to run more than a restricted license, you’ll also need to have a valid serial number and activation keys.

Configuring Qemuwrapper and Cisco PIX image

First, go to Preferences on the Edit menu in GNS3. Click on Qemu in the left pane. The default path to the Qemuwrapper should be fine. You may want to specify a different working directory. Note that Qemuwrapper is shipped with a compiled version of Pemu, therefore you do not need Qemu to emulate PIX.

On PIX tab, use the button next to Binary image to specify the location of your PIX operating system image. You may also change other settings like RAM or the number of interfaces. Once you are finished with the settings, click on Save.

clip_image002clip_image004

You may use the default Key and Serial number, if necessary. This will provide a restricted license with limited features. You will need a valid serial number and activation keys to access additional features. The graphic below on the left is a restricted image. Failover, VPN-DES, and VPN-3DES-AES are disabled. You are also limited to 6 physical interfaces and 25 VLANs. The graphic below on the right is unrestricted. With an unrestricted license, these features are enabled along with support for additional interfaces and VLANs.

clip_image006

If you have a serial number and valid activation keys, you may move from a restricted license to an unrestricted license. Type in the activation keys separated by commas with no spaces. Use all lower case. Be sure your serial number is converted to hexadecimal. It is usually in decimal in a show version command. Use a calculator to convert from decimal to hexadecimal if necessary.

Using Cisco PIX

Click OK to return to the GNS3 main interface. Drag a PIX firewall icon from the Nodes Types pane into the workspace. Right-click FW1 and choose Start, then right-click on FW1 again and choose Console.

Once you console into your PIX firewall, issue a show version command. If the activation keys do not show up properly, then issue the following command from privileged mode (enable mode):

pixfirewall# activation-key 0x12345678 0x12345678 0x12345678 0x12345678

clip_image008

The command is issued on one line with spaces between the activation keys. Save the configuration using either the write command orcopy run start. Stop the device and restart it. Congratulations! Your PIX firewall is up and running.

Interfaces on the PIX are Ethernet interfaces. To connect to other devices, you’ll need to use either Ethernet or FastEthernet interfaces. You may not connect to a serial interface.

You may connect to other PIX firewalls, routers, and switches. You may not connect to a cloud. Consequently, to connect to a real network or to a Virtual PC, you’ll need to connect from the PIX to a switch, and then from the switch to your Cloud.

CPU usage with PIX

Just as with routers, CPU usage is an issue when emulating PIX firewalls on your computer. You will note that your CPU usage is most likely 100%. There are no idle-pc values available for PIX firewalls at this time. Instead, you may use third-party software to control your CPU usage. There are a variety of products on the market. The one that I use for Windows is called BES and is a free download.

Complete documentation is available on the Web site along with the program download. Once you start your PIX firewall, start BES. Click the Target button. Choose the pemu.exe process and click the Limit this button. A confirmation screen will appear.

Click the Control button to control how much CPU limiting will be used. I’ve set mine to reduce CPU usage by 50%. If you are running multiple firewalls, you will want to limit each one. This program may also limit other processes running on your Windows computer.

clip_image010clip_image012

For Linux, use cpulimit. You may learn more about cpulimit at the following Web site: http://cpulimit.sf.net. On ubuntu you can use Synaptic Package Manager or Ubuntu Software Centre to download and install cpulimit.

To run cpulimit, press F2 while holding the ALT key down (ALT+F2) in Ubuntu to open a Run Application box. Type the following in the box:

cpulimit –e pemu –l 40

clip_image014

This will limit the application pemu to 40% CPU usage.

Still in your Ubuntu, choose System Monitor under Administration on the System menu. Click the Resources tab. You should see that pemu process is running at 40% of your CPU usage.

Taken From: http://www.gns3.net/gns3-pix-firewall-emulation/

Wednesday, August 4, 2010

Port-Knocking Security (conditional port opening)

Implement Port-Knocking Security with knockd

When dealing with computer security, you should assume that hackers will be trying to get in through any available doors your system may have, no matter how many precautions you might have taken. The method of allowing entrance depending on a password is a classic one and is widely used. In order to “open a door” (meaning, connect to a port on your computer), you first have to specify the correct password. This can work (provided the password is tough enough to crack, and you don't fall prey to many hacking attacks that might reveal your password), but it still presents a problem. The mere fact of knowing a door exists is enough to tempt would-be intruders.
So, an open port can be thought of as a door with (possibly) a lock, where the password works as the key. If you are running some kind of public service (for example, a Web server), it's pretty obvious that you can't go overboard with protection; otherwise, no one will be able to use your service. However, if you want to allow access only to a few people, you can hide the fact that there actually is a door to the system from the rest of the world. You can “knock intruders away”, by not only putting a lock on the door, but also by hiding the lock itself! Port knocking is a simple method for protecting your ports, keeping them closed and invisible to the world until users provide a secret knock, which will then (and only then) open the port so they can enter the password and gain entrance.
Port knocking is appropriate for users who require access to servers that are not publicly available. The server can keep all its ports closed, but open them on demand as soon as users have authenticated themselves by providing a specific knock sequence (a sort of password). After the port is opened, usual security mechanisms (passwords, certificates and so on) apply. This is an extra advantage; the protected services won't require any modification, because the extra security is provided at the firewall level. Finally, port knocking is easy to implement and quite modest as far as resources, so it won't cause any overloads on the server.
In this article, I explain how to implement port knocking in order to add yet another layer to your system security.
Are You Safe?
Would-be hackers cannot attack your system unless they know which port to try. Plenty of port-scanning tools are available. A simple way to check your machine's security level is by running an on-line test, such as GRC's ShieldsUp (Figure 1). The test results in Figure 1 show that attackers wouldn't even know a machine is available to attack, because all the port queries were ignored and went unanswered.

clip_image001[7]

Figure 1. A completely locked-up site, in “stealth” mode, doesn't give any information to attackers, who couldn't even learn that the site actually exists.
Another common tool is nmap, which is a veritable Swiss Army knife of scanning and inspection options. A simple nmap -v your.site.url command will try to find any open ports. Note that by default, nmap checks only the 1–1000 range, which comprises all the “usual” ports, but you could do a more thorough test by adding a -p1-65535 parameter. Listing 1 shows how you can rest assured that your site is closed to the world. So, now that you know you are safe, how do you go about opening a port, but keep it obscured from view?
Listing 1. The standard nmap port-scanning tool provides another confirmation that your site and all ports are completely closed to the world.


$ nmap -v -A your.site.url
Starting Nmap 4.75 ( http://nmap.org ) at 2009-10-03 12:59 UYT
Initiating Ping Scan at 12:59
Scanning 190.64.105.104 [1 port]
Completed Ping Scan at 12:59, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 12:59
Completed Parallel DNS resolution of 1 host. at 12:59, 0.01s elapsed
Initiating Connect Scan at 12:59
Scanning r190-64-105-104.dialup.adsl.anteldata.net.uy (190.64.105.104)
[1000 ports]
Completed Connect Scan at 12:59, 2.76s elapsed (1000 total ports)
Initiating Service scan at 12:59
SCRIPT ENGINE: Initiating script scanning.
Host r190-64-105-104.dialup.adsl.anteldata.net.uy (190.64.105.104)
appears to be up ... good.
All 1000 scanned ports on r190-64-105-104.dialup.adsl.anteldata.net.uy
(190.64.105.104) are closed



Read data files from: /usr/share/nmap
Service detection performed. Please report any incorrect results
at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.94 seconds
Nmap done: 1 IP address (1 host up) scanned in 2.94 seconds

Secret Handshakes, Taps and Knocks

The idea behind port knocking is to close all ports and monitor attempts to connect to them. Whenever a very specific sequence of attempts (a knock sequence) is recognized, and only in that case, the system can be configured to perform some specific action, like opening a given port, so the outsider can get in. The knock sequence can be as complex as you like—for example, a simple list (like trying TCP port 7005, then TCP port 7006 and finally, TCP port 7007) to a collection of use-only-once sequences, which once used, will not be allowed again. This is the equivalent of “one-time pads”, a cryptography method that, when used correctly, provides perfect secrecy.

Before setting this up, let me explain why it's a good safety measure. There are 65,535 possible ports, but after discarding the already-used ones (see the list of assigned ports in Resources), suppose you are left with “only” 50,000 available ports. If attackers have to guess a sequence of five different ports, there are roughly 312,000,000,000,000,000,000,000 possible combinations they should try. Obviously, brute-force methods won't help! Of course, you shouldn't assume that blind luck is the only possible attack, and that's why port knocking ought not be the only security measure you use, but just another extra layer for attackers to go through (Figure 2).

clip_image002[6]

Figure 2. Would-be attackers (top) are simply rejected by the firewall, but when a legit user (middle) provides the correct sequence of “knocks”, the firewall (bottom) allows access to a specific port, so the user can work with the server.

On the machine you are protecting, install the knockd dæmon, which will be in charge of monitoring the knock attempts. This package is available for all distributions. For example, in Ubuntu, run sudo apt-get install knockd, and in OpenSUSE, run sudo zypper install knockd or use YaST. Now you need to specify your knocking rules by editing the /etc/knockd.conf file and start the dæmon running. An example configuration is shown in Listing 2. Note: the given iptables commands are appropriate for an OpenSUSE distribution running the standard firewall, with eth0 in the external zone; with other distributions and setups, you will need to determine what command to use.

Listing 2. A simple /etc/knockd.conf file, which requires successive knocks on ports 7005, 7007 and 7006 in order to enable secure shell (SSH) access.


[opencloseSSH]
  sequence      = 7005,7006,7007
  seq_timeout   = 15
  tcpflags      = syn
  start_command = /usr/sbin/iptables -s %IP% -I input_ext 1 -p tcp --dport ssh -j ACCEPT
  cmd_timeout   = 30
  stop_command  = /usr/sbin/iptables -s %IP% -D input_ext -p tcp --dport ssh -j ACCEPT



You probably can surmise that this looks for a sequence of three knocks—7005, 7006 and 7007 (not very safe, but just an example)—and then opens or closes the SSH port. This example allows a maximum timeout for entering the knock sequence (15 seconds) and a login window (30 seconds) during which the port will be opened. Now, let's test it out.


First, you can see that without running knockd, an attempt to log in from the remote machine just fails:

$ ssh your.site.url -o ConnectTimeout=10
ssh: connect to host your.site.url port 22: Connection timed out

Next, let's start the knockd server. Usually, you would run it as root via knockd -d or/etc/init.d/knockd start; however, for the moment, so you can see what happens, let's run it in debug mode with knock -D:

# knockd -D

config: new section: 'opencloseSSH'
config: opencloseSSH: sequence: 7005:tcp,7006:tcp,7007:tcp
config: opencloseSSH: seq_timeout: 15
config: tcp flag: SYN
config: opencloseSSH: start_command:
          /usr/sbin/iptables -s %IP% -I input_ext 1
                             -p tcp --dport ssh -j ACCEPT
config: opencloseSSH: cmd_timeout: 30
config: opencloseSSH: stop_command:
          /usr/sbin/iptables -s %IP% -D input_ext
                             -p tcp --dport ssh -j ACCEPT


ethernet interface detected
Local IP: 192.168.1.10



Now, let's go back to the remote machine. You can see that an ssh attempt still fails, but after three knock commands, you can get in:

$ ssh your.site.url -o ConnectTimeout=10
ssh: connect to host your.site.url port 22: Connection timed out

$ knock your.site.url 7005

$ knock your.site.url 7006
$ knock your.site.url 7007
$ ssh your.site.url -o ConnectTimeout=10

Password:
Last login: Sat Oct  3 14:58:45 2009 from 192.168.1.100

Looking at the console on the server, you can see the knocks coming in:


2009-09-03 15:29:47:
     tcp: 190.64.105.104:33036 -> 192.168.1.10:7005 74 bytes
2009-09-03 15:29:50:
     tcp: 190.64.105.104:53783 -> 192.168.1.10:7006 74 bytes
2009-09-03 15:29:51:
     tcp: 190.64.105.104:40300 -> 192.168.1.10:7007 74 bytes


If the remote sequence of knocks had been wrong, there would have been no visible results and the SSH port would have remained closed, with no one the wiser.

Configuring and Running knockd

The config file /etc/knockd.conf is divided into sections, one for each specific knock sequence, with a special general section, options, for global parameters. Let's go through the general options first:

· You can log events either to a specific file by using LogFile=/path/to/log/file, or to the standard Linux log files by using UseSyslog. Note: it's sometimes suggested that you avoid such logging, because it enables an extra possible goal for attackers—should they get their hands on the log, they would have the port-knocking sequences.


· When knockd runs as a dæmon, you may want to check whether it's still running. The PidFile=/path/to/PID/file option specifies a file into which knockd's PID (process ID) will be stored. An interesting point: should knockd crash, your system will be safer than ever—all ports will be closed (so safer) but totally unaccessible. You might consider implementing a cron task that would check for the knockd PID periodically and restart the dæmon if needed.

· By default, eth0 will be the observed network interface. You can change this with something like Interface=eth1. You must not include the complete path to the device, just its name.

Every sequence you want to recognize needs a name; the example (Listing 2) used just one, named openclosessh. Options and their parameters can be written in upper-, lower- or mixed case:

· Sequence is used to specify the desired series of knocks—for example,7005,7007:udp,7003. Knocks are usually TCP, but you can opt for UDP.

· One_Time_Sequences=/path/to/file allows you to specify a file containing “use once” sequences. After each sequence is used, it will be erased. You just need a text file with a sequence (in the format above) in each line.

· Seq_Timeout=seconds.to.wait.for.the.knock is the maximum time for completing a sequence. If you take too long to knock, you won't be able to get in.


· Start_Command=some.command specifies what command (either a single line or a full script) must be executed after recognizing a knock sequence. If you include the %IP% parameter, it will be replaced at runtime by the knocker's IP. This allows you, for example, to open the firewall port but only for the knocker and not for anybody else. This example uses an iptables command to open the port (see Resources for more on this).


· Cmd_Timeout=seconds.to.wait.after.the.knock lets you execute a second command a certain time after the start command is run. You can use this to close the port; if the knocker didn't log in quickly enough, the port will be closed.

· Stop_Command=some.other.command is the command that will be executed after the second timeout.

· TCPFlags=list.of.flags lets you examine incoming TCP packets and discard those that don't match the flags (FIN, SYN, RST, PSH, ACK or URG; see Resources for more on this). Over an SSH connection, you should useTCPFlags=SYN, so other traffic won't interfere with the knock sequence.

For the purposes of this example (remotely opening and closing port 22), you didn't need more than a single sequence, shown in Listing 2. However, nothing requires having a single sequence, and for that matter, commands do not have to open ports either! Whenever a knock sequence is recognized, the given command will be executed. In the example, it opened a firewall port, but it could be used for any other functions you might think of—triggering a backup, running a certain process, sending e-mail and so on.


The knockd command accepts the following command-line options:

· -c lets you specify a different configuration file, instead of the usual /etc/knockd.conf.
· -d makes knockd run as a dæmon in the background; this is the standard way of functioning.
· -h provides syntax help.
· -i lets you change which interface to listen on; by default, it uses whatever you specify in the configuration file or eth0 if none is specified.
· -l allows looking up DNS names for log entries, but this is considered bad practice, because it forces your machine to lose stealthiness and do DNS traffic, which could be monitored.
· -v produces more verbose status messages.
· -D outputs debugging messages.
· -V shows the current version number.


In order to send the required knocks, you could use any program, but the knock command that comes with the knockd package is the usual choice. An example of its usage is shown above (knock your.site.url 7005) for a TCP knock on port 7005. For a UDP knock, either add the -u parameter, or do knock your.site.url 7005:udp. The -h parameter provides the (simple) syntax description.

If You Are behind a Router
If you aren't directly connected to the Internet, but go through a router instead, you need to make some configuration changes. How you make these changes depends on your specific router and the firewall software you use, but in general terms you should do the following:

1) Forward the knock ports to your machine, so knockd will be able to recognize them.

2) Forward port 22 to your machine. Although in fact, you could forward any other port (say, 22960) to port 22 on your machine, and remote users would have to ssh -p 22960 your.site.url in order to connect to your machine. This could be seen as “security through obscurity”—a defense against script kiddies, at least.

3) Configure your machine's firewall to reject connections to port 22 and to the knock ports:

$ /usr/sbin/iptables -I INPUT 1 -p tcp --dport ssh -j REJECT
$ /usr/sbin/iptables -I INPUT 1 -p tcp --sport 7005:7007 -j REJECT


The command to allow SSH connections would then be:


$ /usr/sbin/iptables -I INPUT 1 -p tcp --dport ssh -j ACCEPT

And, the command for closing it again would be:

$ /usr/sbin/iptables -D INPUT -p tcp --dport ssh -j ACCEPT

Conclusion

Port knocking can't be the only security weapon in your arsenal, but it helps add an extra barrier to your machine and makes it harder for hackers to get a toehold into your system.

Resources

The knockd page is at www.zeroflux.org/projects/knock, and you can find the knockd man page documentation at linux.die.net/man/1/knockd, or simply do man knockd at a console.

For more on port knocking, check www.portknocking.org/view, and in particular, seewww.portknocking.org/view/implementations for several more implementations. Also, you might check the critique at www.linux.com/archive/articles/37888 and the answer at www.portknocking.org/view/about/critique for a point/counterpoint argument on port knocking.

Read en.wikipedia.org/wiki/Transmission_Control_Protocol for TCP flags, especially SYN. At www.faqs.org/docs/iptables/tcpconnections.html, you can find a good diagram showing how flags are used.

Port numbers are assigned by IANA (Internet Assigned Numbers Authority); seewww.iana.org/assignments/port-numbers for a list.

To test your site, get nmap at nmap.org, and also go to GRC's (Gibson's Research Corporation) site at https://www.grc.com, and try the ShieldsUp test.

Check www.netfilter.org if you need to refresh your iptables skills.

Federico Kereki is an Uruguayan Systems Engineer, with more than 20 years' experience teaching at universities, doing development and consulting work, and writing articles and course material. He has been using Linux for many years now, having installed it at several different companies. He is particularly interested in the better security and performance of Linux boxes.

Taken From: http://www.linuxjournal.com/article/10600

Wednesday, September 23, 2009

Remote Desktop (XDMCP) on Ubuntu

Here I'm going to show you howto activate XDMCP (remote desktop protocol), on Gnome (bash an gui) and KDE. I have tested it only on Gnome so far. Note that this remote desktop protocol does not forwand sound.

Here some notes on the roles of the XDMCP server and client

Server - The remote machine were we want to login.
Client - The local machine were we will login on the Server

Before trying anything on XDMCP, you should make
sure that on the server your firewall is either disabled
or allows Udp port 177.

Here I'm going to show how to open a UDP 177 (rule),
on Iptables (firewall) using the bash, but you use a
very simple and usefull, Gui for Iptables nown as
"Firestarter" (to install on ubuntu just do
sudo apt-get install iptables).

$ sudo iptables -A INBOUND -p udp --destination-port 177 -j ACCEPT

Here are a couple off other usefull comands on Iptables

## Checking Iptables Rules #####
$ sudo iptables -nvL

if you have already executed the rule to open UDP port 177,
by executing this comand, you should see it there.

## Clearing All the Rules #####
$ sudo iptables -F

be aware that this comand clears all off the rules, and this
does not mean that all is allowed, on the contrary,
IPtables default beaviour, when it has no rules is to
deny all, so be very carefull.


XDMCP GNOME - via Bash
=====================================

XDMCP Server Configuration
----------------------------------

## Allowing the remote login on the Server #####
$ sudo gedit /etc/gdm/gdm.conf-custom
...
[xdmcp]
Enable=true
...

You should have the above on the file.

If you want the remote login screen to be the same as
the graphical greeter that is the default in the Ubuntu
install make sure that the following is present.

...
[daemon]
RemoteGreeter=/usr/lib/gdm/gdmgreeter
...

For these changes to take efect you can either,
reboot:

$ sudo reboot

or restart the service, for that go to text terminal (Ctlr+Alt+F2)
and type:

$ sudo /etc/init.d/gdm restart

to go back to you Gnome environment try Ctlr+Alt+F7, or some
Ctlr+Alt+Fx, close to F7.


XDMCP Client Login
------------------------

$ sudo X :1 -query server_ip

After this if all went well you should see
Ubuntu's graphical login screen, as if you
were on the remote computer fisicaly.

If don't want to see it fullscreen, you can
show the remote desktop on a window by
using the following command instead:

$ sudo Xnest :1 -query server_ip


XDMCP GNOME - via Gui
=====================================

This is equivelent to the shown above, the diference
is that, the server here is configured via Gui.

XDMCP Server Configuration
-----------------------------------
Allowing the remote login on the Server


As shown above System > Administration > Login Window



And then change the Style to "Same as Local", and that's it.
Aditional confuguration can be done on "Configure XDMCP"

For these changes to take efect you can either,
reboot:

$ sudo reboot

or restart the service, for that go to text terminal (Ctlr+Alt+F2)
and type

$ sudo /etc/init.d/gdm restart

to go back to you Gnome environment try Ctlr+Alt+F7, or some
Ctlr+Alt+Fx, close to F7.


XDMCP Client Login
------------------------

$ sudo X :1 -query server_ip

After this if all went well you should see
Ubuntu's graphical login screen, as if you
were on the remote computer fisicaly.

If don't want to see it fullscreen, you can
show the remote desktop on a window
by using the following command instead:

$ sudo Xnest :1 -query server_ip


XDMCP KDE - via Bash
(didn't test it, give me feedback if you do)
=====================================

XDMCP Server Configuration
----------------------------------
Still working on it...

XDMCP Client Login
------------------------

$ sudo X :1 -query server_ip

After this if all went well you should see
Ubuntu's graphical login screen, as if you
were on the remote computer fisicaly.

If don't want to see it fullscreen, you can
show the remote desktop on a window
by using the following command instead:

$ sudo Xnest :1 -query server_ip

Based On:

GNOME
http://megaf.wordpress.com/2009/04/15/xdmcp-internet-seu-linux-onde-voce-estiver/
http://stochasticflux.com/blog/?p=4

KDE

http://www.guiadohardware.net/tutoriais/configurando-servidor-xdmcp/pagina3.html
http://megaf.wordpress.com/2009/04/15/xdmcp-internet-seu-linux-onde-voce-estiver/

Iptables
http://www.cyberciti.biz/tips/linux-iptables-open-bittorrent-tcp-ports-6881-to-6889.html

Tuesday, July 7, 2009

Setting up a dial-up VPN on the Juniper NetScreen Remote (client)

Note: I tried the tutorial on a Juniper SSG350M, with FW 6.0.0r4.0, and it worked althoug it's not the equipement on the tutorial


Note: To see the pictures at full quality just click on them.


This article was graciously contributed by mwdmeyer which was originally posted on his site here.

I've been getting lots of hits to the post about a site to site VPN setup with a netscreen. So I've decided to do one for a dial-up VPN user connecting to a netscreen.

A dial-up user is anyone who needs access into the network and has a dynamic ip address. We don't wish to be able to access them (the dial-up user) from within the network. This is how we setup most connections at work. This allows people to access file shares and outlook (without the need to setup RPC over HTTP).

Background

  • Netscreen 5GT running ScreenOS 5.4.0r1 (Should be the same process for any netscreen running ScreenOS 5.x)
  • Netscreen Remote 8.7 (The Windows VPN client)
  • Local Network (the one in which the vpn users want to access) of 10.0.0.0/22 (10.0.0.0 - 10.0.3.255)
  • External Address of 59.167.253.89

Setting up the Netscreen

1) First we need to create a user. This can be found in Objects -> Users -> Local (Note: Follow the screen shot below, you don't need a password here, you do need the IKE User info though)




















So we have our user, Test.User

2) Create Phase 1 of the VPN tunnel. This can be found in VPNs -> AutoKey Advanced -> Gateway (Note: Security level is set to custom, password for VPN is entered here, Outgoing interface is your untrust interface).














3) Now we'll modify the advanced settings. Click Advanced (Note: We're using DES and MD5 here. Mode is set to Aggressive)




















Now click return and okay to save your settings.

4) Now we'll create the Phase 2 information. This can be found in VPNs -> AutoKey IKE (Note: Security level is set to custom, Remote Gateway is set to "Test.UserP1")













5) Now we'll modify the advanced settings. Click Advanced (Note: We're using DES and MD5 here. Replay Protection is on)




















Now click return and okay to save your settings.

6) Now we'll need to create a policy. This will go from untrust to trust. This can be found in Policies.






Click new (Note: Source Address is Any-IPv4 or just Any if IPv6 is disabled, Destination Address is your local subnet, tunnel the connection though the VPN user "Test.UserP2")





















Now the Netscreen has been setup.

Setting up Netscreen Remote

1) Open the policy editor in Netscreen Remote

NetScreen Remote 1

2) Create a new connection (Note: Type in the remote subnet details and set the secure gateway to your netscreens external address)

















3) Now we'll setup the login details (Note: The Certificate is None, The ID Type is Domain Name and the value is "Test.User")

















4) Now click Pre-Shared Key (Note: Type in the password you used when setting up the connection in the netscreen)

















5) Now we'll set the connection to aggressive (Note: Enable PFS, DH is Group 2 and Enable Replay Dection)

















6) Now we'll setup the Phase 1 details (Note: We're using DES and MD5 here. SA Life is 28800 seconds)

















7) Now we'll setup the Phase 2 details (Note: The SA Life here is 3600 Seconds)

















8) Save the settings and Test!

That should be all you need to do.

Notes

  • The VPN may not work behind some NAT routers. You can try turning on NAT-T within the netscreen, although I find it doesn't normally work.
  • Make sure the details in the Netscreen and Netscreen Remote Match (i.e Phase 1 policies etc)
  • You can check the logs from both Netscreen and Netscreen Remote
  • You cannot connect to the VPN while within the local subnet
  • Netscreen Remote should be disabled when you're directly connected to the network
  • Only traffic for the subnet is passed over the VPN.



Taken From:
http://www.juniperforum.com/index.php?page=20
Added minor correction in te policy source that has to be "Dial Up"

Friday, May 4, 2007

Basic Use of NetCat (Windows e Linux)

Netcat is already avaible in linux for windows you can download it, it's free.


TCP
---------------------------------------
With the comand below you can start a netcat server in any TCP port (here we use 53), in you local machine, and lets assume your local machine has the following IP 192.136.49.47.

# sudo nc -l -p 53

Now in another machine you can connect to the server at 192.136.49.47:53, with netcat as a client.

# sudo nc 192.136.49.47 53

To see if it's working you can type text in the bash (comand line) of the server or client and press enter and see if the text you inputed reaches the other machine, this is a simple and very reliable way to test connections between machines, and also firewalls

Bellow we have the same but for the UDP protocol.

UDP
------------------------------------
# sudo nc -l -p 53 -u

# sudo nc -u 192.136.49.47 53

Saturday, April 28, 2007

Install fwbuilder 2.1.10 from source in Ubuntu 7.04

Firewall builder is a gui to help you build frewalls, the target firewall can be iptable, ipfilter, cisco pix, etc.

Conect your computer to the internet.

# - means it´s to be executed in the bash shell, without the # of course


# sudo apt-get install qt3-dev-tools

# sudo apt-get install libc6-dev

# sudo apt-get install g++


# sudo apt-get install libxml2-dev

# sudo apt-get install libxslt1-dev



download libfwbuilder-2.1.10.tar.gz at here and extract it.

# cd /.../libfwbuilder-2.1.10

# ./configure

# sudo make

# sudo make install



Now we have to install some Qt packages in order to fwbuilder-2.1.10.tar.gz compile, i don't now exactly wich ones are needed, i instaled the folowing packages.

libavahi-qt3-1 0.6.17-0ubuntu3 -- Avahi Qt3 integration library
libqt3-compat-headers 3.3.8really3.3.7-0ubuntu5 -- Qt 1.x and 2.x compatibility includes
libqt3-headers 3.3.8really3.3.7-0ubuntu5 -- Qt3 header files
libqt3-i18n 3.3.8really3.3.7-0ubuntu5 -- i18n files for Qt3 library
libqt3-mt 3.3.8really3.3.7-0ubuntu5 -- Qt GUI Library (Threaded runtime version), V
libqt3-mt-dev 3.3.8really3.3.7-0ubuntu5 -- Qt development files (Threaded)
libqt4-core 4.2.3-0ubuntu3 -- Qt 4 core non-GUI functionality runtime libr
libqt4-dev 4.2.3-0ubuntu3 -- Qt 4 development files
libqt4-gui 4.2.3-0ubuntu3 -- Qt 4 core GUI functionality runtime library
libqt4-qt3support 4.2.3-0ubuntu3 -- Qt 3 compatibility library for Qt 4
libqt4-sql 4.2.3-0ubuntu3 -- Qt 4 SQL database module
libqthreads-12 1.6.8-6build1 -- QuickThreads library for Guile
qt3-designer 3.3.8really3.3.7-0ubuntu5 -- Qt3 Designer
qt3-dev-tools 3.3.8really3.3.7-0ubuntu5 -- Qt3 development tools

Some of these migth not be necessary.


download fwbuilder-2.1.10.tar.gz at here and extract it.

# cd /.../fwbuilder-2.1.10

# ./configure

# sudo make

# sudo make install



# cd /usr/lib/i486-linux-gnu/

or

# cd /usr/lib/x86_64-linux-gnu/

if you have a amd64 (x86_64-linux) processor (may also for other 64 bit cpus) runing a 64 bit linux distribution.


# sudo ln -s /usr/local/lib/libfwbuilder.so.7.3.0 libfwbuilder.so.7

# sudo ln -s /usr/local/lib/libfwcompiler.so.7.3.0 libfwcompiler.so.7


now just run "fwbuilder":

# fwbuilder