Monday, October 29, 2012

Basic iptables howto

Iptables is a firewall, installed by default on all official Ubuntu distributions (Ubuntu, Kubuntu, Xubuntu). When you install Ubuntu, iptables is there, but it allows all traffic by default. Ubuntu 8.04 Comes with ufw - a program for managing the iptables firewall easily.

There is a wealth of information available about iptables, but much of it is fairly complex, and if you want to do a few basic things, this How To is for you.

Basic Commands

Typing

sudo iptables -L


lists your current rules in iptables. If you have just set up your server, you will have no rules, and you should see



Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


Basic Iptables Options



Here are explanations for some of the iptables options you will see in this tutorial. Don't worry about understanding everything here now, but remember to come back and look at this list as you encounter new options later on.





  • -A - Append this rule to a rule chain. Valid chains for what we're doing are INPUT, FORWARD and OUTPUT, but we mostly deal with INPUT in this tutorial, which affects only incoming traffic.





  • -L - List the current filter rules.





  • -m conntrack - Allow filter rules to match based on connection state. Permits the use of the --ctstate option.





  • --ctstate - Define the list of states for the rule to match on. Valid states are:




    • NEW - The connection has not yet been seen.


    • RELATED - The connection is new, but is related to another connection already permitted.


    • ESTABLISHED - The connection is already established.


    • INVALID - The traffic couldn't be identified for some reason.





  • -m limit - Require the rule to match only a limited number of times. Allows the use of the --limit option. Useful for limiting logging rules.





    • --limit - The maximum matching rate, given as a number followed by "/second", "/minute", "/hour", or "/day" depending on how often you want the rule to match. If this option is not used and -m limit is used, the default is "3/hour".







  • -p - The connection protocol used.





  • --dport - The destination port(s) required for this rule. A single port may be given, or a range may be given as start:end, which will match all ports from start to end, inclusive.





  • -j - Jump to the specified target. By default, iptables allows four targets:





    • ACCEPT - Accept the packet and stop processing rules in this chain.





    • REJECT - Reject the packet and notify the sender that we did so, and stop processing rules in this chain.





    • DROP - Silently ignore the packet, and stop processing rules in this chain.





    • LOG - Log the packet, and continue processing more rules in this chain. Allows the use of the --log-prefix and --log-leveloptions.







  • --log-prefix - When logging, put this text before the log message. Use double quotes around the text to use.





  • --log-level - Log using the specified syslog level. 7 is a good choice unless you specifically need something else.





  • -i - Only match if the packet is coming in on the specified interface.





  • -I - Inserts a rule. Takes two options, the chain to insert the rule into, and the rule number it should be.





    • -I INPUT 5 would insert the rule into the INPUT chain and make it the 5th rule in the list.







  • -v - Display more information in the output. Useful for if you have rules that look similar without using -v.





  • -s --source - address[/mask] source specification





  • -d --destination - address[/mask] destination specification





  • -o --out-interface - output name[+] network interface name ([+] for wildcard)





Allowing Established Sessions



We can allow established sessions to receive traffic:



sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT



  • The above rule has no spaces either side of the comma in ESTABLISHED,RELATED



If the line above doesn't work, you may be on a castrated VPS whose provider has not made available the extension, in which case an inferior version can be used as last resort:



sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


Allowing Incoming Traffic on Specific Ports



You could start by blocking traffic, but you might be working over SSH, where you would need to allow SSH before blocking everything else.



To allow incoming traffic on the default SSH port (22), you could tell iptables to allow all TCP traffic on that port to come in.



sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT


Referring back to the list above, you can see that this tells iptables:




  • append this rule to the input chain (-A INPUT) so we look at incoming traffic


  • check to see if it is TCP (-p tcp).


  • if so, check to see if the input goes to the SSH port (--dport ssh).


  • if so, accept the input (-j ACCEPT).



Lets check the rules: (only the first few lines shown, you will see more)



sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh


Now, let's allow all incoming web traffic



sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT


Checking our rules, we have



sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:www


We have specifically allowed tcp traffic to the ssh and web ports, but as we have not blocked anything, all traffic can still come in.



Blocking Traffic



Once a decision is made to accept a packet, no more rules affect it. As our rules allowing ssh and web traffic come first, as long as our rule to block all traffic comes after them, we can still accept the traffic we want. All we need to do is put the rule to block all traffic at the end.



sudo iptables -A INPUT -j DROP
sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:www
DROP all -- anywhere anywhere


Because we didn't specify an interface or a protocol, any traffic for any port on any interface is blocked, except for web and ssh.



Editing iptables



