Shorewall users - Jul 2005 - infected machine behind firewall

Question:

If I have and infected SQL server machine behind the firewall will
requests to port 1433 still go through the firewall despite no rule to
allow this behaviour?

Thanks

Tony 



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

tony wrote:
>Question:
>
>If I have and infected SQL server machine behind the firewall will
>requests to port 1433 still go through the firewall despite no rule to
>allow this behaviour?
>
>Thanks
>
>Tony 
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Shorewall-users mailing list
>Shorewall-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/shorewall-users
>  
>
Depends on your policy rule for the direction you are talking about.
You don''t give any information about your setup that could be used to
give a qualifid answer.
Please read and follow the support guidelines:
http://www.shorewall.net/support.htm

HTH,
Alex


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Le mercredi 27 juillet 2005 à 13:14 +0200, Alexander Wilms a écrit :
> Depends on your policy rule for the direction you are talking about.
> You don''t give any information about your setup that could be used
to
> give a qualifid answer.
 
policy file is default sorry.

Tony



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click

tony wrote:
>Le mercredi 27 juillet 2005 à 13:14 +0200, Alexander Wilms a écrit :
>
>  
>
>>Depends on your policy rule for the direction you are talking about.
>>You don''t give any information about your setup that could be
used to
>>give a qualifid answer.
>>    
>>
> 
>policy file is default sorry.
>
>Tony
>
>  
>
Tony,

sorry, but I forgot my crystal ball at home.
Default policy rules are dependend on the shorewall version. And without
telling us the direction of the traffic that you are talking about this
information is useless! So as requested before: Read and FOLLOW the
support guidelines.


Minimum: post your policy file, describe your setup (used zones, traffic
from where to where).

Alex


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Tony, imagine you are on a car repair aid mailing list.
What you are asking to the list today is to help you repair your car
that doesn''t work any more without specifying the brand, model and
exact description on why it does not function anymore. Sounds tricky,
isnt it ? ;-)

Niko

2005/7/27, Alexander Wilms
<alex.wilms@adminguru.org>:
> tony wrote:
> 
> >Le mercredi 27 juillet 2005 à 13:14 +0200, Alexander Wilms a écrit :
> >
> >
> >
> >>Depends on your policy rule for the direction you are talking
about.
> >>You don''t give any information about your setup that could
be used to
> >>give a qualifid answer.
> >>
> >>
> >
> >policy file is default sorry.
> >
> >Tony
> >
> >
> >
> 
> Tony,
> 
> sorry, but I forgot my crystal ball at home.
> Default policy rules are dependend on the shorewall version. And without
> telling us the direction of the traffic that you are talking about this
> information is useless! So as requested before: Read and FOLLOW the
> support guidelines.
> 
> 
> Minimum: post your policy file, describe your setup (used zones, traffic
> from where to where).
> 
> Alex
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click

Le mercredi 27 juillet 2005 à 14:49 +0200, Nicolas Helleringer a écrit
:
> Tony, imagine you are on a car repair aid mailing list.
> What you are asking to the list today is to help you repair your car
> that doesn''t work any more without specifying the brand, model and
> exact description on why it does not function anymore. Sounds tricky,
> isnt it ? ;-)
> > sorry, but I forgot my crystal ball at home.
OK so it is possible. Thanks! We have located the contaminated server
and are fixing it now.

Tony



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click

tony wrote:
> Le mercredi 27 juillet 2005 à 14:49 +0200, Nicolas Helleringer a écrit :
>>Tony, imagine you are on a car repair aid mailing list.
>>What you are asking to the list today is to help you repair your car
>>that doesn''t work any more without specifying the brand, model
and
>>exact description on why it does not function anymore. Sounds tricky,
>>isnt it ? ;-)
> 
>>>sorry, but I forgot my crystal ball at home.
> 
> OK so it is possible. Thanks! We have located the contaminated server
> and are fixing it now.
Did anyone here understand /anything/ in that thread?  :-)

-- 
Paul Gear, Manager IT Operations, Redlands College
38 Anson Road, Wellington Point 4160, Australia
(Please send attachments in portable formats such as PDF, HTML, or
OpenOffice.)
-- 
The information contained in this message is copyright by Redlands
College.  Any use for direct sales or marketing purposes is expressly
forbidden.  This message does not represent the views of Redlands
College.

