[SOLVED] Linux updates: specify source port

darkxer0x · 12-14-2010, 06:32 AM

Hi!
I've a server, and I want to drop all the traffic going out with other source port than 80 (apache) and 22(ssh).
The reason is I want to prevent my machine sending packets I don't know (i.e. my server scanning networks or making DDOS attacks without my knowledge).

The problem are the updates. If I do what I've said, the updates will not work. I want to allow updates, so I need to let DNS traffic (port 53) and the traffic of the updates to go out. The problem is the source port. This traffic uses a dynamic port (I think like HTTP). Is there any way to specify a source port to do this?
If a have a static port to do this, I would drop all the traffic going out with other port than 22,53,80 and this port.

Thanks in advance

Hangdog42 · 12-14-2010, 07:01 AM

Quote:

I've a server, and I want to drop all the traffic going out with other source port than 80 (apache) and 22(ssh).
The reason is I want to prevent my machine sending packets I don't know (i.e. my server scanning networks or making DDOS attacks without my knowledge).

I'm not sure that locking down ports is the answer to this. Servers like Apache and SSH receive on specific ports, but they send on fairly random ports. Actually any program that communicates via TCP/IP does this. So unless you take steps to lock down what ports your server sends on, doing this is likely to just cause all sorts of problems. If you make a connection to your Apache or ssh server and then look at the netstat output on the server, you'll see what I mean.

You're probably much better off taking a different approach like installing a HIDS like AIDE or Samhain to monitor the status of your file system or something like Snort to monitor for intrusions.

win32sux · 12-14-2010, 05:35 PM

Using source ports for these situations is a bad idea IMHO. You're basically allowing all outbound packets as long as they set that source port. A rule for packets in state ESTABLISHED will be enough to let your servers, well, serve. It'll let them handle all incoming connections without letting them start any outgoing connections themselves. As for the updating, you can specify that you want DNS lookups only to your specific DNS server addresses, and you can also specify the IPs/ports being used by your repositories.

Example (assuming both policies are set to DROP):

Code:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p TCP --dport 22 -m state --state NEW -j ACCEPT
iptables -A INPUT -p TCP --dport 80 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p UDP --dport 53 -d 123.123.123.123 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p UDP --dport 53 -d 123.123.123.124 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p TCP --dport 80 -d 123.123.123.125 -m state --state NEW -j ACCEPT

In the above example, your package repository is 123.123.123.125. You could even specify that you want certain packets to be allowed only if they're generated by root (which would reduce the risk of a non-root exploit being able to make use of the firewall holes). For example:

Code:

iptables -A OUTPUT -p TCP --dport 80 -d 123.123.123.125 -m state --state NEW \
-m owner --uid-owner root -j ACCEPT

Quote:

Originally Posted by Hangdog42

I'm not sure that locking down ports is the answer to this. Servers like Apache and SSH receive on specific ports, but they send on fairly random ports. Actually any program that communicates via TCP/IP does this. So unless you take steps to lock down what ports your server sends on, doing this is likely to just cause all sorts of problems. If you make a connection to your Apache or ssh server and then look at the netstat output on the server, you'll see what I mean.

The packets the daemon replies with will have the source port set as that which the client used as a destination port (in other words, the port which the daemon was listening on). So rules using matches such as "--sport 80" on the server side do actually work, they're just unnecessary (thanks to connection tracking), and way too liberal. Here's an interesting tidbit from the Nmap man page:

Quote:

Code:

       --source-port portnumber; -g portnumber (Spoof source port number) .
           One surprisingly common misconfiguration is to trust traffic based
           only on the source port number. It is easy to understand how this
           comes about. An administrator will set up a shiny new firewall,
           only to be flooded with complains from ungrateful users whose
           applications stopped working. In particular, DNS may be broken
           because the UDP DNS replies from external servers can no longer
           enter the network. FTP is another common example. In active FTP
           transfers, the remote server tries to establish a connection back
           to the client to transfer the requested file.

           Secure solutions to these problems exist, often in the form of
           application-level proxies or protocol-parsing firewall modules.
           Unfortunately there are also easier, insecure solutions. Noting
           that DNS replies come from port 53 and active FTP from port 20,
           many administrators have fallen into the trap of simply allowing
           incoming traffic from those ports. They often assume that no
           attacker would notice and exploit such firewall holes. In other
           cases, administrators consider this a short-term stop-gap measure
           until they can implement a more secure solution. Then they forget
           the security upgrade.

           Overworked network administrators are not the only ones to fall
           into this trap. Numerous products have shipped with these insecure
           rules. Even Microsoft has been guilty. The IPsec filters that
           shipped with Windows 2000 and Windows XP contain an implicit rule
           that allows all TCP or UDP traffic from port 88 (Kerberos). In
           another well-known case, versions of the Zone Alarm personal
           firewall up to 2.1.25 allowed any incoming UDP packets with the
           source port 53 (DNS) or 67 (DHCP).

           Nmap offers the -g and --source-port options (they are equivalent)
           to exploit these weaknesses. Simply provide a port number and Nmap
           will send packets from that port where possible. Nmap must use
           different port numbers for certain OS detection tests to work
           properly, and DNS requests ignore the --source-port flag because
           Nmap relies on system libraries to handle those. Most TCP scans,
           including SYN scan, support the option completely, as does UDP
           scan.

It's talking about this from an inbound perspective, but it can just as well be applied to an outbound perspective. In other words, taking advantage of the compromised host's firewall rules to conduct scans or even further attacks.

darkxer0x · 12-14-2010, 06:39 PM

Thank you very much, win32sux. I think this is what I need. I didn´t think about established,related connections... and it´s perfect in a server.

Quote:

Servers like Apache and SSH receive on specific ports, but they send on fairly random ports. Actually any program that communicates via TCP/IP does this

As win32sux said, the client specify a random port (normally, > 10000), but the destination port is 80. The server, sends the data with source port 80 to the port that the client has choosen. It´s a TCP connection... Random Port <--> 80