The only problem with our setup so far is that even the loopback port is blocked. We could have written the drop rule for just eth0 by specifying -i eth0, but we could also add a rule for the loopback. If we append this rule, it will come too late - after all the traffic has been dropped. We need to insert this rule before that. Since this is a lot of traffic, we'll insert it as the first rule so it's processed first.



sudo iptables -I INPUT 1 -i lo -j ACCEPT
sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:www
DROP all -- anywhere anywhere


The first and last lines look nearly the same, so we will list iptables in greater detail.



sudo iptables -L -v


Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo any anywhere anywhere
0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:www
0 0 DROP all -- any any anywhere anywhere


You can now see a lot more information. This rule is actually very important, since many programs use the loopback interface to communicate with each other. If you don't allow them to talk, you could break those programs!



Logging



In the above examples none of the traffic will be logged. If you would like to log dropped packets to syslog, this would be the quickest way:



sudo iptables -I INPUT 5 -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7


See Tips section for more ideas on logging.



Saving iptables



If you were to reboot your machine right now, your iptables configuration would disappear. Rather than type this each time you reboot, however, you can save the configuration, and have it start up automatically. To save the configuration, you can use iptables-save and iptables-restore.



Configuration on startup



WARNING: Iptables and NetworkManager can conflict. Also if you are concerned enough about security to install a firewall you might not want to trust NetworkManager. Also note NetworkManager and iptables have opposite aims. Iptables aims to keep any questionable network traffic out.NetworkManager aims to keep you connected at all times. Therefore if you want security all the time, run iptables at boot time. If you want security some of the time then NetworkManager might be the right choice.



WARNING: If you use NetworkManager (installed by default on Feisty and later) these steps will leave you unable to use NetworkManager for the interfaces you modify. Please follow the steps in the next section instead.



NOTE: It appears on Hardy, NetworkManager has an issue with properly on saving and restoring the iptable rules when using the method in the next section. Using this first method appears to work. If you find otherwise, please update this note.



Save your firewall rules to a file



sudo sh -c "iptables-save > /etc/iptables.rules"


At this point you have several options. You can make changes to /etc/network/interfaces or add scripts to /etc/network/if-pre-up.d/ and /etc/network/if-post-down.d/ to achieve similar ends. The script solution allows for slightly more flexibility.



Solution #1 - /etc/network/interfaces


(NB: be careful - entering incorrect configuration directives into the interface file could disable all interfaces, potentially locking you out of a remote machine.)



Modify the /etc/network/interfaces configuration file to apply the rules automatically. You will need to know the interface that you are using in order to apply the rules - if you do not know, you are probably using the interface eth0, although you should check with the following command first to see if there are any wireless cards:



iwconfig


If you get output similar to the following, then you do not have any wireless cards at all and your best bet is probably eth0.



lo        no wireless extensions.

eth0 no wireless extensions.


When you have found out the interface you are using, edit (using sudo) your /etc/network/interfaces:



sudo nano /etc/network/interfaces


When in the file, search for the interface you found, and at the end of the network related lines for that interface, add the line:



pre-up iptables-restore < /etc/iptables.rules


You can also prepare a set of down rules, save them into second file /etc/iptables.downrules and apply it automatically using the above steps:



post-down iptables-restore < /etc/iptables.downrules


A fully working example using both from above:



auto eth0
iface eth0 inet dhcp
pre-up iptables-restore < /etc/iptables.rules
post-down iptables-restore < /etc/iptables.downrules


You may also want to keep information from byte and packet counters.



sudo sh -c "iptables-save -c > /etc/iptables.rules" 


The above command will save the whole rule-set to a file called /etc/iptables.rules with byte and packet counters still intact.



Solution #2 /etc/network/if-pre-up.d and ../if-post-down.d


NOTE: This solution uses iptables-save -c to save the counters. Just remove the -c to only save the rules.



Alternatively you could add the iptables-restore and iptables-save to the if-pre-up.d and if-post-down.d directories in the/etc/network directory instead of modifying /etc/network/interface directly.



The script /etc/network/if-pre-up.d/iptablesload will contain:



#!/bin/sh
iptables-restore < /etc/iptables.rules
exit 0


and /etc/network/if-post-down.d/iptablessave will contain:



#!/bin/sh
iptables-save -c > /etc/iptables.rules
if [ -f /etc/iptables.downrules ]; then
iptables-restore < /etc/iptables.downrules
fi
exit 0


Then be sure to give both scripts execute permissions:



sudo chmod +x /etc/network/if-post-down.d/iptablessave
sudo chmod +x /etc/network/if-pre-up.d/iptablesload