Paul Gear wrote:
>tony wrote:
>  
>
>>Le mercredi 27 juillet 2005 à 14:49 +0200, Nicolas Helleringer a écrit :
>>    
>>
>>>Tony, imagine you are on a car repair aid mailing list.
>>>What you are asking to the list today is to help you repair your car
>>>that doesn''t work any more without specifying the brand,
model and
>>>exact description on why it does not function anymore. Sounds
tricky,
>>>isnt it ? ;-)
>>>      
>>>
>>>>sorry, but I forgot my crystal ball at home.
>>>>        
>>>>
>>OK so it is possible. Thanks! We have located the contaminated server
>>and are fixing it now.
>>    
>>
>
>Did anyone here understand /anything/ in that thread?  :-)
>
>  
>
Paul:
  Long time lurker; first time "caller".
Having been an automechanic, I think I understood "car", and
"repair",
but as far as crystal balls are concerned, I am not going to touch them 
with the old proverbial 10 foot pole :-D .
charlie T



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

> Did anyone here understand /anything/ in that thread?  :-)
What is sad is that if Tony did have any problem and now he has found
(even by himself) to solve it, he still does not want to share either
the problem nor the solution with us !
:(

Niko


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Le jeudi 28 juillet 2005 à 08:36 +0200, Nicolas Helleringer a écrit
:
> > Did anyone here understand /anything/ in that thread?  :-)
> What is sad is that if Tony did have any problem and now he has found
> (even by himself) to solve it, he still does not want to share either
> the problem nor the solution with us !
> :(
My question was "is it possible that an infected SQL server can pierce
Shorewall?".

To which it was replied if you want support follow the rules and send
your config files. The reply is not an answer to my question. But I
deduced that if people want to see the config files it may be possible
so we have decided first to see if the box is compromised.

All the other SQL servers behind the firewall behave as expected. If the
one renegade machine has some kind of malware which is getting through
then I will post to the list the following:

WARNING - Microsoft Virus "x" can go through your firewall 

and the steps we took to fix it.

For the moment we have a suspicion - before crying wolf we have some
work to do.

Is that OK with you guys?

Tony



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Very clear.

Thank you for answering Tony.

<thumbs>up</thumbs>

Niko

2005/7/28, tony <tony@tgds.net>:
> Le jeudi 28 juillet 2005 à 08:36 +0200, Nicolas Helleringer a écrit :
> > > Did anyone here understand /anything/ in that thread?  :-)
> > What is sad is that if Tony did have any problem and now he has found
> > (even by himself) to solve it, he still does not want to share either
> > the problem nor the solution with us !
> > :(
> 
> My question was "is it possible that an infected SQL server can pierce
> Shorewall?".
> 
> To which it was replied if you want support follow the rules and send
> your config files. The reply is not an answer to my question. But I
> deduced that if people want to see the config files it may be possible
> so we have decided first to see if the box is compromised.
> 
> All the other SQL servers behind the firewall behave as expected. If the
> one renegade machine has some kind of malware which is getting through
> then I will post to the list the following:
> 
> WARNING - Microsoft Virus "x" can go through your firewall
> 
> and the steps we took to fix it.
> 
> For the moment we have a suspicion - before crying wolf we have some
> work to do.
> 
> Is that OK with you guys?
> 
> Tony
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
> Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

tony escribió:
> My question was "is it possible that an infected SQL server can pierce
> Shorewall?".
if the server was "human compromised" (ie. a cracker) the you should 
tell us if you have your sql servers on a separate DMZ (if not, 
everything inside can be compromised, press the "red button" ;-) )

> To which it was replied if you want support follow the rules and send
> your config files. The reply is not an answer to my question. But I
> deduced that if people want to see the config files it may be possible
> so we have decided first to see if the box is compromised.
the support guidelines are very clear, not too much for comment..

> WARNING - Microsoft Virus "x" can go through your firewall 
I urge you to disable the SQL server TCP port. or limit who can connect 
to it, never expose that port to the wild internet,a lot of malware 
targets M$SQL ..even more.. comunnication via encripted... :-S
sql server password scan be sniffed,bruteforced...etc...
IMHO a really awful idea..

> For the moment we have a suspicion - before crying wolf we have some
> work to do.
> 
> Is that OK with you guys?
maybe not, next time,follow the problem reporting guidelines available 
here :

http://www.shorewall.net/support.htm#Guidelines

