The short answer
Usually you will only need connection tracking for outbound connections. If any local device makes a connection to the Internet, the firewall records that this specific IP and port tried to make a connection to the other IP and port.
Thus when the answer from the Internet arrives, the firewall knows to let it pass, because it has seen an ...
In most cases doing an nmap -p 0-65535 -PN <ip> works well for testing a remote firewall's TCP rulesets. If you want something more advanced you can use a packet crafter like hping which is designed to test firewall rulesets. Here is some information on building packets with hping.
iptables -F does not change the default policy. So when you set it to DROP and do a flush afterwards, it stays on DROP.
I use the following commands to flush the tables
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
This changes the default policies to ACCEPT for all filter chains, flushes the rules ...
The Majestic project is a distributed web crawler, which explains why you get such a lot of different source IP addresses. It is not malicious, that is it does not attack your site and it does not even uses lots of resources (800 requests a day is not much).
Like most proper bots Majestic even includes a URL in the user-agent string and if you visit this ...
Why are you using iptables rather than using good old Wireshark which is specifically made for this? Wireshark is a free and open-source packet analyzer and the ideal tool for performing these types of analysis.
If you need to reinject the packets I would have a look at scapy in python.
Which version of linux are you using and how is your iptables configure that is causing these messages to be logged?
I can offer an alternative possible explanation.
In the packets there seems to be the RST flag being set.
11:45:26 my.com kernel: IPTABLES: SRC=220.255.XX.XXA DST=192.168.1.2
LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=49687 PROTO=TCP SPT=443 ...
First, let's correct some assumptions and terminology which will make understanding the results a lot easier:
The -F option is a "quick" scan because it scans only 100 ports. It is the equivalent of --top-ports 100. Without this option, Nmap scans 1000 TCP ports.
The -A option is not "intense" but rather "All features." It is the equivalent of -sV -sC -O --...
REJECT is nicer to other people: if the connection is the result of an honest mistake (a configuration error) then whoever tried to initiate a connection receives the standards-approved response that nobody is listening on that port. With DROP, nothing is returned, so whoever is trying to connect will wait until it gets bored.
While REJECT seems better for ...
You might want to clarify if you're looking for DoS or DDoS protection. See this answer for more details.
In a typical web-application architecture, the WAF stands in front of your web-application, either in your network zone (e.g. DMZ) or within an external service provider network that filters the traffic for you. In case of a DDoS attack, the WAF will be ...
ARP and TCP/IP are different layers in the networking technology stack. If you have read about the OSI model, that applies here.
ARP is a protocol at layer 2 dealing with connecting the host to the local network.
TCP/IP are protocols dealing with connecting networks together.
iptables deals (mostly) with TCP/IP and higher layers. arptables deals with ...
Right, so this is is a Hard Questiontm. Since all environments are different, it is very tricksome to provide a "One Size Fits All" ruleset that one can expect to just drop in. Any such configs, config snippets, recommendations, etc, must be fully grokked and tweaked to work in your environment. That being said, as discussed in the security.blogoverflow.com ...
You mention iptables, so you are implying linux (at least as an example for an OS with tunable network policies).
Since a very long time, linux has had a limit on the number of ICMP error message sent. The default is very low: 1 message/s.
This behaviour of linux is tunable with network sysctl parameters: the icmp_ratelimit sysctl
icmp_ratelimit - ...
In practice this is likely to be a reasonable protection, but from an ideal standpoint you shouldn't rely on it. Apart from anything else it disregards the possibility that an attacker can get access to a machine on your local LAN (e.g. if one of your systems gets infected by malware)
In terms of having iptables reject LAN IPs from the Internet, yep this ...
Stateful firewalls are mindful of incoming connections that are part of a circuit that was previously established. iptables can certainly do this.
The short answer is that you need a firewall rule that blocks all new incoming connections, but allows established incoming connections.
Assuming that your side initiates every communication, then yes, blocking every connection to your machine from IP addresses you didn't connect to is a good idea.
But note that this is firewall basics. Most client-side firewalls don't allow any incoming connections initiated from a remote machine unless you specificallly allow them. They do more than you ...
Scapy does not route the traffic, nor does it touch the traffic at all in this scenario. When you enable IP forwarding on a host, it becomes a router. When the host receives a packet not destined for one of its own addresses, it will route the packet per its routing table. Since the traffic from the victim has a destination IP address not matching the ...
If you have an OSSEC agent running on the remote firewall, you can use native ossec commands.
The < location > option defines where the active response should be executed. Normally it is configured to execute the active response on the host that generated the event ("local"), but can also be configured to execute the active response on any host that has ...
You can do this by making a customized active response. This will require you to write a script which can add IPs to your remote firewall. I suggest reading up on the linked documents as they explain this quite well.
It depends what you are trying to protect against, if this traffic goes over the internet, technically people would still be able to sniff or modify your traffic if they were able to put themselves between your two machines. IPTables is a firewall but it does not offer means of encrypting the traffic. Therefore you need to depend on other protocols like ...
IPtables won't detect a successful Ettercap attack. Ettercap is used for ARP cache poisoning, CAM table flooding - it's a layer 2 attack tool to perform network sniffing via exploiting issues/vulnerabilities on switches. See this tutorial for some examples.
To be honest, think the question is a little generic and maybe dated. Folks don't generally test ...
You don't have much information in that log, so you need to assume something (or use some tool that will do that for you).
For example, say that most of your clients are in US/EMEA. Then maybe all IPs coming from China can be blocked. You can get them with WHOIS from the logs, or try online services:
IPDeny seems to not have data: http://www.ipdeny.com/...
A routing firewall participates in the IP process, whereas a bridging, or transparent, firewall does not. A transparent firewall acts more as a tap on a line, while a routing firewall has to forward traffic onto its next destination.
The advantages of a transparent firewall are that it can be installed in-line between two devices without having to ...
SSL does not prevent DNS spoofing itself but it prevents that it can be successfully used.
If the certificate of the site does not match the name given the URL the certificate validation will fail. It does not matter how an attacker redirected the client to the other server, that is no matter if DNS spoofing, changes of the routing or ARP cache poising were ...
There is something between the scanner and the target that is responding on behalf of the target, spoofing its source address so as to appear to be the target itself. When you ran the Nmap scan as root with --reason -v, it showed the IP Time-to-Live (TTL) values of the response packets for each port:
PORT STATE SERVICE REASON
21/tcp open ftp ...
However, when an HTTPS connection comes in, it refuses to accept my certificate.
That's expected. You are trying to man in the middle a TLS connection with a certificate which is either not issued by a CA trusted by the client or where the subject of the certificate does not match the hostname of the target URL. That's exactly the kind of attacks ...
Set the default policy to deny everything. (iptables -P INPUT DENY)
Add the minimum rulesets required for the services you need.
If you've got ports that are used only by local machines, set allow rules for that combination of port and IP range only.
iptables -A INPUT -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT
Outbound traffic needs rules as ...
You can also implement logging function in your iptables using -j LOG option and modifying your OS to generate a log file, I do this for new installation of PBX.
iptables -N SIP-Firewall
iptables -A SIP-Firewall -s 22.214.171.124/255.255.255.0 -j ACCEPT
iptables -A SIP-Firewall -s 126.96.36.199 -j ACCEPT
iptables -A SIP-Firewall -s 188.8.131.52 -j ACCEPT
As I understand:
Switch -d and -s are associated by a and expression.
As you're talking about a firewall, and iptables -A OUTPUT mean iptables -t filter -A OUTPUT, this seem not to be right:
chains INPUT and OUTPUT concern packet from or to the host (firewall).
This coud be usefull if your firewall hold many different IP address and want to make ...