Solution #3 iptables-persistent


Install and use the iptables-persistent package.



Configuration on Startup for NetworkManager



NetworkManager includes the ability to run scripts when it activates or deactivates an interface. To save iptables rules on shutdown, and to restore them on startup, we are going to create such a script. To begin, press Alt+F2 and enter this command:



For Ubuntu:



gksudo gedit /etc/NetworkManager/dispatcher.d/01firewall


For Kubuntu:



kdesu kate /etc/NetworkManager/dispatcher.d/01firewall


Then, paste this script into your editor, save, and exit the editor.



if [ -x /usr/bin/logger ]; then
LOGGER="/usr/bin/logger -s -p daemon.info -t FirewallHandler"
else
LOGGER=echo
fi

case "$2" in
up)
if [ ! -r /etc/iptables.rules ]; then
${LOGGER} "No iptables rules exist to restore."
return
fi
if [ ! -x /sbin/iptables-restore ]; then
${LOGGER} "No program exists to restore iptables rules."
return
fi
${LOGGER} "Restoring iptables rules"
/sbin/iptables-restore -c < /etc/iptables.rules
;;
down)
if [ ! -x /sbin/iptables-save ]; then
${LOGGER} "No program exists to save iptables rules."
return
fi
${LOGGER} "Saving iptables rules."
/sbin/iptables-save -c > /etc/iptables.rules
;;
*)
;;
esac


Finally, we need to make sure NetworkManager can execute this script. In a terminal window, enter this command:



sudo chmod +x /etc/NetworkManager/dispatcher.d/01firewall


Tips



If you manually edit iptables on a regular basis


The above steps go over how to setup your firewall rules and presume they will be relatively static (and for most people they should be). But if you do a lot of development work, you may want to have your iptables saved everytime you reboot. You could add a line like this one in/etc/network/interfaces:



  pre-up iptables-restore < /etc/iptables.rules
post-down iptables-save > /etc/iptables.rules


The line "post-down iptables-save > /etc/iptables.rules" will save the rules to be used on the next boot.



Using iptables-save/restore to test rules


If you edit your iptables beyond this tutorial, you may want to use the iptables-save and iptables-restore feature to edit and test your rules. To do this open the rules file in your favorite text editor (in this example gedit).



sudo sh -c "iptables-save > /etc/iptables.rules"
gksudo gedit /etc/iptables.rules


You will have a file that appears similiar to (following the example above):



# Generated by iptables-save v1.3.1 on Sun Apr 23 06:19:53 2006
*filter
:INPUT ACCEPT [368:102354]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [92952:20764374]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -j DROP
COMMIT
# Completed on Sun Apr 23 06:19:53 2006


Notice that these are iptables commands minus the iptable command. Feel free to edit this to file and save when complete. Then to test simply:



sudo iptables-restore < /etc/iptables.rules


NOTE: With iptables 1.4.1.1-1 and above, a script allow you to test your new rules without risking to brick your remote server. If you are applying the rules on a remote server, you should consider testing it with:



sudo iptables-apply /etc/iptables.rules


After testing, if you have not added the iptables-save command above to your /etc/network/interfaces remember not to lose your changes:



sudo sh -c "iptables-save > /etc/iptables.rules"


More detailed Logging


For further detail in your syslog you may want create an additional Chain. This will be a very brief example of my /etc/iptables.rules showing how I setup my iptables to log to syslog:



# Generated by iptables-save v1.3.1 on Sun Apr 23 05:32:09 2006
*filter
:INPUT ACCEPT [273:55355]
:FORWARD ACCEPT [0:0]
:LOGNDROP - [0:0]
:OUTPUT ACCEPT [92376:20668252]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j LOGNDROP
-A LOGNDROP -p tcp -m limit --limit 5/min -j LOG --log-prefix "Denied TCP: " --log-level 7
-A LOGNDROP -p udp -m limit --limit 5/min -j LOG --log-prefix "Denied UDP: " --log-level 7
-A LOGNDROP -p icmp -m limit --limit 5/min -j LOG --log-prefix "Denied ICMP: " --log-level 7
-A LOGNDROP -j DROP
COMMIT
# Completed on Sun Apr 23 05:32:09 2006


Note a new CHAIN called LOGNDROP at the top of the file. Also, the standard DROP at the bottom of the INPUT chain is replaced with LOGNDROPand add protocol descriptions so it makes sense looking at the log. Lastly we drop the traffic at the end of the LOGNDROP chain. The following gives some idea of what is happening:





  • --limit sets the number of times to log the same rule to syslog





  • --log-prefix "Denied..." adds a prefix to make finding in the syslog easier





  • --log-level 7 sets the syslog level to informational (see man syslog for more detail, but you can probably leave this)





