Blocking outgoing TCP

¿F M J¿ · 09-01-2005, 11:56 PM

Hi

Im reasonbley knew to linux..

ok, i have a router connected to my linux server/webserver - i have pc's in the internal network, im trying to block one box from inside the network from uploading to the web on a certian pinholed port, but the catch is im trying to allow it to connect to anything on 411 outside of 19820..

e.g.

DC++ in active mode uses a pinholed port, ( i selected 19820 ), When u connect to the server it connects to port 411, now the trick here im trying to achive is how to block any other traffic coming out of 19820 that isnt going to port 411

im no expert here and i have gotten as far as this

iptables -I OUTPUT -p TCP --sport 19820 --dport ! 411 -j REJECT

which doesnt seem to work.. Im running fc4 ...

Thanks in advance for any help on this..

rhoekstra · 09-02-2005, 01:01 AM

OUTPUT? If it is for forwarding from an inside machine to outside, it should come in the FORWARD chain.

if it is the router itself, it concerns the OUTPUT Chain...

NOTE, just FYI:
INPUT is for filtering traffic destined FOR the physical machine being firewall,
OUTPUT is for filtering traffic originated FROM the physical firewall machine and
FORWARD is for filtering traffic that is to be passed THROUGH the physical firewall machine.

Hope this helps.

¿F M J¿ · 09-02-2005, 08:33 AM

Hey,

I tried replacing OUTPUT with FORWARD and it had the same result, showed no errors but didnt have the desired effect.

Bugga..... haha

rhoekstra · 09-02-2005, 09:20 AM

You could try these two lines in this order:

Code:

iptables -I FORWARD -p TCP --sport 19820 -j REJECT
iptables -I FORWARD -p TCP --sport 19820 --dport  411 -j ACCEPT

