pktstat sniffs on packets before iptables filtering takes place, which I doubt is possible
This is what happens. pktstat, tcpdump etc get the unfiltered data on the interface. See also Does tcpdump bypass iptables?.
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 --...
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 ...
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 ...
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 ...
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 ...
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 ...
It seems your server is connecting to that IPv6 address, which is assigned to Google, on HTTPS and this is the reply from that server, as you can see by the SYN and ACK flag.
My guess would be that your firewall is not allowing established connections initiated from the 'inside' and thus is blocking this traffic.
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 ...
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 ...
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.
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 ...
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 ...
Because iptables deals with TCP/IP. ARP is not TCP/IP.
You can install arptables, and use that for filtering arp requests. On a debian-related distro sudo apt install arptables should do the trick.
Then you can do
arptables -A INPUT --source-mac de:ad:be:ef:ba:be -j DROP
and so forth. man arptables will give you a full overview.