Disabling the firewall


If you need to disable the firewall temporarily, you can flush all the rules using



sudo iptables -F


or create a script using text editor such as nano



sudo nano -w /root/fw.stop


echo "Stopping firewall and allowing everyone..."
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT


Make sure you can execute the script



sudo chmod +x /root/fw.stop


You can run the script



sudo /root/fw.stop
Continue Reading »

Thursday, October 25, 2012

Routing for multiple uplinks/providers

A common configuration is the following, in which there are two providers that connect a local network (or even a single machine) to the big Internet.

                                                                 ________
+------------+ /
| | |
+-------------+ Provider 1 +-------
__ | | | /
___/ \_ +------+-------+ +------------+ |
_/ \__ | if1 | /
/ \ | | |
| Local network -----+ Linux router | | Internet
\_ __/ | | |
\__ __/ | if2 | \
\___/ +------+-------+ +------------+ |
| | | \
+-------------+ Provider 2 +-------
| | |
+------------+ \________


There are usually two questions given this setup.



4.2.1. Split access



The first is how to route answers to packets coming in over a particular provider, say Provider 1, back out again over that same provider.



Let us first set some symbolical names. Let $IF1 be the name of the first interface (if1 in the picture above) and $IF2 the name of the second interface. Then let $IP1 be the IP address associated with $IF1 and $IP2 the IP address associated with $IF2. Next, let $P1 be the IP address of the gateway at Provider 1, and $P2 the IP address of the gateway at provider 2. Finally, let $P1_NET be the IP network $P1 is in, and $P2_NET the IP network $P2 is in.



One creates two additional routing tables, say T1 and T2. These are added in /etc/iproute2/rt_tables. Then you set up routing in these tables as follows:



	  ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2

Nothing spectacular, just build a route to the gateway and build a default route via that gateway, as you would do in the case of a single upstream provider, but put the routes in a separate table per provider. Note that the network route suffices, as it tells you how to find any host in that network, which includes the gateway, as specified above.

