Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 1 subscriber
  • Views 2293 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

CBL - have we been hacked

glynd
We are running ASG 8.304.
We have been black-listed and CBL points to huge amounts of email being sent from us. We have done all the checks we can to see if one of the 3 linux boxes is the culprit but none own up. There is nothing in the SMTP log showing anything other than legal mail going out. We have even turned off all the machines except the mail server and the ASG and still mail is going out (from what we are told by our ISP.
ASG is the SMTP proxy and only the mail server can attach to port 25, none of the internal machines can telnet to anything outside on port 25 and even not even to the firewall from the inside.
Is there a way that the ASG can be the culprit and is sending all the spam and is not leaving any trace of its actions? Where should l look to see if something like this is happening?

TIA
Glyn


This thread was automatically locked due to age.
  • 0
    If you've misconfigured the SMTP proxy in Astaro, then yes, it's possible.

    Please post screenshots of the SMTP config pages.

    Running 
    tcpdump dst port 25
    on the firewall might be a good idea as well.

    Barry
  • 0 in reply to BarryG
    Hi Barry,
    Thanks for the help here. Here are the screenshots.
    The remaining Firewall entries allows FTP, HTTP and DNS from the internal network to "any"

    I am sure I have made a mistake [:@]

    TIA
    Glyn
  • 0
    What services are "neon" and "Connector" used in DNATs?

    It also would be interesting to see the 'Exceptions' tab and the 'Transparent' section of the 'Advanced' tab.

    I think that Firewall rules 1 and 6 have no effect.  1 because it is a duplicate of a hidden rule made by WebAdmin when you enable the SMTP Proxy.  6 because the only reason an internal device would connect with the WAN interface would be because you had a Full NAT that, for example, allowed internal users to reach an internal web server via your public IP.  Otherwise, 'Internal (Network) -> Any -> ADSL (Address)' traffic would be default dropped or otherwise go off to bit heaven.

    I suggest that you restore a config backup from before this problem began.  Did that fix the problem?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Hi Guys,

    Again thanks for the help. I have in the mean time , reinstalled the ASG 8 with the intention of adding the configuration I saved. My thinking was that the ASG had been compromised and there may be problem even with a corrected configuration.
    I have done this but when I try to connect from Chrome I get this:

    Invalid Server Certificate
    You attempted to reach 192.168.1.101, but the server presented an invalid certificate.
    You cannot proceed because the website operator has requested heightened security for this domain.

    I can't seem to get past this.

    How can I sort this out please.

    I will then be able to send the other screenshots you asked for.

    TIA
    Glyn
  • 0 in reply to glynd
    Managed to get past the issue with the certificate. I had to use another machine with IE7 and uploaded the configuration.

    I have attached the rest of the firewall rules.

    I have attached the transparent screen-shot. as you can see there is nothing selected, is this correct?

    There are no exceptions 

    I found that it was possible to telnet to any IP address in the internet from any internal machine. I have now added a rule to stop that. Could this be a cause of the attack? For this reason I have not gone back to an older configuration.

    The DNAT of neon and connection is to allow us to get to the email server from outside on port 8000 and 465 to get email. Is this a hole?

    What do you suggest from here?

    TIA
    Glyn
  • 0 in reply to glynd
    Hi Bob,

    I see you suggest the rule 6 is redundant, but before I implemented this, connection to port 25 can be made from internal machines to the internet which I think is a risk.
    Do I understand correctly?
  • 0 in reply to glynd
    Hi Bob,

    Maybe I misunderstood. Is this the reason that (see screen shot) that internal machines can get to the internet?

    I am splitting SMTP from the rest of the internet traffic to see what is going on with the spamming. However I have had this masquerade in place pointing to the primary external address from the beginning.

    Don't I need this?
  • 0
    The DNAT of neon and connection is to allow us to get to the email server from outside on port 8000 and 465 to get email. Is this a hole?

    465 is SMTP-SSL, so that bypasses the SMTP Proxy.  But, if the traffic were being relayed off your email server, it would show up in the Astaro SMTP log.

    I found that it was possible to telnet to any IP address in the internet from any internal machine. I have now added a rule to stop that.

    They could telnet on port 25?  I don't see a Firewall rule that would allow that, so this doesn't make sense to me.

     Could this be a cause of the attack? For this reason I have not gone back to an older configuration.

    You can always make a new backup before restoring an older configuration.  I was looking for a quick fix and a test of the cause.

    The masq rule just manages the NAT between the public IP and your private, internal IPs.  The Firewall rules determine whether traffic is allowed out.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Hi, Rule #6 on firewall1.jpg should probably be changed to ANY destination.

    Barry
  • 0
    Also, Typhoon should not need a Masquerade rule for SMTP if it is using Astaro's mail relay.

    Barry
Cookie Information Banner