I want to restrict the daemons from opening certain ports, and i wish to achieve it at kernel level.
I came across an idea, i.e to write my own bind function and then redirect to the original bind function. But the user can bypass this by invoking the system call. Any suggestions?
Just a thought:
there's a chance that 'iptables' could do the work for you.
Using 'iptables' you can define a rule which will deny outgoing traffic from a port.
This solution may work for you if you can identify the deamon's traffic according to iptables options. It will not work for you if you can only identify the deamon's traffic according to its process id.
Related
Is there a way to automatically match users to different ports when accessing www.***.com?
Is it possible to change :80 to :10001 when connecting, and if someone is matched, change it to :10002?
No, there's likely not a way to do this automatically. Because it's rare to want to do something like this on a Web server.
In resource monitor under network, there is a tab called listening ports which has a column called firewall status. It has values like
1)allowed, not restricted
2)not allowed, not restricted
3)allowed, restricted
My understanding is that the first one represents whether the incoming traffic will be allowed or not.
(when I tested after disabling the firewall, everything changed to allowed)
My understanding of the second one is whether there is a rule restricting that connection or not. But in this case, allowed, restricted gives no sense because when it is restricted how can it be allowed.
And also there is an option to either block or allow all connections that do no match any available rules.
could anyone please explain these things in detail please?
My understanding of Allowed/Restricted.
FW allows access to that port but with some restrictions.
For example, there is a rule in fw blocking access to that port for some IP addresses or allowing access from local subnet only.
I would like to create chain for Iptable which return URL and post and get from all packets.
I do not believe that netfilter/iptables is generally aware of application-level protocols like HTTP. There is some limited protocol dissection support that is used for connection tracking in some specific protocols (e.g. FTP), but that's about it. The way I see it, you have two options:
Redirect the packets that you want to inspect to userspace where you can have a helper process that will extract the information that you need. I am not aware of any existing application that will do that, however, so you may have to write it yourself.
Do the sane thing and just use a packet sniffer such as Wireshark or tcpdump, preferably with a capture filter that will only let HTTP traffic through. As a bonus, you can get a whole lot more information than just an HTTP request and a URL...
( 3 years later but I think useful for other people too )
barebone iptables are agnostic of application protocols, but there are iptables extensions
for example, see the extensions string and u32
We've got a custom application that needs to serve requests on it's own port number. We really don't care what the number is, although we'll stick to that port after we decide. How do I select a number which is least likely to conflict with other applications or services that are running on the user's system?
Are there any rules or standards we should follow?
A clarification: once we pick a port, we need to stick with it. Can't use a dynamic one. We're building a custom SFTP server and we'll have to tell our customers what port it's running on.
For a static application, consider checking /etc/services to find a port that will not collide with anything else you are using and isn't in common use elsewhere.
$ tail /etc/services
nimspooler 48001/udp # Nimbus Spooler
nimhub 48002/tcp # Nimbus Hub
nimhub 48002/udp # Nimbus Hub
nimgtw 48003/tcp # Nimbus Gateway
nimgtw 48003/udp # Nimbus Gateway
com-bardac-dw 48556/tcp # com-bardac-dw
com-bardac-dw 48556/udp # com-bardac-dw
iqobject 48619/tcp # iqobject
iqobject 48619/udp # iqobject
If you can't predict the exact kind of environment your application is going to run, just don't bother with this. Pick any number over 1024 and also make it configurable so the user can change it in case of conflict with another service/application.
Of course you can still avoid very common ports like 8080 (alternative HTTP) or 3128 (proxies like squid), 1666 (perforce), etc. You can check a comprehensive list of known ports here, or take a look at /etc/services.
If you don't care about the port number, and don't mind that it changes every time your program is run, simply don't bind the port before you listen on it (or bind with port 0, if you want to bind a specific IP address). In both cases, you're telling the OS to pick a free port for you.
After you begin listening, use getsockname to find out which port was picked. You can write it to a file, display on it on the screen, have a child inherit it via fork, etc.
If you want a unique port number for your application, you need to request an assignment from IANA, who maintain the Service Name and Transport Protocol Port Number Registry for the IETF. /etc/services and other secondary records are populated from the IANA registry.
Please do not simply pick a number and ship your application (as mentioned in another answer), because sooner or later, IANA will assign the port you're squatting on to an incoming request, which can lead to conflicts for your application and the unaware assignee.
Why do we need root privileges when we use raw sockets ?
It's because you can spoof custom packets, which may interfere with inbound traffic. This too is also bad.
In short raw sockets is restricted to root because if it otherwise it would break other rules for networking that are in place.
A long standing rule is that you cannot bind on a port lower than 1024 without root's blessing. With raw sockets you can simulate a server on any port. (naturally being able to receive on this port is a different story you'd also have to sniff the network, but perhaps this could be done with a different machine.)
Opening a raw socket allows to read anything that is received in a given interface, so, basically, you can read any packet that is directed to any application - even if that application is owned by another user. That basically means that the user with this capability is able to read any and all communications of all users.