Next you set up the main routing table. It is a good idea to route things to the direct neighbour through the interface connected to that neighbour. Note the `src' arguments, they make sure the right outgoing IP address is chosen.



	    ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2

Then, your preference for default route:

	    ip route add default via $P1

Next, you set up the routing rules. These actually choose what routing table to route with. You want to make sure that you route out a given interface if you already have the corresponding source address:

	    ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

This set of commands makes sure all answers to traffic coming in on a particular interface get answered from that interface.

Warning



Reader Rod Roark notes: 'If $P0_NET is the local network and $IF0 is its interface, the following additional entries are desirable:



ip route add $P0_NET     dev $IF0 table T1
ip route add $P2_NET dev $IF2 table T1
ip route add 127.0.0.0/8 dev lo table T1
ip route add $P0_NET dev $IF0 table T2
ip route add $P1_NET dev $IF1 table T2
ip route add 127.0.0.0/8 dev lo table T2

'

Now, this is just the very basic setup. It will work for all processes running on the router itself, and for the local network, if it is masqueraded. If it is not, then you either have IP space from both providers or you are going to want to masquerade to one of the two providers. In both cases you will want to add rules selecting which provider to route out from based on the IP address of the machine in the local network.



4.2.2. Load balancing



The second question is how to balance traffic going out over the two providers. This is actually not hard if you already have set up split access as above.



Instead of choosing one of the two providers as your default route, you now set up the default route to be a multipath route. In the default kernel this will balance routes over the two providers. It is done as follows (once more building on the example in the section on split-access):



	    ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
nexthop via $P2 dev $IF2 weight 1

This will balance the routes over both providers. The weight parameters can be tweaked to favor one provider over the other.

Note that balancing will not be perfect, as it is route based, and routes are cached. This means that routes to often-used sites will always be over the same provider.



Furthermore, if you really want to do this, you probably also want to look at Julian Anastasov's patches at http://www.ssi.bg/~ja/#routes , Julian's route patch page. They will make things nicer to work with.

Continue Reading »

Cum poti accesa de la distanta computerul tau - Chrome Remote Desktop - Teamviewer

Daca doriti sa accesati de la distanta computerul dvs. puteti folosi Google Chrome Remote Desktop.

De la inceput se anunta ca un adversar de temut al lui Temaviewer.

Google Chrome Remote Desktop permite sa accesati de la distanta computerul  dvs. sau un alt calculator  prin instalarea unei extensii pentru browserul dvs. Google Chrome.

clip_image001[4]

Pentru cei familiarizati cu Remote Assistance ,Google Chrome Remote Desktop a introdus o sectiune dedicata care permite sa acordati suport tehnic prin facilitatea user-to-user screen sharing.

clip_image002[4]

Pentru a putea accesa computerul dvs trebuie sa stabiliti un pin de cel putin sase caractere necesar in momentul conectarii.

clip_image003[4]

Ca si noi caracteristici Google Chrome Remote Desktoppermite transmiterea in timp real a sunetelor computerului dvs de la distanta, precum si mult utila posibilitate de a face “copy” -“paste” intre computerul local si cel pe care il accesati de la distanta.

Download Chrome Remote Desktop.

Continue Reading »

Wednesday, October 24, 2012

Running Additional Programs at Boot Time in CentOS

The /etc/rc.d/rc.local script is executed by the init command at boot time or when changing runlevels. Adding commands to the bottom of this script is an easy way to perform necessary tasks like starting special services or initialize devices without writing complex initialization scripts in the/etc/rc.d/init.d/ directory and creating symbolic links.

The /etc/rc.serial script is used if serial ports must be setup at boot time. This script runs setserialcommands to configure the system's serial ports. Refer to the setserial man page for more information.

Continue Reading »

Centos iptables FORWARD and NAT Rules

Most organizations are allotted a limited number of publicly routable IP addresses from their ISP. Due to this limited allowance, administrators must find creative ways to share access to Internet services without giving limited public IP addresses to every node on the LAN. Using private IP address is the common way to allow all nodes on a LAN to properly access internal and external network services. Edge routers (such as firewalls) can receive incoming transmissions from the Internet and route the packets to the intended LAN node. At the same time, firewall/gateways can also route outgoing requests from a LAN node to the remote Internet service. This forwarding of network traffic can become dangerous at times, especially with the availability of modern cracking tools that can spoof internal IP addresses and make the remote attacker's machine act as a node on your LAN. To prevent this, iptables provides routing and forwarding policies that can be implemented to prevent aberrant usage of network resources.

The FORWARD policy allows an administrator to control where packets can be routed within a LAN. For example, to allow forwarding for the entire LAN (assuming the firewall/gateway is assigned an internal IP address on eth1), the following rules can be set:

iptables -A FORWARD -i eth1 -j ACCEPT
iptables -A FORWARD -o eth1 -j ACCEPT


This rule gives systems behind the firewall/gateway access to the internal network. The gateway routes packets from one LAN node to its intended destination node, passing all packets through its eth1 device.



Note



By default, the IPv4 policy in Red Hat Enterprise Linux kernels disables support for IP forwarding, which prevents boxes running Red Hat Enterprise Linux from functioning as dedicated edge routers. To enable IP forwarding, run the following command:



sysctl -w net.ipv4.ip_forward=1


If this command is run via shell prompt, then the setting is not remembered after a reboot. You can permanently set forwarding by editing the /etc/sysctl.conffile. Find and edit the following line, replacing 0 with 1:



net.ipv4.ip_forward = 0


Execute the following command to enable the change to the sysctl.conf file:



 sysctl -p /etc/sysctl.conf 




Accepting forwarded packets via the firewall's internal IP device allows LAN nodes to communicate with each other; however they still are not allowed to communicate externally to the Internet. To allow LAN nodes with private IP addresses to communicate with external public networks, configure the firewall for IP masquerading, which masks requests from LAN nodes with the IP address of the firewall's external device (in this case, eth0):



 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 


The rule uses the NAT packet matching table ( -t nat) and specifies the built-in POSTROUTING chain for NAT ( -A POSTROUTING) on the firewall's external networking device ( -o eth0). POSTROUTING allows packets to be altered as they are leaving the firewall's external device. The -j MASQUERADE target is specified to mask the private IP address of a node with the external IP address of the firewall/gateway.





If you have a server on your internal network that you want make available externally, you can use the -j DNAT target of the PREROUTING chain in NAT to specify a destination IP address and port where incoming packets requesting a connection to your internal service can be forwarded. For example, if you wanted to forward incoming HTTP requests to your dedicated Apache HTTP Server server system at 172.31.0.23, run the following command:



iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \
--to 172.31.0.23:80


This rule specifies that the NAT table use the built-in PREROUTING chain to forward incoming HTTP requests exclusively to the listed destination IP address of 172.31.0.23.



Note



If you have a default policy of DROP in your FORWARD chain, you must append a rule to allow forwarding of incoming HTTP requests so that destination NAT routing can be possible. To do this, run the following command:



iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT


This rule allows forwarding of incoming HTTP requests from the firewall to its intended destination of the Apache HTTP Server server behind the firewall.



7.4.1. DMZs and iptables




iptables rules can be set to route traffic to certain machines, such as a dedicated HTTP or FTP server, in a demilitarized zone ( DMZ) — a special local subnetwork dedicated to providing services on a public carrier such as the Internet. For example, to set a rule for routing incoming HTTP requests to a dedicated HTTP server at 10.0.4.2 (outside of the 192.168.1.0/24 range of the LAN), NAT calls a PREROUTING table to forward the packets to their proper destination:



iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \ --to-destination 10.0.4.2:80


With this command, all HTTP connections to port 80 from the outside of the LAN are routed to the HTTP server on a separate network from the rest of the internal network. This form of network segmentation can prove safer than allowing HTTP connections to a machine on the network. If the HTTP server is configured to accept secure connections, then port 443 must be forwarded as well.



Continue Reading »

How to enable IP Forwarding

By default any modern Linux distributions will have IP Forwarding disabled. This is normally a good idea, as most peoples will not need IP Forwarding, but if we are setting up a Linux router/gateway or maybe a VPN server (pptp or ipsec) or just a plain dial-in server then we will need to enable forwarding. This can be done in several ways that I will present bellow.
Check if IP Forwarding is enabled
We have to query the sysctl kernel value net.ipv4.ip_forward to see if forwarding is enabled or not:
Using sysctl:

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
or just checking out the value in the /proc system:
cat /proc/sys/net/ipv4/ip_forward
0
As we can see in both the above examples this was disabled (as show by the value 0).
Enable IP Forwarding on the fly
As with any sysctl kernel parameters we can change the value of net.ipv4.ip_forward on the fly (without rebooting the system):
sysctl -w net.ipv4.ip_forward=1
or
echo 1 > /proc/sys/net/ipv4/ip_forward
the setting is changed instantly; the result will not be preserved after rebooting the system.
Permanent setting using /etc/sysctl.conf
If we want to make this configuration permanent the best way to do it is using the file /etc/sysctl.conf where we can add a line containing net.ipv4.ip_forward = 1
/etc/sysctl.conf:
net.ipv4.ip_forward = 1
if you already have an entry net.ipv4.ip_forward with the value 0 you can change that 1.
To enable the changes made in sysctl.conf you will need to run the command:
sysctl -p /etc/sysctl.conf
On RedHat based systems this is also enabled when restarting the network service:
service network restart
Continue Reading »

How To Add Static Routes In CentOS

There are numerous ways to add static routes in Linux (CentOS). The easiest way is via the terminal by using one of the following examples.

How to add a static route for a specific host in Linux.
route add -host 192.168.1.47 gw 192.168.10.1
route del -host 192.168.1.47 gw 192.168.10.1

How to add a static route for a specific network in Linux.
route add -net 192.168.1.0/24 gw 192.168.10.1
route del -net 192.168.1.0/24 gw 192.168.10.1

How to add a default gateway.
route add default gw 192.168.10.1
route del default gw 192.168.10.1

The best place to add the default gateway is in the file /etc/sysconfig/network which would then look something like the below.

NETWORKING=yes
NETWORKING_IPV6=yes
HOSTNAME=server.example.com
GATEWAY=192.168.0.10


Also note that default gateways are added on a per interface level in their startup files located in /etc/sysconfig/network-scripts. Example: /etc/sysconfig/network-scripts/ifcfg-eth0



One of the places to add a static route so it is added each time you reboot the server is to add it to /etc/sysconfig/rc.local. Your rc.local file would then look something like the below.



#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local

# Static Routes
/sbin/route add -net 192.168.1.0/24 gw 192.168.10.1
/sbin/route add -host 192.168.1.47 gw 192.168.10.1
Continue Reading »

Wednesday, October 17, 2012

Cum dai access la internet la alt calculator din casa sau Cum configurezi Windows 7 pentru Internet Connection Sharing

Daca vrei sa dai access la un alt calculator din casa prin calculatorul tau poti folosi  Internet Connection Sharing .Dureaza 2 minute pana configurezi.

Trebuie sa ai doua placi de retea pe calculatorul tau(una care se va conecta la providerul de internet si cealalta pe computerul care il vreti conectat la internet).

Aveti nevoie de un cablu crossover pentru a interconecta cele doua calculatoare.
Cum configurezi  Internet Conection Sharing ?

1. Right-click pe icoana Network Configuration din System Tray.
2. Click Open Network and Sharing Center.

clip_image002[4]
3. Click Change adapter settings localizat in stanga

clip_image004

4. Right-click pe placa de retea care este conectata la internet si selectati Properties.

clip_image006

5.In fereastra nou aparuta click pe tabul Sharing. 

6.Bifati Allow other network users to connect through this computer’s Internet connection.

clip_image008

7. Click OK pe fiecare fereastra pentru a salva modificarile facute

Gata, computerul dvs. va avea access la internet.

Nota: Acest ghid se aplica cu success si pe alte versiuni de windows. Poti configura Internet Connection Sharing si pe Windows XP.

Continue Reading »

Monday, October 1, 2012

How to properly issue a certificate for Forefront TMG Standalone Arrays in a workgroup

Hello,
Due to the problems and pain we have encountered in making Forefront TMG 2010 Standalone Array in a workgroup to work on VMware ESX 3.5 Update 5 I will detail the steps for creating and importing certificates to TMG certificates store and point out to the problems with TMG Control service dependencies.
This is the environment we had:

· Two Forefront TMG 2010 Enterprise Servers in a workgroup configured in Standalone Array with one TMG configured as Array Manager and another configured as Array Member

· Windows Server 2008 R2 Standard

· Virtual machines on VMware ESX 3.5 Update 5

During the implementation we have experienced the problem with Forefront TMG Control service taking 10 minutes to start after a server restart. The service would eventually start but the other Forefront services that depend on it will fail to start.
The problem was solved implementing the following fixes:

· Issue a proper "Server Authentication" certificate and place it in a proper Certificates store

· Configure Forefront TMG Control service dependencies to include KeyIso and HTTP services - described here: TMG is taking more than 16 minutes to start on Windows 2008 R2

I do not imply with this article that the problem with TMG Control service hang is related only to VMware ESX but we only experienced it on this platform. When we encountered the problem we did some tests on Hyper-V environment and on separate VMware ESX 3.5 Update 5 environment and there was no problem, however on this particular environment the service would not start once the TMG array was configured.
So I would recommend for anyone to get these dependencies fixed even if you do not encounter this problem now. Regarding the problem with certificates, I have already blogged about it here but I also wrote a procedure how to properly issue Server Authentication certificate for TMG arrays in a workgroup.
How to issue a proper "Server Authentication" certificate
Prerequisites:

· Access to any Windows Server 2008 IIS 7.0 web server

· Access to Enterprise or Standalone Windows Sever 2008 Certification Authority (Windows 2003 CA is also okay)

1. Open the IIS Manager, click on server name node from the left pane and click on "Server Certificates" from the middle pane

clip_image002[4]

2. Click on the "Create Certificate Request" from the right pane
3. In the "Common name" field type the FQDN of the TMG server that will act as an Array Manager. In this example we will use "tmg01.company.hr". Fill the remaining fields so that you best describe your organization.

clip_image004[4]

4. Choose "Microsoft RSA SChannell Cryptographic Provider" for the "Cryptographic service provider" and choose 2048 for the "Bit lenght".
5. Save the certificate request as C:\tmg01.req.
6. Navigate to the Issuing or Root CA web site such as https://yourservername/certsrv and click on "Request a certificate"

clip_image006[4]

7. Click on "advanced certificate request"
8. Click on "Submit a certificate request by using  a base-64-encoded CMC or PKCS #10 file, or submit a renewall request  by using a base-64-encoded PKCMS #7 file".
9. Paste the contents of the tmg01.req file that you have created earlier from IIS to the "Base-64-encoded certificate request" field. In case you have a drop-box with Certificate Templates list, select "Web Server" template.

clip_image008[4]

10. Your certificate request is now submitted to the CA. In case the "Request Handling" property of your CA is set to automatically issue certificates you will be presented with the following page where you have the possibility to download your issued "cer" file. Click on "Download certificate" and save the file as C:\tmg01.cer. Go to the step number 15.

clip_image010[4]


In case the "Request Handling" is set to manually issue the certificates by the administrator then you will have to perform the following steps.
11. Open the "Certification Authority" console on your Issuing CA server and click on "Pending Requests". You should see your request in the right pane.
12. Right click on the request and select All Tasks > Issue.

clip_image012[4]

13. Browse to the CA web site again (https://yourservername/certsrv) and click "View the status of the pending certificate request". There should be your "Saved-Certificate Request" listed.

clip_image014[4]

14. You are now presented with the same page as in step number 10. Download the "cer" file as described in step 10 and proceed to step 15.
15. Now return to the IIS Manager console from which you have created the certificate request and now select "Complete Certificate Request".
16. In the "Specify Certificate Authority Response" screen browse to the "cer" file you  have downloaded from the CA and enter a friendly name for the certificate. I usually type the same name as common name.

clip_image016[4]

You have now completed the procedure of issuing the "Server Authentication" certificate. If you open the "Local Computer" Certificates store on the server where you have requested the certificate you should see the certificate in the Personal > Certificates folder. The certificate icon should have a little yellow key pictured which means that you have both private and public key. We must export the certificate with private and public keys so that we can import it on our TMG server.
17. Right click on the certificate and click All Tasks > Export.

clip_image018[4]

18. Select "Yes, export the private key".
19. "Personal Information Exchange - PKCS #12 (.PFX)" should be selected. Unmark all the checkboxes and click Next.

clip_image020[4]

20. Type the password that you will need to type when you import the certificate to the TMG computer.
21. Save the certificate as C:\tmg01.pfx. 
Now that we have our certificate ready for import there is still one thing we must do. Since we are creating TMG array in a workgroup mode we must import the root certificate of the CA that issued the certificate to all of the TMG servers that will participate in array. But first we must export the root CA certificate from a computer that has it.
22. Open the "Local Computer" Certificates store on the Issuing CA computer or on some other computer which is a domain member in a domain where CA resides.
23. Navigate to the Trusted Root Certification Authorities > Certificates, right-click on the root certificate from the CA which issued your certificate and select All Tasks > Export.

clip_image022[4]

24. Select "DER encoded binary X.509 (.CER)" and click Next.
25. Save the "cer" file to disk. In our example it is C:\CompanyRootCA.cer.
Now we have both the PFX file which contains our public and private keys for the TMG computer certificate and a CER file that contains a public key from our root CA. The next thing we must do is to import the root certificate to each TMG server that will participate in the array and to import the "Server Authentication" certificate.
Note: It is good practice to create "Server Authentication" certificate for all TMG servers so that if Array Manager fails you can promote some other Array Member to Array Manager.
26. Open the "Local Computer" Certificates store on each TMG server and import the root certificate "cer" file to the "Trusted Root Certification Authorities".
27. Now open the "Forefront TMG Management" console on the TMG server that will act as an Array Manager. Expand "Forefront TMG" in the left pane and click on System node. Click on the TMG server name in the center pane and click on the "Install Server Certificate" in the right pane.

clip_image024[4]

28. Now browse to the "pfx" file you have exported from the web server computer and type a password for the file. Unmark the checkbox "Automatically create the root CA certificate on this array manager." To my experience leaving this checkbox marked always resulted in an error even though the pfx file contained the root CA certificate. Click OK.

clip_image026[4]

Now if you open the Certificates store for the Windows service named ISASTGCTRL you should see the imported certificate with the private key in the Personal store.

clip_image028[4]

So why is important to use Forefront TMG Management console to import the certificate? You could just import the certificate in the Local Computer Certificates store, right? Well the answer is yes and no. If you do it this way the ISASTGCTRL service will not have enough permissions to read private key file that is stored in the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys and you would get Schannel errors in the Windows event log and TMG Control service would not be able to communicate with the ADAM service (ISASTGCTRL) on the Array Manager computer. If you use Forefront TMG Management console to import the certificate all the necessary permissions are added to the private key file including:

· SYSTEM

· NETWORK SERVICE

· fwsrv

Of course you could manually update the permissions on the private key file if you knew which private key it is and things would work but it is not the proper way to do this.
Test the connection
Now there is only thing left and that is to test the secure LDAP connection to the Array Manager server. We will use ldp.exe for this. You should be able to run it from your TMG servers.
Open ldp.exe and click on Connection > Connect. Type FQDN of your TMG server that will act as Array Manager and type 2172 for the port number as this is the port on which ISASTGCTRL service listens. Click on the SSL and click Connect.

clip_image030[4]

If the connection is successful you will see the screen like the following:

clip_image032[4]

And that is all there is to it! Make sure to complete the procedure for all TMG servers that will participate in the array for the already mentioned reason and that is so that another Array Member can become Array Manager in case the Array Manager fails.

Continue Reading »

0×80094801 – the request contains no certificate template information

On my Windows 2008 (AD) Certificate services console I get this error message when I try to add a Web Server Certificate Request file.

0×80094801 – the request contains no certificate template information

The solution is to import the Certificate Request in command line with CertReq tool.  Use the following command to import your Certificate Request file.

certreq -submit -attrib "CertificateTemplate:WebServer" <Cert Request.req>

If the template is different, find the correct template name in “Certificate Authority” console. If you don’t find it, you may have to add the template before you try importing the request file

Continue Reading »