神刀安全网

Linux Tutorial: Postscreen offers superior load mitigation and spam handling in the Postfix…

Linux Tutorial: Postscreen offers superior load mitigation and spam handling in the Postfix... Make Your Servers Invisible!

I’m delighted to be able to offer the first chapter of my brand new book, Linux Server Security: Hack and Defend , for free as a downloadable PDF. Chapter One, entitled Invisibility Cloak , walks you through making your servers invisible online to the extent that not only can you successfully hide your services but even your servers themselves aren’t discoverable on the network.

Despite removing the most common attack vectors you might be surprised to discover that you can still access your servers over the Linux® command line remotely and continue to run key production services. The chapter walks you through, step by step, the obfuscation of your servers so that their attack surfaces are significantly reduced and they are less prone to attacks. Click the link below to download the free PDF.

Linux Server Security: Hack and Defend by Chris Binnie

Learn how to attack and defend the world’s most popular web server platform

Linux Server Security: Hack and Defend presents a detailed guide for experienced admins, aspiring hackers and other IT professionals seeking a more advanced understanding of Linux security. Written by a 20-year veteran of Linux server deployment this book provides the insight of experience along with highly practical instruction.

The topics range from the theory of past, current, and future attacks, to the mitigation of a variety of online attacks, all the way to empowering you to perform numerous malicious attacks yourself (in the hope that you will learn how to defend against them). By increasing your understanding of a hacker’s tools and mindset you’re less likely to be confronted by the all-too-common reality faced by many admins these days: someone else has control of your systems.

  • Master hacking tools and launch sophisticated attacks: perform SQL injections, deploy multiple server exploits and crack complex passwords.
  • Defend systems and networks: make your servers invisible, be confident of your security with penetration testing and repel unwelcome attackers.
  • Increase your background knowledge of attacks on systems and networks and improve all-important practical skills required to secure any Linux server.

The techniques presented apply to almost all Linux distributions including the many Debian and Red Hat derivatives and some other Unix-type systems. Further your career with this intriguing, deeply insightful, must-have technical book. Diverse, broadly-applicable and hands-on practical, Linux Server Security: Hack and Defend is an essential resource which will sit proudly on any techie’s bookshelf.

Download: Linux Server Security: Hack and Defend by Chris Binnie – Chapter One – Invisibility Cloak

©2016 Chris Binnie – please do not copy content without permission.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

Click to return to many more free tutorials on Linux-Server-Security.com

Empower SMTP With Postscreen

©2016 Chris Binnie

