Source: Developpez.com – Christian Caleca
Encore un pépite dans la collection de Christian Caleca. C’est grâce à cet article que j’ai commencé à m’intéresser à la protection contre les agressions réseau.
[pdfviewer width= »600px » height= »849px » beta= »true/false »]https://www.dbsysnet.com/wp-content/uploads/2015/10/Caleca-11-NetFilter-IPtables.pdf[/pdfviewer]
Source: CyberPunk
A firewall is a system that provides network security by filtering incoming and outgoing network traffic based on a set of user-defined rules. In general, the purpose of a firewall is to reduce or eliminate the occurrence of unwanted network communications while allowing all legitimate communication to flow freely. In most server infrastructures, firewalls provide an essential layer of security that, combined with other measures, prevent attackers from accessing your servers in malicious ways.
A firewall typically establishes a barrier between a trusted, secure internal network and another outside network, such as the Internet, that is assumed to not be secure or trusted. Firewalls are often categorized as either network firewalls or host-based firewalls. Network firewalls are a software appliance running on general purpose hardware or hardware-based firewall computer appliances that filter traffic between two or more networks. Host-based firewalls provide a layer of software on one host that controls network traffic in and out of that single machine. Routers that pass data between networks contain firewall components and can often perform basic routing functions as well, Firewall appliances may also offer other functionality to the internal network they protect such as acting as a DHCP or VPN server for that network.
TCP network traffic moves around a network in packets, which are containers that consist of a packet header—this contains control information such as source and destination addresses, and packet sequence information—and the data (also known as a payload). While the control information in each packet helps to ensure that its associated data gets delivered properly, the elements it contains also provides firewalls a variety of ways to match packets against firewall rules.
It is important to note that successfully receiving incoming TCP packets requires the receiver to send outgoing acknowledgment packets back to the sender. The combination of the control information in the incoming and outgoing packets can be used to determine the connection state (e.g. new, established, related) of between the sender and receiver.
There are different types of firewalls depending on where the communication is taking place, where the communication is intercepted and the state that is being traced.
Network layer firewalls, also called packet filters, operate at a relatively low level of the TCP/IP protocol stack, not allowing packets to pass through the firewall unless they match the established rule set. The firewall administrator may define the rules; or default rules may apply. The term “packet filter” originated in the context of BSD operating systems.
Network layer firewalls generally fall into two sub-categories, stateful and stateless.
maintain context about active sessions, and use that “state information” to speed packet processing. Any existing network connection can be described by several properties, including source and destination IP address, UDP or TCP ports, and the current stage of the connection’s lifetime (including session initiation, handshaking, data transfer, or completion connection). If a packet does not match an existing connection, it will be evaluated according to the ruleset for new connections. If a packet matches an existing connection based on comparison with the firewall’s state table, it will be allowed to pass without further processing.
require less memory, and can be faster for simple filters that require less time to filter than to look up a session. They may also be necessary for filtering stateless network protocols that have no concept of a session. However, they cannot make more complex decisions based on what stage communications between hosts have reached.
After recently upgrading some of my servers to Debian Wheezy, I noticed the xtables-addons-dkms package is now available. This means you no longer have to build the iptables modules from source to get tarpit support (and more). If you are not sure what the tarpit target is or why you would want to use it, a basic explaination is that you send unwated TCP traffic to the tarpit target with iptables. All connections are accepted and immediatedly switched to the persist state. The remote side stops sending data and asks to continue every 60-240 seconds and attemts to close the connections from the remote side are ignored. The connection will then timeout in 12-24 minutes.
You might want to do this to slow down and even crash port scans (eg. routed unused ip space to a server with these rules in the forward chain in iptables).
To get started, install the xtables-addons-dkms package:
# apt-get install xtables-addons-dkms
Add rules to send traffic to the tarpit target to suite your needs. Some examples are:
iptables -A INPUT -p tcp --dport mysql -j TARPITiptables -A INPUT -p tcp --dport ms-sql-s -j TARPITiptables -A INPUT -p tcp -s 123.123.123.123 -j TARPITiptables -A INPUT -p tcp -j TARPITTo test that the above rules are working you can telnet to the host on a port that should go to the tarpit. If the connection works and your connection does not get closed within a few minutes it is working.
As an example of the effect this has on a port scan, I ran nmap on the host before and after. The results speak for themselves:
Before:
me ~ # nmap -sV 123.123.123.123 Starting Nmap 5.00 ( http://nmap.org ) at 2013-08-11 08:15 WST Stats: 0:00:52 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 0.00% done .... Nmap done: 1 IP address (1 host up) scanned in 127.25 seconds
After:
Starting Nmap 5.00 ( http://nmap.org ) at 2013-08-11 08:15 WST Stats: 0:02:15 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 1.40% done; ETC: 10:37 (2:38:18 remaining) Stats: 0:17:37 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 9.41% done; ETC: 11:04 (2:49:36 remaining) ....(crash).... me ~ #
Routers between you and the attacker may have issues due to the large amount of connections that will be held open, so make sure you gear can handle it before you try this (the nmap scan as above had a constant 500+ connections open for the tarpit scan alone). This can be an issue if you have a large range routed to the server doing the tarpit.
Source: sysadminblog.net
Source: nixCraft
I need to disable firewall in Linux for testing purpose. I’m using CentOS and RHEL version 4.4 / 5 / 6. How do I disable the firewall in Linux?
A Linux firewall is software based firewall that provides protection between your server (workstation) and damaging content on the Internet or network. It will try to guard your computer against both malicious users and software such as viruses/worms.
Type the following two commands (you must login as the root user):
# /etc/init.d/iptables save
# /etc/init.d/iptables stop
Turn off firewall on boot:
# chkconfig iptables off
Type the following command to turn on iptables firewall:
# /etc/init.d/iptables start
Turn on firewall on boot:
# chkconfig iptables on
source: http://doc.ubuntu-fr.org/port-knocking
Le port-knocking est une méthode permettant de modifier le comportement d’un firewall en temps réel pour provoquer l’ouverture d’un port suite au lancement préalable d’une suite de connexions sur des ports distincts dans le bon ordre, à l’instar d’un code frappé à une porte.
Cette technique est notamment utilisée pour protéger l’accès au port 22 dédié au Secure shell (SSH) ; elle ne nécessite pas beaucoup de ressources et reste facile à mettre en œuvre.
En résumé, le port knocking est donc une méthode simple pour autoriser un accès distant sur un port non constamment ouvert. Cela permet d’éviter les scans de ports et certaines attaques.
La méthode de port-knocking est considérée comme sécurisée étant donné qu’elle est située à un niveau bas des couches TCP/IP et qu’elle ne requière pas de port ouvert (le service knockd est lui aussi invisible). C’est donc une méthode, mais pas infaillible, permettant de masquer la présence d’un serveur derrière un port.