Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Generic advice: it's better to block everything incoming, and then open the ports wanted. (more secure)
(see point 2 for more info)
note: i'm not covering the basics of forwarding etc.. that requires additional rule sets to get that working correctly.
i'm discussing solely a one machine config (server connected to the internet (e.g. colocation machine).
1)
INPUT = outside (internet e.g.) towards machine.
OUTPUT = from machine itself towards outside.
with that in mind, you need the INPUT, not the OUTPUT rule
Connections comming towards the sshd, should be blocked, the output doesn't matter. Cos if input is blocked, then the ssh shall never respond to the incoming connection from the outside world.
-A INPUT -p tcp -m tcp --dport 22 -j DROP
And if you want a specific ip adress to be able to connect remotely:
xxx.xxx.xxx.xxx= is the remote ip address of the machine who needs access
2.
Also make sure you have in the top config part of the firewal these rules, which prevents all ports towards the machine (input) to be dropped, unless openend (either for a specific address or publically), but allow outgoing connections by default.
This makes handling the firewall easier, cos you only need to open ports for the input, and automatically it works, no need to add an output rule along with it (cos it's already openend). And the server itself can perform tasks, as downloading updates, etc.. if it would be blocked.. lol, the server itself has also no access, unless opened.
see the point of opening all output, but dropping all input. by default. if you utilize this, you can skip the first example code in point 1, cos it's already dropped. Example two applies only then, as for all services.
:OUTPUT ACCEPT [0:0]
:INPUT DROP [0:0]
3)
Also these rules are handy for some daemons (it opens subports if the deamon uses it, once the initial connection is validated, you allowed. Only for the source who's making connection, not for other people connecting.. it's per session)
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED -j ACCEPT
#auto opening subports when a deamon i've gained access to, needs it
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED -j ACCEPT
#my services i want to open:
#end of config
5) differences between the three states (DROP, ACCEPT, DENY)
ACCEPT = ALLOW access completely on that port(s). defined by the rule (publically or for certain ip's)
DROP = DENY access silently (meaning not response at all)
DENY = DENY access, but with verbose (meaning it responses back with an error message to the machine trying to connect, e.g. "access denied, no access on the port")
DROP is more secure, cose the remote party would never know if there is a service running behind a specified port, cos no output is returned at all... from the server. So more hacker proof.
If they should get an error message (because you've used DENY instead of drop) then they KNOW a service is running behind that port, and it's more appealing to try a bypass/hack etc..
1)
INPUT = outside (internet e.g.) towards machine.
OUTPUT = from machine itself towards outside.
with that in mind, you need the INPUT, not the OUTPUT rule
Connections comming towards the sshd, should be blocked, the output doesn't matter. Cos if input is blocked, then the ssh shall never respond to the incoming connection from the outside world.
-A INPUT -p tcp -m tcp --dport 22 -j DROP
And if you want a specific ip adress to be able to connect remotely:
Well I agree say I have a machine A, I want to achieve that A should not be able to ssh to any other machine but other machine can ssh to A.
But if I Use INPUT I will be blocking other machines to ssh to A and this is what I do not want.
Oh ok, i missunderstood you
in that case, you're rule should work. If it's not, try this
ditch the -m part in your line
(-m module load)
maybe you should list your firewall of the specified machine, without revealing the ipaddresses, or hostname..
(so it stays anonymous to us, on which machine it is)
but when I reverse the order of these line it works
-A OUTPUT -p tcp -m tcp --dport 22 -j DROP
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
Now why exactly is this happening?
I'll try to explain it to you (without special cases), it's quite complicated to explain without going too techie.
Reading is from top to bottom. (that's how IPTABLES also reads the rules during start)
thus, in your working config, it says basically, first drop 22
then allow other connections going out.
if you would reverse this, it says, allow all (including ssh), then the restrictive rule, is not working. Because it conflicts with the first line (allow all)
reason why:
in generic rules, not defining which port, which protocol etc, ACCEPT is more powerful then DROP or DENY, because it OPENS things (IPTABLES vision, is that OPENING things, is a special assignment, DROPPING DENYING is standard reason to have a firewall in the first place)
That way, you see that if you first open everything, then dropping some lateron, is not effective, cause OPENING (without specifying the ports or protocols, like in your line underneath) is then leading the blockades under it. That the reason most people use a global init config of either blocking everything on a certain route, or ACCEPTING it.)
so those rules a read globale (systemwide), lateron you can specify custom rules with the -A lines.
global rules are set in the top of the config beginning with a ":"
e.g.
:OUTPUT [0:0] DROP
I hope my explaining helps you understand, again it's quite difficult to explain it. (hence there are numerous books about firewalling with IPTABLES, not for no reason )
besides English is not my Native language (but my second)
in generic rules, not defining which port, which protocol etc, ACCEPT is more powerful then DROP or DENY, because it OPENS things (IPTABLES vision, is that OPENING things, is a special assignment, DROPPING DENYING is standard reason to have a firewall in the first place)
Wrong, it is the first match of REJECT, DROP, ACCEPT that matters. DENY has no documented meaning.
DROP = DENY access silently (meaning not response at all)
DENY = DENY access, but with verbose (meaning it responses back with an error message to the machine trying to connect, e.g. "access denied, no access on the port")
It's REJECT, not DENY.
Quote:
Originally Posted by teebones
DROP is more secure, cose the remote party would never know if there is a service running behind a specified port, cos no output is returned at all... from the server. So more hacker proof.
If they should get an error message (because you've used DENY instead of drop) then they KNOW a service is running behind that port, and it's more appealing to try a bypass/hack etc..
Not responding is a giveaway that a firewall is there, a non-firewalled host will respond with an error if the port is not in use. REJECT will not respond differently depending on weather the port in in use, but can be made to mimic an non-firewalled system.
I'm not sure iptables is really the way to go about doing this. Unless I'm very mistaken, for outgoing SSH connections, there is no "standard" port that is used that can be blocked like this. SSH simply uses a random high level port. You're probably better off limiting access to the ssh command than in messing with iptables.
I'm not sure iptables is really the way to go about doing this. Unless I'm very mistaken, for outgoing SSH connections, there is no "standard" port that is used that can be blocked like this. SSH simply uses a random high level port. You're probably better off limiting access to the ssh command than in messing with iptables.
No, whilst the local port number is high and random, the remote port number is typically 22, which is what that iptables rule checks. However one can run SSH servers on non-standard ports, and install their own copy of an SSH client.
Wrong, it is the first match of REJECT, DROP, ACCEPT that matters. DENY has no documented meaning.
no, wrong here, read/interpreted my writing more closely
All rules have a DROP/ACCEPT or REJECT in them, beginning with an -A.
so, their is no first match as YOU wrote.. could be anything of those three
And thus his example should work according to your explanation, however it didn't, reason, cos there is a catch.
(as i tried to explain. Althoug i might be a bit unclear in the explaining.. or we mean the same thing, but tell it differently, and that why we don't follow eachother )
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.