I recently read with interest that the powerful MTA (Mail Transfer Agent) that is Postfix ( http://www.postfix.org ) introduced a relatively new addition to its load mitigation and anti-Spam arsenal. As from version 2.8 onwards Postfix has been incorporating what it refers to as “postscreen”.

In previous versions of the Mail Server only one connection could be processed by each SMTP system process before moving on to the next one in the queue. That’s far from ideal when you’re processing tens if not hundreds of thousands of e-mails every day I’m sure that you will agree. For superior efficiency a single postscreen process can handle multiple connections simultaneously and act as filter, deciding which e-mail is valid and which might be sent from Spambots, before passing the job onto an SMTP process.

The theory goes that with less impact from Spambots there are more resources available to process valid e-mail, much more efficiently. This in turn means you have more capacity available, or bang for your buck, when it comes to your hardware. What piqued my interest about postscreen was the fact that Postfix already makes sterling efforts to mitigate server load conditions impeccably.

Automagically this well-designed MTA deploys its own “stress adaptive behaviour“ when it’s feeling the pressure. This takes the form of a quick daemon restart (without dropping existing network connections) and the lowering in its tolerance of who and how other machines are allowed to connect and deliver e-mail to it. This super-clever and automatically configured changes in settings acts simply as a temporary measure until Postfix can feel that its cortisol has decreased to a healthier level.

Amazed as I was when first reading about this type of reaction to heavy load generated by a deluge of e-mail, whether it be from an attack or a busy Mail Server which had been suffering a network outage coming back online again, I was equally impressed by postscreen’s functionality. Let’s have a look into how it can help you now.

Ham Not Spam

As demoralising a statement as it is, on our beloved Internet, most e-mail sent today is Spam (unsolicited) and not Ham (solicited). Apparently most of the Spam which is generated today is sourced from malware being installed on desktop and laptops. These machines having been compromised unwittingly by a download or an unsuspecting click in the past by the less-technical user in most cases.

Sadly those in-the-know have estimated that this scenario will continue for the foreseeable future and as a result the onus to provide solutions ultimately falls on the Internet’s e-mail infrastructure. According to the Postfix documentation it became obvious that without some form of inbuilt mechanism to cope with the continual waterfall of Spam then Mail Servers would spend significantly more time refusing to process e-mail than actually accepting it.

As you delve further into how postscreen works you realise how difficult a task it is to circumvent the pressures from barrages of inbound Spam. Postfix’s programmers realised that the most efficient way of detecting whether an e-mail should be classified as Spam or Ham was to make the decision based on a single criteria. In other words if any of a number of tests failed, the e-mail is binned.

To achieve such efficiency the key premise of postscreen is one of temporary whitelisting. Thankfully Zombie machines (any compromised machine infected via numerous methods) are in a race against time and so that they can cause as much damage as possible before they are blacklisted by ISPs and Spam lists. This means that they tend to rush through e-mail delivery and try to hurry MTAs along, making them suspicious with less-than-polite and badly ordered SMTP commands. Postfix works on two main criteria to identify Zombie machines; namely if the connecting IP Address is found to be blacklisted and secondly if it hurries through the SMTP process with malformed commands. The Postfix docs make the point that inspecting the content of an e-mail isn’t a good way of making a decision using one measurement, there’s simply too many factors and as a result it requires relatively high levels of processing power.

Some of the single-measurement tests which Postfix employs inevitably delay the processing of e-mails by a few seconds however clearly the main objective is to minimise these. As we’ve just mentioned the inspection of hurried SMTP commands, such as the details relating to the “helo”, the sender and the recipient, are used in the well-considered tests. Before reaching that stage however whitelists (and blacklists) are queried too. We’ll have a closer look at these in a moment.

Defence Overview

First what about a quick summary of which parts of an e-mail transaction that postscreen deals with in order to help with unsolicited e-mail? The Postfix docs refer to a “multi-layer defence”, all designed with efficiency in mind.

In order to keep around 90% of Spam at arm’s length, at the outside layer, the clever postscreen makes light work of repelling Zombie machines and Spambots. These “inexpensive” defences make a massive difference in the effort which a Mail Server needs to undertake.

The second layer is one concerned with SMTP-level checks thanks to configured policies or Milter (a portmanteau of “Mail Filter”) applications such as DKIM (Domain Keys Identified Mail) implementations which check the identity of a sender amongst other things.

The third part is more concerned about the content of e-mails and their headers. The docs say that through a number of options Postfix “can block unacceptable attachments such as executable programs, and worms or viruses with easy-to-recognize signatures.”

Finally we can pipe our e-mail through Postfix, and beyond, into well-known content filtering applications. One example might be the popular Spamassassin which employs clever techniques, such as Bayesian Probability, to determine if an e-mail is Ham or Spam.

I like the simplicity and considered approach of this particular statement from the docs: “The general strategy is to use the less expensive defenses first, and to use the more expensive defenses only for the spam that remains.”

In the above loosely-formed layered model the vigilant postscreen is deployed within the first two layers.

Your Machines

Clearly you need the ability to configure settings so that your own valid machines can always connect without delays or with the risk of them being spurned by your trusty Mail Server. You can adjust the “postscreen_access_list” option to affect those machines which are immediately whitelisted. Usually this particular option will simply default to the “permit_mynetworks” option which might seem familiar thanks to the fact that it essentially just points at the “mynetworks” option. Anybody who has ever looked inside the main config file, “/etc/postfix/main.cf”, will have probably spotted that option or indeed added their own IP Addresses to it.

To see how whitelisting our own machines works here’s a reminder of the greeting which SMTP uses; it usually looks something like this:

220 mail.chrisbinnie.tld ESMTP server ready Tue, 11 Nov 2121 11:11:11 +0100

By adding an IP Address or address range to “mynetworks” or adding a “permit” entry to “postscreen_access_list” (which we’ll look at it a moment) the sending machine won’t be grilled by Postfix either before or after the 220 “greeting” tests. Safe passage is therefore assured.

If you wanted to add either blacklisted or whitelisted IP Addresses and ranges to your Postfix build then you would add them to the “/etc/postfix/postscreen_access.cidr” file and then point your “main.cf” file at that location. Obviously you can adjust that filename if you need to. The “.cidr” file extension means a file format which the flexible MTA will look for Classless Inter-Domain Routing (CIDR) formatted address ranges within. The Postfix docs offer us the following example for our “.cidr” file:

# Rules are evaluated in the order as specified.
# Blacklist 192.168.* except 192.168.0.1.
192.168.0.1           permit
192.168.0.0/16       reject

Listing One: How the “postscreen_access.cidr” file looks using the CIDR notation for networks

Hopefully you agree that example speaks volumes (and follows the clarity of much of the well-written Postfix docs). Hopefully you can tailor it to suit your needs.

Next we make a small change to our “/etc/postfix/main.cf” file. Note the comma separation because we want to also include the contents of “mynetworks” by using the “permit_mynetworks” option.

postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr

A quick refresh of our config, cleverly performed without resetting all of the current connections, is now needed to set any changes live. We can achieve just that by running this simple command:

# postfix reload

There’s more to this approach than meets the eye; we don’t just receive whitelist and blacklist content options. This well-considered MTA also offers us configurable actions on how to react to a blacklisted machine. There are no whitelisted “actions” however because we always want such a host to move forwards, one that has been cleared to proceed, onto an SMTP process of its own. In your log files you will see an entry for each result, including a hostname and a port number, either referenced as “WHITELIST” or “BLACKLIST”.

The settings which you can affect for a blacklisted machine are as we can see in Table One.

Action

Description

ignore

The is the default action and here failures are of little consequence. As other tests will also be applied you could use this setting for testing, generating lots of logs without actually blocking e-mails and upsetting your users.

enforce

Postfix will continue with its additional testing if you use this option. Here we respond with the all-too-common SMTP error 550. One MTA’s exa mple error 550 response might be “550 Requested action not taken: mailbox unavailable” which is often seen for Spam.

You should be aware that there are many 550 error statements made by MTAs such as “relay not permitted”.

Note that if senders generate enough error 550s they may end up on a blacklist (or two) which could affect their ability to send e-mail globally.  For future reference Postfix will dutifully log the “helo”, the sender and the intended recipient for reference.

drop

Here we get much more medieval and simply kill the connection as soon as it arrives. Postfix will respond with a 521 SMTP error code. This draconian error code states something along the lines of “mail.chrisbinnie.tld does not accept mail (see RFC1846)”.

Table One: Available actions for machines which are blacklisted, whitelisted machines go unhindered

The options shown in Table One apply to both permanent blacklisted machines and also those picked up during the tests performed by Postfix before the greeting takes place. Each is tested for again and repeated whenever the sending machine returns at a later date. Additionally if third party Realtime BlackLists (RBLs), such as the powerful SpamHaus ( https://www.spamhaus.org ),  are used and give a negative warning then they also apply. As you can see it’s quite possible to both log and test any changes you make to your configuration and at the same time limit the resources used.

Post Salutation

We’ve looked at Postfix tests pre-greeting, let’s move onwards through the chain and explore the available tests after the greeting. A reminder that by limiting how many machines make it to this stage is of significant value to a Mail Server’s resource capacity. Here our trusty Postfix performs what it calls a series of “deep protocol” tests which are disabled by default for a variety of reasons. One such reason is the fact that the tests are more brutal than those which you might be used to seeing with RBLs. Equally they also come with some limitations which should be understood first.

One key limitation is that a sender machine has to connect to your Mail Server all over again after passing the “deep protocol” tests before it can send its e-mail. Expiration times can be upped in order to allow the machine to return again much later on but obviously this isn’t entirely ideal. Bear in mind however the popularity of “greylisting” which defers e-mail deliveries to detect if a sender is in a frenzied rush and willing to return again in a few minutes or not. The deferral after the “deep protocol tests” is far from alien to Mail Servers and works along these lines. Remember that once an IP Address has been whitelisted then when the sender machine returns they will be let straight through to an SMTP process. This unfettered access will be allowed for a relatively lengthy period of time (we’ll look at that shortly in detail) so this deferral only affects the initial connection.

Another limitation is the lack of compatibility, which sadly means that for the time being you should disable “deep protocol tests” if you need it available on TCP port 25, with the “AUTH”, “XCLIENT”, and “XFORWARD” commands. Additionally you shouldn’t enable RBLs which don’t play nicely with servers running on either dial-up or residential networks and reject those IP Address ranges.

Pipelining

Let’s look at three post-greeting tests now, starting with the “pipelining test”.

If you’re at all familiar with networking you will know that “half duplex” means traffic flowing in one direction and “full duplex” means simultaneous traffic flows in both directions. Clearly the difference in bandwidth between the two is significant. This is compounded if you factor in the delays for response/receive times in addition to the data throughput.

The term “pipelining” also relates to concurrency of sorts. A well-used example is where a manufacturing plant’s assembly line allows greater efficiency thanks to the output of certain processes being the input of another process, which might be next in the line on the conveyor belt. Apparently even if there are some dependencies, and therefore delays, time-savings can usually be achieved.

One of the challenges which Postfix faces is that SMTP is a half duplex protocol by design. Although Postfix itself advertises support for pipelining, where senders don’t have to necessarily wait for a response prior to continuing with a conversation, the excellent postscreen does not. Amongst the SMTP commands included for this functionality are “ RSET” , “ MAIL” , “ RCPT” , or an encoded message. This was introduced by RFC 1854 (Request For Comments https://www.ietf.org/rfc/rfc1854.txt ) in 1995 and then refreshed RFC 2197 ( https://www.ietf.org/rfc/rfc2197.txt ) in 1997. Despite being an old design what’s also clever about adding this capability to Mail Servers is the addition of allowing the server to defer responses so long as the sender is still submitting new requests. According to the documentation provided by the bulletproof “qmail” server ( http://cr.yp.to/qmail.html ) this explanation applies:

“The server must never wait for client input unless it has first “flushed” all pending responses; and it must send responses in the correct order. It is the client’s responsibility to avoid deadlock.”

Despite the benefits it brings as we said pipelining is disabled by default for postscreen and as a result senders are not allowed to send multiple commands. However if you switch on the option "postscreen_pipelining_enable” then postscreen will vigilantly stay alert checking for any Zombie machines that send multiple commands.

This option can add another test and also improve your logging by including the fact that pipelining was attempted. The manual shows the logging syntax which would be written to your log files as so:

COMMAND PIPELINING from [address]:port after command: text

Such a log entry would tell us that the sender machine sent many, and not just one, commands without waiting for the MTA to respond.

Invalid SMTP

Some nefarious Spambots will attack your Mail Server via an open proxy. One such telltale sign of a proxy being used is that non-SMTP commands bleed into the conversation between the Mail Server and the sender such as the “CONNECT” command. We can explicitly log and reject these invalid commands using the “postscreen_forbidden_commands” option. Apparently this function will additionally look out for commands which look like a message’s header, sent in the wrong part of the conversation. This error condition can be common if the sending machine keeps on transmitting data having ignored postscreen’s rejections. The Postfix docs offer this as the logging syntax which you would expect to discover in your logs after such an event has occurred:

NON-SMTP COMMAND from [address]:port  after command: text

You Say LF, I Say CR

Another post-SMTP-greeting test is referred to as the “b are newline test“. The structure of SMTP commands are certainly simple, and usually very short, however they must be adhered to in order to make sense. A long standing pain for Sysadmins involved the differences between Carriage Returns and Line Feeds, known as “<CR>” and “<LF>” respectively in SMTP. These otherwise invisible characters (which are supposed to seen by software but not by humans) have caused great consternation in the past thanks to different support from varying Operating Systems. For example Unix-type machines generally use Line Feeds, Macs Carriage Returns and just to keep everyone on their toes Windows uses “<CR><LF>”, with the Carriage Return always being used first.

For one reason or another the SMTP protocol terminates its new lines with “<CR><LF”, Windows style, and if a Spambot deviates from adhering to such rules then it fails this test. This needs enabled from its default in order to use it. Here’s how such an occurrence appears in Postfix’s logs:

BARE NEWLINE from [address]:port after command

If you want to catch out sender machines which aren’t playing nicely then you simply add this line to your config file which enables it:

postscreen_bare_newline_enable = yes

Failure To Comply

Let’s look at what happens when a sender machine fails the post-greeting tests. Along a similar vein to pre-greeting tests we can see a familiar set of actions in Table Two.

Action

Description

ignore

Ignoring the failure of this particular test is the default for the post-greeting “bare newline” test.

enforce

By default pipelining enforces its actions if a sender machine fails this test. It will then reject connections with a 550 SMTP response. This test is run all over again if the machine returns later on.

drop

If the mighty Postfix picks up any non-SMTP commands then a 521 SMTP error is promptly sent to the connecting machine. This test is repeated upon each connection. You can adjust settings away from the defaults (“CONNECT”, “GET” and “POST”) by altering the  “smtpd_forbidden_commands” option.

Table Two: What actions Postfix undertakes if post-greeting failures occur

Other SMTP Scenarios

There are clearly a number of other errors generated by MTAs which occur due to varying scenarios. In Table Three we can see the log entries which you might expect to see when these errors are generated from differing scenarios.

Log Entry

Description

HANGUP after time from [address]:port in test name

This will show up in your logs if the connecting machine dropped its connection for some reason. You can tell how many seconds after inception it occurred with “time”. You might be surprised to hear that no penalties apply if a machine is caught out hanging up. Postfix continues to allow that machine to progress with other tests afterwards.

COMMAND TIME LIMIT from [address]:port after command

You can specify how long a connection should be allowed to run by using the “postscreen_command_time_limit” option before dropping it.

COMMAND COUNT LIMIT from [address]:port after command

With this option you can avoid a barrage of SMTP commands and specify how many are allowed within a particular session:

“postscreen_command_count_limit”.

COMMAND LENGTH LIMIT from [address]:port after command

Set a strict per-command length limit as specified using the “line_length_limit” option.

NOQUEUE: reject: CONNECT from [address]:port: too many connections

Should the situation arise when an SMTP client requests too many resources from our server in too short a period of time then we can reject the connection using a SMTP 421 error. This error relates to too many messages or connections (concurrency).

NOQUEUE: reject: CONNECT from [address]:port: all server ports busy

This is very similar to the above error, also dealing with concurrency issues.

Table Three: Other Postfix SMTP errors and how they are logged to our log files

What Success Looks Like

Rather than perpetually focussing on the negative what do you think out logs look like when an inbound e-mail passes all of the tests you throw at it? This doesn’t include machines specifically whitelisted but rather machines which have passed your SMTP tests before proving successful.

PASS NEW [address]:port

When such a happy event occurs our trusting MTA then writes an entry inside its temporary whitelist and our Mail Server remains accessible to the IP Address according to the Time To Live (TTL) options which we’ll look at now. Some relate to the actions which we just examined as you will see.

The “postscreen_bare_newline_ttl” usually defaults to thirty days and postscreen will remember the results of such a test for that period. This can be adjusted to your preference with relative impunity.

One of the key concepts behind RBLs is that the information which they contain is current and therefore useful. You may trust some more than others for validity however. You can change the default, one hour, setting to some other time measurement such as a number of seconds, minutes, days or weeks with “postscreen_dnsbl_max_ttl” and the “postscreen_dnsbl_ttl”. In case it causes confusion the latter option was only available in versions 2.8 to 3.0 and is replaced by the former in version 3.1.

There may also be circumstances when a response from an RBL offers a very high or low TTL. We can affect the minimum TTL with “postscreen_dnsbl_min_ttl” which usually defaults to sixty seconds to keep the number of requests down. Note that if there’s sizeable TTL sent back then this will override the “postscreen_dnsbl_max_ttl” option which we just covered..

To keep our Postfix server’s load down we can cache the results of successfully passing our pre-greeting tests. Usually that sits at a day and can be changed with the “postscreen_greet_ttl”. Such a change could be very useful, especially if there aren’t many offenders changing their behaviour too frequently.

If you wanted to change the length of time that we remember if machines aren’t found to be bombarding our Mail Server with non-SMTP commands then you can alter this option, “postscreen_non_smtp_command_ttl”, which is usually thirty days by default. If you infrequently see this error then it prevents unnecessary lookups if you increase this value.

Finally if you’re not expecting your initial findings to change, in respect of your pipelining tests, then you can increase the thirty days by default with this option ”postscreen_pipelining_ttl”. Potentially this can also lessen unnecessary lookups.

Danger, Will Robinson

The docs make an important point about the use of postscreen. It relates to Mail Clients, by that I mean software such as Thunderbird or Evolution for example which are also known as MUAs (Mail User Agents). They allow you to pick up inbound e-mails and send outbound e-mails. With the use of postscreen however you need to avoid using TCP port 25 because you will definitely encounter issues. Essentially that SMTP port is for inbound e-mail only when postscreen is running.

The outside world uses your MX (Mail Exchanger) records, declared in your DNS, to find your Mail Server in the first place and they then start their conversation with TCP port 25. For outbound e-mail however your user’s E-mail Client should instead use the Submission Service (which sits listening on TCP port 587) to firstly authenticate, usually, and then send their e-mails through. You may have seen TCP port 465 in use (known as the “SMTPS” port in order to allow secure, SSL-based SMTP transactions) which was used more in the past. TCP port 587 is known as  “SMTP-MSA” to specifically allow end users to send outbound e-mail. There’s a number of creative workarounds to this scenario however setting up your daemon ports differently is for another day’s discussion.

EOF

We’ve covered a good deal of ground whilst looking at the venerable postscreen. Its raison d’etre is to reduce volumes of Spam at every level of the SMTP transaction and dutifully remember senders that have successfully passed its tricky tests en route so that it can forward their e-mails much quicker next time.

Effective, efficient and robust there’s little doubt that even for small volumes of e-mail I would tune postscreen to suit my user’s e-mail needs. Despite leaving many a stone unturned for what is a massive subject area hopefully now that you are equipped with a decent overview of postscreen you can also take advantage of its many features and choose Ham over Spam.

Linux Tutorial: Postscreen offers superior load mitigation and spam handling in the Postfix... Make Your Servers Invisible!

I’m delighted to be able to offer the first chapter of my brand new book, Linux Server Security: Hack and Defend , for free as a downloadable PDF. Chapter One, entitled Invisibility Cloak , walks you through making your servers invisible online to the extent that not only can you successfully hide your services but even your servers themselves aren’t discoverable on the network.

Despite removing the most common attack vectors you might be surprised to discover that you can still access your servers over the Linux® command line remotely and continue to run key production services. The chapter walks you through, step by step, the obfuscation of your servers so that their attack surfaces are significantly reduced and they are less prone to attacks. Click the link below to download the free PDF.

Linux Server Security: Hack and Defend by Chris Binnie

Learn how to attack and defend the world’s most popular web server platform

Linux Server Security: Hack and Defend presents a detailed guide for experienced admins, aspiring hackers and other IT professionals seeking a more advanced understanding of Linux security. Written by a 20-year veteran of Linux server deployment this book provides the insight of experience along with highly practical instruction.

The topics range from the theory of past, current, and future attacks, to the mitigation of a variety of online attacks, all the way to empowering you to perform numerous malicious attacks yourself (in the hope that you will learn how to defend against them). By increasing your understanding of a hacker’s tools and mindset you’re less likely to be confronted by the all-too-common reality faced by many admins these days: someone else has control of your systems.

  • Master hacking tools and launch sophisticated attacks: perform SQL injections, deploy multiple server exploits and crack complex passwords.
  • Defend systems and networks: make your servers invisible, be confident of your security with penetration testing and repel unwelcome attackers.
  • Increase your background knowledge of attacks on systems and networks and improve all-important practical skills required to secure any Linux server.

The techniques presented apply to almost all Linux distributions including the many Debian and Red Hat derivatives and some other Unix-type systems. Further your career with this intriguing, deeply insightful, must-have technical book. Diverse, broadly-applicable and hands-on practical, Linux Server Security: Hack and Defend is an essential resource which will sit proudly on any techie’s bookshelf.

Download: Linux Server Security: Hack and Defend by Chris Binnie – Chapter One – Invisibility Cloak

©2016 Chris Binnie – please do not copy content without permission.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

Click to return to many more free tutorials on Linux-Server-Security.com

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » Linux Tutorial: Postscreen offers superior load mitigation and spam handling in the Postfix…

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址