I have drawn some sketches
The machine, where the ssh tunnel command is typed is called »your host«.
local: -L Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.
ssh -L sourcePort:forwardToHost:onPort connectToHost means: connect with ssh to connectToHost, and forward all ...
You can limit which hosts can connect by configuring TCP wrappers or filtering network traffic (firewalling) using iptables. If you want to use different authentication methods depending on the client IP address, configure SSH daemon instead (option 3).
Option 1: Filtering with IPTABLES
Iptables rules are evaluated in order, until first match.
For example, ...
I'd accomplish this by adding sources to a zone. First checkout which sources there are for your zone:
firewall-cmd --permanent --zone=public --list-sources
If there are none, you can start to add them, this is your "whitelist"
firewall-cmd --permanent --zone=public --add-source=192.168.100.0/24
firewall-cmd --permanent --zone=public --add-source=192.168....
I don't believe this is possible with ufw. ufw is just a frontend to iptables which also lacks this feature, so one approach would be to create a crontab entry which would periodically run and check if the IP address has changed. If it has then it will update it.
You might be tempted to do this:
$ iptables -A INPUT -p tcp --src mydomain.dyndns.org --dport ...
What do the three rules do?
Those 3 rules seem pretty self-explanatory:
Reject incoming UDP packets with an ICMP message "port unreachable"
Reject incoming TCP packets with "tcp reset"
Reject incoming packets (of any other protocol) with ICMP message "protocol unreachable"
If you're looking for more detail (about UDP/TCP packets, ICMP), you need to dig ...
Your no route to host while the machine is ping-able is the sign of a firewall that denies you access politely (i.e. with an ICMP message rather than just DROP-ping).
See your REJECT lines? They match the description (REJECT with ICMP xxx). The problem is that those seemingly (#) catch-all REJECT lines are in the middle of your rules, therefore the ...
Wikipedia has a great diagram to show the processing order.
For more details you can also look at the iptables documentation, specifically the traversing of tables and chains chapter. Which also includes a flow diagram.
The order changes dependent on how netfilter is being used (as a bridge or network filter and whether it has interaction with the ...
Even if an answer has been accepted and up-voted, I do not think it is a correct one. I fail to find clear explanation in the documentation, but from the implemented behaviour it looks like that:
interface and source are used as selectors - which zone(s) to
both are ignored for the default zone (always active)
So the answer would be:
lock down ...
SNAT and MASQUERADE do the same source NAT thingy in the nat table within the POSTROUTING chain.
MASQUERADE does NOT require --to-source as it was made to work with dynamically assigned IPs
SNAT works ONLY with static IPs, that's why it requires --to-source
MASQUERADE incurs extra overhead and is slower than SNAT because each time MASQUERADE ...
First, Debian tends to assume you know what you are doing, and tries to avoid making choices for you.
The default install of Debian is fairly small and is secure — it doesn't start any services. And even the standard optional extras (e.g., web server, ssh) that are added to an install are usually quite conservative and secure.
So, a firewall is not needed ...
This snippet runs a new interactive instance of bash (bash -i), on a TCP connection to the specified port on the specified host which is created for the duration of the bash process. Standard output and standard error are sent through this connection (>& /dev/tcp/HOST/PORT), and standard input is read through this connection (0>&1 — this should ...
This is needed if you are using DHCP v6 due to the slightly different way that DHCP works in v4 and v6.
In DHCP v4 the client establishes the connection with the server and because of the default rules to allow 'established' connections back through the firewall, the returning DHCP response is allowed through.
However, in DHCP v6, the initial client ...
This is explained in SSH manual, especially the differences between -L (local) and -R (remote).
Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.
This works by allocating a socket to listen to port on the local side, optionally bound to the ...
If you want to see if you can form a TCP connection from a remote machine, get OpenCSW installed on that and the target machine, and install netcat on both. This is the syntax for using netcat to test TCP connections:
nc -vz targetServer portNum
For example to check SSH on "homeServer1":
nc -vz homeserver1 22
That enables you to test TCP-level ...
Here some additional configuration for SSH daemon to extend previous answer:
Add user filtering with AllowUsers option in sshd_config file:
AllowUsers email@example.com.* firstname.lastname@example.org.* otherid1 otherid2
This allows johndoe and admin2 only from 192.168.1.* addresses and otherid1, otherid2 from anywhere.
Restrict a ssh key or ca-based key to a set of ...
Block traffic on both the server and firewall if possible, just in case.
Security groups are good because they are external to your host so the data never reach's you. They are not quite as configurable as most server based firewalls though.
Unfortunately, EC2 security groups can only "allow" services through a default deny policy. So if you are trying to ...
Base on this answer from ServerFault,
ufw supports per rule logging. By default, no logging is performed when a packet matches a rule.
All you have to do is create a UFW deny rule to match those multicast packets.
This should be configured on whatever equipment you have between the DNS server and the outside world. AFAIK port forwarding is disabled by default on pretty much everything so you shouldn't worry too much about it. If you're using residential network gear, there should be port forwarding configuration options in the web interface. To check the port ...
This may be more heavy weight than you're looking for, but you might consider using fail2ban (https://www.fail2ban.org). That's a tool that can monitor your log files and automatically ban addresses that generate logs that match a set of customizable patterns.
Firewalls should reply with an ICMP message when they block a request. However, this is not necessarily the case (you will be interested in this nice article).
You can test from the outside to see whether a port is accessible through a firewall and, if so, whether anything is listening on it. Here's three different scenarios involving a tcp request which ...
I finally found how-to. First, I had to add -i eth1 to my "outside" rule (eth1 is my WAN connection). I also needed to add two others rules. Here in the end what I came with :
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 8080 -j DNAT --to 10.32.25.2:80
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to 10.32.25.2:80
iptables -t nat -A ...
It should work fine, it's not more secure than using a different port for ssh (or less secure for that matter). And no, outbound TCP sockets are not the same as inbound TCP sockets - so it should not interfere with your outbound network traffic.
Simple rate limit is not enough because nmap increases scan delay when it hits rate limit. Here is what you can do best with iptables.
First create ipset lists
ipset create port_scanners hash:ip family inet hashsize 32768 maxelem 65536 timeout 600
ipset create scanned_ports hash:ip,port family inet hashsize 32768 maxelem 65536 timeout 60
And iptables rules
The simplest way of stopping the traffic is (assuming VPC is being used) by adding it to the VPC Network ACL of that instance and denying all traffic from that IP Address.
One thing to remember is the deny rule number should be less than the first allow rule number.
As indicated in the comments, this is likely being caused by the UseDNS yes setting in the sshd_config on the server.
The UseDNS setting is a common culprit for this very issue. Basically what happens is that your IP netblock either has a defective, or missing DNS server. So sshd is trying to do a reverse lookup on your IP address, and waits until it times ...
First off, I do want to repeat what has already been said: Debian caters to a rather different group of users than many other mainstream distributions, particularly so Ubuntu. Debian is geared toward people who know how the system works, and who aren't afraid to tinker from time to time in return for a high degree of control over the system. Ubuntu, for ...