Ricardo Kleemann
2007-Nov-05 21:52 UTC
please help diagnosing "ip_conntrack: table full, dropping packet"
Hi, I run a small system with an older version of shorewall (1.4.2). It has been extremely solid for a long time. But recently I have noticed the connection table filling up, which has never happened before. My guess is that the box is getting hit with floods. The system only has 64M of ram and the conntrack_max is set to 4096 based on the ram. I have temporarily increased it to 8192 so that it doesn''t cause the box to drop packets, but obviously it will eventually fill up again. I need help in trying to understand what is happening. I don''t have many analysis tools on the box since it runs a minimal linux system (for embedded appliances). But I can look at the shorewall status and try to figure out what''s getting hit. The thing is I don''t understand very well how to decipher all the shorewall data, and any help would be greatly appreciated. I understand the problem may not be directly related to shorewall, but if shorewall can be used in any way to protect the box from these attacks and not have it continue to fill up its connection table, then that''s what I need to do. Thanks in advance for any help. I''ve attached the shorewall status. Ricardo ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Hi, I run an older version of shorewall (1.4.2) and need some helping setting up some rules. I received an abusenet notification that one of my servers is being used to hack elsewhere. I don''t know if anyone here is familiar with Linux.Backdoor.Small.o, any help would be greatly appreciated. The suggestion I received is to block outbound traffic:> outbound traffic either source or destination using ports: 6, 8, 17, > 1025, 1433, 1434, 1435, 2798, 2967, 2968, 5761, & 5900Certainly, first I''d like to determine which application is leaving the open door, I''m guessing it''s my apache. But in any case I need to close down the backdoor by blocking at shorewall as well. Thanks for any help. Ricardo ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Ricardo Kleemann wrote:> Hi, > > I run an older version of shorewall (1.4.2) and need some helping > setting up some rules. > > I received an abusenet notification that one of my servers is being used > to hack elsewhere. I don''t know if anyone here is familiar with > Linux.Backdoor.Small.o, any help would be greatly appreciated. > > The suggestion I received is to block outbound traffic: > > outbound traffic either source or destination using ports: 6, 8, 17, > > 1025, 1433, 1434, 1435, 2798, 2967, 2968, 5761, & 5900 > > Certainly, first I''d like to determine which application is leaving the > open door, I''m guessing it''s my apache. But in any case I need to close > down the backdoor by blocking at shorewall as well.The fact that you are still running Shorewall 1.4.2 suggests to me that you don''t keep up with security patch releases very closely. It follows that it is no surprised that one of your systems has been compromised. It is a fact that your internet-exposed servers are the weakest point in your network and the most likely place for a compromise to occur. It is also a fact that you should isolate your internet-exposed servers in their own LAN and that the firewall policy from that LAN to ANYWHERE should be REJECT. So the problem is not to add 100s (1000s) of rules to block the bad stuff but rather to add a few ACCEPT rules for the traffic that must be allowed. That is the only way to approach this problem. And *keep up with software releases*. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Hello Tom, I appreciate you pointing out the error of my ways. And you are absolutely correct. However, lack of resources prevent me from doing this in a production environment in a timely manner. Therefore I need an immediate solution in the meantime, and it would be great to have someone willing to help me out. As I am not a firewall expert, I have difficulties in setting up the outbound connections perfectly. That is also why I''m not comfortable with simply doing a REJECT all outbound traffic except the few ports. It''s something I need to work towards but again what I''m trying to do here is a quick temporary solution. I have setup a REJECT for outbound traffic to those ports as follows: REJECT loc net tcp 6,8,17,1025,1433,1434,1435 REJECT loc net tcp 2798,2967,2968,5761,5900 However I understand I need to also block outbound for those ports as being sources as well. How would I go about doing that? I REALLY appreciate some help with this. I understand I need to do a lot of other stuff but that will take some time, and I need to immediately find a temporary solution, even knowing it''s not the best (or even a catch-all). Thank you Ricardo On Mon, 2008-09-08 at 16:31 -0700, Tom Eastep wrote:> Ricardo Kleemann wrote: > > Hi, > > > > I run an older version of shorewall (1.4.2) and need some helping > > setting up some rules. > > > > I received an abusenet notification that one of my servers is being used > > to hack elsewhere. I don''t know if anyone here is familiar with > > Linux.Backdoor.Small.o, any help would be greatly appreciated. > > > > The suggestion I received is to block outbound traffic: > > > outbound traffic either source or destination using ports: 6, 8, 17, > > > 1025, 1433, 1434, 1435, 2798, 2967, 2968, 5761, & 5900 > > > > Certainly, first I''d like to determine which application is leaving the > > open door, I''m guessing it''s my apache. But in any case I need to close > > down the backdoor by blocking at shorewall as well. > > The fact that you are still running Shorewall 1.4.2 suggests to me that you > don''t keep up with security patch releases very closely. It follows that it > is no surprised that one of your systems has been compromised. > > It is a fact that your internet-exposed servers are the weakest point in > your network and the most likely place for a compromise to occur. > > It is also a fact that you should isolate your internet-exposed servers in > their own LAN and that the firewall policy from that LAN to ANYWHERE should > be REJECT. So the problem is not to add 100s (1000s) of rules to block the > bad stuff but rather to add a few ACCEPT rules for the traffic that must be > allowed. That is the only way to approach this problem. > > And *keep up with software releases*. > > -Tom > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Ricardo Kleemann wrote:> However I understand I need to also block outbound for those ports as > being sources as well. How would I go about doing that?I have no idea what you are talking about. The rules that you posted looked adequate to me (or at least as adequate as is possible in your case). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
I apologize for my lack of knowledge. Ok, but I have some doubts as far as how I would go about first blocking all traffic "anywhere" from the servers lan except for the few ports allowed. For example, won''t dns requests use random source ports when queries are made? Something like (from lsof on the server), I have some named entries like this: named 1620 named 29u IPv4 102898568 TCP server1.americasnet.com:32858->cpe-24-24-238-161.socal.res.rr.com:domain (SYN_SENT) named 1620 named 30u IPv4 102906041 TCP server1.americasnet.com:57631->cpe-24-24-213-189.socal.res.rr.com:domain (SYN_SENT) If I REJECT all traffic, would random source ports like this be blocked, or would opening up domain take care of that? Another question, should the REJECT rule be at the end of the rules file so that it picks up only after all the ACCEPT rules? On Mon, 2008-09-08 at 19:43 -0700, Tom Eastep wrote:> Ricardo Kleemann wrote: > > > However I understand I need to also block outbound for those ports as > > being sources as well. How would I go about doing that? > > I have no idea what you are talking about. The rules that you posted looked > adequate to me (or at least as adequate as is possible in your case). > > -Tom > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Sorry for so many questions, but also for example, I can see valid smtp sessions in netstat like this: tcp 0 0 server1.americasnet.co:smtp 89.165.43.31:17761 SYN_RECV Would this traffic be blocked since it has a random destination port of 17761? On Mon, 2008-09-08 at 20:56 -0700, Ricardo Kleemann wrote:> I apologize for my lack of knowledge. > > Ok, but I have some doubts as far as how I would go about first blocking > all traffic "anywhere" from the servers lan except for the few ports > allowed. > > For example, won''t dns requests use random source ports when queries are > made? Something like (from lsof on the server), I have some named > entries like this: > > named 1620 named 29u IPv4 102898568 TCP > server1.americasnet.com:32858->cpe-24-24-238-161.socal.res.rr.com:domain > (SYN_SENT) > named 1620 named 30u IPv4 102906041 TCP > server1.americasnet.com:57631->cpe-24-24-213-189.socal.res.rr.com:domain > (SYN_SENT) > > > If I REJECT all traffic, would random source ports like this be blocked, > or would opening up domain take care of that? > > > Another question, should the REJECT rule be at the end of the rules file > so that it picks up only after all the ACCEPT rules? > > > > > > On Mon, 2008-09-08 at 19:43 -0700, Tom Eastep wrote: > > Ricardo Kleemann wrote: > > > > > However I understand I need to also block outbound for those ports as > > > being sources as well. How would I go about doing that? > > > > I have no idea what you are talking about. The rules that you posted looked > > adequate to me (or at least as adequate as is possible in your case). > > > > -Tom > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge > > Build the coolest Linux based applications with Moblin SDK & win great prizes > > Grand prize is a trip for two to an Open Source event anywhere in the world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Hi Ricardo,
(Trying to offload Tom a bit.)
The single most important thing I have to say is this:
From your original mail it seems like at least one of
your machines is infected/pwned/trojaned/rooted. In
that situation the first and most important thing to
do is to identify WHICH machine(s) and pull the plug
on them.
You should NOT fiddle with firewall rules just yet.
And, as Tom already said, make sure that all software on all your machines is up
to date. That cannot be stressed enough. Bite the bullet.
When it comes to configure the firewall(s), please read up a bit. Really. Below
I will try to "codify" some of what Tom said.
1) Make a list of all hosts which should be exposed to the internet.
2) Make a list of all services on host in 1) that should be accessible from the
internet and on which host.
3) Make a list of which services the hosts in 1) need on the internet.
4) Place the hosts in 1) in a separate zone "dmz" in
"/etc/shorewall/zones".
5) Use policy "dmz net REJECT" policy in
"/etc/shorewall/policy".
6) Use policy "net dmz DROP" policy in
"/etc/shorewall/policy".
7) Add rules in "/etc/shorewall/rules" for necessary inbound traffic.
8) Add rules in "/etc/shorewall/rules" for necessary outbound traffic.
We are here to help you, but since this is not a paid support line you are also
expected to have made your homework first.
<http://shorewall.net/Introduction.html> should be a good starting point.
Good luck and don''t hesitate to get back in case of trouble. But first
you
should read <http://shorewall.net/support.htm>.
Best regards,
/Martin
Ricardo Kleemann wrote:> Sorry for so many questions, but also for example, I can see valid smtp
> sessions in netstat like this:
>
> tcp 0 0 server1.americasnet.co:smtp 89.165.43.31:17761
> SYN_RECV
>
> Would this traffic be blocked since it has a random destination port of
> 17761?
>
>
> On Mon, 2008-09-08 at 20:56 -0700, Ricardo Kleemann wrote:
>> I apologize for my lack of knowledge.
>>
>> Ok, but I have some doubts as far as how I would go about first
blocking
>> all traffic "anywhere" from the servers lan except for the
few ports
>> allowed.
>>
>> For example, won''t dns requests use random source ports when
queries are
>> made? Something like (from lsof on the server), I have some named
>> entries like this:
>>
>> named 1620 named 29u IPv4 102898568
TCP
>>
server1.americasnet.com:32858->cpe-24-24-238-161.socal.res.rr.com:domain
>> (SYN_SENT)
>> named 1620 named 30u IPv4 102906041
TCP
>>
server1.americasnet.com:57631->cpe-24-24-213-189.socal.res.rr.com:domain
>> (SYN_SENT)
>>
>>
>> If I REJECT all traffic, would random source ports like this be
blocked,
>> or would opening up domain take care of that?
>>
>>
>> Another question, should the REJECT rule be at the end of the rules
file
>> so that it picks up only after all the ACCEPT rules?
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer''s
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Martin, First I''d like to thank you for your patience. One of the things that is confusing to me is related to outbound traffic. Figuring out the inbound traffic is easy, since I know all the services provided. But determining the outbound to me I see it as a lot more complicated, certainly because I may be missing some of the picture. Let me try to explain what I mean. If I look at netstat output, I can see things like this: tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:202.63.164.4:53400 ESTABLISHED tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:8.12.43.34:2616 TIME_WAIT tcp 12 0 ::ffff:192.168.1.245:25 ::ffff:200.198.4.21:58613 ESTABLISHED I have a hard time understanding how I should determine the outbound ports to allow, since my smtp server has connections established to strange port numbers yet I''m assuming here that these are valid smtp transactions. Similarly, tcp 0 0 ::ffff:192.168.1.245:143 ::ffff:206.53.151.202:40866 ESTABLISHED I have no reason to doubt this isn''t a valid imap connection, but again would this imap connection be blocked if I configured "dmz net REJECT" and didn''t open the destination port 40866? And then I have a number of http connections which I don''t know how to determine whether they''re rogue or not. Something like, tcp 0 0 ::ffff:192.168.1.245:80 ::ffff:189.60.234.251:62473 TIME_WAIT tcp 0 0 ::ffff:192.168.1.245:80 ::ffff:201.29.103.98:13725 ESTABLISHED So my concern is once I block everything with the "dmz net REJECT" how do I determine which outbound ports are to be opened, maybe it''s a lot simpler than I think. Ricardo ----- Original Message ----- From: "Martin Leben" <ml060223@leben.nu> To: <shorewall-users@lists.sourceforge.net> Sent: Tuesday, September 09, 2008 9:01 AM Subject: Re: [Shorewall-users] Please help in rule setup> Hi Ricardo, > > (Trying to offload Tom a bit.) > > The single most important thing I have to say is this: > From your original mail it seems like at least one of > your machines is infected/pwned/trojaned/rooted. In > that situation the first and most important thing to > do is to identify WHICH machine(s) and pull the plug > on them. > > You should NOT fiddle with firewall rules just yet. > > And, as Tom already said, make sure that all software on all your machines > is up > to date. That cannot be stressed enough. Bite the bullet. > > When it comes to configure the firewall(s), please read up a bit. Really. > Below > I will try to "codify" some of what Tom said. > > 1) Make a list of all hosts which should be exposed to the internet. > 2) Make a list of all services on host in 1) that should be accessible > from the > internet and on which host. > 3) Make a list of which services the hosts in 1) need on the internet. > 4) Place the hosts in 1) in a separate zone "dmz" in > "/etc/shorewall/zones". > 5) Use policy "dmz net REJECT" policy in "/etc/shorewall/policy". > 6) Use policy "net dmz DROP" policy in "/etc/shorewall/policy". > 7) Add rules in "/etc/shorewall/rules" for necessary inbound traffic. > 8) Add rules in "/etc/shorewall/rules" for necessary outbound traffic. > > We are here to help you, but since this is not a paid support line you are > also > expected to have made your homework first. > <http://shorewall.net/Introduction.html> should be a good starting point. > > Good luck and don''t hesitate to get back in case of trouble. But first you > should read <http://shorewall.net/support.htm>. > > Best regards, > /Martin > > > Ricardo Kleemann wrote: >> Sorry for so many questions, but also for example, I can see valid smtp >> sessions in netstat like this: >> >> tcp 0 0 server1.americasnet.co:smtp 89.165.43.31:17761 >> SYN_RECV >> >> Would this traffic be blocked since it has a random destination port of >> 17761? >> >> >> On Mon, 2008-09-08 at 20:56 -0700, Ricardo Kleemann wrote: >>> I apologize for my lack of knowledge. >>> >>> Ok, but I have some doubts as far as how I would go about first blocking >>> all traffic "anywhere" from the servers lan except for the few ports >>> allowed. >>> >>> For example, won''t dns requests use random source ports when queries are >>> made? Something like (from lsof on the server), I have some named >>> entries like this: >>> >>> named 1620 named 29u IPv4 102898568 TCP >>> server1.americasnet.com:32858->cpe-24-24-238-161.socal.res.rr.com:domain >>> (SYN_SENT) >>> named 1620 named 30u IPv4 102906041 TCP >>> server1.americasnet.com:57631->cpe-24-24-213-189.socal.res.rr.com:domain >>> (SYN_SENT) >>> >>> >>> If I REJECT all traffic, would random source ports like this be blocked, >>> or would opening up domain take care of that? >>> >>> >>> Another question, should the REJECT rule be at the end of the rules file >>> so that it picks up only after all the ACCEPT rules? > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer''s > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> Let me try to explain what I mean. If I look at netstat output, I can see > things like this: > > tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:202.63.164.4:53400 > ESTABLISHED > tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:8.12.43.34:2616 > TIME_WAIT > tcp 12 0 ::ffff:192.168.1.245:25 ::ffff:200.198.4.21:58613 > ESTABLISHEDI think you''re confused about what netstat is showing you. Here you have 3 connections which (almost certainly) were initiated **from** the IP and port in the right-hand column **to** your server in the left-hand column. The traffic going the other way (your server port 25 back to the client''s random port) will be allowed by connection tracking rules. -Brad ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Brad wrote:>> Let me try to explain what I mean. If I look at netstat output, I can see >> things like this: >> >> tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:202.63.164.4:53400 >> ESTABLISHED >> tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:8.12.43.34:2616 >> TIME_WAIT >> tcp 12 0 ::ffff:192.168.1.245:25 ::ffff:200.198.4.21:58613 >> ESTABLISHED > > I think you''re confused about what netstat is showing you. Here you have > 3 connections which (almost certainly) were initiated **from** the IP > and port in the right-hand column **to** your server in the left-hand > column. The traffic going the other way (your server port 25 back to > the client''s random port) will be allowed by connection tracking rules.A better place for Ricardo to start might be with the output of "shorewall show connections" Example: gateway:~ # shorewall-lite show connections Shorewall Lite 4.2.0-RC2 Connections at gateway - Tue Sep 9 11:08:19 PDT 2008 ipv4 2 tcp 6 5 CLOSE src=65.55.209.224 dst=206.124.146.177 sport=41582 dport=80 packets=5 bytes=578 65.55.209.224 connected to 206.124.146.177 port 80. Since 206.124.146.177 is the IP address of my server, the above is an *incoming* connection to TCP port 80 (http). src=206.124.146.177 dst=65.55.209.224 sport=80 dport=41582 packets=4 bytes=357 [ASSURED] mark=256 secmark=0 use=1 ipv4 2 tcp 6 91 TIME_WAIT src=69.216.17.166 dst=206.124.146.177 sport=3236 dport=80 packets=22 bytes=1376 src=206.124.146.177 dst=69.216.17.166 sport=80 dport=3236 packets=25 bytes=31113 [ASSURED] mark=256 secmark=0 use=1 ipv4 2 udp 17 7 src=206.124.146.177 dst=63.218.83.20 sport=3710 dport=53 packets=1 bytes=87 src=63.218.83.20 dst=206.124.146.177 sport=53 dport=3710 packets=1 bytes=316 mark=256 secmark=0 use=1 Here, since 206.124.146.177 is the source, the above is an *outgoing* connection to UDP port 53 (DNS) ipv4 2 udp 17 7 src=206.124.146.177 dst=64.124.52.230 sport=6319 dport=53 packets=1 bytes=87 src=64.124.52.230 dst=206.124.146.177 sport=53 dport=6319 packets=1 bytes=132 mark=256 secmark=0 use=1 ipv4 2 udp 17 7 src=206.124.146.177 dst=194.146.106.50 sport=22153 dport=53 packets=1 bytes=73 src=194.146.106.50 dst=206.124.146.177 sport=53 dport=22153 packets=1 bytes=272 mark=256 secmark=0 use=1 ipv4 2 udp 17 7 src=206.124.146.177 dst=213.47.222.133 sport=26678 dport=53 packets=1 bytes=70 src=213.47.222.133 dst=206.124.146.177 sport=53 dport=26678 packets=1 bytes=111 mark=256 secmark=0 use=1 ipv4 2 tcp 6 24 TIME_WAIT src=66.249.71.139 dst=206.124.146.177 sport=63417 dport=80 packets=6 bytes=603 src=206.124.146.177 dst=66.249.71.139 sport=80 dport=63417 packets=4 bytes=1364 [ASSURED] mark=256 secmark=0 use=1 ipv4 2 udp 17 7 src=206.124.146.177 dst=81.91.161.98 sport=19221 dport=53 packets=1 bytes=73 src=81.91.161.98 dst=206.124.146.177 sport=53 dport=19221 packets=1 bytes=327 mark=256 secmark=0 use=1 -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
So I have it totally backwards. Anyway, what would this mean? tcp 0 1 192.168.1.245:38677 24.24.228.60:53 SYN_SENT tcp 0 1 192.168.1.245:35885 24.24.215.225:53 SYN_SENT tcp 0 1 192.168.1.245:55274 24.24.213.189:53 SYN_SENT tcp 0 1 192.168.1.245:42879 24.24.215.225:53 SYN_SENT A connection was initiated from the dns source port on 24.24.228.60, but it''s hitting port 38677 on my server? Seems strange to me and this definitely looks like malicious stuff. I have a bunch of similar entries originating from external IPs on port 53. I don''t even understand how shorewall is letting those through since I don''t have those ports open. Ricardo ----- Original Message ----- From: "Brad" <brad+shorewall-users@mifflinet.net> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Tuesday, September 09, 2008 9:44 AM Subject: Re: [Shorewall-users] Please help in rule setup>> Let me try to explain what I mean. If I look at netstat output, I can see >> things like this: >> >> tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:202.63.164.4:53400 >> ESTABLISHED >> tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:8.12.43.34:2616 >> TIME_WAIT >> tcp 12 0 ::ffff:192.168.1.245:25 ::ffff:200.198.4.21:58613 >> ESTABLISHED > > I think you''re confused about what netstat is showing you. Here you have > 3 connections which (almost certainly) were initiated **from** the IP > and port in the right-hand column **to** your server in the left-hand > column. The traffic going the other way (your server port 25 back to > the client''s random port) will be allowed by connection tracking rules. > > -Brad > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer''s > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Your machine is probaly making DNS requests. In order to KNOW if it is your machine that is making the request, run "shorewall show connections" as Tom instructed earlier. That command will show not only the local and remote address/ports, but also the direction. BR /Martin Ricardo Kleemann wrote:> So I have it totally backwards. > > Anyway, what would this mean? > > tcp 0 1 192.168.1.245:38677 24.24.228.60:53 > SYN_SENT > tcp 0 1 192.168.1.245:35885 24.24.215.225:53 > SYN_SENT > tcp 0 1 192.168.1.245:55274 24.24.213.189:53 > SYN_SENT > tcp 0 1 192.168.1.245:42879 24.24.215.225:53 > SYN_SENT > > A connection was initiated from the dns source port on 24.24.228.60, but > it''s hitting port 38677 on my server? > > Seems strange to me and this definitely looks like malicious stuff. I have a > bunch of similar entries originating from external IPs on port 53. I don''t > even understand how shorewall is letting those through since I don''t have > those ports open. > > Ricardo > > ----- Original Message ----- > From: "Brad" <brad+shorewall-users@mifflinet.net> > To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> > Sent: Tuesday, September 09, 2008 9:44 AM > Subject: Re: [Shorewall-users] Please help in rule setup > > >>> Let me try to explain what I mean. If I look at netstat output, I can see >>> things like this: >>> >>> tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:202.63.164.4:53400 >>> ESTABLISHED >>> tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:8.12.43.34:2616 >>> TIME_WAIT >>> tcp 12 0 ::ffff:192.168.1.245:25 ::ffff:200.198.4.21:58613 >>> ESTABLISHED >> I think you''re confused about what netstat is showing you. Here you have >> 3 connections which (almost certainly) were initiated **from** the IP >> and port in the right-hand column **to** your server in the left-hand >> column. The traffic going the other way (your server port 25 back to >> the client''s random port) will be allowed by connection tracking rules. >> >> -Brad------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Where can I find a description of the output for show connections? I see the command syntax and description but not for the actual output. Thanks Ricardo ----- Original Message ----- From: "Martin Leben" <ml060223@leben.nu> To: <shorewall-users@lists.sourceforge.net> Sent: Tuesday, September 09, 2008 3:29 PM Subject: Re: [Shorewall-users] Please help in rule setup> Your machine is probaly making DNS requests. In order to KNOW if it is > your > machine that is making the request, run "shorewall show connections" as > Tom > instructed earlier. That command will show not only the local and remote > address/ports, but also the direction. > > BR > /Martin > > > Ricardo Kleemann wrote: >> So I have it totally backwards. >> >> Anyway, what would this mean? >> >> tcp 0 1 192.168.1.245:38677 24.24.228.60:53 >> SYN_SENT >> tcp 0 1 192.168.1.245:35885 24.24.215.225:53 >> SYN_SENT >> tcp 0 1 192.168.1.245:55274 24.24.213.189:53 >> SYN_SENT >> tcp 0 1 192.168.1.245:42879 24.24.215.225:53 >> SYN_SENT >> >> A connection was initiated from the dns source port on 24.24.228.60, but >> it''s hitting port 38677 on my server? >> >> Seems strange to me and this definitely looks like malicious stuff. I >> have a >> bunch of similar entries originating from external IPs on port 53. I >> don''t >> even understand how shorewall is letting those through since I don''t have >> those ports open. >> >> Ricardo >> >> ----- Original Message ----- >> From: "Brad" <brad+shorewall-users@mifflinet.net> >> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> >> Sent: Tuesday, September 09, 2008 9:44 AM >> Subject: Re: [Shorewall-users] Please help in rule setup >> >> >>>> Let me try to explain what I mean. If I look at netstat output, I can >>>> see >>>> things like this: >>>> >>>> tcp 0 0 ::ffff:192.168.1.245:25 >>>> ::ffff:202.63.164.4:53400 >>>> ESTABLISHED >>>> tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:8.12.43.34:2616 >>>> TIME_WAIT >>>> tcp 12 0 ::ffff:192.168.1.245:25 >>>> ::ffff:200.198.4.21:58613 >>>> ESTABLISHED >>> I think you''re confused about what netstat is showing you. Here you have >>> 3 connections which (almost certainly) were initiated **from** the IP >>> and port in the right-hand column **to** your server in the left-hand >>> column. The traffic going the other way (your server port 25 back to >>> the client''s random port) will be allowed by connection tracking rules. >>> >>> -Brad > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer''s > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
I am no expert, so take my words wit a grain of salt. From just looking at the output of "shorewall show connections" on my own firewall I came to the following conclusion: - The first instance of the quadruplet "src, dst, sport and dport" describes the initial request. - The second instance of the quadruplet "src, dst, sport and dport" describes the reverse direction. Both of these groups of data is needed for the connection tracking. So if I am correct in my assumption that your machine is making DNS requests the first quadruplet would look like this on your system: "src=192.168.1.245 dst=24.24.228.60 sport=38677 dport=53" BR /Martin "going to bed now" Leben Ricardo Kleemann wrote:> Where can I find a description of the output for show connections? > > I see the command syntax and description but not for the actual output. > > Thanks > Ricardo > ----- Original Message ----- > From: "Martin Leben" <ml060223@leben.nu> > To: <shorewall-users@lists.sourceforge.net> > Sent: Tuesday, September 09, 2008 3:29 PM > Subject: Re: [Shorewall-users] Please help in rule setup > > >> Your machine is probaly making DNS requests. In order to KNOW if it is >> your >> machine that is making the request, run "shorewall show connections" as >> Tom >> instructed earlier. That command will show not only the local and remote >> address/ports, but also the direction. >> >> BR >> /Martin >> >> >> Ricardo Kleemann wrote: >>> So I have it totally backwards. >>> >>> Anyway, what would this mean? >>> >>> tcp 0 1 192.168.1.245:38677 24.24.228.60:53 >>> SYN_SENT >>> tcp 0 1 192.168.1.245:35885 24.24.215.225:53 >>> SYN_SENT >>> tcp 0 1 192.168.1.245:55274 24.24.213.189:53 >>> SYN_SENT >>> tcp 0 1 192.168.1.245:42879 24.24.215.225:53 >>> SYN_SENT >>> >>> A connection was initiated from the dns source port on 24.24.228.60, but >>> it''s hitting port 38677 on my server? >>> >>> Seems strange to me and this definitely looks like malicious stuff. I >>> have a >>> bunch of similar entries originating from external IPs on port 53. I >>> don''t >>> even understand how shorewall is letting those through since I don''t have >>> those ports open. >>> >>> Ricardo >>> >>> ----- Original Message ----- >>> From: "Brad" <brad+shorewall-users@mifflinet.net> >>> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> >>> Sent: Tuesday, September 09, 2008 9:44 AM >>> Subject: Re: [Shorewall-users] Please help in rule setup >>> >>> >>>>> Let me try to explain what I mean. If I look at netstat output, I can >>>>> see >>>>> things like this: >>>>> >>>>> tcp 0 0 ::ffff:192.168.1.245:25 >>>>> ::ffff:202.63.164.4:53400 >>>>> ESTABLISHED >>>>> tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:8.12.43.34:2616 >>>>> TIME_WAIT >>>>> tcp 12 0 ::ffff:192.168.1.245:25 >>>>> ::ffff:200.198.4.21:58613 >>>>> ESTABLISHED >>>> I think you''re confused about what netstat is showing you. Here you have >>>> 3 connections which (almost certainly) were initiated **from** the IP >>>> and port in the right-hand column **to** your server in the left-hand >>>> column. The traffic going the other way (your server port 25 back to >>>> the client''s random port) will be allowed by connection tracking rules. >>>> >>>> -Brad------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
I am no expert, so take my words wit a grain of salt. From just looking at the output of "shorewall show connections" on my own firewall I came to the following conclusion: - The first instance of the quadruplet "src, dst, sport and dport" describes the initial request. - The second instance of the quadruplet "src, dst, sport and dport" describes the reverse direction. So if I am correct in my assumption that your machine is making DNS requests the first quadruplet would look like this on your system: "src=192.168.1.245 dst=24.24.228.60 sport=38677 dport=53" BR /Martin "going to bed now" Leben Ricardo Kleemann wrote:> Where can I find a description of the output for show connections? > > I see the command syntax and description but not for the actual output. > > Thanks > Ricardo > ----- Original Message ----- > From: "Martin Leben" <ml060223@leben.nu> > To: <shorewall-users@lists.sourceforge.net> > Sent: Tuesday, September 09, 2008 3:29 PM > Subject: Re: [Shorewall-users] Please help in rule setup > > >> Your machine is probaly making DNS requests. In order to KNOW if it is >> your >> machine that is making the request, run "shorewall show connections" as >> Tom >> instructed earlier. That command will show not only the local and remote >> address/ports, but also the direction. >> >> BR >> /Martin >> >> >> Ricardo Kleemann wrote: >>> So I have it totally backwards. >>> >>> Anyway, what would this mean? >>> >>> tcp 0 1 192.168.1.245:38677 24.24.228.60:53 >>> SYN_SENT >>> tcp 0 1 192.168.1.245:35885 24.24.215.225:53 >>> SYN_SENT >>> tcp 0 1 192.168.1.245:55274 24.24.213.189:53 >>> SYN_SENT >>> tcp 0 1 192.168.1.245:42879 24.24.215.225:53 >>> SYN_SENT >>> >>> A connection was initiated from the dns source port on 24.24.228.60, but >>> it''s hitting port 38677 on my server? >>> >>> Seems strange to me and this definitely looks like malicious stuff. I >>> have a >>> bunch of similar entries originating from external IPs on port 53. I >>> don''t >>> even understand how shorewall is letting those through since I don''t have >>> those ports open. >>> >>> Ricardo >>> >>> ----- Original Message ----- >>> From: "Brad" <brad+shorewall-users@mifflinet.net> >>> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> >>> Sent: Tuesday, September 09, 2008 9:44 AM >>> Subject: Re: [Shorewall-users] Please help in rule setup >>> >>> >>>>> Let me try to explain what I mean. If I look at netstat output, I can >>>>> see >>>>> things like this: >>>>> >>>>> tcp 0 0 ::ffff:192.168.1.245:25 >>>>> ::ffff:202.63.164.4:53400 >>>>> ESTABLISHED >>>>> tcp 0 0 ::ffff:192.168.1.245:25 ::ffff:8.12.43.34:2616 >>>>> TIME_WAIT >>>>> tcp 12 0 ::ffff:192.168.1.245:25 >>>>> ::ffff:200.198.4.21:58613 >>>>> ESTABLISHED >>>> I think you''re confused about what netstat is showing you. Here you have >>>> 3 connections which (almost certainly) were initiated **from** the IP >>>> and port in the right-hand column **to** your server in the left-hand >>>> column. The traffic going the other way (your server port 25 back to >>>> the client''s random port) will be allowed by connection tracking rules. >>>> >>>> -Brad------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Ricardo Kleemann wrote:> Where can I find a description of the output for show connections? > > I see the command syntax and description but not for the actual output.The output is not produced by Shorewall -- depending on your kernel version, it is produced either by cat /proc/net/ip_conntrack or by cat /proc/net/nf_conntrack As Martin has described, the left part of each entry describes the original connection and the right side describes the reverse direction. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> As Martin has described, the left part of each entry describes the > original connection and the right side describes the reverse direction.Note that when NAT occurs, the left part is not a mirror image of the right side. Here''s an example where a masqueraded host (192.168.0.9) connected to an external HTTPS site. The left side has src=192.168.0.9 dst=63.245.209.119 While the right side has src=63.245.209.119 dst=172.20.1.102 172.20.1.102 is the Shorewall box''s external IP address. ipv4 2 tcp 6 80 TIME_WAIT src=192.168.0.9 dst=63.245.209.119 sport=38171 dport=443 packets=9 bytes=1469 src=63.245.209.119 dst=172.20.1.102 sport=443 dport=38171 packets=8 bytes=1595 [ASSURED] mark=0 secmark=0 use=1 -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Is there a way for show connections to show only the outbound? It''s seems to be very difficult to filter out the outbound only from such a large output. Ricardo On Tue, 2008-09-09 at 16:25 -0700, Tom Eastep wrote:> Tom Eastep wrote: > > > As Martin has described, the left part of each entry describes the > > original connection and the right side describes the reverse direction. > > Note that when NAT occurs, the left part is not a mirror image of the right side. > > Here''s an example where a masqueraded host (192.168.0.9) connected to an external HTTPS site. > > The left side has > > src=192.168.0.9 dst=63.245.209.119 > > While the right side has > > src=63.245.209.119 dst=172.20.1.102 > > 172.20.1.102 is the Shorewall box''s external IP address. > > ipv4 2 tcp 6 80 TIME_WAIT src=192.168.0.9 dst=63.245.209.119 sport=38171 dport=443 packets=9 bytes=1469 src=63.245.209.119 dst=172.20.1.102 sport=443 dport=38171 packets=8 bytes=1595 [ASSURED] mark=0 secmark=0 use=1 > > -Tom > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
I''ll answer my own question... ;-) I simply took the output of show connections, put it into excel and sorted the data in order to be able to better diagnose it. ;-) Ricardo On Thu, 2008-09-11 at 07:36 -0700, Ricardo Kleemann wrote:> Is there a way for show connections to show only the outbound? > > It''s seems to be very difficult to filter out the outbound only from > such a large output. > > Ricardo > > On Tue, 2008-09-09 at 16:25 -0700, Tom Eastep wrote: > > Tom Eastep wrote: > > > > > As Martin has described, the left part of each entry describes the > > > original connection and the right side describes the reverse direction. > > > > Note that when NAT occurs, the left part is not a mirror image of the right side. > > > > Here''s an example where a masqueraded host (192.168.0.9) connected to an external HTTPS site. > > > > The left side has > > > > src=192.168.0.9 dst=63.245.209.119 > > > > While the right side has > > > > src=63.245.209.119 dst=172.20.1.102 > > > > 172.20.1.102 is the Shorewall box''s external IP address. > > > > ipv4 2 tcp 6 80 TIME_WAIT src=192.168.0.9 dst=63.245.209.119 sport=38171 dport=443 packets=9 bytes=1469 src=63.245.209.119 dst=172.20.1.102 sport=443 dport=38171 packets=8 bytes=1595 [ASSURED] mark=0 secmark=0 use=1 > > > > -Tom > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge > > Build the coolest Linux based applications with Moblin SDK & win great prizes > > Grand prize is a trip for two to an Open Source event anywhere in the world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Hi, I was looking at shorewall-rules manpage but couldn''t find additional info about the use of "SERVICE/ACTION" like for example "DNS/ACCEPT" in the rules file. Where does shorewall retrieve the service list to map to "DNS" for example? I wanted to run openvpn which uses port 1194, how would I state that in the rules file with this new syntax? Thanks Ricardo ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Ricardo Kleemann wrote:>I was looking at shorewall-rules manpage but couldn''t find additional >info about the use of "SERVICE/ACTION" like for example "DNS/ACCEPT" in >the rules file. > >Where does shorewall retrieve the service list to map to "DNS" for >example? > >I wanted to run openvpn which uses port 1194, how would I state that in >the rules file with this new syntax?Shorewall looks for a macro file of the same name - in the case you gave, it would look for a file called "macro.DNS". There are a load of standard ones in /usr/share/shorewall (on Debian, could be somewhere else on other distros), and you can put them in /etc/shorewall - they will be found in either location. If you want to use a service that isn''t already defined, then either write a rule with the port number specified in the rule, or copy an existing macro file (put it in /etc/shorewall so it doesn''t conflict with the package manager) and modify it. The contents of macro.DNS are : PARAM - - udp 53 PARAM - - tcp 53 So a rule written as : DNS/ACCEPT net loc:192.168.1.123 would expand to the same as writing : ACCEPT net loc:192.168.1.123 udp 53 ACCEPT net loc:192.168.1.123 tcp 53 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Ricardo Kleemann wrote:> Hi, > > I was looking at shorewall-rules manpage but couldn''t find additional > info about the use of "SERVICE/ACTION" like for example "DNS/ACCEPT" in > the rules file. > > Where does shorewall retrieve the service list to map to "DNS" for > example? > > I wanted to run openvpn which uses port 1194, how would I state that in > the rules file with this new syntax?Use /etc/shorewall/tunnels instead (man shorewall-tunnels) or write your own OpenVPN macro. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Chris Morley
2008-Sep-15 13:21 UTC
All traffic blocked until ''shorewall clear'' & ''shorewall restart'' despite same config
Hi, i have a very strange issue in that after restart and bootup of my firewall all traffic is blocked for hosts behind the firewall trying to connect out onto the net or through the vpn (although i can reach the internal firewall interface and obtain dumps etc). Once i issue ''shorewall clear'' followed by ''shorewall restart'' it then works, despite the config not changing (similar to this thread http://ubuntuforums.org/showthread.php?t=57781). Please find attached the config, and the two states (dump when broken, dump when working after shorewall restart). In the broken state there are no logs in /var/log/messages regarding rejected or dropped packets. I''ve used a similar configuration without issue for months, i''ve obviously made a mistake somewhere but i cant see where. Not sure if this is to do with Shorewall starting before the tunnel is up but again im sure this used to work as is or i was just lucky. Appreciate any thoughts on the above. Many thanks in advance, Chris _________________________________________________________________ Win New York holidays with Kellogg’s & Live Search http://clk.atdmt.com/UKM/go/111354033/direct/01/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep
2008-Sep-15 14:15 UTC
Re: All traffic blocked until ''shorewall clear'' & ''shorewall restart'' despite same config
Chris Morley wrote:> Appreciate any thoughts on the above.Set IP_FORWARDING=On in shorewall.conf. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Chris Morley
2008-Sep-15 15:11 UTC
Re: All traffic blocked until ''shorewall clear'' & ''shorewall restart'' despite same config
> Set IP_FORWARDING=On in shorewall.conf.> > -TomCheers for pointing out my school boy error. ''shorewall.conf'' was the only file i didn''t copy across, i guess shorewall clear must enable forwarding. I thought it was already enabled on my box. Thanks again, Chris _________________________________________________________________ Make a mini you and download it into Windows Live Messenger http://clk.atdmt.com/UKM/go/111354029/direct/01/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep
2008-Sep-15 15:36 UTC
Re: All traffic blocked until ''shorewall clear'' & ''shorewall restart'' despite same config
Chris Morley wrote:>> Set IP_FORWARDING=On in shorewall.conf. >> >> -Tom > > Cheers for pointing out my school boy error. ''shorewall.conf'' was the > only file i didn''t copy across, i guess shorewall clear must enable > forwarding. I thought it was already enabled on my box.The default Debian shorewall.conf file sets IP_FORWARDING=Keep. ''shorewall clear'' has the side effect of enabling forwarding. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Hi,
I''m setting up shorewall (v. 3.4.8) and have established some IPs in
the
nat file.
For testing purposes only, I have my main eth0 interface for shorewall
(the "net" interface) in network 192.168.0. The dmz interface is eth2
in
network 192.168.1.
Here''s a snippet of ip addr output:
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:24:c0:02:dc brd ff:ff:ff:ff:ff:ff
inet 192.168.0.200/24 brd 192.168.0.255 scope global eth0
inet 192.168.0.199/24 brd 192.168.0.255 scope global secondary
eth0:1
5: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:24:c0:02:de brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global eth2
And I have in the nat file:
192.168.0.199 eth0:1 192.168.1.200
in the rules file I opened it up for testing:
Ping/ACCEPT net fw
Ping/ACCEPT net dmz
Ping/ACCEPT loc fw
Ping/ACCEPT dmz fw
Ping/ACCEPT fw dmz
And I have a test PC connected to the net interface, IP 192.168.0.104.
The routing from the fw looks correct:
# ip route
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.200
default via 192.168.0.1 dev eth0
Here''s what I see:
ping fw -> dmz is ok (192.168.1.1 -> 192.168.1.200)
ping net -> fw main address is ok (192.168.0.104 -> 192.168.0.200)
ping net -> dmz FAILS (192.168.0.104 -> 192.168.0.199)
I know packets are not being dropped so it''s not shorewall
that''s
blocking. I guess something''s just not getting routed properly? If I
can
go net -> fw and fw -> dmz, why is the net -> dmz failing?
Thanks
Ricardo
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer''s
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Ricardo Kleemann wrote:> Hi, > > I''m setting up shorewall (v. 3.4.8) and have established some IPs in the > nat file. > > For testing purposes only, I have my main eth0 interface for shorewall > (the "net" interface) in network 192.168.0. The dmz interface is eth2 in > network 192.168.1. > > Here''s a snippet of ip addr output: > > 3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:00:24:c0:02:dc brd ff:ff:ff:ff:ff:ff > inet 192.168.0.200/24 brd 192.168.0.255 scope global eth0 > inet 192.168.0.199/24 brd 192.168.0.255 scope global secondary > eth0:1 > > 5: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:00:24:c0:02:de brd ff:ff:ff:ff:ff:ff > inet 192.168.1.1/24 brd 192.168.1.255 scope global eth2 > > > And I have in the nat file: > 192.168.0.199 eth0:1 192.168.1.200 > > > in the rules file I opened it up for testing: > Ping/ACCEPT net fw > Ping/ACCEPT net dmz > Ping/ACCEPT loc fw > Ping/ACCEPT dmz fw > Ping/ACCEPT fw dmz > > > And I have a test PC connected to the net interface, IP 192.168.0.104. > > > The routing from the fw looks correct: > # ip route > 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.1 > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.200 > default via 192.168.0.1 dev eth0 > > > Here''s what I see: > > ping fw -> dmz is ok (192.168.1.1 -> 192.168.1.200) > ping net -> fw main address is ok (192.168.0.104 -> 192.168.0.200) > ping net -> dmz FAILS (192.168.0.104 -> 192.168.0.199) > > I know packets are not being dropped so it''s not shorewall that''s > blocking. I guess something''s just not getting routed properly? If I can > go net -> fw and fw -> dmz, why is the net -> dmz failing?What is the output of "shorewall show zones"? -Tom -- Tom Eastep \ The ultimate result of shielding men from the effects of folly \ is to fill the world with fools -- Herbert Spencer Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
On Thu, 2008-09-18 at 17:59 -0700, Tom Eastep wrote:> Ricardo Kleemann wrote: > > Hi, > > > > I''m setting up shorewall (v. 3.4.8) and have established some IPs in the > > nat file. > > > > For testing purposes only, I have my main eth0 interface for shorewall > > (the "net" interface) in network 192.168.0. The dmz interface is eth2 in > > network 192.168.1. > > > > Here''s a snippet of ip addr output: > > > > 3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > > link/ether 00:00:24:c0:02:dc brd ff:ff:ff:ff:ff:ff > > inet 192.168.0.200/24 brd 192.168.0.255 scope global eth0 > > inet 192.168.0.199/24 brd 192.168.0.255 scope global secondary > > eth0:1 > > > > 5: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > > link/ether 00:00:24:c0:02:de brd ff:ff:ff:ff:ff:ff > > inet 192.168.1.1/24 brd 192.168.1.255 scope global eth2 > > > > > > And I have in the nat file: > > 192.168.0.199 eth0:1 192.168.1.200 > > > > > > in the rules file I opened it up for testing: > > Ping/ACCEPT net fw > > Ping/ACCEPT net dmz > > Ping/ACCEPT loc fw > > Ping/ACCEPT dmz fw > > Ping/ACCEPT fw dmz > > > > > > And I have a test PC connected to the net interface, IP 192.168.0.104. > > > > > > The routing from the fw looks correct: > > # ip route > > 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.1 > > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.200 > > default via 192.168.0.1 dev eth0 > > > > > > Here''s what I see: > > > > ping fw -> dmz is ok (192.168.1.1 -> 192.168.1.200) > > ping net -> fw main address is ok (192.168.0.104 -> 192.168.0.200) > > ping net -> dmz FAILS (192.168.0.104 -> 192.168.0.199) > > > > I know packets are not being dropped so it''s not shorewall that''s > > blocking. I guess something''s just not getting routed properly? If I can > > go net -> fw and fw -> dmz, why is the net -> dmz failing? > > What is the output of "shorewall show zones"? ># shorewall show zones Shorewall 3.4.8 Zones at firewall - Fri Sep 19 01:02:15 UTC 2008 fw (firewall) net (ipv4) eth0:0.0.0.0/0 loc (ipv4) eth1:0.0.0.0/0 dmz (ipv4) eth2:0.0.0.0/0 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Ricardo Kleemann wrote:> On Thu, 2008-09-18 at 17:59 -0700, Tom Eastep wrote: >> Ricardo Kleemann wrote: >>> I know packets are not being dropped so it''s not shorewall that''s >>> blocking. I guess something''s just not getting routed properly? If I can >>> go net -> fw and fw -> dmz, why is the net -> dmz failing? >> What is the output of "shorewall show zones"? >> > > # shorewall show zones > Shorewall 3.4.8 Zones at firewall - Fri Sep 19 01:02:15 UTC 2008 > > fw (firewall) > net (ipv4) > eth0:0.0.0.0/0 > loc (ipv4) > eth1:0.0.0.0/0 > dmz (ipv4) > eth2:0.0.0.0/0What is the setting of IP_FORWARDING in /etc/shorewall/shorewall.conf? -Tom -- Tom Eastep \ The ultimate result of shielding men from the effects of folly \ is to fill the world with fools -- Herbert Spencer Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
On Thu, 2008-09-18 at 18:07 -0700, Tom Eastep wrote:> Ricardo Kleemann wrote: > > On Thu, 2008-09-18 at 17:59 -0700, Tom Eastep wrote: > >> Ricardo Kleemann wrote: > >>> I know packets are not being dropped so it''s not shorewall that''s > >>> blocking. I guess something''s just not getting routed properly? If I can > >>> go net -> fw and fw -> dmz, why is the net -> dmz failing? > >> What is the output of "shorewall show zones"? > >> > > > > # shorewall show zones > > Shorewall 3.4.8 Zones at firewall - Fri Sep 19 01:02:15 UTC 2008 > > > > fw (firewall) > > net (ipv4) > > eth0:0.0.0.0/0 > > loc (ipv4) > > eth1:0.0.0.0/0 > > dmz (ipv4) > > eth2:0.0.0.0/0 > > What is the setting of IP_FORWARDING in /etc/shorewall/shorewall.conf? >It''s set to On... :-/ Could it be because I have the fw connected directly to the server (rather than via switch)? I wouldn''t think so since ping from the firewall (fw -> dmz) works... it''s just from the net -> dmz that doesn''t work... ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
On Thu, 2008-09-18 at 18:07 -0700, Tom Eastep wrote:> Ricardo Kleemann wrote: > > On Thu, 2008-09-18 at 17:59 -0700, Tom Eastep wrote: > >> Ricardo Kleemann wrote: > >>> I know packets are not being dropped so it''s not shorewall that''s > >>> blocking. I guess something''s just not getting routed properly? If I can > >>> go net -> fw and fw -> dmz, why is the net -> dmz failing? > >> What is the output of "shorewall show zones"? > >> > > > > # shorewall show zones > > Shorewall 3.4.8 Zones at firewall - Fri Sep 19 01:02:15 UTC 2008 > > > > fw (firewall) > > net (ipv4) > > eth0:0.0.0.0/0 > > loc (ipv4) > > eth1:0.0.0.0/0 > > dmz (ipv4) > > eth2:0.0.0.0/0 > > What is the setting of IP_FORWARDING in /etc/shorewall/shorewall.conf? >Would it have anything to do with the Bridging setting? I have: IP_FORWARDING=On BRIDGING=No ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Ricardo Kleemann wrote:> On Thu, 2008-09-18 at 18:07 -0700, Tom Eastep wrote: >> Ricardo Kleemann wrote: >>> On Thu, 2008-09-18 at 17:59 -0700, Tom Eastep wrote: >>>> Ricardo Kleemann wrote: >>>>> I know packets are not being dropped so it''s not shorewall that''s >>>>> blocking. I guess something''s just not getting routed properly? If I can >>>>> go net -> fw and fw -> dmz, why is the net -> dmz failing? >>>> What is the output of "shorewall show zones"? >>>> >>> # shorewall show zones >>> Shorewall 3.4.8 Zones at firewall - Fri Sep 19 01:02:15 UTC 2008 >>> >>> fw (firewall) >>> net (ipv4) >>> eth0:0.0.0.0/0 >>> loc (ipv4) >>> eth1:0.0.0.0/0 >>> dmz (ipv4) >>> eth2:0.0.0.0/0 >> What is the setting of IP_FORWARDING in /etc/shorewall/shorewall.conf? >> > > It''s set to On... :-/ > > Could it be because I have the fw connected directly to the server > (rather than via switch)? I wouldn''t think so since ping from the > firewall (fw -> dmz) works... it''s just from the net -> dmz that doesn''t > work...We''re going to need the output of "shorewall dump", collected as described at http://www.shorewall.net/support.htm#Guidelines -Tom -- Tom Eastep \ The ultimate result of shielding men from the effects of folly \ is to fill the world with fools -- Herbert Spencer Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> What is the setting of IP_FORWARDING in /etc/shorewall/shorewall.conf? > >> > > > > It''s set to On... :-/ > > > > Could it be because I have the fw connected directly to the server > > (rather than via switch)? I wouldn''t think so since ping from the > > firewall (fw -> dmz) works... it''s just from the net -> dmz that doesn''t > > work... > > We''re going to need the output of "shorewall dump", collected as > described at http://www.shorewall.net/support.htm#GuidelinesThanks Tom. It''s attached. I did the reset then attempted to ping. Again the issue here is that the ping isn''t going through the NAT. It goes to the main net interface (192.168.0.200) but the IP that is NAT''ed to the internal server (192.168.0.199 -> 192.168.1.200) is not pingable. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Ricardo Kleemann wrote:>>>> What is the setting of IP_FORWARDING in /etc/shorewall/shorewall.conf? >>>> >>> It''s set to On... :-/ >>> >>> Could it be because I have the fw connected directly to the server >>> (rather than via switch)? I wouldn''t think so since ping from the >>> firewall (fw -> dmz) works... it''s just from the net -> dmz that doesn''t >>> work... >> We''re going to need the output of "shorewall dump", collected as >> described at http://www.shorewall.net/support.htm#Guidelines > > Thanks Tom. > > It''s attached. I did the reset then attempted to ping. > > Again the issue here is that the ping isn''t going through the NAT. It > goes to the main net interface (192.168.0.200) but the IP that is NAT''ed > to the internal server (192.168.0.199 -> 192.168.1.200) is not pingable.What is the configured default gateway on host 192.168.1.200? -Tom -- Tom Eastep \ The ultimate result of shielding men from the effects of folly \ is to fill the world with fools -- Herbert Spencer Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
On Thu, 2008-09-18 at 19:53 -0700, Tom Eastep wrote:> Ricardo Kleemann wrote: > >>>> What is the setting of IP_FORWARDING in /etc/shorewall/shorewall.conf? > >>>> > >>> It''s set to On... :-/ > >>> > >>> Could it be because I have the fw connected directly to the server > >>> (rather than via switch)? I wouldn''t think so since ping from the > >>> firewall (fw -> dmz) works... it''s just from the net -> dmz that doesn''t > >>> work... > >> We''re going to need the output of "shorewall dump", collected as > >> described at http://www.shorewall.net/support.htm#Guidelines > > > > Thanks Tom. > > > > It''s attached. I did the reset then attempted to ping. > > > > Again the issue here is that the ping isn''t going through the NAT. It > > goes to the main net interface (192.168.0.200) but the IP that is NAT''ed > > to the internal server (192.168.0.199 -> 192.168.1.200) is not pingable. > > What is the configured default gateway on host 192.168.1.200? >Hi Tom, thanks for your help! The gateway configured was correct (192.168.1.1). The error of my ways was that the server had an unconnected eth interface that was assuming the 192.168.0 network... so maybe it was attempting to use that interface since the source IP of the NAT is on the 192.168.0 network? Anyway, after removing that interface, things started working. Ricardo ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/