After executing these lines, the second line gets interpreted by iptables first (!!). so.. it accepts traffic that is explicitly originated from port 19820 and has a dport of 411.
nextly, the first line gets interpreted (for if the dport isn't 411) and all traffic originated from the same source port 19820 gets rejected.

¿F M J¿ · 09-02-2005, 10:11 AM

I must be cursed lol, that had the same result as the previous line of code.. im purely stumped, im no guru but from reading the faq's/manuals with my understanding it should be working.. ?

yet its not... Hope u got more ideas i can rack from your brain

rhoekstra · 09-02-2005, 12:40 PM

Try:

Code:

iptables -I FORWARD -p TCP --sport 19820 --dport  411 -j LOG

after the above lines and you shall see in your log files (/var/log/messages) if those packets are indeed being sent.

Furthermore you can try using iptraf, which enables you to monitor traffic on a specific interface, you can see which packets are passing through.

¿F M J¿ · 09-02-2005, 08:12 PM

Ok, changed that, put in your line, restarted the network, started the box with the application which is offending, it carryed on as it always did, i then went to /var/log/messages - there wasnt a trace of anything in there regarding the block, far as i can tell somethings causing it to ignore it all together or something ?

I tried iptraf - dont have it installed, so i used TCPdump - but after seeing what it puked out, i was instantly confused haha

TCPdump did show something i thought was odd though, after viewing it im starting to wonder if perhaps the application isnt being 100% truthful about which ports its using despite it all going via 19820..

14:01:15.512835 IP pool-151-200-47-148.res.east.verizon.net.25470 > Logical.Sureal.1059: . ack 339749 win 17520
14:01:15.513635 IP Logical.Sureal.1059 > pool-151-200-47-148.res.east.verizon.net.25470: P 339749:341201(1452) ack 292 win 65244
14:01:15.513743 IP Logical.Sureal.1059 > pool-151-200-47-148.res.east.verizon.net.25470: P 341201:342653(1452) ack 292 win 65244
14:01:15.513851 IP Logical.Sureal.1059 > pool-151-200-47-148.res.east.verizon.net.25470: P 342653:344105(1452) ack 292 win 65244
14:01:15.891708 IP pool-151-200-47-148.res.east.verizon.net.25470 > Logical.Sureal.1059: . ack 342653 win 17520
14:01:15.892425 IP Logical.Sureal.1059 > pool-151-200-47-148.res.east.verizon.net.25470: P 344105:345557(1452) ack 292 win 65244
14:01:15.892532 IP Logical.Sureal.1059 > pool-151-200-47-148.res.east.verizon.net.25470: P 345557:347009(1452) ack 292 win 65244
14:01:16.108964 IP pool-151-200-47-148.res.east.verizon.net.25470 > Logical.Sureal.1059: . ack 344105 win 16068
14:01:16.109664 IP Logical.Sureal.1059 > pool-151-200-47-148.res.east.verizon.net.25470: P 347009:348461(1452) ack 292 win 65244
14:01:16.257296 IP pool-151-200-47-148.res.east.verizon.net.25470 > Logical.Sureal.1059: . ack 347009 win 17520
14:01:16.258097 IP Logical.Sureal.1059 > pool-151-200-47-148.res.east.verizon.net.25470: P 348461:349913(1452) ack 292 win 65244
14:01:16.258206 IP Logical.Sureal.1059 > pool-151-200-47-148.res.east.verizon.net.25470: P 349913:351365(1452) ack 292 win 65244
14:01:16.258335 IP Logical.Sureal.1059 > pool-151-200-47-148.res.east.verizon.net.25470: P 351365:352541(1176) ack 292 win 65244

Im no networking genius lol..

fotoguy · 09-02-2005, 08:58 PM

Use INPUT chain, all data must be filtered through the input chain before it can be determined it's destination is a local process on the machine or whether it needs to be routed through to the FORWARD and OUTPUT chains.

rhoekstra · 09-03-2005, 01:12 AM

@fotoguy, that is ipchains technology, not iptables technology. Traffic not destined or originated at the firewall box where iptables is running will never hit the INPUT or the OUTPUT chain.

As for the logging, I cannot make sense out of it. what you can do is 'tcpdump -n src <ip of sending/offending machine> or dst <ip of sending/offending machine>'

You should see packets coming from and going to the offending machine
you will see packets without their names being resolved and only seeing ip numbers and ports..

Best thing is to run it on the firewall machine.

¿F M J¿ · 09-03-2005, 02:15 AM

Ok, this seems to be a tedious problem..

Ill explain in more detail..

I'm actually using a friends coded rc.firewall sitting in my /etc/rc.d/init.d folder, hes told me its a "beta" still and hes not sure what could be causing this issue, as hes currently really busy with his job and he hasn't been able to lend a hand, which is understandable, so i took it upon myself to try and solve the issue myself..

I spose the next thing is you'd want to see the rc.firewall to perhaps try and pinpoint the problem.. There in lies a problem, as its not really mine to show, i feel this could be a fruitless journey. I really want to solve the problem but on the other hand i dont want to give out a copy of my mates security setup for the world to see..

Pritty sure i know what the answer's will be..

Im a rock stuck in a hard place..

rhoekstra · 09-03-2005, 03:51 PM

Well, what could help, without disposing the script of your mate, is telling what exactly is the setup.

What is the program causing the traffic, and what are the settings of that program?

What is exactly the traffic you want to allow and what to block.

The lines I provided above don't have anything to do with the init script of your mate, provided you don't rerun the init script AFTER you have run the above script.

First thing is to understand the actual situation, (what traffic, try to make the traffic visible through tcpdump to have the exact characteristics of the generated traffic.
Then it is the task to identify what exactly is what you want. Which traffic is to be allowed, and which traffic is to be blocked.
Lastly is how you want to implement it. If you have the extensive answers to above questions / tasks, the last is what I will be able to help you out with.

Good luck..

¿F M J¿ · 09-03-2005, 10:34 PM

Ok...

Router TO
Ethernet to router (eth1) TO
Ethernet to internal network (eth0) TO internal network

Inside the internal network theres x2 pc's 192.168.0.2 (gaming box) and 192.168.0.4 (this box which downloads/uploads etc)

The application is DCPlusPlus (DC++)

Heres something i found which can perhaps put things inter better persepective.. seen as though it seems apparent i've been wrong about how DC++ handles its traffic..

Active
In active mode, DC++ needs to make outbound TCP connections and send UDP packets to other machines, as well as receive inbound TCP connections and inbound UDP packets. TCP is used for file transfers and UDP is used for file search results. Remote DC++ clients will return a maximum of 10 search hits to an active user. A user in active mode will have M:A in their DC++ tag. Use this guide to set up active mode.

IP
DC++ will automatically detect and use your local IP. If you are behind a router (or your IP is otherwise non-routable) you will need to put in your external IP here. If you put a DNS name here, DC++ will try to resolve it into an IP address before use.
TCP Port
This is the port that DC++ listens on for incoming client connections. If this setting is blank, DC++ will use a random port between 1025 and 32000.
UDP Port
This is the port that DC++ listens on for incoming search results. If this setting is blank, DC++ will use a random port between 1025 and 32000.

Well i dont know how extensive these answers are or helpful..

Basically, i now am not sure whats connecting in which direction since viewing the info about the dc++ application..

ina real simple short-form, i want to stop this box from uploading to people, but on the other hand i want to be able to download and connect tot he server's (which varie in ports, generally 411, 7778 etc)

If all else fails i'll give up and go back to SneakerNet

rhoekstra · 09-05-2005, 01:28 AM

And there's no way to disable the downloads from the DC++ application?

If you can't find it out from documentation, you'd need to monitor the connections the application makes when connecting, and when downloading. If you can identify what to block (once again, tcpdump can help you with that, it also can show udp packets though), you can achieve this with iptables ...

What did you enter at 'IP' (your public IP? it should be)? and what at 'TCP Port' and 'UDP Port' ? and is it all TCP you want to disable?

My guess would be that you enter one port at TCP Port and go tcpdump on that .. if all TCP to that box is to be blocked you can put them in the iptables FORWARD chain like:

Code:

iptables -I FORWARD -s 192.168.0.2 -p tcp --dport <tcp port> -j REJECT
iptables -I FORWARD -s 192.168.0.2 -p tcp --sport <tcp port> -j REJECT
iptables -I FORWARD -d 192.168.0.2 -p tcp --dport <tcp port> -j REJECT
iptables -I FORWARD -d 192.168.0.2 -p tcp --sport <tcp port> -j REJECT

Four times to make sure packets FROM the machine as well as TO the machine, with SOURCE port <tcp port> as well ass DESTINATION port <tcp port> will be blocked..

Hope this helps (again) a little further?

fotoguy · 09-06-2005, 12:59 AM

Quote:

Originally posted by rhoekstra
@fotoguy, that is ipchains technology, not iptables technology. Traffic not destined or originated at the firewall box where iptables is running will never hit the INPUT or the OUTPUT chain.

Thanks for pointing that out, your are quit correct, I've now made adjustments to my iptables script that I have been working on my test router. I had made my iptables script thinking it was folowing the same as ipchains, I have now been able to get the script to function correctly as I had intended it too.