Showing posts with label Centos. Show all posts
Showing posts with label Centos. Show all posts

Tuesday, February 17, 2015

/var/spool/squid/swap.state: (13) Permission denied FATAL: commonUfsDirOpenSwapLog: Failed to open swap log.

Daca primesti eroarea de mai jos:

2015/02/17 08:13:39| Store logging disabled

2015/02/17 08:13:39| Swap maxSize 30720000 + 2048000 KB, estimated 2520615 objects

2015/02/17 08:13:39| Target number of buckets: 126030

2015/02/17 08:13:39| Using 131072 Store buckets

2015/02/17 08:13:39| Max Mem  size: 2048000 KB

2015/02/17 08:13:39| Max Swap size: 30720000 KB

2015/02/17 08:13:39| /var/spool/squid/swap.state: (13) Permission denied

FATAL: commonUfsDirOpenSwapLog: Failed to open swap log.

Cum rezolvi eroarea de mai sus si cum o rezolvi..

Principalul vinovat e cache-ul squid-ului si permisiunile acestuia..

Eu am intalnit-o pe un Centos..

Primul pas e sa afli locatia directorului squid cache

Intr-un terminal dai comanda

grep cache_dir /etc/squid/squid.conf

si vei avea un output de genul

cache_dir ufs /var/spool/squid 100 16 256

apoi dai comanda

# squid -k shutdown

Apoi ar cam trebui sa stergi directoarele de cache cu comenzile de mai jos

# rm -rf /path/to/dir/cache/

# rm -rf /var/spool/squid/

Apoi va trebui sa recreezi directoarele tocmai sterse si sa aplici permisiuni corespunzator owner-ului squid

# mkdir /var/spool/squid

# chown squid:squid /var/spool/squid

In cazul meu fiindca foloseam SELinux, a fost nevoie de restaurare a permisiunilor SELinux si se rezolva cu comanda

# restorecon -vr /var/spool/squid

Apoi va trebui sa recreezi directoarele de cache cu comanda

# squid -z

Si va afisa ceva de genul

2015/08/24 04:24:19| Making directories in /var/spool/squid/002015/08/24 04:24:19| Making directories in /var/spool/squid/012015/08/24 04:24:19| Making directories in /var/spool/squid/022015/08/24 04:24:20| Making directories in /var/spool/squid/032015/08/24 04:24:20| Making directories in /var/spool/squid/042015/08/24 04:24:20| Making directories in /var/spool/squid/052015/08/24 04:24:20| Making directories in /var/spool/squid/062015/08/24 04:24:20| Making directories in /var/spool/squid/072015/08/24 04:24:20| Making directories in /var/spool/squid/082015/08/24 04:24:20| Making directories in /var/spool/squid/092015/08/24 04:24:20| Making directories in /var/spool/squid/0A2015/08/24 04:24:20| Making directories in /var/spool/squid/0B2015/08/24 04:24:20| Making directories in /var/spool/squid/0C2015/08/24 04:24:20| Making directories in /var/spool/squid/0D2015/08/24 04:24:20| Making directories in /var/spool/squid/0E2015/08/24 04:24:20| Making directories in /var/spool/squid/0F

Poai va trebui sa pornesti serviciul squid cu

/etc/init.d/squid start

Apoi verifici functinalitatea cu comenzile de mai jos

# netstat -tulpn | grep :3128

# tail -f /var/log/squid/access.log

# tail -f /var/log/squid/cache.log

Continue Reading »

Sunday, May 5, 2013

Cum cauti in linuc fisiere si copiezi rezultatul intr-un folder

Comanda de mai jos cauta toate fisierele cu extensia .html si le copiaza in folderul /admin

find / -name "*.html" -exec cp {} /admin \;

Continue Reading »

Sunday, April 28, 2013

Cum convertesti data in squid

Stiti cu totii ca daca din fisierul access.log din squid nu e in format “human readable” si e salvata in formatul <unix timestamp>.<centisecond> si pentru a procesa folositi comanda de mai jos

cat access.log | perl -p -e 's/^([0-9]*)/"[".localtime($1)."]"/e'

squid linux

Continue Reading »

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 »

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 »

Tuesday, March 20, 2012

Cum spargi sau resetezi parola de root in Centos Linux

Help! I forgot my root password. How do I log in now?

You can log in using single-user mode and create a new root password.

To enter single-user mode, reboot your computer. If you use the default boot loader, GRUB, you can enter single user mode by performing the following:

  1. At the boot loader menu, use the arrow keys to highlight the installation you want to edit and type [A] to enter into append mode.

  2. You are presented with a prompt that looks similar to the following:

    grub append> ro root=LABEL=/




  3. Press the Spacebar once to add a blank space, then add the word single to tell GRUB to boot into single-user Linux mode. The result should look like the following:



    ro root=LABEL=/ single




  4. Press [Enter] and GRUB will boot single-user Linux mode. After it finishes loading, you will be presented with a shell prompt similar to the following:



    sh-2.05b#




  5. You can now change the root password by typing



    passwd root


    You will be asked to re-type the password for verification. Once you are finished, the password will be changed. You can then reboot by typing reboot at the prompt; then you can log in to root as you normally would.



Continue Reading »