tony wrote:
>Le jeudi 28 juillet 2005 à 08:36 +0200, Nicolas Helleringer a écrit :
>  
>
>>>Did anyone here understand /anything/ in that thread?  :-)
>>>      
>>>
>>What is sad is that if Tony did have any problem and now he has found
>>(even by himself) to solve it, he still does not want to share either
>>the problem nor the solution with us !
>>:(
>>    
>>
>
>My question was "is it possible that an infected SQL server can pierce
>Shorewall?".
>
>To which it was replied if you want support follow the rules and send
>your config files. The reply is not an answer to my question. But I
>deduced that if people want to see the config files it may be possible
>so we have decided first to see if the box is compromised.
>
>All the other SQL servers behind the firewall behave as expected. If the
>one renegade machine has some kind of malware which is getting through
>then I will post to the list the following:
>
>WARNING - Microsoft Virus "x" can go through your firewall 
>
>and the steps we took to fix it.
>
>For the moment we have a suspicion - before crying wolf we have some
>work to do.
>
>Is that OK with you guys?
>
>  
>
No, actually it is not.

The issue is this: you didn''t give information needed to get a
qualified
answer.

And: A infected MSSQL server cannot pierce a firewall running on a
separate machine that is configured correctly! If you configured
shorewall correctly according to your needs/setup...who knows. (Hint: I
ASKED YOU ABOUT ZONES/POLICY/RULES)You didn''t want give this
information, ok then it is your problem. But don''t complain about not
getting an answer.
We and I  in special don''t want to give an answer that is under heavy
risk of being wrong (according to  the lack of information).
Tony, this is a security related mailing list, so don''t expect to get
easy answers to unqualified questions.

If you don''t follow the support guidelines (and use your brain) you
can''t expect ANY help.

Sorry.
Alex


>Tony
>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
September
>19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
>Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
>_______________________________________________
>Shorewall-users mailing list
>Shorewall-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/shorewall-users
>  
>


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

tony wrote:
> My question was "is it possible that an infected SQL server can pierce
> Shorewall?".
Not likely, that would depend on your security-in-depth scenario. Back
when Sapphire, Slammer hit the net the probable danger was that while
the worm was propagating itself the compromised machines would become
vulnerable to DoS attacks which would produce even more havoc among the
systems that are run on a critical 24/7 daily basis. 

http://www.eeye.com/html/Research/Flash/AL20030125.html
http://www.cert.org/advisories/CA-2003-04.html
> To which it was replied if you want support follow the rules and send
> your config files. The reply is not an answer to my question. But I
> deduced that if people want to see the config files it may be possible
> so we have decided first to see if the box is compromised.
If you are allowing high risk traffic into your network, bypassing the
firewall using your own best judgment, then it it would not really be a
Shorewall issue after all. I posted a solution for that specific problem
just a short while ago about how to access the firewall using ssh with
*only* RSA authentication enabled, only accessible by the sysadmin
through a relay box....
  
> All the other SQL servers behind the firewall behave as expected. If the
> one renegade machine has some kind of malware which is getting through
> then I will post to the list the following:
> 
> WARNING - Microsoft Virus "x" can go through your firewall
> 
> and the steps we took to fix it.
Well, Microsoft Virus "x" can certainly go through your firewall,
you''re
allowing it in, aren''t you? If you put a plug on udp 1434 with
iptables/Shorewall then there''s no problem. Isn''t that the
crux of the
matter?
 
> For the moment we have a suspicion - before crying wolf we have some
> work to do.
Would be nice to hear what really happened over there...
 
> Is that OK with you guys?
It''s OK with me, but you must expect to get mixed reactions, solutions
from a security mailing list with so many different personalities, when
addressing a problem that sounds very vague to most of us here. If you
tried to ask this type of question on an OpenBSD mailing list someone
would have had to dial 911, on your behalf.....

Good luck to you


-- 
Patrick Benson
Stockholm, Sweden


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

tony wrote:
> ...
> My question was "is it possible that an infected SQL server can pierce
> Shorewall?".
> 
> To which it was replied if you want support follow the rules and send
> your config files. The reply is not an answer to my question. But I
> deduced that if people want to see the config files it may be possible
> so we have decided first to see if the box is compromised.
The correct answer to your question is "that depends", and since
it''s
not a terribly useful answer, most of us are reluctant to give it first
up.  (Hence Alex''s request for you to provide your configuration.)
> All the other SQL servers behind the firewall behave as expected. If the
> one renegade machine has some kind of malware which is getting through
> then I will post to the list the following:
> 
> WARNING - Microsoft Virus "x" can go through your firewall 
>
> and the steps we took to fix it.
That''s like posting:
	WARNING - HTTP can go through your firewall.

For those who understand what you''re talking about, it''s so
obvious that
it doesn''t need saying, and for those who don''t it''s
pointless saying it
because they won''t know what to do with the information.

Packet filters by their nature are designed to pass some traffic and
block some other traffic.  Which traffic yours is blocking and passing
is entirely up to you.

-- 
Paul
<http://paulgear.webhop.net>
--
Did you know?  Using HTML email (or "Rich Text" email) rather than
plain
text is less efficient, and makes you more vulnerable to security flaws
in your computer software.  Learn more about securing your computer at
<http://www.kb.cert.org/vuls/id/713878>.

Alexander Wilms wrote:
> ...
>>My question was "is it possible that an infected SQL server can
pierce
>>Shorewall?".
>>
>>To which it was replied if you want support follow the rules and send
>>your config files. The reply is not an answer to my question. But I
>>deduced that if people want to see the config files it may be possible
>>so we have decided first to see if the box is compromised.
>>...
>>Is that OK with you guys?
>>
>>
>>
> No, actually it is not.
>
> The issue is this: you didn''t give information needed to get a
qualified
> answer.
> ...
> If you don''t follow the support guidelines (and use your brain)
you
> can''t expect ANY help.
Or to put it another way - asking questions the smart way will get you
a more appropriate answer:
	http://www.catb.org/~esr/faqs/smart-questions.html

Here are some key points from the above that would be relevant to this
thread:
- Use meaningful, specific subject headers
- Be precise and informative about your problem
- Describe your problem''s symptoms in chronological order
- Describe the goal, not the step

The last one is the most important, IMHO - it''s about /context/.
Providing people with context, even in everyday, face-to-face
conversations, is one of the best ways to get help quickly.

--
Paul Gear, Manager IT Operations, Redlands College
38 Anson Road, Wellington Point 4160, Australia
(Please send attachments in portable formats such as PDF, HTML, or
OpenOffice.)
--
The information contained in this message is copyright by Redlands
College.  Any use for direct sales or marketing purposes is expressly
forbidden.  This message does not represent the views of Redlands
College.

tony wrote:
>Question:
>
>If I have and infected SQL server machine behind the firewall will
>requests to port 1433 still go through the firewall despite no rule to
>allow this behaviour?
>
>Thanks
>
>Tony 
>  
>
 Sorry to catch up on this late. Here is a simple answer to your question.

If you have no rules allowing outbound traffic (ie port 1433), than you 
must consider the policy file.

For certain default shorewall configurations, the policy will allow all 
traffic from a certain interface.

For example, a two interface firewall will sometimes have a default 
policy to allow all outbound traffic from the protected interface.

If this open policy is the case, then, yes, your infected server will be 
allowed by the policy to spew 1433 stuff out to the net.

If you remove the allow all policy, then, you would get log messages 
showing that a certain ip was getting blocked, because there would be no 
rule allowing such traffic.

That way, examining the logs would tell you which ip is infected.

Another simple way to tell would be to make an explicit rule like: 
"DROP:info loc net tcp 1433" (assuming loc is the interface with the 
server), which I believe (someone please correct me if I am wrong) will 
override any default policy that would allow outbound traffic from your 
server. Then again, you would just examine the logs to see which ip was 
trying to make outbound 1433 connections.

That would be the easiest way to locate your infected server. However, I 
would suggest that you never have a default allow all policy for a 
firewall interface that is hosting servers. For example, the standard 
three interface firewall has net, loc, dmz, as interfaces. As long as 
you trust your loc users, an allow all policy is reasonable to implement 
there. If you have your servers in the dmz, then as they usually only 
should have certain types of outbound traffic, you should not have an 
allow all outbound traffic policy, and you should make explicit rules to 
define what types of outbound traffic the servers are allowed. In this 
type of configuration a hacked server trying to make outbound 
connections will be logged.

For example, behind a firewall I had a server hacked into that attempted 
to run an irc server, and I immediately noticed the server''s outbound 
irc attempts and knew its ip, as the default policy for the dmz was to 
not allow outbound traffic and no rules to allow irc were implemented.

I am not sure why other people had so much trouble providing this 
information. But, as many people suggested, if my above answer does not 
make sense, then by posting your config files, the reason that your 
server was allowed to spew outbound 1433 traffic could be quickly shown, 
and suggestions for configuration modification could be made to easily 
find your infected server and block its malicious traffic.

Regards,
Alex Martin
http://www.rettc.com





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf